![Projet de fin d’études Page 10
Table des figures
Figure 1 : Cycle de vie d’un projet Scrum [N6]..............................................................................25
Figure 2 : Diagramme de Burndown Chart [N7].............................................................................27
Figure 3 : Équipe et rôles..............................................................................................................33
Figure 4 : Découpage des releases en sprints..................................................................................37
Figure 5 : Planification des sprints ................................................................................................37
Figure 6 : Planning de réalisation du projet....................................................................................38
Figure 7 : Diagramme de cas d’utilisation global............................................................................39
Figure 8 : Diagramme de cas d’utilisation du premier sprint............................................................47
Figure 9 : Diagramme de séquences système du cas d’utilisation «s’authentifier»............................49
Figure 10 : Diagramme de séquences système du cas d’utilisation «s’inscrire»................................50
Figure 11 : Diagramme de séquences système du cas d’utilisation «Récupérer mot de passe»...........52
Figure 12 : Diagramme de séquences système du cas d’utilisation «Changer mot de passe»..............53
Figure 13 : Diagramme de cas d’utilisation de «Gérer mon profil»..................................................54
Figure 14 : Diagramme de séquences système du cas d’utilisation «Afficher mon profil»..................55
Figure 15 : Diagramme de séquences système du cas d’utilisation «Modifier mon profil».................56
Figure 16 : Diagramme de cas d’utilisation du cas «Gérer catégories boutiques».............................56
Figure 17 : Diagramme de séquences système du cas d’utilisation «Lister catégories boutiques»......57
Figure 18 : Diagramme de séquences système du cas d’utilisation «Ajouter catégorie boutiques».....58
Figure 19 : Diagramme de séquences système du cas d’utilisation «Modifier catégorie boutiques» ...60
Figure 20 : Diagramme de séquences système du cas d’utilisation «Supprimer catégorie boutiques».61
Figure 21 : Diagramme de cas d’utilisation du cas «Gérer vendeurs»..............................................61
Figure 22 : Diagramme de séquences système du cas d’utilisation «Lister vendeurs» .......................62
Figure 23 : Diagramme de séquences système du cas d’utilisation «Supprimer vendeur» ..................63
Figure 24 : Diagramme de classes participantes du cas d’utilisation «s’authentifier» ........................64
Figure 25 : Diagramme de séquences détaillées du cas d’utilisation «s’authentifier».........................64
Figure 26 : Diagramme de classes participantes au cas d’utilisation «s’inscrire»...............................65
Figure 27 : Diagramme de séquences détaillées du cas d’utilisation «s’inscrire»...............................65
Figure 28 : Diagramme de classes participantes au cas d’utilisation «Afficher mon profil»................66
Figure 29 : Diagramme de séquences détaillées du cas d’utilisation «Afficher mon profil»................66
Figure 30 : Diagramme de classes participantes au cas d’utilisation «Modifier mon profil»...............67
Figure 31 : Diagramme de séquences détaillées du cas d’utilisation «Modifier mon profil»...............67
Figure 32 : Diagramme de classes participantes au cas d’utilisation «Lister catégories boutiques».....68
Figure 33 : Diagramme de séquences détaillées du cas d’utilisation «Lister catégories boutiques».....68
Figure 34 : Diagramme de classes participantes au cas d’utilisation «Ajouter catégorie boutiques»...69
Figure 35 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter catégorie boutiques»...69
Figure 36 : Diagramme de classes participantes au cas d’utilisation «Modifier catégorie boutiques»..70
Figure 37 : Diagramme de séquences détaillées du cas d’utilisation «Modifier catégorie boutiques».70
Figure 38 : Diagramme de classes participantes au cas d’utilisation «Supprimer catégorie boutiques»
...................................................................................................................................................71
Figure 39 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer catégorie boutiques»
...................................................................................................................................................71
Figure 40 : Diagramme de classes participantes au cas d’utilisation «Lister vendeurs» .....................72
Figure 41 : Diagramme de séquences détaillées du cas d’utilisation «Lister vendeurs» .....................72
Figure 42 : Diagramme de classes participantes au cas d’utilisation «Supprimer vendeur»................73
Figure 43 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer vendeur»................73
Figure 44: Diagramme de classes global du premier sprint..............................................................74
Figure 45 : Interface d’authentification..........................................................................................75
Figure 46 : Interface d’inscription .................................................................................................76](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-10-320.jpg)
![Projet de fin d’études Page 12
Figure 97 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter boutique aux favoris» 121
Figure 98 : Diagramme de classes participantes au cas d’utilisation «Lister produits boutique»....... 122
Figure 99 : Diagramme de séquences détaillées du cas d’utilisation «Lister produits boutique»....... 122
Figure 100 : Diagramme de classes participantes au cas d’utilisation «Consulter produit».............. 123
Figure 101 : Diagramme de séquences détaillées du cas d’utilisation «Consulter produit».............. 123
Figure 102 : Diagramme de classes global du deuxième sprint ...................................................... 124
Figure 103 : Interface du cas «Lister boutiques» .......................................................................... 125
Figure 104 : Interface du cas «Paramétrer ma boutique».............................................................. 126
Figure 105 : Code source de la méthode de test du cas «Verrouiller boutique» ............................... 127
Figure 106 : Interface de résultat du test du cas «Verrouiller boutique» ......................................... 127
Figure 107 : Code source de la méthode de test du cas «Paramétrer ma boutique»......................... 128
Figure 108 : Interface de résultat du test du cas «Paramétrer ma boutique» .................................... 128
Figure 109 : Code source de la méthode de test d’ajout d’un produit aux favoris ............................ 129
Figure 110 : Interface de résultat du test d’ajout d’un produit aux favoris....................................... 129
Figure 111 : Code source de la méthode de test de confirmation d’une boutique............................. 130
Figure 112 : Interface de résultat du test de confirmation d’une boutique ....................................... 130
Figure 113 : Diagramme de Burndown Chart du sprint 2 .............................................................. 131
Figure 114 : Diagramme de cas d’utilisation du troisième sprint.................................................... 137
Figure 115 : Diagramme de cas d’utilisation : Gérer les clients ..................................................... 138
Figure 116 : Diagramme de séquences système du cas d’utilisation «Lister les clients».................. 138
Figure 117 : Diagramme de séquences système du cas d’utilisation «Supprimer client».................. 139
Figure 118 : Diagramme de cas d’utilisation : Gérer mes commandes............................................ 140
Figure 119 : Diagramme de séquences système du cas d’utilisation «Lister mes commandes»......... 140
Figure 120 : Diagramme de séquences système du cas d’utilisation «Modifier état commande»...... 141
Figure 121 : Diagramme de cas d’utilisation : Gérer les commandes ............................................. 142
Figure 122 : Diagramme de séquences système du cas d’utilisation «Lister les commandes»........... 142
Figure 123 : Diagramme de séquences système du cas d’utilisation «Afficher les statistiques de ma
boutique».................................................................................................................................. 143
Figure 124 : Diagramme de séquences système du cas d’utilisation «Afficher les statistiques de la
place de marché»....................................................................................................................... 144
Figure 125 : Diagramme de classes participantes au cas d’utilisation «Lister les clients»................ 145
Figure 126 : Diagramme de séquences détaillées du cas d’utilisation «Lister les clients»................ 145
Figure 127 : Diagramme de classes participantes au cas d’utilisation «Supprimer client»................ 146
Figure 128 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer client»................ 146
Figure 129 : Diagramme de classes participantes au cas d’utilisation «Lister mes commandes»....... 147
Figure 130 : Diagramme de séquences détaillées du cas d’utilisation «Lister mes commandes»....... 147
Figure 131 : Diagramme de classes participantes au cas d’utilisation «Modifier état commande».... 148
Figure 132 : Diagramme de séquences détaillées du cas d’utilisation «Modifier état commande».... 148
Figure 133 : Diagramme de classes participantes au cas d’utilisation «Lister les commandes»......... 149
Figure 134 : Diagramme de séquences détaillées du cas d’utilisation «Lister les commandes»......... 149
Figure 135 : Diagramme de classes participantes au cas d’utilisation «Afficher les statistiques de ma
boutique».................................................................................................................................. 150
Figure 136 : Diagramme de séquences détaillées du cas d’utilisation «Afficher les statistiques de ma
boutique».................................................................................................................................. 150
Figure 137 : Diagramme de classes participantes au cas d’utilisation «Afficher les statistiques de la
place de marché»....................................................................................................................... 151
Figure 138 : Diagramme de séquences détaillées du cas d’utilisation «Afficher les statistiques de la
place de marché»....................................................................................................................... 151
Figure 139 : Mise en place d’un service WEB [N14].................................................................... 154
Figure 140 : Diagramme de classes participantes à l’API «Inscription client»................................ 154](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-12-320.jpg)
![Projet de fin d’études Page 13
Figure 141 : Diagramme de séquences détaillées de l’API «Inscription client»............................... 155
Figure 142 : Diagramme de classes participantes à l’API «Authentification client»......................... 155
Figure 143 : Diagramme de séquences détaillées de l’API «Authentification client»....................... 156
Figure 144 : Diagramme de classes participantes à l’API «GET catégories boutiques»................... 156
Figure 145 Diagramme de séquences détaillées de l’API «GET catégories boutiques»................... 157
Figure 146 : Diagramme de classes participantes à l’API «GET boutiques favoris»........................ 157
Figure 147 : Diagramme de séquences détaillées de l’API «GET boutiquesfavoris»....................... 158
Figure 148 : Diagramme de classes participantes à l’API «GET boutiques By Catégorie»............... 158
Figure 149 : Diagramme de séquences détaillées de l’API «GET boutiques By Catégorie»............. 159
Figure 150 : Diagramme de classes participantes à l’API «GET produits By Boutique».................. 159
Figure 151 : Diagramme de séquences détaillées de l’API «GET produits By Boutique»................. 160
Figure 152 : Diagramme de classes participantes à l’API «GET produits By Catégorie»................. 160
Figure 153 : Diagramme de séquences détaillées de l’API «GET produits By Catégorie»............... 161
Figure 154 : Diagramme de classes participantes à l’API «GET Catégories produits By Boutique».161
Figure 155 : Diagramme de séquences détaillées de l’API «GET Catégories produits By Boutique»162
Figure 156 : Diagramme de classes participantes à l’API «GET Libellé By ID Catégorie».............. 162
Figure 157 : Diagramme de séquences détaillées de l’API «GET libellé By ID catégorie».............. 163
Figure 158 : Diagramme de classes participantes à l’API «GET Produit By ID»............................. 163
Figure 159 : Diagramme de séquences détaillées de l’API «GET Produit By ID»........................... 164
Figure 160 : Diagramme de classes participantes à l’API «GET produits Favoris»......................... 164
Figure 161 : Diagramme de séquences détaillées de l’API «GET produitsfavoris»......................... 165
Figure 162 : Diagramme de classes participantes à l’API «GET Images By ID Produit»................. 165
Figure 163 : Diagramme de séquences détaillées de l’API «GET Images By ID Produit»................ 166
Figure 164 : Diagramme de classes participantes à l’API «GET Commande Client»....................... 166
Figure 165 : Diagramme de séquences détaillées de l’API «GET Commande Client»..................... 167
Figure 166 : Diagramme de classes global du troisième sprint....................................................... 167
Figure 167 : Interface du cas «Lister mes commandes».................................................................169
Figure 168 : Interface du cas «Afficher les statistiques de ma boutique» ........................................ 169
Figure 169 : Code source de la méthode de test de l’API «GET Catégories boutiques»................... 170
Figure 170 : Interface de résultat du test de l’API «GET Catégories boutiques»............................. 171
Figure 171 : Code source de la méthode de test de l’API «GET produits By Boutique»................... 171
Figure 172 : Interface de résultat du test de l’API «GET produits By Boutique»............................. 172
Figure 173 : Code source de la méthode de test du cas d’utilisation «Modifier état commande» ...... 172
Figure 174 : Interface de résultat du test de modification d’état d’une commande........................... 173
Figure 175 : Diagramme de Burndown Chart du troisième sprint .................................................. 174
Figure 176 : Architecture MVC [N21]......................................................................................... 179
Figure 177 : Répartition des tâches du premier sprint ................................................................... 181
Figure 178 : Répartition des tâches du deuxième sprint.................................................................181
Figure 179 : Répartition des tâches du troisième sprint .................................................................182
Figure 180 : Diagramme de GANTT........................................................................................... 182
Figure 181 : Diagramme de cas d’utilisation du cas «Gérer catégories produits»........................... 188
Figure 182 : Diagramme de séquences système du cas d’utilisation «Lister catégories de produits» 189
Figure 183 : Diagramme de séquences système du cas d’utilisation «Ajouter catégorie produits» ... 190
Figure 184 : Diagramme de séquences système du cas d’utilisation «Modifier catégorie produits».. 191
Figure 185 : Diagramme de séquences système du cas d’utilisation «Supprimer catégorie produits»
................................................................................................................................................. 192
Figure 186 : Diagramme de cas d’utilisation du cas «Gérer marques»........................................... 193
Figure 187 : Diagramme de séquences système du cas d’utilisation «Lister marques».................... 193
Figure 188 : Diagramme de séquences système du cas d’utilisation «Ajouter marque»................... 194
Figure 189 : Diagramme de séquences système du cas d’utilisation «Modifier marque» ................. 195](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-13-320.jpg)
![Projet de fin d’études Page 18
Introduction générale
De nos jours, le commerce électronique a pris une place considérable dans les
habitudes d’achats. Selon le site jumia.com.tn, le commerce électronique en Tunisie, ayant
5.8 millions d’internautes et un chiffre d’affaires pour l’année 2014, qui dépasse 100 millions
de dinars est considéré comme un secteur dynamique.
Selon aujourdhui.ma1, le commerce électronique au Maroc rejoint de plus en plus un rythme
précipité. «Les commerçants et e-marchands ont enregistré, durant l’année 2015, 32.8
millions d’opérations de paiement, par cartes bancaires pour un montant global de 22,9
milliards de dirhams.»[N1]
Aujourd’hui, la question est de transformer la société pour répondre aux demandes de notre
nouvelle ère du numérique. En fait, chaque client a sa spécificité, donc il est devenu de plus
en plus complexe de vendre mais aussi de garder nos clients.
Les places de marchés viennent alors pour améliorer le ciblage et la prise de contact avec les
clients, où qu’ils soient localisés et tendent de plus en plus à augmenter la compétitivité des
entreprises. Elles permettent ainsi d’offrir aux vendeurs une opportunité leur permettant de
diversifier leurs canaux de ventes, augmenter leur chiffres d’affaires, améliorer leur
perception à l’égard des consommateurs et renforcer la visibilité de leurs produits sur le web.
«La place de marché, ou marketplace, est un support mettant en relation un acheteur et des
vendeurs. La place de marché intervient donc comme un intermédiaire entre la demande de
l’acheteur et l’offre proposée par les commerçants en échange d’une commission.»[N2]
C’est dans ce cadre que s’inscrit notre projet de fin d’études intitulé : «Conception et
développement du backoffice d’une application mobile de gestion de place de marché multi-
boutiques» dont l’objectif est de gérer les transactions entre les vendeurs et les acheteurs.
Notre rapport est divisé comme suit :
Un premier chapitre «Étude de projet» où on présentera le cadre du projet, l’état de l’art, la
solution proposée, le langage de modélisation et la méthodologie adoptée.
Un deuxième chapitre «Planification et architecture» qui sera la première partie dans
l’application du cadre méthodologique SCRUM. Il s’agit du sprint 0. Il abordera les
fonctionnalités, l’ensemble des besoins fonctionnels et non fonctionnels, les acteurs qui vont
réagir avec notre système, le diagramme de cas d’utilisation général et l’équipe SCRUM
affecté à ce projet avec la précision du rôle de chaque membre de l’équipe.
Ce chapitre présentera également le backlog du produit, le processus de découpage de notre
projet ainsi que la planification de nos sprints à l’intérieur de chaque release.
Un troisième chapitre «Gestion des accès, catégories de boutiques et vendeurs» avec lequel
on va initier notre première itération et donc notre premier sprint.
1 http://aujourdhui.ma/economie/e-commerce-le-grand-boom](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-18-320.jpg)
![Projet de fin d’études Page 21
Introduction
Durant ce premier chapitre, on va présenter notre projet d’une manière
générale afin d’avoir une vision complète et éclairée sur celui-ci.
Cette vision va nous aider à dessiner le chemin que notre projet va traverser et par conséquent
on obtiendra une très bonne organisation de déroulement de ce dernier.
Ce chapitre va traiter les sections relatives à la présentation de l’organisme d’accueil, l’étude
et les critiques de l’existant, la solution proposée, le langage de modélisation et la
méthodologie adoptée.
I. Cadre du projet
Le présent projet s’intitule «Conception et développement du backoffice d’une
application mobile de gestion de place de marché multi-boutiques».Il a été proposé comme un
projet de fin d’études en vue de l’obtention du diplôme de licence fondamentale en
informatique appliquée à la gestion. Ce stage a été effectué au sein de l’agence web ITCANE.
I.1. Présentationde l’organisme d’accueil
«ITCANE est une agence Web en Tunisie qui opère sur le marché tunisien et
international et compte parmi ses partenaires et ses clients des entreprises tunisiennes,
françaises et belges. ITCANE a été fondée en 2007 par Hatem BELHASSINE.
Cette société offre des solutions Web aux entreprises et ses services couvrent tous les métiers
du Web. Les prestations qu’elle propose sont :
Création de sites web et de portails web
Développement de sites web e-commerce et boutiques en ligne
Développement d'applications Web sur mesure
Réalisation de sites et applications pour mobiles (smartphones et tablettes)
Outsourcing et la mise à disposition d'équipes qualifiées en développement Web
Conseil en stratégie Internet
Hébergement et maintenance de serveurs Web et de serveurs de messagerie
Vente de matériel et d'accessoires informatiques.» [N3]
ITCANE propose aux entreprises des solutions web personnalisées conformément à leurs
besoins et exigences. Ses clients bénéficient de sa spécialisation dans les nouvelles
technologies ainsi que de son dynamisme. Elle cherche à occuper la position de leader sur le
marché tunisien, pour cela, elle a signé des accords de partenariat avec des partenaires
nationaux et internationaux.](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-21-320.jpg)
![Projet de fin d’études Page 24
certainement être géré par l’administrateur de la place de marché à partir du Back Office que
nous allons développer.
Nous essayerons d’inclure un système de notification pour les différents acteurs de notre
système s’il nous reste encore assez de temps sinon on l’ajoutera plus tard.
IV. Langage et méthodologie adoptée
Tout projet ayant un niveau de complexité considérable rend l’adoption d’une
méthodologie de développement une nécessité pour garantir une qualité acceptable et éviter
tout retard au niveau des délais.
Une méthodologie de développement définit les règles de conduite de notre projet, les rôles
des différents acteurs, l’ordonnancement des tâches, l’enchainement des actions, etc…
IV.1. Les méthodes AGILES
«La méthode Agile se base sur un cycle de développement qui porte le client
au centre. Le client est impliqué dans la réalisation du début à la fin du projet. L’implication
du client dans le processus permet à l’équipe d’obtenir un feedback régulier afin d’appliquer
directement les changements nécessaires. Cette méthode vise à accélérer le développement
d’un logiciel. De plus, elle assure la réalisation d’un logiciel fonctionnel tout au long de la
durée de sa création.»[N4]
ITCANE utilise les méthodologies de développement agiles comme cycle de vie pour ses
projets, de même pour le projet en cours. Ce choix est basé sur les avantages offerts par ces
méthodologies tels que leurs capacités d’adaptation aux changements de contexte et à
l’instabilité des spécifications qui subissent des modifications fréquentes durant le processus
de développement.
IV.1.1. Les quatre piliers des méthodes agiles
Individu et interaction au lieu de processus et outils.
Logiciel fonctionnel au lieu de documentation massive
Collaboration du client au lieu de négociation de contrats
Réagir aux changements au lieu de suivre le plan
IV.1.2. Les principales méthodes agiles
Les méthodes agiles les plus connues et utilisées actuellement sont :
Scrum
XP (Extreme Programming)
Test Driven Development
Crystal Clear
Suite à une réunion qu’on a faite avant le démarrage du projet, on a décidé de travailler avec
SCRUM vu qu’il convient le plus à notre projet.](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-24-320.jpg)
![Projet de fin d’études Page 25
IV.2. Pourquoi SCRUM ?
«Le Scrum est un Framework d’organisation de développement de produits
complexes. Il est défini par ses créateurs comme un cadre de travail permettant de répondre à
des problèmes complexes et changeants tout en livrant de manière productive et créative des
produits de la plus grande valeur possible.»[N5]
Le terme «SCRUM» se rapproche plus d’une gestion de ressources humaines plutôt que d’une
réelle méthode de développement. SCRUM se base sur un ensemble d’itérations appelées
également sprints d’une durée en moyenne entre deux et quatre semaines. En effet, parmi les
problèmes majeurs qui peuvent se présenter avec les méthodes classiques, la faible
implication du client de façon que le produit développé n’est visible qu’à la fin de sa
réalisation ce qui peut engendrer un décalage important entre ce qui a été demandé par le
client et ce qui a été développé.
Avec SCRUM, l’équipe de projet veille toujours à satisfaire le client à travers des livraisons
rapides et à avoir un contact direct avec lui. Le client intervient à la fin de chaque sprint, après
la génération d’un produit potentiellement livrable pour donner son feed-back. L’équipe de
projet doit ainsi réagir aux changements et ajustements demandés par le client.
Le processus de Scrum peut être représenté par la figure 1.
Figure 1 : Cycle de vie d’un projet Scrum [N6]](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-25-320.jpg)
![Projet de fin d’études Page 26
IV.2.1. Rôles définis par Scrum
Les rôles définis par la méthode Scrum :
Le Product Owner : Il s’agit du propriétaire du produit. La définition des exigences
du produit et l’ajustement de ses fonctionnalités au cours des itérations sont parmi ses
missions. C’est lui qui confirme ou refuse la version partiellement livrable présentée.
L’équipe de développement : L’équipe de développement est généralement d’une
taille de 4 à 6 membres. Elle est multi compétente et auto-organisée. Elle est engagée
à livrer un produit partiellement livrable à la fin de chaque sprint.
Le Scrum Master : Il s’agit d’un membre de l’équipe qui doit essentiellement bien
connaître Scrum. Il doit également être courageux pour pouvoir communiquer
sincèrement sur l’état d’avancement du projet. Il vérifie aussi si les membres de
l’équipe sont en train de bien appliquer la méthode Scrum. De plus, il résout les
conflits et les obstacles rencontrés ainsi qu’il contrôle le niveau de production de
l’équipe.
IV.2.2. Les artéfacts de Scrum
Product Backlog
Le backlog de produit, appelé également «carnet du produit» contient
l’ensemble des exigences et des besoins exprimés par le client. Comme les besoins du client
sont généralement instables, ce carnet va subir des changements de façon fréquente au cours
du projet. Ce dynamisme affectant le backlog de produit est un avantage majeur de la
méthode Scrum.
«Le product backlog est un document qui contient les exigences initiales dressées puis
hiérarchisées avec le client en début de projet. Néanmoins il va évoluer tout au long de la
durée du projet, en fonction des divers besoins du client.»[N4]
Sprint Backlog
Le sprint backlog, appelé également «carnet de sprint » est l’ensemble de
fonctionnalités extraites à partir du backlog de produit et qui vont être réalisés au cours d’un
sprint bien déterminé.
«En chaque début de sprint, l’équipe définit un but. Puis lors de la réunion de sprint, l’équipe
de développement choisit les éléments du carnet à réaliser. L’ensemble de ces éléments
constitue alors le sprint backlog.»[N4]
Burn Down Chart
Le Burndown Chart, appelé également «graphique d’avancement» permet à
une équipe travaillant sur un projet de visualiser son état d’avancement par rapport à ce qui a
été planifié au début du sprint. Ce graphe doit être actualisé régulièrement afin de prendre les
mesures nécessaires dans les bons moments.](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-26-320.jpg)
![Projet de fin d’études Page 27
Figure 2 : Diagramme de Burndown Chart [N7]
IV.2.3. Les activités du sprint
Planification d’itération
La planification d’itération se traduit par une réunion où les membres de
l’équipe tentent de fixer les objectifs du sprint en question et les fonctionnalités qui vont être
développés au cours de celui-ci.
Mêlée quotidienne
Il s’agit d’une réunion très courte dont l’objectif est de permettre à chaque
membre de l’équipe de présenter son état d’avancement vers l’atteinte de l’objectif du sprint
fixé lors de la planification d’itération.
Pour mieux tirer les avantages de cette réunion, les membres de l’équipe doivent un par un
répondre aux questions suivantes :
- Qu’avez-vous fait depuis la dernière mêlée ?
- Quels sont les obstacles que vous avez rencontrés au cours de votre avancement ?
- Que ce que vous allez faire d’ici à la prochaine mêlée ?
Revue d’itération
La revue d’itération est une activité faite régulièrement à la fin du
développement d’un sprint donné. Le Product Owner est responsable dans cette étape de la
comparaison du produit livré par l’équipe par rapport aux engagements établis au cours de la
planification d’itération. La revue d’itération est suivie par un nouveau sprint et donc une
nouvelle itération avec le cycle quotidien : planification, développement et revue.
«La revue d'itération est le moment où l'on présente le travail de l'équipe. C'est l'occasion,
pour l'équipe, de célébrer ses réussites, de présenter les tâches terminées dans le cadre de
l'itération et d'obtenir un feedback immédiat de la part des parties prenantes du projet. Les
tâches doivent être complètement présentables et répondre aux critères de qualité de l'équipe
pour être considérées comme terminées et prêtes pour la revue.»[N8]](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-27-320.jpg)
![Projet de fin d’études Page 28
Rétrospective de sprint :
Il s’agit d’une réunion qui aura lieu à la fin du sprint. Cette fois-ci, c’est le
Scrum Master qui intervient pour organiser cette réunion. Au cours de cette rencontre, les
idées de chaque membre de l’équipe sont prises en considération en vue d’améliorer le
rendement global de l’équipe
«La rétrospective du sprint est faite en interne avec toute l’équipe du projet le dernier jour de
l’itération. L’objectif est d’inspecter l’itération précédente, afin de déterminer quels sont les
éléments du processus de développement qui ont bien fonctionné et ceux qui sont à améliorer.
Chaque membre de l’équipe s’exprime sur le déroulement de l’itération, afin d’améliorer en
continu le processus projet.»[N5]
IV.3. Langage de modélisation
«UML (en anglais Unified Modeling Language ou «langage de modélisation
unifié») est un langage de modélisation graphique à base de pictogrammes. Il est apparu dans
le monde du génie logiciel, dans le cadre de la «conception orientée objet». Couramment
utilisé dans les projets logiciels, il peut être appliqué à toutes sortes de systèmes ne se limitant
pas au domaine informatique. UML est l’accomplissement de la fusion de précédents
langages de modélisation objet : Booch, OMT et OOSE.»[N9]
Deux points importants qu’on peut retenir de la notation «UML» :
Le terme ‘Unified’ parce que des auteurs ont essayé de regrouper les fondamentaux
des concepts objets.
Le terme ‘Language’ parce qu’on parle d’un langage de modélisation et non pas
d’une méthode.
Pour notre projet, nous avons opté pour l’utilisation d’UML (Unified Modeling Language)
comme langage de modélisation.
Conclusion
Dans ce chapitre, nous avons présenté le cadre de notre projet, ensuite nous
avons dégagé une liste comportant les critiques de l’existant, et en se basant sur cette liste,
nous avons proposé une solution qui tente de résoudre quelques problèmes constatés.
Enfin, nous avons évoqué le choix du langage de modélisation et de la méthodologie adoptée.
À ce niveau, nous pouvons passer au chapitre suivant qui comportera la planification et
l’architecture du projet.](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-28-320.jpg)
![Projet de fin d’études Page 30
Introduction
Dans ce chapitre, nous allons commencer à élaborer la première phase de la
méthodologie Scrum, appelée également «planification et architecture» ou «sprint zéro».
L’objectif de ce chapitre est d’établir une vision globale de notre produit, dégager les besoins
et les fonctionnalités, identifier les acteurs qui vont interagir avec notre système, élaborer la
planification des releases, établir le backlog de produit et finalement préparer la planification
initiale des sprints et le planning de réalisation du projet.
La particularité de ce sprint se manifeste par le fait qu’on n’aura pas un produit
potentiellement livrable à la fin de sa réalisation. Cette phase de planification et architecture
est consacrée essentiellement à la préparation de l’environnement de développement.
I. Spécification des besoins
Nous commençons par l’identification des acteurs puis l’extraction des
besoins fonctionnels et non fonctionnels.
I.1. Identifier les acteurs
«Un acteur représente un rôle joué par une entité externe (utilisateur humain,
dispositif matériel ou autre système) qui interagit directement avec le système étudié. Un
acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou en
recevant des messages susceptibles d’être porteurs de données.»[B1]
Notre projet se déroule dans le contexte de développement du back office qui donne l’accès
seulement à l’administrateur et aux vendeurs de la place de marché tout en donnant à chacun
d’eux des privilèges bien déterminés.
Notre application va interagir avec deux acteurs :
Administrateur : Un acteur qui va accéder au Back Office et gérer l’ensemble des
composants de la place de marché (clients, vendeurs, boutiques, etc…) ainsi que d’afficher
des informations utiles tel que des indicateurs et des statistiques sur les ventes de toute la
place de marché.
Vendeur : Un acteur qui va accéder au BackOffice, créer un compte, créer et paramétrer sa
boutique, gérer l’ensemble de ses produits, catégories de produits, marques et les commandes
de ses clients ainsi que d’afficher des informations utiles tel que des indicateurs et statistiques
sur les ventes de sa boutique.
I.2. Besoins fonctionnels
Les besoins fonctionnels expriment ce que doit effectuer le système afin de
répondre à ce qui a été demandé par le client.](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-30-320.jpg)
![Projet de fin d’études Page 32
Les besoins non fonctionnels de notre système se décrivent comme suit :
Ergonomie : Le back office doit être facile à utiliser. Il doit y avoir une certaine
cohérence et homogénéité entre les différentes interfaces pour les utilisateurs.
Rapidité : Les traitements doivent être optimisés pour avoir un court temps de
réponse.
Efficacité: L’application doit être fonctionnelle indépendamment de toutes
circonstances pouvant entourer l’utilisateur.
Sécurité : Assurance de la confidentialité et sécurité des données.
Maintenabilité : La solution doit être facile à maintenir.
II. Structure et découpage du projet
Nous commençons par l’identification de l’équipe Scrum, l’établissement du
backlog de produit, la planification des releases et finalement la structuration de ces derniers
en sprints.
II.1. Identification de l’équipe Scrum
Dans un projet SCRUM, l’équipe a un rôle fondamental : elle permet
d’optimiser la productivité et la flexibilité.
En effet, Elle doit être auto organisée et multifonctionnelle.
«L’équipe Scrum est auto-organisée et choisit la façon d'accomplir son travail, sans que ce
soit imposé par une personne externe. Il n'y a pas non plus de notion de hiérarchie interne :
toutes les décisions sont prises ensemble. Ce mode d'organisation a pour objectif d'augmenter
l'efficacité de travail de l'équipe. Elle est pluridisciplinaire et comporte toutes les compétences
pour réaliser son projet, sans faire appel à des personnes externes à celle-ci.»[N10]
Cette méthode agile intègre généralement la participation de plusieurs acteurs, dans notre
contexte il s’agit de M. Hatem Belhassine qui est à la fois le propriétaire et le directeur de
produit vu qu’il satisfait les prérequis de ces deux acteurs tout en mentionnant que l’équipe se
compose de deux membres : Rami Raddaoui et Mounir Homrani.](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-32-320.jpg)
![Projet de fin d’études Page 33
Figure 3 : Équipe et rôles
II.2. Le Backlog du Produit
Le backlog du produit est l’ensemble des fonctionnalités attendues du produit.
C’est l’ensemble des spécifications fonctionnelles et techniques de ce dernier.
«Le Backlog de produit est un élément indispensable de toute démarche Scrum. C’est une liste
ordonnée de tout ce qui pourrait être requis dans le produit. Il retrace la vision utilisateur et
reste ouvert et évolutif sur toute la durée du projet. Géré sous la responsabilité du PO, il est
créé par décomposition successive à partir de la vision du produit.»[N5]
ID Fonctionnalité ID Users Stories Priorité Risque
1 Gestion d’inscription
et d’authentification
1.1 En tant que vendeur, je
veux m’inscrire et créer
mon propre compte.
Elevé Faible
1.2 En tant qu’utilisateur, je
veux récupérer mon mot de
passe en cas d’oubli.
Moyenne Moyen
1.3 En tant qu’utilisateur, je
veux m’authentifier via
mon email et mon mot de
passe en toute sécurité.
Elevé Faible
2 Gestion des
boutiques
2.1 En tant que vendeur, je
veux créer ma boutique.
Elevé Faible
2.2 En tant que vendeur, je
veux paramétrer ma
boutique.
Elevé Faible
2.3 En tant qu’administrateur,
je veux lister les boutiques.
Elevé Faible
2.4 En tant qu’administrateur,
je veux accepter/refuser la
publication d’une boutique
Elevé Faible](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-33-320.jpg)
![Projet de fin d’études Page 42
Introduction :
Dans le chapitre précédent, nous avons défini et analysé les différents besoins
fonctionnels relatifs à notre projet. Ensuite, nous avons découpé notre projet afin de mener à
bien sa planification.
Dans ce chapitre, nous allons traiter les histoires utilisateurs (Users Stories) du sprint qu’on
vient d’initier afin de réaliser un incrément potentiellement livrable.
Le but de notre sprint doit être déterminé avant de commencer sa réalisation.
Une question qui se pose toujours en démarrant un sprint «Pourquoi faisons-nous ce
sprint ?»
La réponse à cette question devra être compréhensible à l’intérieur et à l’extérieur de l’équipe.
Chaque User story va passer par les quatre étapes du cycle Scrum qui sont :
La spécification fonctionnelle
La conception
L’implémentation
Les tests
I. La spécification fonctionnelle
«Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner
une vision globale du comportement fonctionnel d'un système logiciel.»[N11]
À l’initiation de chaque itération, la spécification fonctionnelle est représentée par un
diagramme de cas d’utilisation. Ce dernier va donner une vision globale du système et définir
les différentes interactions entre celui-ci et les utilisateurs.
I.1. Le sprint backlog
Il s’agit de l’ensemble de fonctionnalités extraites par l’équipe Scrum à partir
du backlog de produit et qui vont être réalisées au cours de ce sprint.
Le tableau 2 englobe le backlog du premier sprint.
ID User Story User Story ID tâche Tâche Affectation
1 En tant que
utilisateur, je
veux
m’authentifier
1.1 Élaborer le
diagramme de cas
d’utilisation, de
séquences système,
de séquences
détaillées et de
classes du cas
d’utilisation
«s’authentifier»
Rami
Raddaoui
1.2 Implémenter le cas Rami](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-42-320.jpg)
![Projet de fin d’études Page 81
La figure 54 montre un message d’échec indiquant que le résultat prévu vaut 7 alors que la
fonction a retournée 8 donc la suppression d’une catégorie de boutiques a échouée.
Après avoir terminé la phase de test, nous allons commencer à penser à notre deuxième sprint
où on va commencer à développer les parties les plus importantes de notre application telles
que la gestion des boutiques, produits, commandes, etc…
VI.Revue de sprint
«L’objectif de la revue de sprint est d’inspecter l’incrément produit au
cours du sprint écoulé. L’équipe de développement présente à tout acteur projet intéressé les
nouvelles fonctionnalités développées au cours du sprint. Le Product Owner donne un
feedback à l’équipe de développement, il accepte ou refuse les fonctionnalités
présentées.»[N13]
VI.1. Diagramme de «Burndown Chart»
«Un burndown chart (graphique d'avancement) est une représentation
graphique de l'évolution de quantité de travail restante par rapport au temps sur une période
de temps donnée. Le travail restant se situe en général sur l'axe vertical, alors que le temps est
sur l'axe horizontal.»[N12]
Figure 55 : Diagramme de Burndown Chart du premier sprint](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-81-320.jpg)
![Projet de fin d’études Page 82
VI.2 Calcul de vélocité
«L’équipe de développement calcule sa vélocité en additionnant les points
d’estimations associées aux fonctionnalités acceptées. Une fonctionnalité partiellement
terminée ne rapportera aucun point car une telle fonctionnalité n’est pas utilisable.»[N13]
En calculant la vélocité, l’équipe de développement aura l’opportunité de s’assurer que le
nombre de fonctionnalités du sprint est adapté ou nécessite encore des ajustements.
Estimer directement le temps ou l’effort nécessaire pour le développement d’un User Story ou
d’une fonctionnalité n’est pas assez facile. Par exemple, pour une équipe qui n’est pas assez
expérimentée dans les technologies utilisées, le temps consacré à l’implémentation d’un tel
User Story peut aller jusqu’au double du temps nécessaire pour une équipe expérimentée. En
effet, un développeur débutant peut estimer l’implémentation d’un User Story à 2 jours alors
qu’un développeur ayant plus d’expérience estimera l’implémentation de la même
fonctionnalité à un seul jour.
Pour nous, on s’est mis d’accord pour attribuer un nombre de points aux histoires utilisateurs
en fonction de leur complexité.
ID User Story Estimation
1 10
2 15
3 10
4 5
5 10
6 15
7 10
8 15
9 15
10 10
11 10
12 10
Vélocité estimée 135
Tableau 21 : Calcul de vélocité estimée
La figure 55 comporte le diagramme de Burndown Chart et un tableau à gauche comportant
une colonne nommée ‘Done Today’ qui indique l’ensemble des points réalisés pour chaque
jour durant ce premier sprint. La somme de cette colonne est égale à 135 ça veut dire :
Vélocité estimée = Vélocité réelle
L’équipe Scrum a donc réussi à implémenter les fonctionnalités du backlog de sprint courant.
Ces derniers ont été validés par le Product Owner.
Conclusion
Dans ce chapitre, nous nous sommes concentrés sur le développement de
notre premier sprint. Nous avons donc un incrément potentiellement livrable de notre logiciel.
Dans le chapitre suivant nous allons nous concentrer sur la réalisation de notre deuxième
sprint.](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-82-320.jpg)
![Projet de fin d’études Page 91
I.3 Diagramme de cas d’utilisation :
La figure 56 représente le diagramme de cas d’utilisation général de notre deuxième sprint.
Figure 56 : Diagramme de cas d’utilisation du deuxième sprint
II. Analyse des cas d’utilisation
Au cours de cette section, nous allons faire le raffinement des cas
d’utilisations afin de prévoir tous les scénarios possibles. Vu le nombre important des
fonctionnalités de ce sprint, nous avons choisi de ne montrer que quelques diagrammes au
cours de ce chapitre et ceci en éliminant ceux qui ont le même principe. Nous avons préparé
une annexe pour présenter les diagrammes restants. De cette manière, nous évitons d’avoir un
chapitre très volumineux par rapport aux autres. [Voir annexe B]
II.1 Analyse du cas d’utilisation «Gérer ma boutique»
Nous commençons par le raffinement du cas d’utilisation «Gérer ma
boutique».
II.1.1 Raffinement du cas d’utilisation «Gérer ma boutique»
Figure 57 : Diagramme de cas d’utilisation : Gérer ma boutique](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-91-320.jpg)
![Projet de fin d’études Page 130
Code source de la méthode de test du cas d’utilisation «Confirmer boutique»
Figure 111 : Code source de la méthode de test de confirmation d’une boutique
Capture d’écran représentant le résultat du test du cas d’utilisation «Confirmer
boutique»
Figure 112 : Interface de résultat du test de confirmation d’une boutique
Après avoir terminé la phase de test, nous allons commencer à penser à notre troisième sprint
où on va réaliser les parties restantes dans le backlog de produit et gérer les échanges avec
l’application mobile (le front office) à travers les APIs. C’est la partie la plus délicate de notre
application vu qu’on va commencer à développer les services web. Elle nécessite une forte
communication avec les membres de l’équipe pour assurer une cohérence avec les 2 releases
qui sont développés d’une manière indépendante.
VI. Revue de sprint
La revue de sprint a pour objectif d’inspecter les résultats issus de cette itération.
«L’équipe du projet et les utilisateurs se réunissent pour effectuer la revue du sprint. L’équipe
rappelle les objectifs de l’itération et indique les fonctionnalités réalisées pendant le sprint.
Chaque membre de l’équipe fait une démonstration des nouvelles fonctionnalités qu’il a
réalisées.»[N5]](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-130-320.jpg)
![Projet de fin d’études Page 152
IV. Les Services WEB
Un service web est une technologie qui permet à des applications éloignés de
communiquer ensemble à travers l’internet. Cette communication est établie indépendamment
des plates-formes et langages de programmation associés aux applications. Il est identifié par
un URL et son contenu est représenté avec un format de données spécifique comme JSON
(JavaScript Object Notation) ou XML (eXtensible Markup Language). [Voir annexe A]
Description des APIs
URL Méthode(s)
supportée(s)
Rôle
/api/get/client POST Cette API a pour rôle d’intercepter
les données d’un client spécifique
qui a remplit et validé le formulaire
d’inscription au niveau de
l’application mobile. Ces données
récupérées sont insérées dans la
table associée de notre base de
données.
/api/verif/client POST Cette API a pour rôle d’intercepter
les données d’un client spécifique
qui a remplit et validé le formulaire
de connexion au niveau de
l’application mobile. Ces données
récupérées seront chargées dans le
système qui va vérifier la validité de
ces identifiants. La méthode
associée à cet API retourne une
réponse pour permettre à
l’application mobile soit de passer à
la page d’accueil du client, soit de
lui indiquer que les identifiants sont
incorrects.
/api/catégories/boutiques GET Cette API a pour rôle de retourner
les catégories de boutiques
existantes dans la base de données
sous le format de données JSON.
/api/boutiques/favoris GET Cette API a pour rôle de retourner
les boutiques ajoutées aux favoris.
/api/boutiques/catégories/
{catégorie_id}
GET Cette API a pour rôle de retourner
les boutiques qui appartiennent à la
catégorie de boutiques ayant
comme identifiant le contenu de la
variable {catégorie_id}.
/api/boutiques/produits/
{boutique_id}
GET Cette API a pour rôle de retourner
les produits qui appartiennent à la
boutique ayant comme identifiant le
contenu de la variable
{boutique_id}.
/api/catégories/produits/ GET Cette API a pour rôle de retourner](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-152-320.jpg)
![Projet de fin d’études Page 154
IV.1 Conceptiondes services WEB
«La conception d’un service Web nécessite les étapes suivantes :
• Définir et créer un service Web
• Publier le service Web sur le serveur d’application
• Utiliser un service Web en créant un client.»[N14]
Figure 139 : Mise en place d’un service WEB [N14]
IV.1.1 Conception de l’API «Inscription client»
Diagramme de classes participantes à l’API «Inscription client»
Figure 140 : Diagramme de classes participantes à l’API «Inscription client»](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-154-320.jpg)
![Projet de fin d’études Page 173
Capture d’écran représentant le résultat du test du cas d’utilisation «Modifier état
commande»
Figure 174 : Interface de résultat du test de modification d’état d’une commande
Après avoir terminé la phase de test de notre troisième et dernier sprint, nous allons
commencer à penser à faire la liaison et enchainements entre les trois sprints développés.
VII. Revue de sprint
«À la fin du sprint, l'équipe Scrum et les parties-prenantes invitées se réunissent pour
effectuer la revue de sprint, qui dure au maximum quatre heures. L'objectif de la revue de
sprint est de valider l'incrément de produit qui a été réalisé pendant le sprint. L'équipe énonce
les éléments du carnet de produit sélectionnés en début de sprint. L'équipe présente les
éléments finis (complètement réalisés). Les éléments non finis (partiellement réalisés) ne sont
pas présentés.»[N10]
VII.1. Diagramme de «BurndownChart»
«Un burndown chart (graphique d'avancement) est une représentation graphique de
l'évolution de quantité de travail restante par rapport au temps sur une période de temps
donnée. Ce type de représentation est souvent utilisé pour suivre une activité gérée en boite de
temps, puisque la quantité de travail à réaliser ainsi que la date de fin sont connues dès le
début de la période couverte par le graphique.»[N12]](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-173-320.jpg)
![Projet de fin d’études Page 177
Introduction
Ce chapitre représente le dernier volet de ce rapport. En concrétisant notre
solution, nous étions face à un choix de l’environnement matériel et logiciel que nous
utilisons et les outils de développement que nous adoptons. Dans le présent chapitre, nous
allons expliciter les choix effectué.
I. Environnement de développement
Nous commençons par la présentation de l’environnement matériel et logiciel
que nous utilisons.
I.1 Environnement matériel
Propriétaire Rami Raddaoui
Processeur Core i3
RAM 4Go
Disque Dur 500Go
Système d’exploitation Windows 8.1 Professionnel (x64)
Tableau 58 : Environnement matériel
I.2 Environnement logiciel
Wamp Server
«Wamp server est une plateforme de développement Web de type wamp,
permettant de faire fonctionner localement (sans avoir à se connecter à un
serveur externe) des scripts PHP.»[N15]
phpMyAdmin
phpMyAdmin est une application web ayant une interface graphique
permettant une administration flexible des bases de données MySQL.
SQLYog
SQLYog est un logiciel qui permet la gestion des bases de données MySQL. Il
offre une interface graphique pour manipuler facilement une base de données.
Il est utilisé surtout pour la connexion à des bases de données distantes.
MySQL
«MySQL et en l'occurrence MySQL Community Server est une base de
données multi-plateforme, libre, gratuite et pourtant très performante et
offrant de nombreuses possibilités.
Elle est très populaire auprès des concepteurs de site internet en PHP et est
proposée par la plupart des hébergeurs web.» [N16]](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-177-320.jpg)
![Projet de fin d’études Page 178
Filezilla FTP Client
«FileZilla est un logiciel client libre qui permet aux utilisateurs de relier un
ordinateur local à un serveur Web dans le but d’échanger des données. Les
chargements et téléchargements sont effectués via un protocole de réseau FTP
(File Transfer Protocol), aussi appelé SFTP (SSH File Transfert Protocol) ou
FTPS (FTP over SSL/TLS).» [N17]
Microsoft Word
Microsoft Word est un logiciel de traitement de texte propre à Microsoft.
Microsoft Excel
Microsoft Excel est un logiciel tableur propre à Microsoft.
NetBeans
«NetBeans est un environnement de développement intégré (EDI) open source.
En plus de Java, NetBeans permet la prise en charge native de divers langages
tels le C, le C++, le JavaScript, le XML, le Groovy, le PHP et le HTML, ou
d'autres (dont Python et Ruby) par l'ajout de greffons. Il offre toutes les facilités
d'un IDE moderne (éditeur en couleurs, projets multi-langage, refactoring,
éditeur graphique d'interfaces et de pages Web).» [N18]
Power AMC
«Power AMC est un logiciel de conception créé par la société SAP, qui permet
de modéliser les traitements informatiques et leurs bases de données associées. Il
permet de réaliser tous les types de modèles informatiques.» [N19]
TortoiseGit
TortoiseGit est un client du logiciel de gestion de versions Git, implémenté
comme une extension shell de Windows. C'est un logiciel libre diffusé
sous licence publique générale GNU. [N20]
Time Performance
Time Performance est un logiciel de gestion de projets facile à utiliser et
efficace
II. Choix technologiques
II.1. L’architecture MVC
L’architecture MVC (Model View Controller) est une architecture ayant 3 couches destinées
aux interfaces graphiques et servant pour la programmation client/serveur. Il s’agit d’un
modèle architectural très puissant et très utilisé de nos jours.](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-178-320.jpg)
![Projet de fin d’études Page 179
L’architecture MVC est venue essentiellement pour faciliter la maintenabilité des applications
en offrant une organisation du code très puissante. L’objectif de cette architecture est de
séparer les données(Model) de l’affichage(View) et des actions (Controller).
En résumé, on peut définir les 3 couches du modèle MVC comme suit :
Modèle
Il contient l’ensemble des données à afficher et qui sont le plus souvent stocké
dans la base de données de notre application. Pour les langages de programmation orientés
objet, l’exploitation de ces données se fait à travers les classes.
Vue
Elle contient l’ensemble des données qui concernent l’affichage. Elle n’a pas
un accès direct à la base de données. Son rôle est limité par l’affichage de ce qu’elle reçoit
sans demander d’où proviennent les données. Il s’agit tout simplement d’une interface
homme/machine.
Contrôleur
Il s’agit d’un intermédiaire entre les 2 couches modèle et vue. Il récupère les
informations par l’intermédiaire du modèle, fait les traitements nécessaires et transmet les
données à la vue correspondante.
Figure 176 : Architecture MVC [N21]
II.2. Le Framework Symfony
«Symfony est un ensemble de composants PHP ainsi
qu'un Framework MVC libre écrit en PHP. Il fournit des fonctionnalités modulables et
adaptables qui permettent de faciliter et d’accélérer le développement d'un site web.
Symfony propose entre autres :
Une séparation du code en trois couches, selon le modèle MVC, pour une plus
grande maintenabilité et évolutivité.
Des performances optimisées et un système de cache afin d'assurer des temps de
réponse optimaux.](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-179-320.jpg)
![Projet de fin d’études Page 180
Une gestion des URL parlante, permettant à une page d'avoir une URL distincte de sa
position dans l'arborescence.
Un système de configuration en cascade utilisant pleinement le langage YAML ;
L'internationalisation native.
Le support d'AJAX.
Une architecture extensible permettant créations et utilisations de plugins.
Symfony fournit une interface en ligne de commande pour améliorer la productivité en créant
un code de base modifiable à volonté.»[N22]
II.2.1. Le Gestionnaire ORM
«Un ORM (Object Relational Mapping) est une technique de programmation
informatique qui crée l'illusion d'une base de données orientée objet à partir d'une base de
données relationnelle en définissant des correspondances entre cette base de données et les
objets du langage utilisé. On pourrait le désigner par "correspondance entre monde objet et
monde relationnel."»[N23]
Pour nous, nous avons opté pour l’utilisation de l’ORM par défaut de Symfony Doctrine.
II.2.2. Pourquoi Symfony ?
Le choix d’un Framework se fait toujours en fonction des besoins du client. Symfony
est utilisé généralement pour le développement des projets complexes dont les fonctionnalités
ne peuvent pas être traitées par les CMS (Content Management System) vu qu’ils sont des
boites noires et ne permettent pas la modification de leur code source. Nous avons donc opté
pour l’utilisation du Framework Symfony pour l’implémentation de notre projet.
II.3.L’outil de versionning GIT
«Git est un système de gestion de versionnement décentralisé (DVCS). Il est
notamment utilisé pour le noyau Linux ou pour PHP. C'est un logiciel libre créé par Linus
Torvalds en 2005. Git permet notamment de "commiter" localement puis de pousser aux
autres développeurs un ensemble de commits locaux. Il permet également d'utiliser un
workflow de développement en soumettant par exemple l'envoi de code à l'approbation d'un
des développeurs. La faculté de Git à créer des branches facilement ainsi que de permettre
leur administration de façon simple en fait un outil de choix dans le cadre de développement
de projets open source.»[N24]
II.4. REST
«REST est un style d'architecture réseau pour Web Services qui met l'accent sur la
définition de ressources identifiées par des URI, et utilise les messages du protocole HTTP
pour définir la sémantique de la communication client/serveur: GET pour le rapatriement
d'une ressource, POST pour une création.»[N25]
REST n’est pas réellement un protocole. Il s’agit d’un ensemble de conventions servant pour
l’implémentation et qui respectent un ensemble de principes bien définis.](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-180-320.jpg)
![Projet de fin d’études Page 181
Un service WEB utilisant HTTP et qui respecte l’ensemble de ces principes sera considéré
comme un RESTful Web Service. [Voir annexe A]
II.5. JSON
JSON (JavaScript Object Notation) est un format d’échange de données basé sur un sous
ensemble du langage de programmation JavaScript. La particularité de ce format d’échange
de données c’est qu’on peut le manipuler d’une façon abstraite par rapport aux langages de
programmation existants. Il est facilement compréhensible par les êtres humains.
[Voir annexe A]
III. Gestion de projet
III.1 Tableau des tâches
Nous allons présenter quelques captures d’écrans illustrant la répartition des
tâches à des moments données au cours du développement de notre projet.
Répartition des tâches du premier sprint
Figure 177 : Répartition des tâches du premier sprint
Répartition des tâches du deuxième sprint
Figure 178 : Répartition des tâches du deuxième sprint](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-181-320.jpg)
![Projet de fin d’études Page 185
A.1 Présentationdes services WEB
Les services web (ou Web Services en anglais) sont des fonctionnalités qui
peuvent être exécutées à distance et dont on peut les développer avec divers langages comme
PHP, JAVA, .NET, etc…
Un service WEB peut être consommé par plusieurs types de clients et permet à l’application
appelante d’extraire un ensemble de données qui servent pour ses propres analyses.
Par exemple, pour une application mobile de géo localisation des voitures, on peut
consommer à un instant t un service web qui contient les cordonnées GPS des voitures
(latitude et longitude) afin de pouvoir les dessiner sur le Map et déterminer la position exacte
des véhicules. L’application mobile a donc extrait un ensemble de données servant pour ses
traitements. On dit qu’elle a consommé un service WEB avec la méthode GET.
Un des majeurs avantages des services WEB c’est qu’on peut les appeler à partir d’un langage
différent de celui qui a été utilisé pour les développer. Par exemple, on peut appeler un service
WEB codé en PHP au sein d’un code C#.
A.2 REST
REST est un style d’architecture reposant sur le protocole HTTP : On peut accéder à une
ressource spécifique via son URL qui doit être unique pour bénéficier de multiples
opérations (GET pour lire, POST pour écrire, PUT pour modifier et enfin DELETE pour
supprimer), opérations supportés par le protocole HTTP.
«Le principe de REST est d'utiliser HTTP pour l'implémentation d'un Web Service, non plus
comme simple protocole de transport, mais également pour définir l'API (Application
Programming Interface) de chaque service c'est à dire la définition même des messages entre
clients et serveur.
REST décrit un style d'architecture logicielle permettant de construire une application devant
fonctionner sur des systèmes distribués (typiquement internet).
En résumé, REST est donc le style d'architecture soutenant le Web.» [N25]
Principes directeurs
«La construction d'un Web Service RESTful implique l'utilisation des éléments suivants:
• Architecture client serveur.
• Des requêtes sans état (2 requêtes d'un client sont indépendantes).
• L'utilisation de mécanismes de cache possible.
• Une interface uniforme.»[N25]](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-185-320.jpg)
![Projet de fin d’études Page 186
A.3 Représentationdes ressources
«REST n’impose ni ne revendique un format d’échange entre client et serveur. Vous êtes libre
de représenter vos données en XML, en JSON, en PHP sérialisé, en MessagePack ou dans
tout autre dialecte de votre propre cru (sans oublier que le but est souvent d’exposer des
services vers l’extérieur). Il n’est pas rare que les services REST permettent au client
d’indiquer le format dans lequel ils souhaitent dialoguer, sous la forme par exemple d’un
paramètre supplémentaire dans l’URL, ou plus simplement grâce aux en tête HTTP en
spécifiant le content-type.» [N26]
A.4 JSON
«JSON est un format léger d’échange de données. Il est facile à lire ou à écrire pour des
humains. Il est aisément analysable ou générable par des machines. Il est basé sur un sous-
ensemble du langage de programmation JavaScript. JSON est un format texte complètement
indépendant de tout langage, mais les conventions qu’il utilise seront familières à tout
programmeur habitué aux langages descendant du C, comme par exemple : C lui-même, C++,
C#, Java, JavaScript, Perl, Python et bien d’autres. Ces propriétés font de JSON un langage
d’échange de données idéal.
JSON se base sur deux structures :
Une collection de couples nom/valeur. Divers langages la réifient par un objet, un
enregistrement, une structure, un dictionnaire, une table de hachage, une liste typée ou
un tableau associatif.
Une liste de valeurs ordonnées. La plupart des langages la réifient par un tableau, un
vecteur, une liste ou une suite.
Ces structures de données sont universelles. Pratiquement tous les langages de programmation
modernes les proposent sous une forme ou une autre. Il est raisonnable qu’un format de
données interchangeable avec des langages de programmation se base aussi sur ces structures.
En JSON, elles prennent les formes suivantes :
Un objet, qui est un ensemble de couples nom/valeur non ordonnés. Un objet
commence par une accolade gauche et se termine par une accolade droite. Chaque
nom est suivi de : (deux-points) et les couples nom/valeur sont séparés par , (virgule).
Un tableau est une collection de valeurs ordonnées. Un tableau commence par [
(crochet gauche) et se termine par ] (crochet droit) . Les valeurs sont séparées par ,
(virgule).
Une valeur peut être soit une chaine de caractères entre guillemets, soit un nombre,
soit true ou false ou null, soit un objet soit un tableau. Ces structures peuvent être
imbriquées.
Une chaine de caractères est une suite de zéro ou plus caractères Unicode, entre
guillemets, et utilisant les échappements avec antislash. Un caractère est représenté par
une chaîne d’un seul caractère.» [N27]](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-186-320.jpg)
![Projet de fin d’études Page 215
C.1 Présentation des gestionnaires de version
«Les gestionnaires de version sont, de nos jours, fortement utilisés par les développeurs. Et
ceci pour plusieurs raisons, tout d'abord ils permettent d'archiver et de conserver les
différentes étapes de développement d'un projet. Ce qui procure l'avantage de pouvoir revenir
à une version antérieure à tout moment. Il est également possible de consulter les différences
entre les révisions. Et enfin, c'est également utilisé pour le travail collaboratif. Chaque
développeur dispose du projet en local, et peut à tout moment envoyer ses changements vers
le repository principal afin que les autres développeurs puissent bénéficier de son
travail.»[N28]
C.2 Utilisation des gestionnaires de version
Les logiciels de gestion de version sont fortement utilisés dans les projets de
développement logiciel et surtout dans les projets WEB. Ils permettent de garder trace de
toute modification affectant le code source et sauvegardent ainsi des informations pouvant
être utiles tel que le nom de la personne qui a apporté la modification et la date.
De cette manière, une équipe de développement travaillant sur un projet et ayant rencontré un
bug peut revenir à une version précédente et même savoir la source du bug à travers la
consultation de l’historique des modifications du code source.
C.3 GIT : L’outil de versionning décentralisé
«GIT est un logiciel de gestion de versions décentralisé. Son rôle principal est d'assurer le
suivi des modifications dans un ensemble de fichiers. Il repose sur un système d'archivage de
fichiers adressable par le contenu via l'utilisation de fonctions de hachage cryptographiques
(SHA-1) pour indexer les fichiers.
Comme tout logiciel de gestion de version, il permet d'enregistrer les modifications
successives de l'ensemble des fichiers, de visualiser l'historique des modifications, de gérer
des branches de modifications parallèles.
Son aspect distribué rend cette dernière fonctionnalité particulièrement puissante. Chaque
utilisateur disposant d'une copie locale de l'historique du projet, il est possible de travailler
hors-ligne, les outils de fusion des branches permettant ensuite de résoudre les éventuels
conflits.
Enfin git permet de gérer de nombreux types de flux de travail, que ce soit pour un utilisateur
isolé, des petits groupes de travail informel ou des gros projets nécessitant le respect de règles
précises.» [N29]](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-215-320.jpg)
![Projet de fin d’études Page 216
Nétographie
[N1] http://aujourdhui.ma/economie/e-commerce-le-grand-boom [Accès le 01/03/2017]
[N2] https://www.ecommerce-nation.fr/quelle-strategie-adopter-sur-les-places-de-marche [Accès le
04/03/2017]
[N3] http://www.itcane.com [Accès le 04/03/2017]
[N4] https://www.ideematic.com/actualites/2015/01/methodes-agiles-definition/
[Accès le 09/03/2017]
[N5] http://www.groupeafg.com/methodes-agiles-scrum/ [Accès le 15/03/2017]
[N6] http://www.roxecom.fr/blog/scrum-gestion-de-projet-agile [Accès le 15/03/2017]
[N7]https://fr.wikipedia.org/wiki/Burndown_chart [Accès le 17/03/2017]
[N8] https://fr.atlassian.com/agile/ceremonies [Accès le 17/03/2017]
[N9] http://www.additeam.com/SSII/uml/ [Accès le 18/03/2017]
[N10] https://fr.wikipedia.org/wiki/Scrum_(Boite_%C3%A0_outils) [Accès le 20/03/2017]
[N11]https://fr.wikipedia.org/wiki/Diagramme_des_cas_d%27utilisation [Accès le 20/03/2017]
[N12] https://fr.wikipedia.org/wiki/Burndown_chart [Accès le 27/03/2017]
[N13] http://www.agiliste.fr/guide-de-demarrage-scrum/ [Accès le 31/03/2017]
[N14] http://www.lsis.org/sellamis/Cours%20SW%20S1.pdf [Accès le 18/04/2017]
[N15] https://fr.wikipedia.org/wiki/WampServer [Accès le 22/04/2017]
[N16] http://www.sqlfacile.com/apprendre_bases_de_donnees/mysql_1 [Accès le 22/04/2017]
[N17] https://www.1and1.fr/digitalguide/serveur/configuration/filezilla-tutoriel-du-logiciel-client-ftp/
[Accès le 22/04/2017]
[N18] https://fr.wikipedia.org/wiki/NetBeans [Accès le 23/04/2017]
[N19] https://fr.wikipedia.org/wiki/PowerAMC [Accès le 23/04/2017]
[N20] https://fr.wikipedia.org/wiki/TortoiseGit [Accès le 23/04/2017]
[N21] http://www.adventy.org/le-mvc [Accès le 26/04/2017]
[N22] https://fr.wikipedia.org/wiki/Symfony [Accès le 26/04/2017]
[N23] https://fr.wikipedia.org/wiki/Mapping_objet-relationnel [Accès le 27/04/2017]
[N24]http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Outils-
de-developpement/Git [Accès le 29/04/2017]
[N25] https://www.tala-informatique.fr/wiki/images/8/8b/Webservices.pdf [Accès le 30/04/2017]
[N26] www.tondeurh.fr/document_146.html [Accès le 30/04/2017]
[N27] http://www.json.org/json-fr.html [Accès le 02/05/2017]
[N28] http://igm.univ-mlv.fr/~dr/XPOSE2008/git/gestionnaires.html [Accès le 04/05/2017]
[N29] https://www.projet-plume.org/fiche/git [Accès le 10/05/2017]](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-216-320.jpg)
![Projet de fin d’études Page 217
Bibliographie
[B1] Pascal Roques, UML2 par la pratique, édition Eyrolles, 2007.](https://image.slidesharecdn.com/rapportramiraddaouiversionfinale-171118110629/85/PFE-Conception-et-developpement-du-Back-Office-d-une-application-mobile-de-gestion-d-une-place-de-marche-multi-boutiques-217-320.jpg)
PFE::Conception et développement du Back Office d'une application mobile de gestion d'une place de marché multi-boutiques.
- 1. تلخيص شهادة على للحصول الدروس ختم مشروع إطار في يندرج العمل هذاالتصرف إعالمية في أساسية إجازة. شركة داخل العمل هذا تم قد ومن الفترة خالل ""إتقان01فيفري2017إلى11ماي2017. لتطبيق الخلفي المكتب إلدارة تطبيق تنفيذ و تصميم هو المشروع هذا من والهدفمحمولعبارة وهوسوق عن التي افتراضية.التجارية المحالت من العديد تضمالمستخ من للعديد متاح التطبيق هذا سيكون ويوفر أنه كما دمين .اإلفتراضية للسوق التابعة التجارية المحالت إلدارة الوظائف من العديد المفاتيح الكلمات:افتراضية,سيمفون سوقي.الويب,جيسون ,خدمات Résumé Ce présent mémoire a été rédigé dans le cadre du projet de fin d’études pour l’obtention du diplôme de licence fondamentale en informatique de gestion. Ce projet a été effectué au sein de l’organisme "ITCANE" pendant la période de 01 Février 2017 au 11 mai 2017. L'objectif de ce travail est de concevoir et développer le back office d'une application mobile de gestion de place de marché multi-boutiques. Le back office sera accessible d’une manière sécurisée à plusieurs profils d’utilisateurs et proposera plusieurs fonctionnalités pour la gestion et l’administration des boutiques de la place de marché. Le back office proposera aussi une API pour communiquer avec l’application mobile. Mots clés : Place de marché, Symfony, Services WEB, JSON. Abstract This project is a part of the final studies project graduation to obtain the diploma of the computer science management licence. The work was realized within ITCANE company during the period of 01 February 2017 to 11 May 2017. The objective of this work is to design and implement the back-end of a mobile multi-store marketplace management application. The back-end will be accessible to several users and will offer several functionalities for the management and administration of shops in the marketplace. The back-end will also offer an API (Application Programming Interface) to communicate with the mobile application. Key words: Marketplace, Symfony, WEB Services, JSON
- 2. Projet de fin d’études Page 2 Dédicace A mes parents, Pour avoir cru en moi et mes capacités et pour m’avoir permis de me développer dans un endroit différent afin d’accroitre mes connaissances et expériences dans mon domaine d’études. A toute ma famille ainsi qu'à mes amis. A tous ceux que j'aime et qui m'aiment. Je dédie ce travail espérant avoir répondu à leurs souhaits de me voir réussir. Rami
- 3. Projet de fin d’études Page 3 Remerciements C’est avec un grand plaisir que nous réservons ces lignes en signe de gratitude et de reconnaissance à tous ceux qui ont contribué de près ou de loin à la réalisation de ce modeste travail. Nous nous adressons en premier lieu aux membres de jury que nous remercions d’avoir accepté d’évaluer ce travail. Nous tenons à remercier monsieur «Karim KAMOUN», notre encadrant au sein de l’ESEN, pour son aide, la patience qu’il a su exercer à notre égard et les conseils précieux qu’il nous a prodigué tout au long de ce stage. Nos remerciements s’adressent à notre encadrant au sein d’ITCANE monsieur «Hatem BELHASSINE» de nous avoir offert cette opportunité d’effectuer notre stage de fin d’études au sein de la société ITCANE ainsi que pour sa disponibilité, ses conseils et sa confiance. Il convient à la fin de remercier profondément tous nos enseignants de l’ESEN pour la qualité de la formation qu’ils nous ont fournit tout au long de notre cursus universitaire. Qu’ils trouvent dans ce modeste travail une graine de ce qu’ils ont semé. Rami
- 4. Projet de fin d’études Page 4 Table des matières Introduction générale.................................................................................................................. 19 Chapitre I : Étude de projet Introduction..................................................................................................................... 22 I. Cadre du projet ............................................................................................................ 22 I.1.Présentation de l’organisme d’accueil ...................................................................... 22 II. État de l’art ................................................................................................................. 23 II.1. Étude de l’existant .................................................................................................23 II.2. Critiques de l’existant ............................................................................................ 24 III. Solution proposée ...................................................................................................... 24 IV. Langage et méthodologie adoptée ............................................................................... 25 IV.1. Les méthodes agiles ............................................................................................. 25 IV.1.1 Les quatre piliers des méthodes agiles................................................................ 25 IV.1.2 Les principales méthodes agiles......................................................................... 25 IV.2. Pourquoi Scrum ? .................................................................................................26 IV.2.1 Rôles définis par Scrum.................................................................................... 27 IV.2.2 Les artéfacts de Scrum...................................................................................... 27 IV.2.3 Les activités du sprint....................................................................................... 28 IV.3. Langage de modélisation ....................................................................................... 29 Conclusion ...................................................................................................................... 29 Chapitre II : Planification et architecture Introduction..................................................................................................................... 31 I. Spécification des besoins .............................................................................................. 31 I.1. Identification des acteurs ......................................................................................... 31 I.2. Besoins fonctionnels ............................................................................................... 31 I.3. Besoins non fonctionnels ......................................................................................... 32 II. Structure et découpage du projet .................................................................................. 33 II.1. Identification de l’équipe SCRUM .......................................................................... 33 II.2. Le backlog du produit ............................................................................................ 34 II.3. Planification des releases ....................................................................................... 37 II.4. Structuration des releases en sprints ........................................................................ 38 II.4.1 Planning de réalisation du projet ........................................................................ 39 II.5. Diagramme de cas d’utilisation global .................................................................... 39 Conclusion ...................................................................................................................... 41 Chapitre III : Sprint 1 : Gestion des accès, catégories de boutiques et vendeurs Introduction..................................................................................................................... 43 I. La spécification fonctionnelle ....................................................................................... 43 I.1. Le sprint Backlog ...................................................................................................43 I.2. Classification des cas d’utilisations par acteur ........................................................... 47
- 5. Projet de fin d’études Page 5 I.3. Diagramme de cas d’utilisation ................................................................................ 48 II. Analyse des cas d’utilisations ...................................................................................... 49 II.1. Analyse du cas d’utilisation «S’authentifier» ........................................................... 49 II.2. Analyse du cas d’utilisation «S’inscrire»..................................................................50 II.3. Analyse du cas d’utilisation «Récupérer mot de passe»............................................. 52 II.4. Analyse du cas d’utilisation «Changer mot de passe» ............................................... 53 II.5. Analyse du cas d’utilisation «Gérer mon profil» ...................................................... 55 II.5.1 Raffinement du cas d’utilisation «Gérer mon profil» ........................................... 55 II.5.1.1 Analyse du cas d’utilisation «Afficher mon profil» ........................................ 55 II.5.1.2 Analyse du cas d’utilisation «Modifier mon profil» ....................................... 56 II.6. Analyse du cas d’utilisation «Gérer catégories boutiques» ........................................ 57 II.6.1 Raffinement du cas d’utilisation «Gérer catégories boutiques» ............................. 57 II.6.1.1 Analyse du cas d’utilisation «Lister catégories boutiques» ............................. 58 II.6.1.2 Analyse du cas d’utilisation «Ajouter catégorie boutiques» ............................ 58 II.6.1.3 Analyse du cas d’utilisation «Modifier catégorie boutiques» .......................... 60 II.6.1.4 Analyse du cas d’utilisation «Supprimer catégorie boutiques» ........................ 61 II.7. Analyse du cas d’utilisation «Gérer vendeurs» ........................................................ 62 II.7.1 Raffinement du cas d’utilisation «Gérer vendeurs» .............................................. 62 II.7.1.1 Analyse du cas d’utilisation «Lister vendeurs» .............................................. 63 II.7.1.2 Analyse du cas d’utilisation «Supprimer vendeur» ......................................... 63 III. Conception des cas d’utilisations ................................................................................ 64 III.1. Conception du cas d’utilisation «S’authentifier» ..................................................... 65 III.2. Conception du cas d’utilisation «S’inscrire» ........................................................... 66 III.3. Conception du cas d’utilisation «Gérer mon profil» ................................................ 67 III.3.1. Conception du cas d’utilisation «Afficher mon profil» ...................................... 67 III.3.2. Conception du cas d’utilisation «Modifier mon profil» ...................................... 68 III.4. Conception du cas d’utilisation «Gérer catégories boutiques» .................................69 III.4.1. Conception du cas d’utilisation «Lister catégories boutiques» ............................ 69 III.4.2. Conception du cas d’utilisation «Ajouter catégorie boutiques» ........................... 70 III.4.3. Conception du cas d’utilisation «Modifier catégorie boutiques» ......................... 71 III.4.4. Conception du cas d’utilisation «Supprimer catégorie boutiques» ...................... 72 III.5. Conception du cas d’utilisation «Gérer vendeurs» .................................................. 73 III.5.1. Conception du cas d’utilisation «Lister vendeurs» ............................................. 73 III.5.2. Conception du cas d’utilisation «Supprimer vendeur» ....................................... 74 III.6. Diagramme de classes global du premier sprint ...................................................... 75 IV. Implémentation ........................................................................................................... 75 V. Tests ............................................................................................................................ 78 V.1 Les tests unitaires ..................................................................................................... 78 V.1.1 Le test unitaire du cas d’utilisation «Ajouter catégorie boutiques» ......................... 79
- 6. Projet de fin d’études Page 6 V.1.2 Le test unitaire du cas d’utilisation «Supprimer catégorie boutiques»...................... 80 VI. Revue de sprint ........................................................................................................... 82 VI.1 Diagramme de «Burndown Chart» ........................................................................... 82 VI.2 Calcul de vélocité ...................................................................................................83 Conclusion ....................................................................................................................... 83 Chapitre 4 : Sprint2 : Gestiondesboutiques,marques,catégoriesde produits et produits Introduction..................................................................................................................... 85 I. La spécification fonctionnelle ...................................................................................... 85 I.1 Le sprint backlog.................................................................................................... 85 I.2 Classification des cas d’utilisations par acteur .......................................................... 91 I.3 Diagramme de cas d’utilisation................................................................................ 92 II. Analyse des cas d’utilisations ...................................................................................... 92 II.1 Analyse de cas d’utilisation «Gérer ma boutique» .................................................... 92 II.1.1 Raffinement du cas d’utilisation «Gérer ma boutique» ........................................ 92 II.1.1.1 Analyse du cas d’utilisation «Créer ma boutique» ............................................ 93 II.1.1.2 Analyse du cas d’utilisation «Paramétrer ma boutique» .................................... 94 II.2 Analyse de cas d’utilisation «Gérer mes produits».................................................... 95 II.2.1 Raffinement du cas d’utilisation «Gérer mes produits»........................................ 95 II.2.1.1 Analyse du cas d’utilisation «Lister produits» ............................................... 96 II.2.1.2 Analyse du cas d’utilisation «Ajouter produit» .............................................. 96 II.2.1.3 Analyse du cas d’utilisation «Modifier produit» ............................................ 97 II.2.1.4 Analyse du cas d’utilisation «Supprimer produit».......................................... 98 II.3 Analyse du cas d’utilisation «Gérer les boutiques» ................................................... 99 II.3.1 Raffinement du cas d’utilisation «Gérer les boutiques» ..................................... 100 II.3.1.1 Analyse du cas d’utilisation «Lister boutiques»........................................... 101 II.3.1.2 Analyse du cas d’utilisation «Confirmer boutique»...................................... 101 II.3.1.3 Analyse du cas d’utilisation «Supprimer boutique» ..................................... 102 II.3.1.4 Analyse du cas d’utilisation «Verrouiller boutique»..................................... 103 II.3.1.5 Analyse du cas d’utilisation «Consulter boutique»....................................... 105 II.3.1.6 Analyse du cas d’utilisation «Ajouter boutique aux favoris» ........................ 105 II.3.1.7 Analyse du cas d’utilisation «Lister produits boutique» ............................... 106 II.3.1.8 Analyse du cas d’utilisation «Consulter produit»......................................... 107 III. Conception des cas d’utilisations ............................................................................ 108 III.1 Conception du cas d’utilisation «Gérer ma boutique» .......................................... 108 III.1.1 Conception du cas d’utilisation «Créer ma boutique»..................................... 108 III.1.2 Conception du cas d’utilisation «Paramétrer ma boutique»............................. 110 III.2 Conception du cas d’utilisation «Gérer mes produits».......................................... 111 III.2.1 Conception du cas d’utilisation «Lister produits»........................................... 111 III.2.2 Conception du cas d’utilisation «Ajouter produit».......................................... 112
- 7. Projet de fin d’études Page 7 III.2.3 Conception du cas d’utilisation «Modifier produit»........................................ 114 III.2.4 Conception du cas d’utilisation «Supprimer produit» ..................................... 116 III.3 Conception du cas d’utilisation «Gérer les boutiques» .......................................... 117 III.3.1 Conception du cas d’utilisation «Lister boutiques» ......................................... 117 III.3.2 Conception du cas d’utilisation «Confirmer boutique» .................................... 118 III.3.3 Conception du cas d’utilisation «Supprimer boutique».................................... 119 III.3.4 Conception du cas d’utilisation «Verrouiller boutique» ................................... 120 III.3.5 Conception du cas d’utilisation «Consulter boutique» ..................................... 121 III.3.6 Conception du cas d’utilisation «Ajouter boutique aux favoris»....................... 122 III.3.7 Conception du cas d’utilisation «Lister produits boutique».............................. 123 III.3.8 Conception du cas d’utilisation «Consulter produit» ....................................... 124 III.3.9 Diagramme de classes global du deuxième sprint............................................ 125 IV. Implémentation ...................................................................................................... 125 V. Tests....................................................................................................................... 127 V.1 Les tests unitaires................................................................................................ 127 V.1.1 Le test unitaire du cas d’utilisation «Verrouiller boutique» ............................... 127 V.1.2 Le test unitaire du cas d’utilisation «Paramétrer ma boutique» .......................... 128 V.1.3 Le test unitaire du cas d’utilisation «Ajouter produit aux favoris» ..................... 129 V.1.4 Le test unitaire du cas d’utilisation «Confirmer boutique» ................................ 130 VI. Revue de sprint ...................................................................................................... 131 VI.1 Diagramme de «Burndown Chart»...................................................................... 132 VI.2 Calcul de vélocité .............................................................................................. 132 VI.3 Réajustements à faire pour le prochain sprint ....................................................... 133 Conclusion .................................................................................................................. 133 Chapitre 5 : Sprint3 : Gestiondeséchanges,commandes,statistiqueset clients Introduction................................................................................................................... 135 I. La spécification fonctionnelle .................................................................................... 135 I.1 Le sprint backlog.................................................................................................. 135 I.2 Classification des cas d’utilisations par acteur........................................................ 138 I.3 Diagramme de cas d’utilisation.............................................................................. 138 II. Analyse des cas d’utilisations ................................................................................... 138 II.1 Analyse de cas d’utilisation «Gérer les clients» ..................................................... 139 II.1.1 Raffinement du cas d’utilisation «Gérer les clients» ......................................... 139 II.1.1.1 Analyse du cas d’utilisation «Lister les clients».......................................... 139 II.1.1.2 Analyse du cas d’utilisation «Supprimer client» ......................................... 140 II.2 Analyse de cas d’utilisation «Gérer mes commandes» ........................................... 141 II.2.1 Raffinement du cas d’utilisation «Gérer mes commandes» ............................... 141 II.2.1.1 Analyse du cas d’utilisation «Lister mes commandes»................................ 141 II.2.1.2 Analyse du cas d’utilisation «Modifier état commande».............................. 142
- 8. Projet de fin d’études Page 8 II.3 Analyse du cas d’utilisation «Gérer les commandes»............................................. 143 II.3.1 Raffinement du cas d’utilisation «Gérer les commandes»................................. 143 II.3.1.1 Analyse du cas d’utilisation «Lister les commandes».................................. 143 II.3.1.2 Analyse du cas d’utilisation «Afficher les statistiques de ma boutique»........ 144 II.3.1.3 Analyse du cas d’utilisation «Afficher les statistiques de la place de marché» ................................................................................................................................................. 144 III. Conception des cas d’utilisations ............................................................................. 146 III.1 Conception du cas d’utilisation «Gérer les clients»............................................... 146 III.1.1 Conception du cas d’utilisation «Lister les clients» ......................................... 146 III.1.2 Conception du cas d’utilisation «Supprimer client»......................................... 147 III.2 Conception du cas d’utilisation «Gérer mes commandes»..................................... 148 III.2.1 Conception du cas d’utilisation «Lister mes commandes» ............................... 148 III.2.2 Conception du cas d’utilisation «Modifier état commande»............................. 149 III.3 Conception du cas d’utilisation «Gérer les commandes»....................................... 150 III.3.1 Conception du cas d’utilisation «Lister les commandes» ................................. 150 III.4 Conception du cas d’utilisation «Afficher les statistiques de ma boutique»............. 151 III.5 Conception du cas d’utilisation «Afficher les statistiques de la place de marché»... 152 IV. Les services WEB.................................................................................................. 153 IV.1 Conception des services WEB ........................................................................... 155 IV.1.1 Conception de l’API «Inscription client» ....................................................... 156 IV.1.2 Conception de l’API «Authentification client» .............................................. 156 IV.1.3 Conception de l’API «GET Catégories boutiques» ......................................... 157 IV.1.4 Conception de l’API «GET boutiques favoris»............................................... 158 IV.1.5 Conception de l’API «GET boutiques By Catégorie»...................................... 159 IV.1.6 Conception de l’API «GET produits By Boutique»......................................... 160 IV.1.7 Conception de l’API «GET produits By Catégorie»........................................ 161 IV.1.8 Conception de l’API «GET Catégories produits By Boutique» ........................ 162 IV.1.9 Conception de l’API «GET libellé By ID catégorie »...................................... 163 IV.1.10 Conception de l’API «GET produit By ID».................................................. 164 IV.1.11 Conception de l’API «GET produits favoris»................................................ 165 IV.1.12 Conception de l’API «GET Images By ID Produit» ...................................... 166 IV.1.13 Conception de l’API «GET Commande Client»............................................ 167 IV.1.14 Diagramme de classes global du troisième sprint .......................................... 168 V. Implémentation ....................................................................................................... 169 VI. Tests...................................................................................................................... 171 VI.1 Les tests unitaires............................................................................................... 171 VI.1.1 Le test unitaire de l’API «GET Catégories boutiques» .................................... 171 VI.1.2 Le test unitaire de l’API «GET produits By Boutique».................................... 172 VI.1.3 Le test unitaire du cas d’utilisation «Modifier état commande»........................ 173
- 9. Projet de fin d’études Page 9 VII. Revue de sprint ..................................................................................................... 174 VII.1 Diagramme de «Burndown Chart»..................................................................... 174 VII.2 Calcul de vélocité ............................................................................................. 175 Conclusion .................................................................................................................. 176 Chapitre 6 : Phase de clôture Introduction ................................................................................................................. 178 I. Environnement de développement............................................................................... 178 I.1 Environnement matériel......................................................................................... 178 I.2 Environnement logiciel.......................................................................................... 178 II. Choix technologiques................................................................................................ 179 II.1 L’architecture MVC............................................................................................. 179 II.2 Le Framework Symfony ....................................................................................... 180 II.2.1 Le gestionnaire ORM...................................................................................... 181 II.2.2 Pourquoi Symfony ? ....................................................................................... 181 II.3 L’outil de versionning GIT ................................................................................... 181 II.4 REST.................................................................................................................. 181 II.5 JSON .................................................................................................................. 182 III. Gestion de projet ..................................................................................................... 182 III.1 Tableaux des tâches ............................................................................................ 182 III.2 Diagramme de GANTT....................................................................................... 183 Conclusion ................................................................................................................................ 183 Conclusion et perspectives........................................................................................................184 ANNEXE A..............................................................................................................................185 ANNEXE B..............................................................................................................................188 ANNEXE C..............................................................................................................................215 Nétographie .............................................................................................................................217 Bibliographie ...........................................................................................................................218
- 10. Projet de fin d’études Page 10 Table des figures Figure 1 : Cycle de vie d’un projet Scrum [N6]..............................................................................25 Figure 2 : Diagramme de Burndown Chart [N7].............................................................................27 Figure 3 : Équipe et rôles..............................................................................................................33 Figure 4 : Découpage des releases en sprints..................................................................................37 Figure 5 : Planification des sprints ................................................................................................37 Figure 6 : Planning de réalisation du projet....................................................................................38 Figure 7 : Diagramme de cas d’utilisation global............................................................................39 Figure 8 : Diagramme de cas d’utilisation du premier sprint............................................................47 Figure 9 : Diagramme de séquences système du cas d’utilisation «s’authentifier»............................49 Figure 10 : Diagramme de séquences système du cas d’utilisation «s’inscrire»................................50 Figure 11 : Diagramme de séquences système du cas d’utilisation «Récupérer mot de passe»...........52 Figure 12 : Diagramme de séquences système du cas d’utilisation «Changer mot de passe»..............53 Figure 13 : Diagramme de cas d’utilisation de «Gérer mon profil»..................................................54 Figure 14 : Diagramme de séquences système du cas d’utilisation «Afficher mon profil»..................55 Figure 15 : Diagramme de séquences système du cas d’utilisation «Modifier mon profil».................56 Figure 16 : Diagramme de cas d’utilisation du cas «Gérer catégories boutiques».............................56 Figure 17 : Diagramme de séquences système du cas d’utilisation «Lister catégories boutiques»......57 Figure 18 : Diagramme de séquences système du cas d’utilisation «Ajouter catégorie boutiques».....58 Figure 19 : Diagramme de séquences système du cas d’utilisation «Modifier catégorie boutiques» ...60 Figure 20 : Diagramme de séquences système du cas d’utilisation «Supprimer catégorie boutiques».61 Figure 21 : Diagramme de cas d’utilisation du cas «Gérer vendeurs»..............................................61 Figure 22 : Diagramme de séquences système du cas d’utilisation «Lister vendeurs» .......................62 Figure 23 : Diagramme de séquences système du cas d’utilisation «Supprimer vendeur» ..................63 Figure 24 : Diagramme de classes participantes du cas d’utilisation «s’authentifier» ........................64 Figure 25 : Diagramme de séquences détaillées du cas d’utilisation «s’authentifier».........................64 Figure 26 : Diagramme de classes participantes au cas d’utilisation «s’inscrire»...............................65 Figure 27 : Diagramme de séquences détaillées du cas d’utilisation «s’inscrire»...............................65 Figure 28 : Diagramme de classes participantes au cas d’utilisation «Afficher mon profil»................66 Figure 29 : Diagramme de séquences détaillées du cas d’utilisation «Afficher mon profil»................66 Figure 30 : Diagramme de classes participantes au cas d’utilisation «Modifier mon profil»...............67 Figure 31 : Diagramme de séquences détaillées du cas d’utilisation «Modifier mon profil»...............67 Figure 32 : Diagramme de classes participantes au cas d’utilisation «Lister catégories boutiques».....68 Figure 33 : Diagramme de séquences détaillées du cas d’utilisation «Lister catégories boutiques».....68 Figure 34 : Diagramme de classes participantes au cas d’utilisation «Ajouter catégorie boutiques»...69 Figure 35 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter catégorie boutiques»...69 Figure 36 : Diagramme de classes participantes au cas d’utilisation «Modifier catégorie boutiques»..70 Figure 37 : Diagramme de séquences détaillées du cas d’utilisation «Modifier catégorie boutiques».70 Figure 38 : Diagramme de classes participantes au cas d’utilisation «Supprimer catégorie boutiques» ...................................................................................................................................................71 Figure 39 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer catégorie boutiques» ...................................................................................................................................................71 Figure 40 : Diagramme de classes participantes au cas d’utilisation «Lister vendeurs» .....................72 Figure 41 : Diagramme de séquences détaillées du cas d’utilisation «Lister vendeurs» .....................72 Figure 42 : Diagramme de classes participantes au cas d’utilisation «Supprimer vendeur»................73 Figure 43 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer vendeur»................73 Figure 44: Diagramme de classes global du premier sprint..............................................................74 Figure 45 : Interface d’authentification..........................................................................................75 Figure 46 : Interface d’inscription .................................................................................................76
- 11. Projet de fin d’études Page 11 Figure 47 : Interface du cas «Lister catégories boutiques»..............................................................76 Figure 48 : Interface du cas «Lister vendeurs»...............................................................................77 Figure 49 : Code de source de la méthode de test d’ajout d’une catégorie de boutiques.....................78 Figure 50 : Interface de résultat du test d’ajout...............................................................................78 Figure 51 : Interface de résultat du test d’ajout en cas d’échec.........................................................79 Figure 52 : Code source de la méthode de test de suppression .........................................................80 Figure 53 : Interface de résultat du test de suppression....................................................................80 Figure 54 : Interface de résultat du test de suppression en cas d’échec.............................................80 Figure 55 : Diagramme de Burndown Chart du premier sprint.........................................................81 Figure 56 : Diagramme de cas d’utilisation du deuxième sprint.......................................................91 Figure 57 : Diagramme de cas d’utilisation : Gérer ma boutique......................................................91 Figure 58 : Diagramme de séquences système du cas d’utilisation «Créer ma boutique»...................93 Figure 59 : Diagramme de séquences système du cas d’utilisation «Paramétrer ma boutique»..........94 Figure 60 : Diagramme de cas d’utilisation du cas «Gérer mes produits».........................................94 Figure 61 : Diagramme de séquences système du cas d’utilisation «Lister produits».........................95 Figure 62 : Diagramme de séquences système du cas d’utilisation «Ajouter produit» .......................96 Figure 63 : Diagramme de séquences système du cas d’utilisation «Modifier produit»......................97 Figure 64 : Diagramme de séquences système du cas d’utilisation «Supprimer produit»...................98 Figure 65 : Diagramme de cas d’utilisation du cas «Gérer les boutiques»........................................99 Figure 66 : Diagramme de séquences système du cas d’utilisation «Lister boutiques» .................... 100 Figure 67 : Diagramme de séquences système du cas d’utilisation «Confirmer boutique»............... 101 Figure 68 : Diagramme de séquences système du cas d’utilisation «Supprimer boutique»............... 102 Figure 69 : Diagramme de séquences système du cas d’utilisation «Verrouiller boutique».............. 103 Figure 70 : Diagramme de séquences système du cas d’utilisation «Consulter boutique»................ 104 Figure 71 : Diagramme de séquences système du cas d’utilisation «Ajouter boutique aux favoris».. 105 Figure 72 : Diagramme de séquences système du cas d’utilisation «Lister produits boutique»......... 106 Figure 73 : Diagramme de séquences système du cas d’utilisation «Consulter produit».................. 107 Figure 74 : Diagramme de classes participantes au cas d’utilisation «Créer ma boutique» .............. 108 Figure 75 : Diagramme de séquences détaillées du cas d’utilisation «Créer boutique».................... 108 Figure 76 : Diagramme de classes participantes au cas d’utilisation «Paramétrer ma boutique»...... 109 Figure 77 : Diagramme de séquences détaillées du cas d’utilisation «Paramétrer ma boutique»...... 109 Figure 78 : Diagramme de classes participantes au cas d’utilisation «Lister produits» .................... 110 Figure 79 : Diagramme de séquences détaillées du cas d’utilisation «Lister produits» .................... 110 Figure 80 : Diagramme de classes participantes au cas d’utilisation «Ajouter produit» ................... 111 Figure 81 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter produit» ................... 112 Figure 82 : Diagramme de classes participantes au cas d’utilisation «Modifier produit».................. 113 Figure 83 : Diagramme de séquences détaillées du cas d’utilisation «Modifier produit».................. 114 Figure 84 : Diagramme de classes participantes au cas d’utilisation «Supprimer produit»............... 115 Figure 85 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer produit»............... 115 Figure 86 : Diagramme de classes participantes au cas d’utilisation «Lister boutiques» .................. 116 Figure 87 : Diagramme de séquences détaillées du cas d’utilisation «Lister boutiques» .................. 116 Figure 88 : Diagramme de classes participantes au cas d’utilisation «Confirmer boutique»............. 117 Figure 89 : Diagramme de séquences détaillées du cas d’utilisation «Confirmer boutique»............. 117 Figure 90 : Diagramme de classes participantes au cas d’utilisation «Supprimer boutique»............. 118 Figure 91 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer boutique»............. 118 Figure 92 : Diagramme de classes participantes au cas d’utilisation «Verrouiller boutique»............ 119 Figure 93 : Diagramme de séquences détaillées du cas d’utilisation «Verrouiller boutique»............ 119 Figure 94 : Diagramme de classes participantes au cas d’utilisation «Consulter boutique».............. 120 Figure 95 : Diagramme de séquences détaillées du cas d’utilisation «Consulter boutique».............. 120 Figure 96 : Diagramme de classes participantes au cas d’utilisation «Ajouter boutique aux favoris» 121
- 12. Projet de fin d’études Page 12 Figure 97 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter boutique aux favoris» 121 Figure 98 : Diagramme de classes participantes au cas d’utilisation «Lister produits boutique»....... 122 Figure 99 : Diagramme de séquences détaillées du cas d’utilisation «Lister produits boutique»....... 122 Figure 100 : Diagramme de classes participantes au cas d’utilisation «Consulter produit».............. 123 Figure 101 : Diagramme de séquences détaillées du cas d’utilisation «Consulter produit».............. 123 Figure 102 : Diagramme de classes global du deuxième sprint ...................................................... 124 Figure 103 : Interface du cas «Lister boutiques» .......................................................................... 125 Figure 104 : Interface du cas «Paramétrer ma boutique».............................................................. 126 Figure 105 : Code source de la méthode de test du cas «Verrouiller boutique» ............................... 127 Figure 106 : Interface de résultat du test du cas «Verrouiller boutique» ......................................... 127 Figure 107 : Code source de la méthode de test du cas «Paramétrer ma boutique»......................... 128 Figure 108 : Interface de résultat du test du cas «Paramétrer ma boutique» .................................... 128 Figure 109 : Code source de la méthode de test d’ajout d’un produit aux favoris ............................ 129 Figure 110 : Interface de résultat du test d’ajout d’un produit aux favoris....................................... 129 Figure 111 : Code source de la méthode de test de confirmation d’une boutique............................. 130 Figure 112 : Interface de résultat du test de confirmation d’une boutique ....................................... 130 Figure 113 : Diagramme de Burndown Chart du sprint 2 .............................................................. 131 Figure 114 : Diagramme de cas d’utilisation du troisième sprint.................................................... 137 Figure 115 : Diagramme de cas d’utilisation : Gérer les clients ..................................................... 138 Figure 116 : Diagramme de séquences système du cas d’utilisation «Lister les clients».................. 138 Figure 117 : Diagramme de séquences système du cas d’utilisation «Supprimer client».................. 139 Figure 118 : Diagramme de cas d’utilisation : Gérer mes commandes............................................ 140 Figure 119 : Diagramme de séquences système du cas d’utilisation «Lister mes commandes»......... 140 Figure 120 : Diagramme de séquences système du cas d’utilisation «Modifier état commande»...... 141 Figure 121 : Diagramme de cas d’utilisation : Gérer les commandes ............................................. 142 Figure 122 : Diagramme de séquences système du cas d’utilisation «Lister les commandes»........... 142 Figure 123 : Diagramme de séquences système du cas d’utilisation «Afficher les statistiques de ma boutique».................................................................................................................................. 143 Figure 124 : Diagramme de séquences système du cas d’utilisation «Afficher les statistiques de la place de marché»....................................................................................................................... 144 Figure 125 : Diagramme de classes participantes au cas d’utilisation «Lister les clients»................ 145 Figure 126 : Diagramme de séquences détaillées du cas d’utilisation «Lister les clients»................ 145 Figure 127 : Diagramme de classes participantes au cas d’utilisation «Supprimer client»................ 146 Figure 128 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer client»................ 146 Figure 129 : Diagramme de classes participantes au cas d’utilisation «Lister mes commandes»....... 147 Figure 130 : Diagramme de séquences détaillées du cas d’utilisation «Lister mes commandes»....... 147 Figure 131 : Diagramme de classes participantes au cas d’utilisation «Modifier état commande».... 148 Figure 132 : Diagramme de séquences détaillées du cas d’utilisation «Modifier état commande».... 148 Figure 133 : Diagramme de classes participantes au cas d’utilisation «Lister les commandes»......... 149 Figure 134 : Diagramme de séquences détaillées du cas d’utilisation «Lister les commandes»......... 149 Figure 135 : Diagramme de classes participantes au cas d’utilisation «Afficher les statistiques de ma boutique».................................................................................................................................. 150 Figure 136 : Diagramme de séquences détaillées du cas d’utilisation «Afficher les statistiques de ma boutique».................................................................................................................................. 150 Figure 137 : Diagramme de classes participantes au cas d’utilisation «Afficher les statistiques de la place de marché»....................................................................................................................... 151 Figure 138 : Diagramme de séquences détaillées du cas d’utilisation «Afficher les statistiques de la place de marché»....................................................................................................................... 151 Figure 139 : Mise en place d’un service WEB [N14].................................................................... 154 Figure 140 : Diagramme de classes participantes à l’API «Inscription client»................................ 154
- 13. Projet de fin d’études Page 13 Figure 141 : Diagramme de séquences détaillées de l’API «Inscription client»............................... 155 Figure 142 : Diagramme de classes participantes à l’API «Authentification client»......................... 155 Figure 143 : Diagramme de séquences détaillées de l’API «Authentification client»....................... 156 Figure 144 : Diagramme de classes participantes à l’API «GET catégories boutiques»................... 156 Figure 145 Diagramme de séquences détaillées de l’API «GET catégories boutiques»................... 157 Figure 146 : Diagramme de classes participantes à l’API «GET boutiques favoris»........................ 157 Figure 147 : Diagramme de séquences détaillées de l’API «GET boutiquesfavoris»....................... 158 Figure 148 : Diagramme de classes participantes à l’API «GET boutiques By Catégorie»............... 158 Figure 149 : Diagramme de séquences détaillées de l’API «GET boutiques By Catégorie»............. 159 Figure 150 : Diagramme de classes participantes à l’API «GET produits By Boutique».................. 159 Figure 151 : Diagramme de séquences détaillées de l’API «GET produits By Boutique»................. 160 Figure 152 : Diagramme de classes participantes à l’API «GET produits By Catégorie»................. 160 Figure 153 : Diagramme de séquences détaillées de l’API «GET produits By Catégorie»............... 161 Figure 154 : Diagramme de classes participantes à l’API «GET Catégories produits By Boutique».161 Figure 155 : Diagramme de séquences détaillées de l’API «GET Catégories produits By Boutique»162 Figure 156 : Diagramme de classes participantes à l’API «GET Libellé By ID Catégorie».............. 162 Figure 157 : Diagramme de séquences détaillées de l’API «GET libellé By ID catégorie».............. 163 Figure 158 : Diagramme de classes participantes à l’API «GET Produit By ID»............................. 163 Figure 159 : Diagramme de séquences détaillées de l’API «GET Produit By ID»........................... 164 Figure 160 : Diagramme de classes participantes à l’API «GET produits Favoris»......................... 164 Figure 161 : Diagramme de séquences détaillées de l’API «GET produitsfavoris»......................... 165 Figure 162 : Diagramme de classes participantes à l’API «GET Images By ID Produit»................. 165 Figure 163 : Diagramme de séquences détaillées de l’API «GET Images By ID Produit»................ 166 Figure 164 : Diagramme de classes participantes à l’API «GET Commande Client»....................... 166 Figure 165 : Diagramme de séquences détaillées de l’API «GET Commande Client»..................... 167 Figure 166 : Diagramme de classes global du troisième sprint....................................................... 167 Figure 167 : Interface du cas «Lister mes commandes».................................................................169 Figure 168 : Interface du cas «Afficher les statistiques de ma boutique» ........................................ 169 Figure 169 : Code source de la méthode de test de l’API «GET Catégories boutiques»................... 170 Figure 170 : Interface de résultat du test de l’API «GET Catégories boutiques»............................. 171 Figure 171 : Code source de la méthode de test de l’API «GET produits By Boutique»................... 171 Figure 172 : Interface de résultat du test de l’API «GET produits By Boutique»............................. 172 Figure 173 : Code source de la méthode de test du cas d’utilisation «Modifier état commande» ...... 172 Figure 174 : Interface de résultat du test de modification d’état d’une commande........................... 173 Figure 175 : Diagramme de Burndown Chart du troisième sprint .................................................. 174 Figure 176 : Architecture MVC [N21]......................................................................................... 179 Figure 177 : Répartition des tâches du premier sprint ................................................................... 181 Figure 178 : Répartition des tâches du deuxième sprint.................................................................181 Figure 179 : Répartition des tâches du troisième sprint .................................................................182 Figure 180 : Diagramme de GANTT........................................................................................... 182 Figure 181 : Diagramme de cas d’utilisation du cas «Gérer catégories produits»........................... 188 Figure 182 : Diagramme de séquences système du cas d’utilisation «Lister catégories de produits» 189 Figure 183 : Diagramme de séquences système du cas d’utilisation «Ajouter catégorie produits» ... 190 Figure 184 : Diagramme de séquences système du cas d’utilisation «Modifier catégorie produits».. 191 Figure 185 : Diagramme de séquences système du cas d’utilisation «Supprimer catégorie produits» ................................................................................................................................................. 192 Figure 186 : Diagramme de cas d’utilisation du cas «Gérer marques»........................................... 193 Figure 187 : Diagramme de séquences système du cas d’utilisation «Lister marques».................... 193 Figure 188 : Diagramme de séquences système du cas d’utilisation «Ajouter marque»................... 194 Figure 189 : Diagramme de séquences système du cas d’utilisation «Modifier marque» ................. 195
- 14. Projet de fin d’études Page 14 Figure 190 : Diagramme de séquences système du cas d’utilisation «Supprimer marque»............... 196 Figure 191 : Diagramme de séquences système du cas d’utilisation «Déverrouiller boutique» ........ 197 Figure 192 : Diagramme de séquences système du cas d’utilisation «Supprimer boutique du favoris» ................................................................................................................................................. 198 Figure 193 : Diagramme de séquences système du cas d’utilisation «Ajouter produit aux favoris».. 199 Figure 194 : Diagramme de séquences système du cas d’utilisation «Supprimer produit du favoris»201 Figure 195 : Diagramme de classes participantes au cas d’utilisation «Lister catégories produits» .. 201 Figure 196 : Diagramme de séquences détaillées du cas d’utilisation «Lister catégories produits» .. 202 Figure 197 : Diagramme de classes participantes au cas d’utilisation «Ajouter catégorie produit»... 202 Figure 198 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter catégorie produit»... 203 Figure 199 : Diagramme de classes participantes au cas d’utilisation «Modifier catégorie produit».203 Figure 200 : Diagramme de séquences détaillées du cas d’utilisation «Modifier catégorie produit».204 Figure 201 : Diagramme de classes participantes au cas d’utilisation «Supprimer catégorie produit» ................................................................................................................................................. 204 Figure 202 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer catégorie produit» ................................................................................................................................................. 205 Figure 203 : Diagramme de classes participantes au cas d’utilisation «Lister marques».................. 205 Figure 204 : Diagramme de séquences détaillées du cas d’utilisation «Lister marques».................. 206 Figure 205 : Diagramme de classes participantes au cas d’utilisation «Ajouter marque»................. 206 Figure 206 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter marque»................. 207 Figure 207 : Diagramme de classes participantes au cas d’utilisation «Modifier marque»............... 207 Figure 208 : Diagramme de séquences détaillées du cas d’utilisation «Modifier marque»............... 208 Figure 209 : Diagramme de classes participantes au cas d’utilisation «Supprimer marque»............. 208 Figure 210 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer marque»............. 209 Figure 211 : Diagramme de classes participantes au cas d’utilisation «Déverrouiller boutique» ...... 209 Figure 212 : Diagramme de séquences détaillées du cas d’utilisation «Déverrouiller boutique» ...... 210 Figure 213 : Diagramme de classes participantes au cas d’utilisation «Supprimer boutique du favoris» ................................................................................................................................................. 210 Figure 214 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer boutique du favoris» ................................................................................................................................................. 211 Figure 215 : Diagramme de classes participantes au cas d’utilisation «Ajouter produit aux favoris» 211 Figure 216 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter produit aux favoris» 212 Figure 217 : Diagramme de classes participantes au cas d’utilisation «Supprimer produit du favoris» ................................................................................................................................................. 212 Figure 218 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer produit du favoris» ................................................................................................................................................. 213
- 15. Projet de fin d’études Page 15 Liste des tableaux Tableau 1 : Backlog du produit .....................................................................................................36 Tableau 2 : Backlog du premier sprint ...........................................................................................46 Tableau 3 : Classification des cas d’utilisation par acteur................................................................47 Tableau 4 : Description textuelle du cas d’utilisation «s’authentifier»..............................................48 Tableau 5 : Description textuelle du cas d’utilisation «s’inscrire»...................................................50 Tableau 6 : Description textuelle du cas d’utilisation «Récupérer mot de passe»..............................51 Tableau 7 : Description textuelle du cas d’utilisation «Changer mot de passe».................................53 Tableau 8 : Description textuelle du cas d’utilisation «Afficher mon profil».....................................54 Tableau 9 : Description textuelle du cas d’utilisation «Modifier mon profil»....................................55 Tableau 10 : Description textuelle du cas d’utilisation «Lister catégories boutiques»........................57 Tableau 11 : Description textuelle du cas d’utilisation «Ajouter catégorie boutiques».......................58 Tableau 12 : Description textuelle du cas d’utilisation «Modifier catégorie boutiques».....................59 Tableau 13 : Description textuelle du cas d’utilisation «Supprimer catégorie boutiques»..................61 Tableau 14 : Description textuelle du cas d’utilisation «Lister vendeurs».........................................62 Tableau 15 : Description textuelle du cas d’utilisation «Supprimer vendeur»...................................63 Tableau 16 : Table «Utilisateur»...................................................................................................75 Tableau 17 : Table «Vendeur»......................................................................................................75 Tableau 18 : Table «Admin».........................................................................................................75 Tableau 19 : Table «Categorie_boutique».....................................................................................75 Tableau 20 : Table «Boutique» .....................................................................................................75 Tableau 21 : Calcul de vélocité estimée .........................................................................................82 Tableau 22 : Backlog du deuxième sprint ......................................................................................90 Tableau 23 : Classification des cas d’utilisation par acteur..............................................................90 Tableau 24 : Description textuelle du cas d’utilisation «Créer boutique».........................................92 Tableau 25 : Description textuelle du cas d’utilisation «Paramétrer ma boutique»...........................94 Tableau 26 : Description textuelle du cas d’utilisation «Lister produits»..........................................95 Tableau 27 : Description textuelle du cas d’utilisation «Ajouter produit».........................................96 Tableau 28 : Description textuelle du cas d’utilisation «Modifier produit».......................................97 Tableau 29 : Description textuelle du cas d’utilisation «Supprimer produit»....................................98 Tableau 30 : Description textuelle du cas d’utilisation «Lister boutiques»...................................... 100 Tableau 31 : Description textuelle du cas d’utilisation «Confirmer boutique» ................................ 101 Tableau 32 : Description textuelle du cas d’utilisation «Supprimer boutique»................................ 102 Tableau 33 : Description textuelle du cas d’utilisation «Verrouiller boutique»............................... 103 Tableau 34 : Description textuelle du cas d’utilisation «Consulter boutique».................................104 Tableau 35 : Description textuelle du cas d’utilisation «Ajouter boutique aux favoris» ................... 105 Tableau 36 : Description textuelle du cas d’utilisation «Lister produits boutique».......................... 106 Tableau 37 : Description textuelle du cas d’utilisation «Consulter produit»................................... 106 Tableau 38 : Table «Categorie_produit»..................................................................................... 125 Tableau 39 : Table «Marque»..................................................................................................... 125 Tableau 40 : Table «Produit» ..................................................................................................... 125 Tableau 41 : Table «Image»........................................................................................................ 125 Tableau 42 : Calcul de vélocité estimée ....................................................................................... 132 Tableau 43 : Backlog du troisième sprint..................................................................................... 136 Tableau 44 : Classification des cas d’utilisation par acteur............................................................ 137 Tableau 45 : Description textuelle du cas d’utilisation «Lister les clients» ..................................... 138 Tableau 46 : Description textuelle du cas d’utilisation «Supprimer client»..................................... 139 Tableau 47 : Description textuelle du cas d’utilisation «Lister mes commandes»............................ 140 Tableau 48 : Description textuelle du cas d’utilisation «Modifier état commande» ......................... 141
- 16. Projet de fin d’études Page 16 Tableau 49 : Description textuelle du cas d’utilisation «Lister les commandes».............................. 142 Tableau 50 : Description textuelle du cas d’utilisation «Afficher les statistiques de ma boutique».... 143 Tableau 51 : Description textuelle du cas d’utilisation «Afficher les statistiques de ma boutique».... 144 Tableau 52 : Description des APIs .............................................................................................. 153 Tableau 53 : Table «Client»........................................................................................................ 168 Tableau 54 : Table «Produit» ..................................................................................................... 168 Tableau 55 : Table «Commande»................................................................................................ 168 Tableau 56 : Table «ligne_commande»........................................................................................ 168 Tableau 57 : Calcul de vélocité estimée ....................................................................................... 174 Tableau 58 : Environnement matériel .......................................................................................... 177 Tableau 59 : Description textuelle du cas d’utilisation «Lister catégories produits»........................ 188 Tableau 60 : Description textuelle du cas d’utilisation «Ajouter catégorie produits»....................... 189 Tableau 61 : Description textuelle du cas d’utilisation «Modifier catégorie produits»..................... 191 Tableau 62 : Description textuelle du cas d’utilisation «Supprimer catégorie produits».................. 192 Tableau 63 : Description textuelle du cas d’utilisation «Lister marques» ....................................... 193 Tableau 64 : Description textuelle du cas d’utilisation «Ajouter marque»...................................... 194 Tableau 65 : Description textuelle du cas d’utilisation «Modifier marque»..................................... 195 Tableau 66 : Description textuelle du cas d’utilisation «Supprimer marque».................................. 196 Tableau 67 : Description textuelle du cas d’utilisation «Déverrouiller boutique»............................ 197 Tableau 68 : Description textuelle du cas d’utilisation «Supprimer boutique du favoris»................. 198 Tableau 69 : Description textuelle du cas d’utilisation «Ajouter produit aux favoris» ..................... 199 Tableau 70 : Description textuelle du cas d’utilisation «Supprimer produit du favoris»................... 200
- 17. Projet de fin d’études Page 17 Table des abréviations API : Application Programming Interface UML : Unified Modeling Language JSON : JavaScript Object Notation XML : eXtensible Markup Language FTP : File Transfer Protocol EDI : Environnement de Développement Intégré MVC : Model View Controller ORM : Object Relational Mapping CMS : Content Management System REST : Representational State Transfer
- 18. Projet de fin d’études Page 18 Introduction générale De nos jours, le commerce électronique a pris une place considérable dans les habitudes d’achats. Selon le site jumia.com.tn, le commerce électronique en Tunisie, ayant 5.8 millions d’internautes et un chiffre d’affaires pour l’année 2014, qui dépasse 100 millions de dinars est considéré comme un secteur dynamique. Selon aujourdhui.ma1, le commerce électronique au Maroc rejoint de plus en plus un rythme précipité. «Les commerçants et e-marchands ont enregistré, durant l’année 2015, 32.8 millions d’opérations de paiement, par cartes bancaires pour un montant global de 22,9 milliards de dirhams.»[N1] Aujourd’hui, la question est de transformer la société pour répondre aux demandes de notre nouvelle ère du numérique. En fait, chaque client a sa spécificité, donc il est devenu de plus en plus complexe de vendre mais aussi de garder nos clients. Les places de marchés viennent alors pour améliorer le ciblage et la prise de contact avec les clients, où qu’ils soient localisés et tendent de plus en plus à augmenter la compétitivité des entreprises. Elles permettent ainsi d’offrir aux vendeurs une opportunité leur permettant de diversifier leurs canaux de ventes, augmenter leur chiffres d’affaires, améliorer leur perception à l’égard des consommateurs et renforcer la visibilité de leurs produits sur le web. «La place de marché, ou marketplace, est un support mettant en relation un acheteur et des vendeurs. La place de marché intervient donc comme un intermédiaire entre la demande de l’acheteur et l’offre proposée par les commerçants en échange d’une commission.»[N2] C’est dans ce cadre que s’inscrit notre projet de fin d’études intitulé : «Conception et développement du backoffice d’une application mobile de gestion de place de marché multi- boutiques» dont l’objectif est de gérer les transactions entre les vendeurs et les acheteurs. Notre rapport est divisé comme suit : Un premier chapitre «Étude de projet» où on présentera le cadre du projet, l’état de l’art, la solution proposée, le langage de modélisation et la méthodologie adoptée. Un deuxième chapitre «Planification et architecture» qui sera la première partie dans l’application du cadre méthodologique SCRUM. Il s’agit du sprint 0. Il abordera les fonctionnalités, l’ensemble des besoins fonctionnels et non fonctionnels, les acteurs qui vont réagir avec notre système, le diagramme de cas d’utilisation général et l’équipe SCRUM affecté à ce projet avec la précision du rôle de chaque membre de l’équipe. Ce chapitre présentera également le backlog du produit, le processus de découpage de notre projet ainsi que la planification de nos sprints à l’intérieur de chaque release. Un troisième chapitre «Gestion des accès, catégories de boutiques et vendeurs» avec lequel on va initier notre première itération et donc notre premier sprint. 1 http://aujourdhui.ma/economie/e-commerce-le-grand-boom
- 19. Projet de fin d’études Page 19 Un quatrième chapitre «Gestion des boutiques, catégories de produits, marques et produits» qui représente le deuxième sprint de notre application. Un cinquième chapitre «Gestion des échanges, commandes, statistiques et clients» qui représente le troisième sprint et donc la dernière itération. Un sixième chapitre «Phase de clôture» qui comporte l’ensemble des outils utilisées lors de la conception et développement de notre projet ainsi que les technologies que nous avons utilisées pour implémenter notre application. Finalement, on clôture notre rapport par une conclusion générale qui résume tout le travail et l’effort consacré à la réalisation de ce projet ainsi que tout ce qu’on a acquis et retenu de cette expérience qui représente un point fondamental dans notre carrière.
- 20. Projet de fin d’études Page 20 Chapitre 1 Étude de projet
- 21. Projet de fin d’études Page 21 Introduction Durant ce premier chapitre, on va présenter notre projet d’une manière générale afin d’avoir une vision complète et éclairée sur celui-ci. Cette vision va nous aider à dessiner le chemin que notre projet va traverser et par conséquent on obtiendra une très bonne organisation de déroulement de ce dernier. Ce chapitre va traiter les sections relatives à la présentation de l’organisme d’accueil, l’étude et les critiques de l’existant, la solution proposée, le langage de modélisation et la méthodologie adoptée. I. Cadre du projet Le présent projet s’intitule «Conception et développement du backoffice d’une application mobile de gestion de place de marché multi-boutiques».Il a été proposé comme un projet de fin d’études en vue de l’obtention du diplôme de licence fondamentale en informatique appliquée à la gestion. Ce stage a été effectué au sein de l’agence web ITCANE. I.1. Présentationde l’organisme d’accueil «ITCANE est une agence Web en Tunisie qui opère sur le marché tunisien et international et compte parmi ses partenaires et ses clients des entreprises tunisiennes, françaises et belges. ITCANE a été fondée en 2007 par Hatem BELHASSINE. Cette société offre des solutions Web aux entreprises et ses services couvrent tous les métiers du Web. Les prestations qu’elle propose sont : Création de sites web et de portails web Développement de sites web e-commerce et boutiques en ligne Développement d'applications Web sur mesure Réalisation de sites et applications pour mobiles (smartphones et tablettes) Outsourcing et la mise à disposition d'équipes qualifiées en développement Web Conseil en stratégie Internet Hébergement et maintenance de serveurs Web et de serveurs de messagerie Vente de matériel et d'accessoires informatiques.» [N3] ITCANE propose aux entreprises des solutions web personnalisées conformément à leurs besoins et exigences. Ses clients bénéficient de sa spécialisation dans les nouvelles technologies ainsi que de son dynamisme. Elle cherche à occuper la position de leader sur le marché tunisien, pour cela, elle a signé des accords de partenariat avec des partenaires nationaux et internationaux.
- 22. Projet de fin d’études Page 22 II. État de l’art II.1.Étude de l’existant L’étude de l’existant est une étape très importante, voire essentielle lors de la réalisation d’un projet. Elle se définit par la recherche des applications qui sont similaires ou semblables à la nôtre en vue d’avoir une idée sur ce qui existe actuellement. Deux cas peuvent se présenter : Le produit existe déjà, il faut donc chercher comment améliorer ses fonctionnalités. Le produit est inexistant : il faut donc le créer. Pour nous, nous n’avons pas trouvé un produit existant déjà chez l’organisme d’accueil sur lequel on va dégager les différents points négatifs et par conséquent tenter de l'améliorer. Nous allons donc créer un nouveau produit. Pour ce faire, on doit chercher ailleurs les applications similaires à la nôtre et qui portent sur le même thème pour dégager les fonctionnalités de base communes, les points forts qui différencient une application des autres et les points faibles. Après avoir effectué une recherche, nous avons relevé quelques constats qui peuvent nous aider pour élaborer la liste des fonctionnalités de notre future application. Comme nous sommes en train de traiter la partie relative au Back Office de l’application, nous avons relevé avec difficulté quelques constats relatifs aux parties d’administration vu qu’on ne peut pas avoir un accès administrateur sur les applications existantes pour pouvoir analyser et dégager les points négatifs et même les points positifs. Le site www.joker.tn Les points positifs : 1. Facilité d’utilisation : le site joker.tn offre aux vendeurs un tableau de bord ergonomique et facile à manipuler. Si l’utilisateur ne connaît pas grand-chose en informatique, il peut quand même s’inscrire, déposer ses produits, gérer ses commandes, etc… 2. Pas de frais de maintenance : un commerçant veille toujours à mettre à jour son site web et le rendre de plus en plus sécurisé. Le site de joker n’impose pas aux vendeurs de payer des frais de maintenance. 3. Bonne visibilité des produits : Les produits du site web joker.tn sont référencés par les moteurs de recherche. Les vendeurs n’ont pas besoin de faire appel à un référenceur. Le site www.ebay.com Les points positifs : 1. Excellente visibilité des produits : Une annonce déposé par un vendeur et qui comporte un titre ayant des mots clés généralement saisis dans les barres de recherches apparaisse en premier lieu dans les résultats retournées par les moteurs de recherches.
- 23. Projet de fin d’études Page 23 2. Possibilité de cibler un grand public à l’échelle internationale : Un vendeur inscrit sur le site d’eBay peut déposer des annonces qui seront facilement perçues par des acheteurs étrangers. II.2. Critiques de l’existant Les points négatifs du site www.joker.tn : 1. Pas de représentation graphique des données statistiques. 2. Absence d’un système de notification pour avertir les vendeurs si par exemple la quantité d’un produit en stock est épuisée. 3. Les vendeurs sont soumis à des contraintes imposés par l’application. Par exemple, ils ne peuvent pas définir leurs propres catégories de produits. Ils ont une liste prédéfinie et ils sont obligés de vendre des produits qui appartiennent à des catégories disponibles. 4. Espace de vente impersonnel : Les vendeurs n’ont pas le droit ni de définir de nouvelles marques, ni de créer de nouvelles catégories pour leurs produits de façon que la vitrine d’un vendeur ressemble beaucoup à celle de son voisin. 5. Pas de possibilité d’apparition en premier : Certains vendeurs veulent que leurs boutiques apparaissent en premier lors de l’accès à une place de marché. Ils sont même prêts à payer n’importe quel prix pour se positionner en premier pour une certaine durée ce qui augmente la visibilité de leurs boutiques et par conséquent leurs produits. Les points négatifs du site www.ebay.com : 1. Espace de vente impersonnel : Le même problème constaté au niveau du site de joker.tn on le retrouve encore une autre fois dans le site d’ebay.com. La boutique d’un vendeur ressemble beaucoup à celle de son voisin de façon qu’à un premier regard, on n’arrive pas à différencier une boutique de l’autre. 2. Frais mensuel : Les vendeurs sont soumis à des frais mensuels ce qui peut être dur surtout pour ceux qui sont nouveaux dans le e-commerce et qui cherchent à attirer les acheteurs. III. Solution proposée Après avoir relevé un ensemble de constats, nous avons décidé en premier lieu de permettre à tout vendeur de notre place de marché de gérer ses propres catégories de produits et marques d’une façon indépendante des autres pour qu’il soit plus libre et bénéficie d’une notoriété personnelle. Dans notre application, le vendeur est un maître de lui-même. Il peut vendre les produits qu’il veut quelque soit leur marques, catégories, etc … Nous avons également décidé d’inclure un très bon système de gestion des statistiques et des indicateurs pour permettre aux vendeurs de visualiser l’état de leurs boutiques le plus précisément possible afin de pouvoir prendre les décisions appropriées dans les bon délais. Nous avons décidé aussi d’inclure un système de gestion des favoris qui va permettre l’affichage des boutiques et produits en premier dans l’application mobile. Ce système va
- 24. Projet de fin d’études Page 24 certainement être géré par l’administrateur de la place de marché à partir du Back Office que nous allons développer. Nous essayerons d’inclure un système de notification pour les différents acteurs de notre système s’il nous reste encore assez de temps sinon on l’ajoutera plus tard. IV. Langage et méthodologie adoptée Tout projet ayant un niveau de complexité considérable rend l’adoption d’une méthodologie de développement une nécessité pour garantir une qualité acceptable et éviter tout retard au niveau des délais. Une méthodologie de développement définit les règles de conduite de notre projet, les rôles des différents acteurs, l’ordonnancement des tâches, l’enchainement des actions, etc… IV.1. Les méthodes AGILES «La méthode Agile se base sur un cycle de développement qui porte le client au centre. Le client est impliqué dans la réalisation du début à la fin du projet. L’implication du client dans le processus permet à l’équipe d’obtenir un feedback régulier afin d’appliquer directement les changements nécessaires. Cette méthode vise à accélérer le développement d’un logiciel. De plus, elle assure la réalisation d’un logiciel fonctionnel tout au long de la durée de sa création.»[N4] ITCANE utilise les méthodologies de développement agiles comme cycle de vie pour ses projets, de même pour le projet en cours. Ce choix est basé sur les avantages offerts par ces méthodologies tels que leurs capacités d’adaptation aux changements de contexte et à l’instabilité des spécifications qui subissent des modifications fréquentes durant le processus de développement. IV.1.1. Les quatre piliers des méthodes agiles Individu et interaction au lieu de processus et outils. Logiciel fonctionnel au lieu de documentation massive Collaboration du client au lieu de négociation de contrats Réagir aux changements au lieu de suivre le plan IV.1.2. Les principales méthodes agiles Les méthodes agiles les plus connues et utilisées actuellement sont : Scrum XP (Extreme Programming) Test Driven Development Crystal Clear Suite à une réunion qu’on a faite avant le démarrage du projet, on a décidé de travailler avec SCRUM vu qu’il convient le plus à notre projet.
- 25. Projet de fin d’études Page 25 IV.2. Pourquoi SCRUM ? «Le Scrum est un Framework d’organisation de développement de produits complexes. Il est défini par ses créateurs comme un cadre de travail permettant de répondre à des problèmes complexes et changeants tout en livrant de manière productive et créative des produits de la plus grande valeur possible.»[N5] Le terme «SCRUM» se rapproche plus d’une gestion de ressources humaines plutôt que d’une réelle méthode de développement. SCRUM se base sur un ensemble d’itérations appelées également sprints d’une durée en moyenne entre deux et quatre semaines. En effet, parmi les problèmes majeurs qui peuvent se présenter avec les méthodes classiques, la faible implication du client de façon que le produit développé n’est visible qu’à la fin de sa réalisation ce qui peut engendrer un décalage important entre ce qui a été demandé par le client et ce qui a été développé. Avec SCRUM, l’équipe de projet veille toujours à satisfaire le client à travers des livraisons rapides et à avoir un contact direct avec lui. Le client intervient à la fin de chaque sprint, après la génération d’un produit potentiellement livrable pour donner son feed-back. L’équipe de projet doit ainsi réagir aux changements et ajustements demandés par le client. Le processus de Scrum peut être représenté par la figure 1. Figure 1 : Cycle de vie d’un projet Scrum [N6]
- 26. Projet de fin d’études Page 26 IV.2.1. Rôles définis par Scrum Les rôles définis par la méthode Scrum : Le Product Owner : Il s’agit du propriétaire du produit. La définition des exigences du produit et l’ajustement de ses fonctionnalités au cours des itérations sont parmi ses missions. C’est lui qui confirme ou refuse la version partiellement livrable présentée. L’équipe de développement : L’équipe de développement est généralement d’une taille de 4 à 6 membres. Elle est multi compétente et auto-organisée. Elle est engagée à livrer un produit partiellement livrable à la fin de chaque sprint. Le Scrum Master : Il s’agit d’un membre de l’équipe qui doit essentiellement bien connaître Scrum. Il doit également être courageux pour pouvoir communiquer sincèrement sur l’état d’avancement du projet. Il vérifie aussi si les membres de l’équipe sont en train de bien appliquer la méthode Scrum. De plus, il résout les conflits et les obstacles rencontrés ainsi qu’il contrôle le niveau de production de l’équipe. IV.2.2. Les artéfacts de Scrum Product Backlog Le backlog de produit, appelé également «carnet du produit» contient l’ensemble des exigences et des besoins exprimés par le client. Comme les besoins du client sont généralement instables, ce carnet va subir des changements de façon fréquente au cours du projet. Ce dynamisme affectant le backlog de produit est un avantage majeur de la méthode Scrum. «Le product backlog est un document qui contient les exigences initiales dressées puis hiérarchisées avec le client en début de projet. Néanmoins il va évoluer tout au long de la durée du projet, en fonction des divers besoins du client.»[N4] Sprint Backlog Le sprint backlog, appelé également «carnet de sprint » est l’ensemble de fonctionnalités extraites à partir du backlog de produit et qui vont être réalisés au cours d’un sprint bien déterminé. «En chaque début de sprint, l’équipe définit un but. Puis lors de la réunion de sprint, l’équipe de développement choisit les éléments du carnet à réaliser. L’ensemble de ces éléments constitue alors le sprint backlog.»[N4] Burn Down Chart Le Burndown Chart, appelé également «graphique d’avancement» permet à une équipe travaillant sur un projet de visualiser son état d’avancement par rapport à ce qui a été planifié au début du sprint. Ce graphe doit être actualisé régulièrement afin de prendre les mesures nécessaires dans les bons moments.
- 27. Projet de fin d’études Page 27 Figure 2 : Diagramme de Burndown Chart [N7] IV.2.3. Les activités du sprint Planification d’itération La planification d’itération se traduit par une réunion où les membres de l’équipe tentent de fixer les objectifs du sprint en question et les fonctionnalités qui vont être développés au cours de celui-ci. Mêlée quotidienne Il s’agit d’une réunion très courte dont l’objectif est de permettre à chaque membre de l’équipe de présenter son état d’avancement vers l’atteinte de l’objectif du sprint fixé lors de la planification d’itération. Pour mieux tirer les avantages de cette réunion, les membres de l’équipe doivent un par un répondre aux questions suivantes : - Qu’avez-vous fait depuis la dernière mêlée ? - Quels sont les obstacles que vous avez rencontrés au cours de votre avancement ? - Que ce que vous allez faire d’ici à la prochaine mêlée ? Revue d’itération La revue d’itération est une activité faite régulièrement à la fin du développement d’un sprint donné. Le Product Owner est responsable dans cette étape de la comparaison du produit livré par l’équipe par rapport aux engagements établis au cours de la planification d’itération. La revue d’itération est suivie par un nouveau sprint et donc une nouvelle itération avec le cycle quotidien : planification, développement et revue. «La revue d'itération est le moment où l'on présente le travail de l'équipe. C'est l'occasion, pour l'équipe, de célébrer ses réussites, de présenter les tâches terminées dans le cadre de l'itération et d'obtenir un feedback immédiat de la part des parties prenantes du projet. Les tâches doivent être complètement présentables et répondre aux critères de qualité de l'équipe pour être considérées comme terminées et prêtes pour la revue.»[N8]
- 28. Projet de fin d’études Page 28 Rétrospective de sprint : Il s’agit d’une réunion qui aura lieu à la fin du sprint. Cette fois-ci, c’est le Scrum Master qui intervient pour organiser cette réunion. Au cours de cette rencontre, les idées de chaque membre de l’équipe sont prises en considération en vue d’améliorer le rendement global de l’équipe «La rétrospective du sprint est faite en interne avec toute l’équipe du projet le dernier jour de l’itération. L’objectif est d’inspecter l’itération précédente, afin de déterminer quels sont les éléments du processus de développement qui ont bien fonctionné et ceux qui sont à améliorer. Chaque membre de l’équipe s’exprime sur le déroulement de l’itération, afin d’améliorer en continu le processus projet.»[N5] IV.3. Langage de modélisation «UML (en anglais Unified Modeling Language ou «langage de modélisation unifié») est un langage de modélisation graphique à base de pictogrammes. Il est apparu dans le monde du génie logiciel, dans le cadre de la «conception orientée objet». Couramment utilisé dans les projets logiciels, il peut être appliqué à toutes sortes de systèmes ne se limitant pas au domaine informatique. UML est l’accomplissement de la fusion de précédents langages de modélisation objet : Booch, OMT et OOSE.»[N9] Deux points importants qu’on peut retenir de la notation «UML» : Le terme ‘Unified’ parce que des auteurs ont essayé de regrouper les fondamentaux des concepts objets. Le terme ‘Language’ parce qu’on parle d’un langage de modélisation et non pas d’une méthode. Pour notre projet, nous avons opté pour l’utilisation d’UML (Unified Modeling Language) comme langage de modélisation. Conclusion Dans ce chapitre, nous avons présenté le cadre de notre projet, ensuite nous avons dégagé une liste comportant les critiques de l’existant, et en se basant sur cette liste, nous avons proposé une solution qui tente de résoudre quelques problèmes constatés. Enfin, nous avons évoqué le choix du langage de modélisation et de la méthodologie adoptée. À ce niveau, nous pouvons passer au chapitre suivant qui comportera la planification et l’architecture du projet.
- 29. Projet de fin d’études Page 29 Chapitre 2 Planification et architecture
- 30. Projet de fin d’études Page 30 Introduction Dans ce chapitre, nous allons commencer à élaborer la première phase de la méthodologie Scrum, appelée également «planification et architecture» ou «sprint zéro». L’objectif de ce chapitre est d’établir une vision globale de notre produit, dégager les besoins et les fonctionnalités, identifier les acteurs qui vont interagir avec notre système, élaborer la planification des releases, établir le backlog de produit et finalement préparer la planification initiale des sprints et le planning de réalisation du projet. La particularité de ce sprint se manifeste par le fait qu’on n’aura pas un produit potentiellement livrable à la fin de sa réalisation. Cette phase de planification et architecture est consacrée essentiellement à la préparation de l’environnement de développement. I. Spécification des besoins Nous commençons par l’identification des acteurs puis l’extraction des besoins fonctionnels et non fonctionnels. I.1. Identifier les acteurs «Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié. Un acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des messages susceptibles d’être porteurs de données.»[B1] Notre projet se déroule dans le contexte de développement du back office qui donne l’accès seulement à l’administrateur et aux vendeurs de la place de marché tout en donnant à chacun d’eux des privilèges bien déterminés. Notre application va interagir avec deux acteurs : Administrateur : Un acteur qui va accéder au Back Office et gérer l’ensemble des composants de la place de marché (clients, vendeurs, boutiques, etc…) ainsi que d’afficher des informations utiles tel que des indicateurs et des statistiques sur les ventes de toute la place de marché. Vendeur : Un acteur qui va accéder au BackOffice, créer un compte, créer et paramétrer sa boutique, gérer l’ensemble de ses produits, catégories de produits, marques et les commandes de ses clients ainsi que d’afficher des informations utiles tel que des indicateurs et statistiques sur les ventes de sa boutique. I.2. Besoins fonctionnels Les besoins fonctionnels expriment ce que doit effectuer le système afin de répondre à ce qui a été demandé par le client.
- 31. Projet de fin d’études Page 31 Ces besoins englobent ainsi la représentation abstraite des services que le système est censé fournir aux différents utilisateurs. Notre système doit permettre : La création d’un compte : Notre système doit permettre la création d’un compte pour qu’un vendeur puisse rejoindre la place de marché. La gestion des catégories de boutiques : Notre système doit permettre la gestion des catégories de boutiques avec la possibilité d’ajout, de modification et de suppression. La gestion des boutiques : Notre système doit permettre la gestion des boutiques avec la possibilité d’ajout, de modification, de suppression, de confirmation, de verrouillage et d’ajout aux favoris. Afin de pouvoir déposer ses produits, le vendeur doit créer et paramétrer sa propre boutique. La définition des paramètres des boutiques, tel que par exemple leur catégorie permet à un client de filtrer l’affichage des boutiques selon ce critère. La gestion des catégories de produits : Notre système doit permettre la gestion des catégories de produits avec la possibilité d’ajout, de modification et de suppression. Chaque vendeur peut définir ses propres catégories de produits qu’il envisage utiliser au futur. En effet pour ajouter un produit, le vendeur aura une liste de catégories personnalisées et aura seulement le choix de sélectionner cette dernière parmi la liste qu’il a défini. La gestion des marques : Notre système doit permettre la gestion des marques avec la possibilité d’ajout, de modification et de suppression. La gestion des produits : Notre système doit permettre la gestion des produits avec la possibilité d’ajout, de modification, de consultation, d’ajout aux favoris et de suppression. Un vendeur doit bien sûr pouvoir ajouter ou supprimer un produit, lister l’ensemble des produits existants dans sa boutique et modifier les caractéristiques d’un produit tel que la description, le nombre d’exemplaires (Quantité en stock), etc… La gestion des commandes : Notre système doit permettre la gestion des commandes avec la possibilité de modification d’état d’une commande spécifique. La gestion des clients : Notre système doit permettre la gestion des clients avec la possibilité de suppression. La gestion des vendeurs : Notre système doit permettre la gestion des vendeurs avec la possibilité de suppression. La gestion des statistiques : Notre système doit permettre l’affichage d’un tableau de bord comportant des indicateurs et des statistiques. I.3 Besoins non fonctionnels Il s’agit des besoins qui peuvent être perçus par l’utilisateur et qui sont reliés indirectement au comportement du système.
- 32. Projet de fin d’études Page 32 Les besoins non fonctionnels de notre système se décrivent comme suit : Ergonomie : Le back office doit être facile à utiliser. Il doit y avoir une certaine cohérence et homogénéité entre les différentes interfaces pour les utilisateurs. Rapidité : Les traitements doivent être optimisés pour avoir un court temps de réponse. Efficacité: L’application doit être fonctionnelle indépendamment de toutes circonstances pouvant entourer l’utilisateur. Sécurité : Assurance de la confidentialité et sécurité des données. Maintenabilité : La solution doit être facile à maintenir. II. Structure et découpage du projet Nous commençons par l’identification de l’équipe Scrum, l’établissement du backlog de produit, la planification des releases et finalement la structuration de ces derniers en sprints. II.1. Identification de l’équipe Scrum Dans un projet SCRUM, l’équipe a un rôle fondamental : elle permet d’optimiser la productivité et la flexibilité. En effet, Elle doit être auto organisée et multifonctionnelle. «L’équipe Scrum est auto-organisée et choisit la façon d'accomplir son travail, sans que ce soit imposé par une personne externe. Il n'y a pas non plus de notion de hiérarchie interne : toutes les décisions sont prises ensemble. Ce mode d'organisation a pour objectif d'augmenter l'efficacité de travail de l'équipe. Elle est pluridisciplinaire et comporte toutes les compétences pour réaliser son projet, sans faire appel à des personnes externes à celle-ci.»[N10] Cette méthode agile intègre généralement la participation de plusieurs acteurs, dans notre contexte il s’agit de M. Hatem Belhassine qui est à la fois le propriétaire et le directeur de produit vu qu’il satisfait les prérequis de ces deux acteurs tout en mentionnant que l’équipe se compose de deux membres : Rami Raddaoui et Mounir Homrani.
- 33. Projet de fin d’études Page 33 Figure 3 : Équipe et rôles II.2. Le Backlog du Produit Le backlog du produit est l’ensemble des fonctionnalités attendues du produit. C’est l’ensemble des spécifications fonctionnelles et techniques de ce dernier. «Le Backlog de produit est un élément indispensable de toute démarche Scrum. C’est une liste ordonnée de tout ce qui pourrait être requis dans le produit. Il retrace la vision utilisateur et reste ouvert et évolutif sur toute la durée du projet. Géré sous la responsabilité du PO, il est créé par décomposition successive à partir de la vision du produit.»[N5] ID Fonctionnalité ID Users Stories Priorité Risque 1 Gestion d’inscription et d’authentification 1.1 En tant que vendeur, je veux m’inscrire et créer mon propre compte. Elevé Faible 1.2 En tant qu’utilisateur, je veux récupérer mon mot de passe en cas d’oubli. Moyenne Moyen 1.3 En tant qu’utilisateur, je veux m’authentifier via mon email et mon mot de passe en toute sécurité. Elevé Faible 2 Gestion des boutiques 2.1 En tant que vendeur, je veux créer ma boutique. Elevé Faible 2.2 En tant que vendeur, je veux paramétrer ma boutique. Elevé Faible 2.3 En tant qu’administrateur, je veux lister les boutiques. Elevé Faible 2.4 En tant qu’administrateur, je veux accepter/refuser la publication d’une boutique Elevé Faible
- 34. Projet de fin d’études Page 34 suite à la demande d’un vendeur. 2.5 En tant qu’administrateur, je veux verrouiller/déverrouiller une boutique. Moyenne Faible 2.6 En tant qu’administrateur, je veux ajouter/supprimer une boutique du favoris. Faible Faible 2.7 En tant qu’administrateur, je veux consulter une boutique. Elevé Faible 2.8 En tant qu’administrateur, je veux supprimer une boutique. Elevé Faible 3 Gestion des produits 3.1 En tant que vendeur, je veux afficher la liste des produits de ma boutique. Elevé Faible 3.2 En tant que vendeur, je veux ajouter un ou plusieurs produits. Elevé Moyen 3.3 En tant que vendeur, je veux modifier un produit appartenant à ma boutique. Elevé Moyen 3.4 En tant que vendeur, je veux supprimer un produit appartenant à ma boutique Elevé Faible 3.5 En tant qu’administrateur, je veux lister les produits d’une boutique spécifique. Elevé Faible 3.6 En tant qu’administrateur, je veux consulter un produit d’une boutique spécifique. Moyenne Faible 3.7 En tant qu’administrateur, je veux ajouter/supprimer un produit spécifique du favoris. Faible Faible 4 Gestion des commandes 4.1 En tant que vendeur, je veux afficher la liste des commandes relatives à mes clients. Elevé Faible 4.2 En tant que vendeur, je veux modifier l’état d’une commande spécifique. Elevé Faible 4.3 En tant qu’administrateur, je veux afficher la liste des commandes de toute la place de marché. Elevé Faible 4.4 En tant que vendeur, je veux exporter la liste de mes commandes. Faible Faible
- 35. Projet de fin d’études Page 35 4.5 En tant qu’administrateur, je veux exporter la liste des commandes de toute la place de marché. Faible Faible 5 Gestion des marques 5.1 En tant que vendeur, je veux lister mes marques. Elevé Faible 5.2 En tant que vendeur, je veux créer une ou plusieurs marques. Elevé Faible 5.3 En tant que vendeur, je veux modifier une marque spécifique parmi la liste des marques créées. Elevé Faible 5.4 En tant que vendeur, je veux supprimer une marque spécifique parmi la liste des marques créées. Elevé Faible 6 Gestion des catégories de produits 6.1 En tant que vendeur, je veux lister mes catégories de produits. Elevé Faible 6.2 En tant que vendeur, je veux créer une ou plusieurs catégories de produits. Elevé Faible 6.3 En tant que vendeur, je veux modifier une catégorie de produit spécifique parmi la liste des catégories créées. Elevé Faible 6.4 En tant que vendeur, je veux supprimer une catégorie de produit spécifique parmi la liste des catégories créées. Elevé Faible 7 Gestion des catégories de boutiques 7.1 En tant qu’administrateur, je veux lister les catégories de boutiques. Elevé Faible 7.2 En tant qu’administrateur, je veux créer une ou plusieurs catégories de boutiques. Elevé Faible 7.3 En tant qu’administrateur, je veux modifier une catégorie de boutiques. Elevé Faible 7.4 En tant qu’administrateur, je veux supprimer une catégorie de boutique. Elevé Faible 8 Gestion des vendeurs 8.1 En tant qu’administrateur, je veux afficher la liste des vendeurs. Elevé Faible 8.2 En tant qu’administrateur, je veux supprimer un vendeur spécifique. Elevé Faible
- 36. Projet de fin d’études Page 36 9 Gestion des clients 9.1 En tant qu’administrateur, je veux afficher la liste des clients. Elevé Faible 9.2 En tant qu’administrateur, je veux supprimer un client spécifique. Elevé Faible 10 Gestion des indicateurs et statistiques 10.1 En tant que vendeur, je veux afficher des indicateurs et statistiques sur les ventes de ma boutique. Moyenne Moyen 10.2 En tant qu’administrateur, je veux afficher des indicateurs et statistiques sur les ventes de toute la place de marché. Moyenne Moyen Tableau 1 : Backlog du produit II.3. Planificationdes releases Pour mener à bien un projet Scrum, on doit découper notre système en release(s). Chaque release comporte une succession de sprints qui à leur tours contribuent à la livraison d’un produit présentant suffisamment de valeurs pour ses utilisateurs. La décomposition d’un projet en releases, nous permet d’obtenir à la fin de chaque release un produit qui peut être livré et qui est indépendant des autres releases du même projet. Notre projet peut alors être décomposé en 2 releases : Un release du back office. Un release du front office. Comme nous sommes en train de traiter seulement la partie du Back Office, nous allons alors nous concentrer seulement sur le premier release. Le release du front office va être traité par un autre membre de l’équipe sachant qu’il faut garder une certaine cohérence entre les 2 releases car à un moment donné, les deux parties vont communiquer ensemble pour l’échange des données d’où se traduit l’importance de la communication entre les membres de l’équipe. Notre release va alors comporter les features qui sont étroitement liés et ayant une forte dépendance entre eux. Après avoir fixé notre release, il nous reste que la structuration de ce dernier en sprints. La figure 4 montre le concept du découpage des releases en sprints.
- 37. Projet de fin d’études Page 37 Figure 4:Découpage des releases en sprints II.4. Structuration des releases en sprints Dans cette section, nous allons établir la planification de nos sprints à l’intérieur des releases qu’on a fixés précédemment. Figure 5:Planification des sprints • Inscription • Authentification • Récupération du mot de passe • Changement des paramètres de connexion • Gestion profil • Gestion catégories de boutiques • Gestion vendeurs Sprint 1 : Gestion des accès, catégories de boutiques et vendeurs 02/03 - 21/03 • Gestion boutiques • Gestion produits • Gestion marques • Gestion catégories de produits Sprint 2 : Gestion des boutiques, catégories de produits, marques et produits. 22/03 - 10/04 • Gestion indicateurs et statistiques • Gestion des APIs • Gestion clients • Gestion commandes Sprint 3 : Gestion des échanges, clients,commandes et statistiques. 11/04 - 30/04
- 38. Projet de fin d’études Page 38 II.4.1 Planning de réalisationdu projet Pour gérer ce projet, tout au long de la période de stage, la figure 6 montre le planning qu’on suivra. Figure 6:Planning de réalisation du projet 04/02 – 17/02 : Autoformation. 18/02 – 01/03 : Étude de l’existant et familiarisation avec le projet. 02/03 – 21/03 : Sprint 1 : Gestion des accès, catégories de boutiques et vendeurs. 22/03 – 10/04 : Sprint 2 : Gestion des boutiques, catégories de produits, marques et produits. 11/04 – 30/04 : Sprint 3 : Gestion des échanges, clients, commandes et statistiques. 01/05 – 12/05 : Liaison et enchainements entre les sprints 13/05 : Dépôt du rapport. II.5. Diagramme de cas d’utilisation global Le diagramme de cas d’utilisation global nous permet d’avoir une vision abstraite du comportement de notre système. Autoformation Etude de l'existant et familiarisation avec le projet Sprint1 Sprint2Sprint3 Liaison et enchainements entre les sprints Dépôt du rapport
- 39. Projet de fin d’études Page 39 Figure 7 : Diagramme de cas d’utilisation global
- 40. Projet de fin d’études Page 40 Conclusion Au cours de ce chapitre, nous avons réalisé la planification qu’on comptera suivre dans notre projet. Nous avons également identifié les acteurs, l’équipe Scrum de notre projet et dégagé le backlog de produit à partir des besoins fonctionnels et non fonctionnels capturés. Ensuite, nous avons élaboré la planification de nos releases et établi la structuration des sprints à l’intérieur des releases ainsi que le planning de réalisation de notre projet. Finalement, nous avons établi un diagramme de cas d’utilisation global de notre projet. Dans le chapitre suivant, nous allons entamer notre premier sprint, qui à la fin de celui-ci on va avoir notre première version potentiellement livrable.
- 41. Projet de fin d’études Page 41 Chapitre 3 Sprint 1 : Gestion des accès, catégories de boutiques et vendeurs
- 42. Projet de fin d’études Page 42 Introduction : Dans le chapitre précédent, nous avons défini et analysé les différents besoins fonctionnels relatifs à notre projet. Ensuite, nous avons découpé notre projet afin de mener à bien sa planification. Dans ce chapitre, nous allons traiter les histoires utilisateurs (Users Stories) du sprint qu’on vient d’initier afin de réaliser un incrément potentiellement livrable. Le but de notre sprint doit être déterminé avant de commencer sa réalisation. Une question qui se pose toujours en démarrant un sprint «Pourquoi faisons-nous ce sprint ?» La réponse à cette question devra être compréhensible à l’intérieur et à l’extérieur de l’équipe. Chaque User story va passer par les quatre étapes du cycle Scrum qui sont : La spécification fonctionnelle La conception L’implémentation Les tests I. La spécification fonctionnelle «Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une vision globale du comportement fonctionnel d'un système logiciel.»[N11] À l’initiation de chaque itération, la spécification fonctionnelle est représentée par un diagramme de cas d’utilisation. Ce dernier va donner une vision globale du système et définir les différentes interactions entre celui-ci et les utilisateurs. I.1. Le sprint backlog Il s’agit de l’ensemble de fonctionnalités extraites par l’équipe Scrum à partir du backlog de produit et qui vont être réalisées au cours de ce sprint. Le tableau 2 englobe le backlog du premier sprint. ID User Story User Story ID tâche Tâche Affectation 1 En tant que utilisateur, je veux m’authentifier 1.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «s’authentifier» Rami Raddaoui 1.2 Implémenter le cas Rami
- 43. Projet de fin d’études Page 43 d’utilisation «s’authentifier» Raddaoui 1.3 Tester le cas d’utilisation «s’authentifier» Rami Raddaoui 2 En tant que vendeur, je veux m’inscrire et créer mon propre compte. 2.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «s’inscrire» Rami Raddaoui 2.2 Implémenter le cas d’utilisation «s’inscrire» Rami Raddaoui 2.3 Tester le cas d’utilisation «s’inscrire» Rami Raddaoui 3 En tant qu’utilisateur, je veux récupérer mon mot de passe en cas d’oubli. 3.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «Récupérer mot de passe» Rami Raddaoui 3.2 Implémenter le cas d’utilisation «Récupérer mot de passe» Rami Raddaoui 3.3 Tester le cas d’utilisation «Récupérer mot de passe» Rami Raddaoui 4 En tant qu’utilisateur, je veux changer mon mot de passe. 4.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «Changer mot de passe» Rami Raddaoui 4.2 Implémenter le cas d’utilisation «Changer mot de passe» Rami Raddaoui
- 44. Projet de fin d’études Page 44 4.3 Tester le cas d’utilisation «Changer mot de passe» Rami Raddaoui 5 En tant que vendeur, je veux afficher mon profil. 5.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «afficher mon profil» Rami Raddaoui 5.2 Implémenter le cas d’utilisation «afficher mon profil» Rami Raddaoui 5.3 Tester le cas d’utilisation «afficher mon profil» Rami Raddaoui 6 En tant que vendeur, je veux modifier mon profil. 6.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «modifier mon profil» Rami Raddaoui 6.2 Implémenter le cas d’utilisation «modifier mon profil» Rami Raddaoui 6.3 Tester le cas d’utilisation «modifier mon profil» Rami Raddaoui 7 En tant qu’administrateur, je veux lister les catégories de boutiques. 7.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «lister catégories boutiques» Rami Raddaoui 7.2 Implémenter le cas d’utilisation «lister Rami Raddaoui
- 45. Projet de fin d’études Page 45 catégories boutiques» 7.3 Tester le cas d’utilisation «lister catégories boutiques» Rami Raddaoui 8 En tant qu’administrateur, je veux créer une ou plusieurs catégories de boutiques. 8.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «ajouter catégorie boutique» Rami Raddaoui 8.2 Implémenter le cas d’utilisation «ajouter catégorie boutique» Rami Raddaoui 8.3 Tester le cas d’utilisation «ajouter catégorie boutique» Rami Raddaoui 9 En tant qu’administrateur, je veux modifier une catégorie de boutiques. 9.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «modifier catégorie boutique» Rami Raddaoui 9.2 Implémenter le cas d’utilisation «modifier catégorie boutique» Rami Raddaoui 9.3 Tester le cas d’utilisation «modifier catégorie boutique» Rami Raddaoui 10 En tant qu’administrateur, je veux supprimer une catégorie de boutiques. 10.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «supprimer catégorie boutique» Rami Raddaoui
- 46. Projet de fin d’études Page 46 10.2 Implémenter le cas d’utilisation «supprimer catégorie boutique» Rami Raddaoui 10.3 Tester le cas d’utilisation «supprimer catégorie boutique» Rami Raddaoui 11 En tant qu’administrateur, je veux lister les vendeurs. 11.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «lister vendeurs» Rami Raddaoui 11.2 Implémenter le cas d’utilisation «lister vendeurs» Rami Raddaoui 11.3 Tester le cas d’utilisation «lister vendeurs» 12 En tant qu’administrateur, je veux supprimer un vendeur. 12.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «supprimer vendeur» Rami Raddaoui 12.2 Implémenter le cas d’utilisation «supprimer vendeur» Rami Raddaoui 12.3 Tester le cas d’utilisation «supprimer vendeur» Rami Raddaoui Tableau 2 : Backlog du premier sprint I.2 Classificationdes cas d’utilisations par acteur Acteur Cas d’utilisation Vendeur S’inscrire S’authentifier Récupérer mot de passe Changer mot de passe Afficher mon profil Modifier mon profil
- 47. Projet de fin d’études Page 47 Administrateur S’authentifier Récupérer mot de passe Changer mot de passe Lister catégories boutiques Ajouter catégorie boutique Modifier catégorie boutique Supprimer catégorie boutique Lister vendeurs Supprimer vendeur Tableau 3 : Classification des cas d’utilisation par acteur I.3 Diagramme de cas d’utilisation La figure 8 représente le diagramme de cas d’utilisation général de notre premier sprint. Figure 8 : Diagramme de cas d’utilisation du premier sprint D’après ce qu’on a explicité dans le tableau 1, tout utilisateur du système peut récupérer son mot de passe en cas d’oubli en accédant à la fonctionnalité «Récupérer mot de passe». Un utilisateur du système authentifié, quelque soit son type peut changer son mot de passe actuel en accédant à la fonctionnalité «Changer mot de passe». Un vendeur authentifié peut gérer son profil en accédant à la fonctionnalité «Gérer mon profil». Pour y parvenir, il doit accéder à la fonctionnalité «S’inscrire» en premier lieu afin d’obtenir des identifiants de connexion lui permettant d’accéder à l’application en toute sécurité.
- 48. Projet de fin d’études Page 48 II. Analyse des cas d’utilisations Pour que les cas d’utilisation soient plus compréhensibles, nous avons mis en place le raffinement de chacun dans le but de livrer une description sur les différents scénarios qui peuvent se présenter. II.1 Analyse du cas d’utilisation «s’authentifier» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «s’authentifier». Description textuelle du cas d’utilisation «s’authentifier» : Cas d’utilisation S’authentifier Acteur Utilisateur (Vendeur/Administrateur) Pré condition Utilisateur inscrit et possède des identifiants de connexion Post condition Utilisateur authentifié Description du scénario principal 1. Le système affiche le formulaire de connexion 2. L’utilisateur saisit ses identifiants (email et mot de passe) dans les champs appropriés et valide le formulaire. 3. Le système vérifie les informations saisies par l’utilisateur. 4. Le système affiche l’interface appropriée selon le type d’acteur. Exception 3.1 Un message d’erreur est affiché si l’email et/ou le mot de passe est erroné. Tableau 4 : Description textuelle du cas d’utilisation «s’authentifier» Diagramme de séquences système du cas d’utilisation «s’authentifier» La figure 9 représente le diagramme de séquences système du cas «s’authentifier».
- 49. Projet de fin d’études Page 49 Figure 9 : Diagramme de séquences système du cas d’utilisation «s’authentifier» Chaque utilisateur doit saisir son email et son mot de passe afin d’accéder aux services offerts par l’application. Ces identifiants seront chargés dans le système qui va les vérifier. Si les identifiants sont valides, l’utilisateur accède en toute sécurité aux différents services dont il est autorisé selon son rôle. Dans le cas contraire, un message d’erreur est affiché indiquant que les identifiants saisis sont invalides. II.2 Analyse du cas d’utilisation «s’inscrire» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «s’inscrire». Descriptiontextuelle du cas d’utilisation «S’inscrire» : Cas d’utilisation S’inscrire Acteur Vendeur Pré condition Néant Post condition Vendeur inscrit Description du scénario principal 1. Le système affiche le formulaire d’inscription. 2. Le vendeur remplit le formulaire d’inscription et valide le formulaire. 3. Le système vérifie les informations saisies par le vendeur. 4. Le système affiche un message indiquant que la demande de création do compte a été enregistrée et qu’un message de confirmation est envoyé par email.
- 50. Projet de fin d’études Page 50 Exception 3.1 Un message d’erreur est affiché si l’email existe déjà. Un message d’erreur est affiché si l’un des champs obligatoires est vide et/ou invalide . Tableau 5 : Description textuelle du cas d’utilisation «s’inscrire» Diagramme de séquences système du cas d’utilisation «S’inscrire» : La figure 10 représente le diagramme de séquences système de la fonctionnalité «s’inscrire» de notre sprint. Figure 10 : Diagramme de séquences système du cas d’utilisation «s’inscrire» Chaque utilisateur voulant s’inscrire en tant que vendeur doit remplir le formulaire d’inscription. Les données saisies seront chargées dans le système qui va vérifier d’abord que l’email indiqué est inexistant et passer ensuite à la vérification des données saisies. Si toutes les données sont valides, un message indiquant que la création de compte a été effectuée avec succès et qu’un message de confirmation a été envoyé au vendeur par email est affiché. Dans le cas contraire, le système affiche le(s) message(s) d’erreur approprié(s).
- 51. Projet de fin d’études Page 51 II.3 Analyse du cas d’utilisation «Récupérer mot de passe» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Récupérer mot de passe». Description textuelle du cas d’utilisation «Récupérer mot de passe» : Cas d’utilisation Récupérer mot de passe Acteur Utilisateur (Vendeur/Administrateur) Pré condition Néant Post condition Email de récupération envoyé à l’utilisateur concerné. Description du scénario principal 1. Le système affiche le formulaire de récupération de mot de passe. 2. L’utilisateur saisi son adresse email et valide le formulaire. 3. Le système vérifie l’adresse email introduite par l’utilisateur. 4. Le système affiche un message indiquant qu’un email de récupération a été envoyé à l’adresse indiquée. Exception 3.1 Un message d’erreur est affiché si aucun compte n’est associé à l’adresse email introduite. Un message d’erreur est affiché si le champ d’adresse email est vide et/ou invalide . Tableau 6 : Description textuelle du cas d’utilisation «Récupérer mot de passe» Diagramme de séquences système du cas d’utilisation «Récupérer mot de passe» : La figure 11 représente le diagramme de séquences système de la fonctionnalité «Récupérer mot de passe» de notre sprint.
- 52. Projet de fin d’études Page 52 Figure 11 : Diagramme de séquences système du cas d’utilisation «Récupérer mot de passe» Chaque utilisateur voulant récupérer son mot de passe oublié doit remplir le formulaire de récupération. L’adresse email saisie sera chargée dans le système qui va vérifier qu’elle est valide et existante. En cas de succès, un message indiquant que la demande de récupération de mot de passe a été retenue est affiché et qu’un message de récupération a été envoyé à l’utilisateur concerné par email. Dans le cas contraire, le système affiche le message d’erreur approprié. L’utilisateur consulte son adresse email et clique sur le lien reçu pour afficher le formulaire de récupération où il doit saisir son nouveau mot de passe et valider cette opération. II.4 Analyse du cas d’utilisation «Changermotde passe» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Changer mot de passe». Description textuelle du cas d’utilisation «Changer mot de passe» Cas d’utilisation Changer mot de passe Acteur Utilisateur (Vendeur/Administrateur) Pré condition Utilisateur authentifié Post condition Mot de passe changé Description du scénario principal 1. L’utilisateur clique sur changer mon mot de passe. 2. Le système affiche le formulaire de changement de mot de passe.
- 53. Projet de fin d’études Page 53 3. L’utilisateur remplit et valide le formulaire. 4. Le système vérifie les données saisies par l’utilisateur. 5. Le système affiche un message indiquant que le mot de passe a été changé avec succès. Exception 4.1. Un message d’erreur est affiché si l’un des champs obligatoires est vide et/ou invalide . Tableau 7 : Description textuelle du cas d’utilisation «Changer mot de passe» Diagramme de séquences système du cas d’utilisation «Changer mot de passe» La figure 12 représente le diagramme de séquences système de la fonctionnalité «Changer mot de passe» de notre sprint. Figure 12 : Diagramme de séquences système du cas d’utilisation «Changer mot de passe» Chaque utilisateur voulant changer son mot de passe doit remplir le formulaire qui apparait en cliquant sur le lien «Changer mon mot de passe». Les données saisies seront chargées dans le système qui va les vérifier. En cas de succès, un message est affiché pour dire que le mot de passe a été changé avec succès. Dans le cas contraire, le système affiche le(s) message(s) d’erreur approprié(s).
- 54. Projet de fin d’études Page 54 II.5 Analyse du cas d’utilisation «Gérer mon profil» Nous commençons par le raffinement du cas d’utilisation «Gérer mon profil». II.5.1 Raffinement du cas d’utilisation «Gérer mon profil» Figure 13 : Diagramme de cas d’utilisation de «Gérer mon profil» II.5.1.1 Analyse du cas d’utilisation «Afficher mon profil» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Afficher mon profil». Description textuelle du cas d’utilisation «Afficher mon profil» Cas d’utilisation Afficher mon profil Acteur Vendeur Pré condition Vendeur authentifié Post condition Ensemble des informations personnelles affichées Description du scénario principal 1. Le vendeur clique sur le lien «Mon profil». 2. Le système affiche l’ensemble des informations personnelles dans un formulaire. Exception Néant Tableau 8 : Description textuelle du cas d’utilisation «Afficher mon profil» Diagramme de séquences système du cas d’utilisation «Afficher mon profil» La figure 14 représente le diagramme de séquences système de la fonctionnalité «Afficher mon profil» de notre sprint.
- 55. Projet de fin d’études Page 55 Figure 14 : Diagramme de séquences système du cas d’utilisation «Afficher mon profil» II.5.1.2 Analyse du cas d’utilisation «Modifiermon profil» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Modifier mon profil». Descriptiontextuelle du cas d’utilisation «Modifiermon profil» Cas d’utilisation Modifier mon profil Acteur Vendeur Pré condition Vendeur authentifié. Profil affiché. Post condition Profil mis à jour. Description du scénario principal 1. Le vendeur modifie un ou plusieurs champs de son profil. 2. Le vendeur valide le formulaire. 3. Le système vérifie les données saisies par le vendeur. 4. Le système affiche un message au vendeur indiquant que son profil est mis à jour. Exception 3.1 Un message d’erreur est affiché si l’un des champs obligatoire est vide et/ou invalide. Tableau 9 : Description textuelle du cas d’utilisation «Modifier mon profil» Diagramme de séquences système du cas d’utilisation «Modifier mon profil» La figure 15 représente le diagramme de séquences système de la fonctionnalité «Modifier mon profil» de notre sprint.
- 56. Projet de fin d’études Page 56 Figure 15 : Diagramme de séquences système du cas d’utilisation «Modifier mon profil» Le vendeur modifie ses informations personnelles et valide le formulaire. Les données saisies seront chargées dans le système qui va les vérifier. En cas de succès, un message indiquant que le profil est mis à jour avec succès est affiché. Dans le cas contraire, le système affiche le(s) message(s) d’erreur approprié(s). II.6 Analyse du cas d’utilisation «Gérer catégories boutiques» Nous commençons par le raffinement du cas d’utilisation «Gérer catégories boutiques». II.6.1 Raffinement du cas d’utilisation «Gérer catégories boutiques» Figure 16 : Diagramme de cas d’utilisation du cas «Gérer catégories boutiques»
- 57. Projet de fin d’études Page 57 II.6.1.1 Analyse du cas d’utilisation «Lister catégories boutiques» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Lister catégories boutiques». Description textuelle du cas d’utilisation «Lister catégories boutiques» Cas d’utilisation Lister catégories boutiques Acteur Administrateur Pré condition Administrateur authentifié. Post condition Liste des catégories de boutiques affichée Description du scénario principal 1. L’administrateur clique sur «Catégories boutiques». 2. Le système affiche la liste des catégories de boutiques Exception Néant Tableau 10 : Description textuelle du cas d’utilisation «Lister catégories boutiques» Diagramme de séquences système du cas d’utilisation «Lister catégories boutiques» Figure 17 : Diagramme de séquences système du cas d’utilisation «Lister catégories boutiques» II.6.1.2 Analyse du cas d’utilisation «Ajouter catégorie boutiques» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Ajouter catégorie boutiques». Description textuelle du cas d’utilisation «Ajouter catégorie boutiques» Cas d’utilisation Ajouter catégorie boutiques Acteur Administrateur Pré condition Administrateur authentifié Liste des catégories de boutiques affichée. Post condition Catégorie de boutiques ajoutée Description du scénario principal 1. L’administrateur clique sur le bouton «ajouter une catégorie».
- 58. Projet de fin d’études Page 58 2. Le système affiche le formulaire d’ajout d’une catégorie de boutiques. 3. L’administrateur remplit le formulaire. 4. L’administrateur valide le formulaire. 5. Le système vérifie les informations saisies par l’administrateur. 6. Le système affiche un message indiquant que la catégorie de boutiques est ajoutée avec succès. Exception 5.1 Un message d’erreur est affiché si l’un des champs obligatoire est vide et/ou invalide. Tableau 11 : Description textuelle du cas d’utilisation «Ajouter catégorie boutiques» Diagramme de séquences système du cas d’utilisation «Ajouter catégorie boutiques» Figure 18 : Diagramme de séquencessystème du cas d’utilisation «Ajouter catégorie boutiques»
- 59. Projet de fin d’études Page 59 II.6.1.3 Analyse du cas d’utilisation «Modifier catégorie boutiques» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Modifier catégorie boutiques». Description textuelle du cas d’utilisation «Modifier catégorie boutiques» Cas d’utilisation Modifier catégorie boutiques Acteur Administrateur Pré condition Administrateur authentifié Liste des catégories de boutiques affichée. Catégorie de boutiques existante. Post condition Catégorie de boutiques modifiée Description du scénario principal 1. L’administrateur clique sur «Modifier». 2. Le système affiche le formulaire de modification d’une catégorie de boutiques. 3. L’administrateur modifie le formulaire. 4. L’administrateur valide le formulaire. 5. Le système vérifie les informations saisies par l’administrateur. 6. Le système affiche un message indiquant que la catégorie de boutiques est mise à jour. Exception 5.1.Un message d’erreur est affiché si l’un des champs obligatoire est vide et/ou invalide Tableau 12 : Description textuelle du cas d’utilisation «Modifier catégorie boutiques» Diagramme de séquences système du cas d’utilisation «Modifier catégorie boutiques» Après avoir affiché la liste des catégories de boutiques, l’administrateur clique sur le lien «Modifier» devant la catégorie qu’il envisage modifier. Le système affiche les informations de la catégorie dans un formulaire. L’administrateur modifie et valide le formulaire. Les données introduites seront chargées dans le système qui va les vérifier. En cas de succès, un message indiquant que la catégorie de boutiques est modifiée avec succès est affiché. Dans le cas contraire, le système affiche le(s) message(s) d’erreur approprié(s). La figure 19 représente le diagramme de séquences système de la fonctionnalité «Modifier catégorie boutiques» de notre sprint.
- 60. Projet de fin d’études Page 60 Figure 19 : Diagramme de séquencessystème du cas d’utilisation «Modifier catégorie boutiques» II.6.1.4 Analyse du cas d’utilisation«Supprimer catégorie boutiques» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Supprimer catégorie boutiques». Description textuelle du cas d’utilisation «Supprimer catégorie boutiques» Cas d’utilisation Supprimer catégorie boutiques Acteur Administrateur Pré condition Administrateur authentifié. Liste des catégories de boutiques affichée. Catégorie de boutiques existante. Post condition Catégorie de boutiques supprimée. Description du scénario principal 1. L’administrateur clique sur « supprimer». 2. Le système affiche une fenêtre de confirmation. 3. L’administrateur confirme la suppression. 4. Le système supprime la catégorie de boutiques.
- 61. Projet de fin d’études Page 61 5. Le système affiche un message indiquant que la catégorie de boutiques est supprimée avec succès. 6. Le système redirige l’administrateur vers la page «Lister les catégories de boutiques» Exception 2.1 L’opération de suppression est annulée si l’administrateur clique sur le bouton annuler. Tableau 13 : Description textuelle du cas d’utilisation «Supprimer catégorie boutiques» Diagramme de séquences système du cas d’utilisation «Supprimer catégorie boutiques» Figure 20 : Diagramme de séquences système du cas d’utilisation «Supprimer catégorie boutiques» II.7 Analyse du cas d’utilisation «Gérer vendeurs» Nous commençons par le raffinement du cas d’utilisation «Gérer vendeurs». II.7.1 Raffinement du cas d’utilisation«Gérer vendeurs» Figure 21 : Diagramme de cas d’utilisation du cas «Gérer vendeurs»
- 62. Projet de fin d’études Page 62 II.7.1.1 Analyse du cas d’utilisation«Lister vendeurs» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Lister vendeurs». Description textuelle du cas d’utilisation «Lister vendeurs» Cas d’utilisation Lister vendeurs Acteur Administrateur Pré condition Administrateur authentifié. Post condition Liste des vendeurs affichée Description du scénario principal 1. L’administrateur clique sur «Vendeurs». 2. Le système affiche la liste des vendeurs. Exception Néant Tableau 14 : Description textuelle du cas d’utilisation «Lister vendeurs» Diagramme de séquences système du cas d’utilisation «Lister vendeurs» Figure 22 : Diagramme de séquences système du cas d’utilisation «Lister vendeurs» II.7.1.2 Analyse du cas d’utilisation «Supprimer vendeur» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Supprimer vendeur». Description textuelle du cas d’utilisation «Supprimer vendeur» Cas d’utilisation Supprimer vendeur Acteur Administrateur Pré condition Administrateur authentifié. Liste des vendeurs affichée. Vendeur existant. Post condition Vendeur supprimé. Description du scénario principal 1. L’administrateur clique sur «supprimer».
- 63. Projet de fin d’études Page 63 2. Le système affiche une fenêtre de confirmation. 3. L’administrateur confirme la suppression. 4. Le système supprime le vendeur. 5. Le système affiche un message indiquant que le vendeur est supprimé avec succès. 6. Le système redirige l’administrateur vers la page «Lister les vendeurs» Exception 2.1 L’opération de suppression est annulée si l’administrateur clique sur le bouton annuler. Tableau 15 : Description textuelle du cas d’utilisation «Supprimer vendeur» Diagramme de séquences système du cas d’utilisation «Supprimer vendeur» Figure 23 : Diagramme de séquences système du cas d’utilisation «Supprimer vendeur» III. Conception des cas d’utilisations : Dans cette étape, nous allons élaborer les diagrammes de séquences détaillées ainsi que les diagrammes de classes des cas d’utilisations les plus importants. Par la suite, nous allons clôturer cette étape par l’établissement du diagramme de classes global de notre premier sprint.
- 64. Projet de fin d’études Page 64 III.1 Conceptionde cas d’utilisation «s’authentifier» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «s’authentifier». Diagramme de classes participantes au cas d’utilisation «s’authentifier» Figure 24 : Diagramme de classes participantes du cas d’utilisation «s’authentifier» Diagramme de séquences détaillées du cas d’utilisation «s’authentifier» Figure 25 : Diagramme de séquences détaillées du cas d’utilisation «s’authentifier»
- 65. Projet de fin d’études Page 65 III.2 Conceptionde cas d’utilisation «s’inscrire» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «s’inscrire». Diagramme de classes participantes au cas d’utilisation «s’inscrire» Figure 26 : Diagramme de classes participantes au cas d’utilisation «s’inscrire» Diagramme de séquences détaillées du cas d’utilisation «s’inscrire» Figure 27 : Diagramme de séquences détaillées du cas d’utilisation «s’inscrire»
- 66. Projet de fin d’études Page 66 III.3 Conceptionde cas d’utilisation «Gérer mon profil» III.3.1 Conception de cas d’utilisation «Afficher mon profil» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Afficher mon profil». Diagramme de classes participantes au cas d’utilisation «Afficher mon profil» Figure 28 : Diagramme de classes participantes au cas d’utilisation «Afficher mon profil» Diagramme de séquences détaillées du cas d’utilisation «Afficher mon profil» Figure 29 : Diagramme de séquences détaillées du cas d’utilisation «Afficher mon profil»
- 67. Projet de fin d’études Page 67 III.3.2 Conception de cas d’utilisation «Modifier mon profil» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Modifier mon profil». Diagramme de classes participantes au cas d’utilisation «Modifier mon profil» Figure 30 : Diagramme de classes participantes au cas d’utilisation «Modifier mon profil» Diagramme de séquences détaillées du cas d’utilisation «Modifier mon profil» Figure 31 : Diagramme de séquences détaillées du cas d’utilisation «Modifier mon profil»
- 68. Projet de fin d’études Page 68 III.4 Conceptionde cas d’utilisation «Gérer catégories boutiques» III.4.1 Conception de cas d’utilisation «Lister catégories boutiques» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Lister catégories boutiques». Diagramme de classes participantes au cas d’utilisation «Lister catégories boutiques» Figure 32 : Diagramme de classes participantes au cas d’utilisation «Lister catégories boutiques» Diagramme de séquences détaillées du cas d’utilisation «Lister catégories boutiques» Figure 33 : Diagramme de séquencesdétaillées du cas d’utilisation «Lister catégoriesboutiques»
- 69. Projet de fin d’études Page 69 III.4.2 Conception de cas d’utilisation «Ajouter catégorie de boutiques» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Ajouter catégorie boutiques». Diagramme de classes participantes au cas d’utilisation «Ajouter catégorie boutiques» Figure 34 : Diagramme de classes participantes au cas d’utilisation «Ajoutercatégorie boutiques» Diagramme de séquences détaillées du cas d’utilisation «Ajouter catégorie de boutiques» Figure 35 : Diagramme de séquencesdétaillées du cas d’utilisation «Ajouter catégorie boutiques»
- 70. Projet de fin d’études Page 70 III.4.3 Conception de cas d’utilisation «Modifier catégorie boutiques» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Modifier catégorie de boutiques». Diagramme de classes participantes au cas d’utilisation «Modifier catégorie boutiques» Figure 36 : Diagramme de classes participantes au cas d’utilisation «Modifier catégorie boutiques» Diagramme de séquences détaillées du cas d’utilisation «Modifier catégorie boutiques» Figure 37 : Diagramme de séquences détaillées du cas d’utilisation «Modifier catégorie boutiques»
- 71. Projet de fin d’études Page 71 III.4.4 Conception de cas d’utilisation «Supprimer catégorie boutiques» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Supprimer catégorie boutiques». Diagramme de classes participantes au cas d’utilisation «Supprimer catégorie boutiques» Figure 38 : Diagramme de classes participantes au cas d’utilisation «Supprimer catégorie boutiques» Diagramme de séquences détaillées du cas d’utilisation «Supprimer catégorie boutiques» Figure 39 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer catégorie boutiques»
- 72. Projet de fin d’études Page 72 III.5 Conceptionde cas d’utilisation «Gérer vendeurs» III.5.1 Conception de cas d’utilisation «Lister vendeurs» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Lister vendeurs». Diagramme de classes participantes au cas d’utilisation «Lister vendeurs» Figure 40 : Diagramme de classes participantes au cas d’utilisation «Lister vendeurs» Diagramme de séquences détaillées du cas d’utilisation «Lister vendeurs» Figure 41 : Diagramme de séquences détaillées du cas d’utilisation «Lister vendeurs»
- 73. Projet de fin d’études Page 73 III.5.2 Conception de cas d’utilisation «Supprimer vendeur» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Supprimer vendeur». Diagramme de classes participantes au cas d’utilisation «Supprimer vendeur» Figure 42 : Diagramme de classes participantes au cas d’utilisation «Supprimer vendeur» Diagramme de séquences détaillées du cas d’utilisation «Supprimer vendeur» Figure 43 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer vendeur»
- 74. Projet de fin d’études Page 74 III.6 Diagramme de classesglobaldu premier sprint : Figure 44: Diagramme de classes global du premier sprint IV. Implémentation La phase d’implémentation, appelé également phase de codage, consiste à implémenter les histoires utilisateurs (les users stories) traités précédemment. Dans cette étape, nous allons définir la structure de la base de données du sprint courant tout en appliquant les règles de passage du modèle entité/association au modèle relationnel. Comme notre diagramme de classes global l’indique (figure 44), les deux classes vendeur et admin héritent de la classe parent utilisateur, ce qui nous oblige, lors du passage au modèle relationnel de choisir une méthode de traitement de généralisation. Dans notre cas, nous avons choisi la méthode de décomposition par distinction. Schéma de la base de données : Champs Types Contraintes Id INT(11) PRIMARY KEY Email VARCHAR (50) UNIQUE Enabled INT(1) Password VARCHAR (50) Last_login DATETIME Confirmation_token VARCHAR (50) Password_requested_at DATETIME
- 75. Projet de fin d’études Page 75 Roles VARCHAR (50) Type VARCHAR (50) Tableau 16 : Table «Utilisateur» Champs Types Contraintes Id INT(11) PRIMARY KEY FOREIGN KEY Prenom VARCHAR (50) Nom VARCHAR (50) Adresse VARCHAR(50) Tel INT(8) Tableau 17 : Table «Vendeur» Champs Types Contraintes Id INT(11) PRIMARY KEY FOREIGN KEY Tableau 18 : Table «Admin» Champs Types Contraintes Id INT(11) PRIMARY KEY Libelle VARCHAR(50) Admin_id INT(11) FOREIGN KEY Tableau 19 : Table «Categorie_boutique» Champs Types Contraintes Id INT(11) PRIMARY KEY Nom VARCHAR(50) Adresse VARCHAR(50) Confirm BOOLEAN Verrou BOOLEAN Favoris BOOLEAN Vendeur_id INT(11) FOREIGN KEY Categorie_boutique_id INT(11) FOREIGN KEY Tableau 20 : Table «Boutique» Interface d’authentification Figure 45 : Interface d’authentification
- 76. Projet de fin d’études Page 76 Interface d’inscription Figure 46 : Interface d’inscription Interface du cas «Lister catégories boutiques» Figure 47 : Interface du cas «Lister catégories boutiques»
- 77. Projet de fin d’études Page 77 Interface du cas «Lister vendeurs» Figure 48 : Interface du cas «Lister vendeurs» V. Tests Comme on l’a mentionné à l’introduction de ce sprint, les tests représentent la dernière étape du cycle Scrum. Ils permettent ainsi de comparer les résultats actuels avec les objectifs du sprint fixés au début. Un des majeurs avantages de Scrum, c’est qu’il nous permet de tester chaque incrément lorsqu’il touche à sa fin jusqu’à la livraison d’un produit final. V.1 Les tests unitaires Les tests unitaires nous permettent de tester chaque unité (méthode) de notre incrément d’une façon indépendante des autres méthodes du même incrément. Pour ce type de test, on s’intéresse à extraire les différents erreurs qui peuvent se présenter lors de l’exécution d’une méthode donnée. Les tests unitaires se font toujours avant les tests d’intégration car ce n’est pas utile de tester l’intégration des unités alors que certaines méthodes peuvent être non valides. En PHP, il existe plusieurs outils de tests comme les Frameworks de tests Lime, PHPUnit, etc … Nous avons choisi de travailler avec le Framework de tests unitaires open source PHPUnit. Nous allons montrer dans cette section quelques cas de tests unitaires effectués ainsi que le raisonnement adopté pour la réalisation de ces derniers.
- 78. Projet de fin d’études Page 78 V.1.1 Le test unitaire du cas d’utilisation «Ajouter catégorie boutiques» Raisonnement Pour tester l’ajout d’une catégorie de boutiques, nous avons suivi le raisonnement suivant : 1. Compter le nombre de catégories de boutiques actuels et le stocker dans une variable 2. Ajouter une nouvelle catégorie de boutiques 3. Compter de nouveau le nombre de catégories de boutiques et le stocker dans une autre variable 4. Comparer le nombre obtenu initialement et le dernier nombre récupéré. En cas de succès, on obtiendra : Le nombre de catégories de boutiques initial+1 = le nombre de catégories de boutiques après ajout. Code source de la méthode de test du cas d’utilisation «Ajouter catégorie boutiques» Figure 49 : Code de source de la méthode de test d’ajout d’une catégorie de boutiques Capture d’écran représentant le résultat du test du cas d’utilisation «Ajouter catégorie boutiques» Figure 50 : Interface de résultat du test d’ajout
- 79. Projet de fin d’études Page 79 En cas d’échec, notre méthode de test doit retourner un message indiquant que la méthode testée n’a pas retournée le résultat prévu. Nous avons essayé d’ajouter une catégorie de boutiques en violant certaines conditions et nous avons eu un message d’échec. Capture d’écran représentant le résultat de test du cas d’utilisation «Ajouter catégorie boutiques» en violant certaines conditions Figure 51 : Interface de résultat du test d’ajout en cas d’échec La figure 51 montre un message d’échec indiquant que le résultat prévu vaut 10 alors que la fonction a retournée 9 donc l’ajout d’une nouvelle catégorie de boutiques a échoué. V.1.2 Le test unitaire du cas d’utilisation «Supprimer catégorie boutiques» Raisonnement Pour tester la suppression d’une catégorie de boutique, nous avons suivi le raisonnement suivant : 1. Compter le nombre de catégories de boutiques actuels et le stocker dans une variable 2. Supprimer une catégorie de boutique existante 3. Compte de nouveau le nombre de catégories de boutiques et le stocker dans une autre variable 4. Comparer le nombre obtenu initialement et le dernier nombre récupéré. En cas de succès, on obtiendra : Le nombre de catégories de boutiques initial-1 = le nombre de catégories de boutiques après suppression.
- 80. Projet de fin d’études Page 80 Code source de la méthode de test du cas d’utilisation «Supprimer catégorie boutiques» Figure 52 : Code source de la méthode de test de suppression Capture d’écran représentant le résultat du test du cas d’utilisation «Supprimer catégorie boutiques» Figure 53 : Interface de résultat du test de suppression En cas d’échec, notre méthode de test doit retourner un message indiquant que la méthode testée n’a pas retournée le résultat prévu. Nous avons essayé de supprimer une catégorie de boutique en violant certaines conditions et nous avons eu un message d’échec. Capture d’écran représentant le résultat du test du cas d’utilisation «Supprimer catégorie boutiques» en violant certaines conditions Figure 54 : Interface de résultat du test de suppression en cas d’échec
- 81. Projet de fin d’études Page 81 La figure 54 montre un message d’échec indiquant que le résultat prévu vaut 7 alors que la fonction a retournée 8 donc la suppression d’une catégorie de boutiques a échouée. Après avoir terminé la phase de test, nous allons commencer à penser à notre deuxième sprint où on va commencer à développer les parties les plus importantes de notre application telles que la gestion des boutiques, produits, commandes, etc… VI.Revue de sprint «L’objectif de la revue de sprint est d’inspecter l’incrément produit au cours du sprint écoulé. L’équipe de développement présente à tout acteur projet intéressé les nouvelles fonctionnalités développées au cours du sprint. Le Product Owner donne un feedback à l’équipe de développement, il accepte ou refuse les fonctionnalités présentées.»[N13] VI.1. Diagramme de «Burndown Chart» «Un burndown chart (graphique d'avancement) est une représentation graphique de l'évolution de quantité de travail restante par rapport au temps sur une période de temps donnée. Le travail restant se situe en général sur l'axe vertical, alors que le temps est sur l'axe horizontal.»[N12] Figure 55 : Diagramme de Burndown Chart du premier sprint
- 82. Projet de fin d’études Page 82 VI.2 Calcul de vélocité «L’équipe de développement calcule sa vélocité en additionnant les points d’estimations associées aux fonctionnalités acceptées. Une fonctionnalité partiellement terminée ne rapportera aucun point car une telle fonctionnalité n’est pas utilisable.»[N13] En calculant la vélocité, l’équipe de développement aura l’opportunité de s’assurer que le nombre de fonctionnalités du sprint est adapté ou nécessite encore des ajustements. Estimer directement le temps ou l’effort nécessaire pour le développement d’un User Story ou d’une fonctionnalité n’est pas assez facile. Par exemple, pour une équipe qui n’est pas assez expérimentée dans les technologies utilisées, le temps consacré à l’implémentation d’un tel User Story peut aller jusqu’au double du temps nécessaire pour une équipe expérimentée. En effet, un développeur débutant peut estimer l’implémentation d’un User Story à 2 jours alors qu’un développeur ayant plus d’expérience estimera l’implémentation de la même fonctionnalité à un seul jour. Pour nous, on s’est mis d’accord pour attribuer un nombre de points aux histoires utilisateurs en fonction de leur complexité. ID User Story Estimation 1 10 2 15 3 10 4 5 5 10 6 15 7 10 8 15 9 15 10 10 11 10 12 10 Vélocité estimée 135 Tableau 21 : Calcul de vélocité estimée La figure 55 comporte le diagramme de Burndown Chart et un tableau à gauche comportant une colonne nommée ‘Done Today’ qui indique l’ensemble des points réalisés pour chaque jour durant ce premier sprint. La somme de cette colonne est égale à 135 ça veut dire : Vélocité estimée = Vélocité réelle L’équipe Scrum a donc réussi à implémenter les fonctionnalités du backlog de sprint courant. Ces derniers ont été validés par le Product Owner. Conclusion Dans ce chapitre, nous nous sommes concentrés sur le développement de notre premier sprint. Nous avons donc un incrément potentiellement livrable de notre logiciel. Dans le chapitre suivant nous allons nous concentrer sur la réalisation de notre deuxième sprint.
- 83. Projet de fin d’études Page 83 Chapitre 4 Sprint 2 : Gestiondes boutiques, marques, catégories de produits et produits
- 84. Projet de fin d’études Page 84 Introduction Dans le chapitre précédent, nous avons introduit notre premier sprint, qui nous a permis d’obtenir une version initiale de notre application potentiellement livrable. Au démarrage d’un sprint, on commence toujours par la définition de ses objectifs et la fixation de l’ensemble des fonctionnalités qu’on comptera développer. Ces fonctionnalités forment ainsi le Backlog du sprint. Au cours de ce deuxième sprint, nous allons commencer à développer la partie la plus importante de notre projet. I. La spécification fonctionnelle À l’initiation de chaque itération, la spécification fonctionnelle est représentée par un diagramme de cas d’utilisation. Ce dernier va donner une vision globale du système et définir les différentes interactions entre celui-ci et les utilisateurs. I.1 Le sprint backlog Il s’agit de l’ensemble de fonctionnalités extraites par l’équipe Scrum à partir du Backlog du produit et qui vont être réalisés au cours de ce sprint. Le tableau 22 englobe le backlog du deuxième sprint. ID User Story User Story ID tâche Tâche Affectatio n 1 En tant que vendeur, je veux créer ma boutique 1.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «créer ma boutique» Rami Raddaoui 1.2 Implémenter le cas d’utilisation «créer ma boutique» Rami Raddaoui 1.3 Tester le cas d’utilisation «créer ma boutique» Rami Raddaoui 2 En tant que vendeur, je veux paramétrer ma boutique 2.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «paramétrer ma boutique» Rami Raddaoui 2.2 Implémenter le cas d’utilisation «paramétrer ma boutique» Rami Raddaoui 2.3 Tester le cas d’utilisation «paramétrer ma boutique» Rami Raddaoui
- 85. Projet de fin d’études Page 85 3 En tant qu’administrateur, je veux lister les boutiques. 3.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «lister boutiques» Rami Raddaoui 3.2 Implémenter le cas d’utilisation «lister boutiques» Rami Raddaoui 3.3 Tester le cas d’utilisation «lister boutiques» Rami Raddaoui 4 En tant qu’administrateur, je veux consulter une boutique. 4.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «consulter boutique» Rami Raddaoui 4.2 Implémenter le cas d’utilisation «consulter boutique» Rami Raddaoui 4.3 Tester le cas d’utilisation «consulter boutique» Rami Raddaoui 5 En tant qu’administrateur, je veux confirmer une boutique. 5.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «confirmer boutique» Rami Raddaoui 5.2 Implémenter le cas d’utilisation «confirmer boutique» Rami Raddaoui 5.3 Tester le cas d’utilisation «confirmer boutique» Rami Raddaoui 6 En tant qu’administrateur, je veux verrouiller une boutique. 6.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «verrouiller boutique» Rami Raddaoui 6.2 Implémenter le cas d’utilisation «verrouiller boutique» Rami Raddaoui 6.3 Tester le cas d’utilisation «verrouiller boutique» Rami Raddaoui 7 En tant qu’administrateur, je veux déverrouiller une boutique. 7.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «déverrouiller boutique» Rami Raddaoui 7.2 Implémenter le cas d’utilisation Rami Raddaoui
- 86. Projet de fin d’études Page 86 «déverrouiller boutique» 7.3 Tester le cas d’utilisation «déverrouiller boutique» Rami Raddaoui 8 En tant qu’administrateur, je veux ajouter une boutique aux favoris. 8.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «ajouter boutique aux favoris» Rami Raddaoui 8.2 Implémenter le cas d’utilisation «ajouter boutique aux favoris» Rami Raddaoui 8.3 Tester le cas d’utilisation «ajouter boutique aux favoris» Rami Raddaoui 9 En tant qu’administrateur, je veux supprimer une boutique du favori. 9.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «supprimer boutique du favoris» Rami Raddaoui 9.2 Implémenter le cas d’utilisation «supprimer boutique du favoris» Rami Raddaoui 9.3 Tester le cas d’utilisation «supprimer boutique du favoris» Rami Raddaoui 10 En tant qu’administrateur, je veux supprimer une boutique. 10.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «supprimer boutique» Rami Raddaoui 10.2 Implémenter le cas d’utilisation «supprimer boutique» Rami Raddaoui 10.3 Tester le cas d’utilisation «supprimer boutique» Rami Raddaoui 11 En tant que vendeur, je veux lister les catégories de produits 11.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «lister catégories produits» Rami Raddaoui 11.2 Implémenter le cas d’utilisation «lister catégories produits» Rami Raddaoui 11.3 Tester le cas d’utilisation «lister catégories Rami Raddaoui
- 87. Projet de fin d’études Page 87 produits» 12 En tant que vendeur, je veux ajouter une catégorie de produit 12.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «ajouter catégorie produits» Rami Raddaoui 12.2 Implémenter le cas d’utilisation «ajouter catégorie produits» Rami Raddaoui 12.3 Tester le cas d’utilisation «ajouter catégorie produits» Rami Raddaoui 13 En tant que vendeur, je veux modifier une catégorie de produit 13.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «modifier catégorie produits» Rami Raddaoui 13.2 Implémenter le cas d’utilisation «modifier catégorie produits» Rami Raddaoui 13.3 Implémenter le cas d’utilisation «modifier catégorie produits» Rami Raddaoui 14 En tant que vendeur, je veux supprimer une catégorie de produit 14.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «supprimer catégorie produits» Rami Raddaoui 14.2 Implémenter le cas d’utilisation «supprimer catégorie produits» Rami Raddaoui 14.3 Tester le cas d’utilisation «supprimer catégorie produits» Rami Raddaoui 15 En tant que vendeur, je veux lister les marques 15.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «lister marques» Rami Raddaoui 15.2 Implémenter le cas d’utilisation «lister marques» Rami Raddaoui 15.3 Tester le cas d’utilisation «lister marques» Rami Raddaoui 16 En tant que 16.1 Élaborer le diagramme de
- 88. Projet de fin d’études Page 88 vendeur, je veux ajouter une marque cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «ajouter marque» Rami Raddaoui 16.2 Implémenter le cas d’utilisation «ajouter marque» Rami Raddaoui 16.3 Tester le cas d’utilisation «ajouter marque» Rami Raddaoui 17 En tant que vendeur, je veux modifier une marque 17.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «modifier marque» Rami Raddaoui 17.2 Implémenter le cas d’utilisation «modifier marque» Rami Raddaoui 17.3 Tester le cas d’utilisation «modifier marque» Rami Raddaoui 18 En tant que vendeur, je veux supprimer une marque 18.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «supprimer marque» Rami Raddaoui 18.2 Implémenter le cas d’utilisation «supprimer marque» Rami Raddaoui 18.3 Tester le cas d’utilisation «supprimer marque» Rami Raddaoui 19 En tant que vendeur, je veux lister mes produits 19.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «lister produits» Rami Raddaoui 19.2 Implémenter le cas d’utilisation «lister produits» Rami Raddaoui 19.3 Tester le cas d’utilisation «lister produits» Rami Raddaoui 20 En tant que vendeur, je veux ajouter un produit 20.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «ajouter produit» Rami Raddaoui 20.2 Implémenter le cas d’utilisation «ajouter produit» Rami Raddaoui
- 89. Projet de fin d’études Page 89 20.3 Tester le cas d’utilisation «ajouter produit» Rami Raddaoui 21 En tant que vendeur, je veux modifier un produit 21.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «modifier produit» Rami Raddaoui 21.2 Implémenter le cas d’utilisation «modifier produit» Rami Raddaoui 21.3 Tester le cas d’utilisation «modifier produit» Rami Raddaoui 22 En tant que vendeur, je veux supprimer un produit 22.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «supprimer produit» Rami Raddaoui 22.2 Implémenter le cas d’utilisation «supprimer produit» Rami Raddaoui 22.3 Tester le cas d’utilisation «supprimer produit» Rami Raddaoui 23 En tant qu’administrateur, je veux lister les produits d’une boutique spécifique. 23.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «lister produits boutique» Rami Raddaoui 23.2 Implémenter le cas d’utilisation «lister produits boutique» Rami Raddaoui 23.3 Tester le cas d’utilisation «lister produits boutique» Rami Raddaoui 24 En tant qu’administrateur, je veux consulter un produit d’une boutique spécifique. 24.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «consulter produit» Rami Raddaoui 24.2 Implémenter le cas d’utilisation «consulter produit» Rami Raddaoui 24.3 Tester le cas d’utilisation «consulter produit» Rami Raddaoui 25 En tant qu’administrateur, je veux ajouter un produit spécifique aux favoris. 25.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «ajouter produit aux Rami Raddaoui
- 90. Projet de fin d’études Page 90 favoris» 25.2 Implémenter le cas d’utilisation «ajouter produit aux favoris» Rami Raddaoui 25.3 Tester le cas d’utilisation «ajouter produit aux favoris» Rami Raddaoui 26 En tant qu’administrateur, je veux supprimer un produit spécifique du favori. 26.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «supprimer produit du favoris» Rami Raddaoui 26.2 Implémenter le cas d’utilisation «supprimer produit du favoris» Rami Raddaoui 26.3 Tester le cas d’utilisation «supprimer produit du favoris» Rami Raddaoui Tableau 22 : Backlog du deuxième sprint I.2 Classificationdes cas d’utilisations par acteur : Acteur Cas d’utilisation Vendeur Créer ma boutique Paramétrer ma boutique Lister catégories produits Ajouter catégorie produit Modifier catégorie produit Supprimer catégorie produit Lister marques Ajouter marque Modifier marque Supprimer marque Lister produits Ajouter produit Modifier produit Supprimer produit Administrateur Lister les boutiques Consulter une boutique Confirmer une boutique Verrouiller une boutique Déverrouiller une boutique Ajouter boutique aux favoris Supprimer boutique du favoris Supprimer une boutique Lister produits boutique Consulter produit boutique Ajouter produit aux favoris Supprimer produit du favoris Tableau 23 : Classification des cas d’utilisation par acteur
- 91. Projet de fin d’études Page 91 I.3 Diagramme de cas d’utilisation : La figure 56 représente le diagramme de cas d’utilisation général de notre deuxième sprint. Figure 56 : Diagramme de cas d’utilisation du deuxième sprint II. Analyse des cas d’utilisation Au cours de cette section, nous allons faire le raffinement des cas d’utilisations afin de prévoir tous les scénarios possibles. Vu le nombre important des fonctionnalités de ce sprint, nous avons choisi de ne montrer que quelques diagrammes au cours de ce chapitre et ceci en éliminant ceux qui ont le même principe. Nous avons préparé une annexe pour présenter les diagrammes restants. De cette manière, nous évitons d’avoir un chapitre très volumineux par rapport aux autres. [Voir annexe B] II.1 Analyse du cas d’utilisation «Gérer ma boutique» Nous commençons par le raffinement du cas d’utilisation «Gérer ma boutique». II.1.1 Raffinement du cas d’utilisation «Gérer ma boutique» Figure 57 : Diagramme de cas d’utilisation : Gérer ma boutique
- 92. Projet de fin d’études Page 92 II.1.1.1 Analyse du cas d’utilisation «Créer ma boutique» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Créer ma boutique». Description textuelle du cas d’utilisation «Créer ma boutique» Cas d’utilisation Créer ma boutique Acteur Vendeur Pré condition Vendeur inscrit Vendeur authentifié Post condition Boutique créée Description du scénario principal 1. Le système affiche le formulaire de création de boutique 2. Le vendeur remplit les champs et valide le formulaire. 3. Le système vérifie les informations saisies par le vendeur. 4. Le système affiche un message indiquant que la demande de création de boutique a été retenue. Exception 3.1 Un message d’erreur est affiché si l’un des champs obligatoire est vide et/ou invalide. Tableau 24 : Description textuelle du cas d’utilisation «Créer boutique» Diagramme de séquences système du cas «Créer ma boutique» Après l’authentification d’un vendeur, le système vérifie tout d’abord si cet acteur a déjà créé une boutique ou non. Si le vendeur ne possède pas une boutique, le système le redirige vers la page «Créer ma boutique». Dans le cas échéant, il sera redirigé vers le tableau de bord. La figure 58 représente le diagramme de séquences système de la fonctionnalité «Créer ma boutique» de notre sprint.
- 93. Projet de fin d’études Page 93 Figure 58 : Diagramme de séquences système du cas d’utilisation «Créer ma boutique» II.1.1.2 Analyse du cas d’utilisation «Paramétrer ma boutique» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Paramétrer ma boutique». Description textuelle du cas d’utilisation «Paramétrer ma boutique» Cas d’utilisation Paramétrer ma boutique Acteur Vendeur Pré condition Vendeur authentifié Boutique créée Post condition Boutique mise à jour Description du scénario principal 1. Le vendeur clique sur «Paramétrer ma boutique». 2. Le système affiche les informations de la boutique dans un formulaire 3. Le vendeur modifie les informations de la boutique et valide le formulaire. 4. Le système vérifie les informations saisies par le vendeur. 5. Le système affiche un message indiquant que la boutique est mise à jour.
- 94. Projet de fin d’études Page 94 Exception 4.1 Un message d’erreur est affiché si l’un des champs obligatoire est vide et/ou invalide Tableau 25 : Description textuelle du cas d’utilisation «Paramétrer ma boutique» Diagramme de séquences système du cas «Paramétrer ma boutique» Figure 59 : Diagramme de séquences système du cas d’utilisation «Paramétrer ma boutique» II.2 Analyse du cas d’utilisation «Gérer mes produits» Nous commençons par le raffinement du cas d’utilisation «Gérer mes produits». II.2.1 Raffinement du cas d’utilisation «Gérer mes produits» Figure 60 : Diagramme de cas d’utilisation du cas «Gérer mes produits»
- 95. Projet de fin d’études Page 95 II.2.1.1 Analyse du cas d’utilisation «Lister produits» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Lister produits». Descriptiontextuelle du cas d’utilisation«Lister produits» Cas d’utilisation Lister produit Acteur Vendeur Pré condition Vendeur authentifié. Post condition Liste des produits affichée Description du scénario principal 1. Le vendeur clique sur «Produit». 2. Le système affiche la liste des produits Exception Néant Tableau 26 : Description textuelle du cas d’utilisation «Lister produits» Diagramme de séquences système du cas d’utilisation «Lister produits» Figure 61 : Diagramme de séquences système du cas d’utilisation «Lister produits» II.2.1.2 Analyse du cas d’utilisation «Ajouter produit» Nous commençons par la description textuelle puis le Diagramme de séquences système du cas «Ajouter produit». Descriptiontextuelle du cas d’utilisation «Ajouter produit» Cas d’utilisation Ajouter produit Acteur Vendeur Pré condition Vendeur authentifié Liste des produits affichée Post condition Produit ajouté Description du scénario principal 1. Le vendeur clique sur le bouton «ajouter un produit». 2. Le système affiche le formulaire d’ajout d’un produit. 3. Le vendeur remplit les champs et valide le formulaire.
- 96. Projet de fin d’études Page 96 4. Le système vérifie les informations saisies par le vendeur. 5. Le système affiche un message indiquant que le produit est ajouté avec succès. Exception 4.1 Un message d’erreur est affiché si l’un des champs obligatoire est vide et/ou invalide. Tableau 27 : Description textuelle du cas d’utilisation «Ajouter produit» Diagramme de séquences système du cas d’utilisation «Ajouter produit» Figure 62 : Diagramme de séquences système du cas d’utilisation «Ajouter produit» II.2.1.3 Analyse du cas d’utilisation«Modifier produit» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Modifier produit». Description textuelle du cas d’utilisation «Modifier produit» Cas d’utilisation Modifier produit Acteur Vendeur Pré condition Vendeur authentifié Liste des produits affichée Post condition Produit modifié Description du scénario principal 1. Le vendeur clique sur «Modifier». 2. Le système affiche les informations du produit dans un formulaire.
- 97. Projet de fin d’études Page 97 3. Le vendeur modifie les champs et valide le formulaire. 4. Le système vérifie les informations saisies par le vendeur. 5. Le système affiche un message indiquant que le produit est mis à jour. Exception 4.1 Un message d’erreur est affiché si l’un des champs obligatoire est vide et/ou invalide. Tableau 28 : Description textuelle du cas d’utilisation «Modifier produit» Diagramme de séquences système du cas d’utilisation «Modifier produit» Figure 63 : Diagramme de séquences système du cas d’utilisation «Modifier produit» II.2.1.4 Analyse du cas d’utilisation «Supprimer produit» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Supprimer produit». Description textuelle du cas d’utilisation «Supprimer produit» Cas d’utilisation Supprimer produit Acteur Vendeur Pré condition Vendeur authentifié Liste des produits affichée Post condition Produit supprimé Description du scénario principal 1. Le vendeur clique sur «Supprimer». 2. Le système affiche une fenêtre de confirmation.
- 98. Projet de fin d’études Page 98 3. Le vendeur confirme la suppression. 4. Le système supprime le produit. 5. Le système redirige le vendeur vers la page «lister mes produits» 6. Le système affiche un message indiquant que le produit est supprimé avec succès. Exception 2.1 L’opération de suppression est annulée si le vendeur clique sur le bouton annuler. Tableau 29 : Description textuelle du cas d’utilisation «Supprimer produit» Diagramme de séquences système du cas d’utilisation «Supprimer produit» Figure 64 : Diagramme de séquences système du cas d’utilisation «Supprimer produit» II.3 Analyse du cas d’utilisation «Gérer les boutiques» Nous commençons par le raffinement du cas d’utilisation «Gérer les boutiques».
- 99. Projet de fin d’études Page 99 II.3.1 Raffinement du cas d’utilisation «Gérer les boutiques» Figure 65 : Diagramme de cas d’utilisation du cas «Gérer les boutiques»
- 100. Projet de fin d’études Page 100 II.3.1.1 Analyse du cas d’utilisation «Lister boutiques» Nous commençons par la description textuelle puis le Diagramme de séquences système du cas «Lister boutiques». Descriptiontextuelle du cas d’utilisation «Lister boutiques» Cas d’utilisation Lister boutiques Acteur Administrateur Pré condition Administrateur authentifié. Post condition Liste des boutiques affichée. Description du scénario principal 1. L’administrateur clique sur «Boutiques». 2. Le système affiche la liste des boutiques Exception Néant Tableau 30 : Description textuelle du cas d’utilisation «Lister boutiques» Diagramme de séquences système du cas d’utilisation «Lister boutiques» Figure 66 : Diagramme de séquences système du cas d’utilisation «Lister boutiques» II.3.1.2 Analyse du cas d’utilisation «Confirmer boutique» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Confirmer boutique». Description textuelle du cas d’utilisation «Confirmer boutique» Cas d’utilisation Confirmer boutique Acteur Administrateur Pré condition Administrateur authentifié. Liste des boutiques affichée. Boutique en attente d’approbation. Post condition Boutique confirmée Description du scénario principal 1. L’administrateur clique sur «confirmer». 2. Le système affiche une fenêtre de confirmation du choix.
- 101. Projet de fin d’études Page 101 3. L’administrateur confirme son choix. 4. Le système confirme la boutique. 5. Le système met à jour l’état de la boutique dans la liste des boutiques affichée. 6. Le système redirige l’administrateur vers la page «lister les boutiques» Exception 2.1 L’opération de confirmation est annulée si l’administrateur clique sur le bouton annuler. Tableau 31 : Description textuelle du cas d’utilisation «Confirmer boutique» Diagramme de séquences système du cas d’utilisation «Confirmer boutique» Figure 67 : Diagramme de séquences système du cas d’utilisation «Confirmer boutique» II.3.1.3 Analyse du cas d’utilisation «Supprimer boutique» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Supprimer boutique». Descriptiontextuelle du cas d’utilisation «Supprimerboutique» Cas d’utilisation Supprimer boutique Acteur Administrateur Pré condition Administrateur authentifié. Liste des boutiques affichée. Post condition Boutique supprimée. Description du scénario principal 1. L’administrateur clique sur «Supprimer».
- 102. Projet de fin d’études Page 102 2. Le système affiche une fenêtre de confirmation. 3. L’administrateur confirme la suppression. 4. Le système supprime la boutique. 5. Le système redirige l’administrateur vers la page «lister les boutiques» 6. Le système affiche un message indiquant que la boutique est supprimée avec succès. Exception 2.1 L’opération de suppression est annulée si l’administrateur clique sur le bouton annuler. Tableau 32 : Description textuelle du cas d’utilisation «Supprimer boutique» Diagramme de séquences système du cas d’utilisation «Supprimer boutique» Figure 68 : Diagramme de séquences système du cas d’utilisation «Supprimer boutique» II.3.1.4 Analyse du cas d’utilisation «Verrouillerboutique» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Verrouiller boutique».
- 103. Projet de fin d’études Page 103 Description textuelle du cas d’utilisation «Verrouiller boutique» Cas d’utilisation Verrouiller boutique Acteur Administrateur Pré condition Administrateur authentifié. Liste des boutiques affichée. Boutique confirmée. Boutique déverrouillée. Post condition Boutique verrouillée Description du scénario principal 1. L’administrateur clique sur «Verrouiller». 2. Le système affiche une fenêtre de confirmation du choix. 3. L’administrateur confirme son choix. 4. Le système verrouille la boutique. 5. Le système met à jour l’état de la boutique dans la liste des boutiques affichée. 6. Le système redirige l’administrateur vers la page «lister les boutiques» Exception 2.1 L’opération de verrouillage est annulée si l’administrateur clique sur le bouton annuler. Tableau 33 : Description textuelle du cas d’utilisation «Verrouiller boutique» Diagramme de séquences système du cas d’utilisation «Verrouiller boutique» Figure 69 : Diagramme de séquences système du cas d’utilisation «Verrouiller boutique»
- 104. Projet de fin d’études Page 104 II.3.1.5 Analyse du cas d’utilisation «Consulterboutique» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Consulter boutique». Descriptiontextuelle du cas d’utilisation «Consulterboutique» Cas d’utilisation Consulter boutique Acteur Administrateur Pré condition Administrateur authentifié. Liste des boutiques affichée. Post condition Boutique consultée Description du scénario principal 1. L’administrateur clique sur «Afficher détails». 2. Le système affiche les informations de la boutique. Exception Néant Tableau 34 : Description textuelle du cas d’utilisation «Consulter boutique» Diagramme de séquences système du cas d’utilisation «Consulter boutique» Figure 70 : Diagramme de séquences système du cas d’utilisation «Consulter boutique» II.3.1.6 Analyse du cas d’utilisation «Ajouter boutique aux favoris» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Ajouter boutique aux favoris». Description textuelle du cas d’utilisation «Ajouter boutique aux favoris» Cas d’utilisation Ajouter boutique aux favoris Acteur Administrateur Pré condition Administrateur authentifié. Liste des boutiques affichée. Boutique confirmée. Post condition Boutique ajoutée aux favoris Description du scénario principal 1. L’administrateur clique sur «Ajouter aux favoris».
- 105. Projet de fin d’études Page 105 2. Le système affiche une fenêtre de confirmation du choix. 3. L’administrateur confirme son choix. 4. Le système ajoute la boutique aux favoris. 5. Le système met à jour l’état de la boutique dans la liste des boutiques affichée. 6. Le système redirige l’administrateur vers la page «lister boutiques» Exception 2.1 L’opération d’ajout aux favoris est annulée si l’administrateur clique sur le bouton annuler. Tableau 35 : Description textuelle du cas d’utilisation «Ajouter boutique aux favoris» Diagramme de séquences système du cas d’utilisation «Ajouter boutique aux favoris» Figure 71 : Diagramme de séquencessystème du cas d’utilisation «Ajouter boutique aux favoris» II.3.1.7 Analyse du cas d’utilisation «Lister produits boutique» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Lister produits boutique».
- 106. Projet de fin d’études Page 106 Description textuelle du cas d’utilisation «Lister produits boutique» Cas d’utilisation Lister produits boutique Acteur Administrateur Pré condition Administrateur authentifié. Boutique consultée. Post condition Liste des produits de la boutique affichée. Description du scénario principal 1. L’administrateur clique sur «Consulter les produits». 2. Le système affiche une liste comportant les produits de la boutique. Exception Néant Tableau 36 : Description textuelle du cas d’utilisation «Lister produits boutique» Diagramme de séquences système du cas d’utilisation «Lister produits boutique» Figure 72 : Diagramme de séquences système du cas d’utilisation «Lister produits boutique» II.3.1.8 Analyse du cas d’utilisation «Consulter produit» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Consulter produit». Description textuelle du cas d’utilisation «Consulter produit» Cas d’utilisation Consulter produit Acteur Administrateur Pré condition Administrateur authentifié. Liste des produits d’une boutique spécifique affichée. Post condition Produit consulté. Description du scénario principal 1. L’administrateur clique sur «Afficher détails». 2. Le système affiche les informations du produit. Exception Néant Tableau 37 : Description textuelle du cas d’utilisation «Consulter produit»
- 107. Projet de fin d’études Page 107 Diagramme de séquences système du cas d’utilisation «Consulter produit» Figure 73 : Diagramme de séquences système du cas d’utilisation «Consulter produit» III. Conception des cas d’utilisations Dans cette étape, nous allons élaborer les diagrammes de séquences détaillées ainsi que les diagrammes de classes des cas d’utilisations les plus importants. Par la suite, nous allons clôturer cette étape par l’établissement du diagramme de classes global de notre deuxième sprint. III.1 Conceptionde cas d’utilisation «Gérer ma boutique» III.1.1 Conception de cas d’utilisation «Créer ma boutique» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Créer ma boutique».
- 108. Projet de fin d’études Page 108 Diagramme de classes participantes au cas d’utilisation «Créer ma boutique» Figure 74 : Diagramme de classes participantes au cas d’utilisation «Créer ma boutique» Diagramme de séquences détaillées du cas d’utilisation «Créer ma boutique» Figure 75 : Diagramme de séquences détaillées du cas d’utilisation «Créer boutique»
- 109. Projet de fin d’études Page 109 III.1.2 Conception de cas d’utilisation «Paramétrer ma boutique» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Paramétrer ma boutique». Diagramme de classes participantes au cas d’utilisation «Paramétrer ma boutique» Figure 76 : Diagramme de classes participantes au cas d’utilisation «Paramétrer ma boutique» Diagramme de séquences détaillées du cas d’utilisation «Paramétrer ma boutique» Figure 77 : Diagramme de séquences détaillées du cas d’utilisation «Paramétrer ma boutique»
- 110. Projet de fin d’études Page 110 III.2 Conceptionde cas d’utilisation «Gérer mes produits» III.2.1 Conception de cas d’utilisation «Lister produits» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Lister produits». Diagramme de classes participantes au cas d’utilisation «Lister produits» Figure 78 : Diagramme de classes participantes au cas d’utilisation «Lister produits» Diagramme de séquences détaillées du cas d’utilisation «Lister produits» Figure 79 : Diagramme de séquences détaillées du cas d’utilisation «Lister produits»
- 111. Projet de fin d’études Page 111 III.2.2 Conception de cas d’utilisation «Ajouter produit» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Ajouter produit». Diagramme de classes participantes au cas d’utilisation «Ajouter produit» Figure 80 : Diagramme de classes participantes au cas d’utilisation «Ajouter produit» Pour ajouter un nouveau produit, le vendeur accède en premier lieu à l’interface «Produits» qui contient la liste de ses produits. Il clique ensuite sur le bouton «Ajouter un produit» qui va déclencher la méthode «newAction» au sein du contrôleur «ProduitController». Cette méthode déclenchée va appeler par conséquence l’interface «Ajouter produit» après avoir interrogé la base de données pour récupérer la liste des marques et catégories de produits appartenant au vendeur connecté. Le vendeur remplit le formulaire affiché dans l’interface «Ajouter produit» et clique sur confirmer. Les données seront chargées dans le système qui va vérifier leur validité. En cas de succès, le système affiche un message indiquant que le produit est ajouté avec succès, sinon le système affiche le(s) message(s) d’erreur(s) approprié(s).
- 112. Projet de fin d’études Page 112 Diagramme de séquences détaillées du cas d’utilisation «Ajouter produit» Figure 81 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter produit»
- 113. Projet de fin d’études Page 113 III.2.3 Conception de cas d’utilisation «Modifier produit» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Modifier produit». Diagramme de classes participantes au cas d’utilisation «Modifier produit» Figure 82 : Diagramme de classes participantes au cas d’utilisation «Modifier produit» Diagramme de séquences détaillées du cas d’utilisation «Modifier produit» Pour modifier un produit, le vendeur accède en premier lieu à l’interface «Produits» qui contient la liste de ses produits. Il clique ensuite sur le lien «Modifier» devant le produit qu’il envisage modifier qui va déclencher la méthode «editAction» au sein du contrôleur «ProduitController». Cette méthode déclenchée va appeler par conséquence l’interface «Modifier produit» après avoir interrogé la base de données pour récupérer la liste des marques, catégories de produits appartenant au vendeur connecté ainsi que la liste des images relatives au produit. Le vendeur modifie le formulaire affiché dans l’interface «Modifier produit» et clique sur confirmer. Les données seront chargées dans le système qui va vérifier leur validité. En cas de succès, le système affiche un message indiquant que le produit est modifié avec succès, sinon le système affiche le(s) message(s) d’erreur(s) approprié(s).
- 114. Projet de fin d’études Page 114 Figure 83 : Diagramme de séquences détaillées du cas d’utilisation «Modifier produit»
- 115. Projet de fin d’études Page 115 III.2.4 Conception de cas d’utilisation «Supprimer produit» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Supprimer produit». Diagramme de classes participantes au cas d’utilisation «Supprimer produit» Figure 84 : Diagramme de classes participantes au cas d’utilisation «Supprimer produit» Diagramme de séquences détaillées du cas d’utilisation «Supprimer produit» Figure 85 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer produit»
- 116. Projet de fin d’études Page 116 III.3 Conceptionde cas d’utilisation «Gérer les boutiques» III.3.1 Conception de cas d’utilisation «Lister boutiques» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Lister boutiques». Diagramme de classes participantes au cas d’utilisation «Lister boutiques» Figure 86 : Diagramme de classes participantes au cas d’utilisation «Lister boutiques» Diagramme de séquences détaillées du cas d’utilisation «Lister boutiques» Figure 87 : Diagramme de séquences détaillées du cas d’utilisation «Lister boutiques»
- 117. Projet de fin d’études Page 117 III.3.2 Conception de cas d’utilisation «Confirmer boutique» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Confirmer boutique». Diagramme de classes participantes au cas d’utilisation «Confirmer boutique» Figure 88 : Diagramme de classes participantes au cas d’utilisation «Confirmer boutique» Diagramme de séquences détaillées du cas d’utilisation «Confirmer boutique» Figure 89 : Diagramme de séquences détaillées du cas d’utilisation «Confirmer boutique»
- 118. Projet de fin d’études Page 118 III.3.3 Conception de cas d’utilisation «Supprimer boutique» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Supprimer boutique». Diagramme de classes participantes au cas d’utilisation «Supprimer boutique» Figure 90 : Diagramme de classes participantes au cas d’utilisation «Supprimer boutique» Diagramme de séquences détaillées du cas d’utilisation «Supprimer boutique» Figure 91 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer boutique»
- 119. Projet de fin d’études Page 119 III.3.4 Conception de cas d’utilisation «Verrouiller boutique» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Verrouiller boutique». Diagramme de classes participantes au cas d’utilisation «Verrouiller boutique» Figure 92 : Diagramme de classes participantes au cas d’utilisation «Verrouiller boutique» Diagramme de séquences détaillées du cas d’utilisation «Verrouiller boutique» Figure 93 : Diagramme de séquences détaillées du cas d’utilisation «Verrouiller boutique»
- 120. Projet de fin d’études Page 120 III.3.5 Conception de cas d’utilisation «Consulter boutique» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Consulter boutique». Diagramme de classes participantes au cas d’utilisation «Consulter boutique» Figure 94 : Diagramme de classes participantes au cas d’utilisation «Consulter boutique» Diagramme de séquences détaillées du cas d’utilisation «Consulter boutique» Figure 95 : Diagramme de séquences détaillées du cas d’utilisation «Consulter boutique»
- 121. Projet de fin d’études Page 121 III.3.6 Conception de cas d’utilisation «Ajouter boutique aux favoris» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Ajouter boutique aux favoris». Diagramme de classes participantes au cas d’utilisation «Ajouter boutique aux favoris» Figure 96 : Diagramme de classes participantes au cas d’utilisation «Ajouter boutique aux favoris» Diagramme de séquences détaillées du cas d’utilisation «Ajouter boutique aux favoris» Figure 97 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter boutique aux favoris»
- 122. Projet de fin d’études Page 122 III.3.7 Conception de cas d’utilisation «Lister produits boutique» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Lister produits boutique». Diagramme de classes participantes au cas d’utilisation «Lister produits boutique» Figure 98 : Diagramme de classes participantes au cas d’utilisation «Lister produits boutique» Diagramme de séquences détaillées du cas d’utilisation «Lister produits boutique» Figure 99 : Diagramme de séquences détaillées du cas d’utilisation «Lister produits boutique»
- 123. Projet de fin d’études Page 123 III.3.8 Conception de cas d’utilisation «Consulter produit» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Consulter produit». Diagramme de classes participantes au cas d’utilisation «Consulter produit» Figure 100 : Diagramme de classes participantes au cas d’utilisation «Consulter produit» Diagramme de séquences détaillées du cas d’utilisation «Consulter produit» Figure 101 : Diagramme de séquences détaillées du cas d’utilisation «Consulter produit»
- 124. Projet de fin d’études Page 124 III.4 Diagramme de classe globaldu deuxième sprint Figure 102 : Diagramme de classes global du deuxième sprint IV. Implémentation La phase d’implémentation ou la phase de codage consiste à implémenter les fonctionnalités spécifiées au niveau du backlog de sprint. Dans cette étape, nous allons définir la structure de la base de données du sprint courant tout en appliquant les règles de passage du modèle entité/association au modèle relationnel.
- 125. Projet de fin d’études Page 125 Schéma de la base de données Champs Types Contraintes Id INT(11) PRIMARY KEY Libellé VARCHAR(50) Vendeur_id INT(11) FOREIGN KEY Tableau 38 : Table «Categorie_produit» Champs Types Contraintes Id INT(11) PRIMARY KEY Libellé VARCHAR(50) Vendeur_id INT(11) FOREIGN KEY Tableau 39 : Table «Marque» Champs Types Contraintes Id INT(11) PRIMARY KEY Nom VARCHAR(50) Description VARCHAR(50) Poids VARCHAR(50) Quantité VARCHAR(50) Prix VARCHAR(50) Favoris BOOLEAN Boutique_id INT(11) FOREIGN KEY Categorie_produit_id INT(11) FOREIGN KEY Marque_id INT(11) FOREIGN KEY Tableau 40 : Table «Produit» Champs Types Contraintes Id INT(11) PRIMARY KEY Path VARCHAR(50) Produit_id INT(11) FOREIGN KEY Tableau 41 : Table «Image» Interface du cas «Lister boutiques» Figure 103 : Interface du cas «Lister boutiques»
- 126. Projet de fin d’études Page 126 Interface du cas «Paramétrer ma boutique» Figure 104 : Interface du cas «Paramétrer ma boutique» V. Tests Les tests représentent la dernière étape du cycle Scrum. C’est l’occasion de comparer les résultats issus de notre incrément avec les objectifs fixés au début du sprint. V.1 Les tests unitaires Nous continuons toujours à travailler avec le Framework de tests unitaires open source PHPUnit. Nous allons montrer dans cette section quelques cas de tests unitaires effectués ainsi que le raisonnement adopté pour la réalisation de ces derniers. V.1.1 Le test unitaire du cas d’utilisation «Verrouiller boutique» Raisonnement Pour tester le verrouillage d’une boutique, nous avons suivi le raisonnement suivant : 1. Récupérer une boutique non verrouillée 2. Verrouiller la boutique et mettre à jour la base de données 3. Récupérer de nouveau la même boutique 4. Vérifier l’état de verrouillage de la boutique En cas de succès, on obtiendra : L’attribut «Verrou» de la boutique récupérée vaut TRUE.
- 127. Projet de fin d’études Page 127 Code source de la méthode de test du cas d’utilisation «Verrouiller boutique» Figure 105 : Code source de la méthode de test du cas «Verrouiller boutique» Capture d’écran représentant le résultat du test du cas d’utilisation «Verrouiller boutique» Figure 106 : Interface de résultat du test du cas «Verrouiller boutique» V.1.2 Le test unitaire du cas d’utilisation «Paramétrer ma boutique» Raisonnement Pour tester le cas d’utilisation «Paramétrer ma boutique», nous avons suivi le raisonnement suivant : 1. On récupère une boutique 2. On modifie les attributs de la boutique et on met à jour la base de données 3. On récupère de nouveau la même boutique 4. On compare les attributs récupérés avec les valeurs attribués à l’entité lors de la mise à jour En cas de succès, on obtiendra : Les valeurs des attributs récupérés sont identiques aux valeurs attribuées à l’entité lors de la mise à jour.
- 128. Projet de fin d’études Page 128 Code source de la méthode de test du cas d’utilisation «Paramétrer ma boutique» Figure 107 : Code source de la méthode de test du cas «Paramétrer ma boutique» Capture d’écran représentant le résultat du test du cas d’utilisation «Paramétrer ma boutique» Figure 108 : Interface de résultat du test du cas «Paramétrer ma boutique» V.1.3 Le test unitaire du cas d’utilisation «Ajouter produit aux favoris» Raisonnement Pour tester l’ajout d’un produit aux favoris, nous avons suivi le raisonnement suivant : 1. Récupérer un produit non ajouté aux favoris 2. Ajouter le produit aux favoris et mettre à jour la base de données 3. Récupérer de nouveau le même produit 4. Vérifier si le produit est ajouté aux favoris ou non En cas de succès, on obtiendra : L’attribut «Favoris» du produit récupéré vaut TRUE.
- 129. Projet de fin d’études Page 129 Code source de la méthode de test du cas d’utilisation «Ajouter produit aux favoris» Figure 109 : Code source de la méthode de test d’ajout d’un produit aux favoris Capture d’écran représentant le résultat du test du cas d’utilisation «Ajouter produit aux favoris» Figure 110 : Interface de résultat du test d’ajout d’un produit aux favoris V.1.4 Le test unitaire du cas d’utilisation «Confirmer boutique» Raisonnement Pour tester la confirmation d’une boutique, nous avons suivi le raisonnement suivant : 1. Récupérer une boutique non confirmée 2. Confirmer la boutique et mettre à jour la base de données 3. Récupérer de nouveau la même boutique 4. Vérifier si la boutique est confirmée ou non En cas de succès, on obtiendra : L’attribut «Confirm» de la boutique récupérée vaut TRUE.
- 130. Projet de fin d’études Page 130 Code source de la méthode de test du cas d’utilisation «Confirmer boutique» Figure 111 : Code source de la méthode de test de confirmation d’une boutique Capture d’écran représentant le résultat du test du cas d’utilisation «Confirmer boutique» Figure 112 : Interface de résultat du test de confirmation d’une boutique Après avoir terminé la phase de test, nous allons commencer à penser à notre troisième sprint où on va réaliser les parties restantes dans le backlog de produit et gérer les échanges avec l’application mobile (le front office) à travers les APIs. C’est la partie la plus délicate de notre application vu qu’on va commencer à développer les services web. Elle nécessite une forte communication avec les membres de l’équipe pour assurer une cohérence avec les 2 releases qui sont développés d’une manière indépendante. VI. Revue de sprint La revue de sprint a pour objectif d’inspecter les résultats issus de cette itération. «L’équipe du projet et les utilisateurs se réunissent pour effectuer la revue du sprint. L’équipe rappelle les objectifs de l’itération et indique les fonctionnalités réalisées pendant le sprint. Chaque membre de l’équipe fait une démonstration des nouvelles fonctionnalités qu’il a réalisées.»[N5]
- 131. Projet de fin d’études Page 131 VI.1. Diagramme de «Burndown Chart» Figure 113 : Diagramme de Burndown Chart du sprint 2 VI.2 Calculde vélocité Le calcul de vélocité se fait en additionnant les points d’estimations attribués aux histoires utilisateurs acceptés. L’équipe de développement aura l’opportunité de vérifier que le choix «Nombre de fonctionnalités/Temps nécessaires» fait précédemment est adapté ou nécessite encore des ajustements. Comme on a mentionné précédemment, on est en train d’attribuer un nombre de points aux histoires utilisateurs en fonction de leur complexité. ID User Story Estimation 1 15 2 15 3 10 4 10 5 10 6 10 7 10 8 10 9 10 10 10 11 10
- 132. Projet de fin d’études Page 132 12 15 13 15 14 10 15 10 16 15 17 15 18 10 19 10 20 20 21 20 22 10 23 10 24 10 25 10 26 10 Vélocité estimée 310 Tableau 42 : Calcul de vélocité estimée La figure 113 comporte le diagramme de Burndown Chart et un tableau à gauche comportant une colonne (nommée ‘Done Today’) qui indique l’ensemble des points réalisés pour chaque jour durant ce deuxième sprint. La somme de cette colonne est égale à 250 points alors que la vélocité estimée vaut 310 points. Partant du principe qui indique que chaque fonctionnalité partiellement terminée ne rapportera aucun point vu qu’on ne peut pas l’utiliser actuellement, on a éliminé la totalité des points des fonctionnalités non terminées. VI.3 Réajustements à faire pour le prochain sprint Lors de cette étape, on commencer toujours par le classement des user stories non terminées au cours de ce sprint par ordre de priorité. Dans notre cas, les users stories partiellement traitées ont le même ordre de priorité. Il s’agit des fonctionnalités relatives au listage, ajout, modification et suppression des produits. Vus les obstacles rencontrés et comme ces fonctionnalités sont indispensables pour notre application, nous avons décidé de reporter l’implémentation de ces derniers au sprint suivant. Conclusion Dans ce chapitre, nous nous sommes concentrés sur le développement de notre deuxième sprint. Nous avons donc un deuxième incrément potentiellement livrable de notre logiciel. Dans le chapitre suivant, nous allons nous concentrer sur la réalisation de notre troisième et dernier sprint qui va nous permettre de communiquer avec l’application mobile à travers les APIs.
- 133. Projet de fin d’études Page 133 Chapitre 5 Sprint 3 : Gestion des échanges, commandes, statistiques et clients
- 134. Projet de fin d’études Page 134 Introduction Dans le chapitre précédent, nous avons réalisé notre deuxième sprint, qui nous a permis d’obtenir une deuxième version potentiellement livrable de notre logiciel. Au démarrage d’un sprint, on commence toujours par la définition de ses objectifs et la fixation de l’ensemble des fonctionnalités qu’on comptera développer. Au cours de ce troisième sprint, nous allons commencer à développer une partie très importante de notre application. Il s’agit des services web qui vont nous permettre de réaliser les échanges nécessaires avec l’application mobile (le front office). Cette partie délicate nécessite une forte communication entre les membres de l’équipe Scrum vu que nous allons fournir les informations nécessaires au front office d’une part et intercepter les données dont nous avons besoin à partir de l’application mobile d’autre part. I. La spécification fonctionnelle À l’initiation de chaque itération, la spécification fonctionnelle est représentée par un diagramme de cas d’utilisation. I.1 Le sprint backlog Il s’agit de l’ensemble de fonctionnalités extraites par l’équipe Scrum à partir du Backlog du produit et qui vont être réalisés au cours de ce sprint. Le tableau 43 englobe le backlog du troisième sprint ID User Story User Story ID tâche Tâche Affectation 1 En tant que vendeur, je veux afficher la liste des commandes relatives à mes clients. 1.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «Lister mes commandes» Rami Raddaoui 1.2 Implémenter le cas d’utilisation «Lister mes commandes» Rami Raddaoui 1.3 Tester le cas d’utilisation «Lister mes commandes» Rami Raddaoui 2 En tant que vendeur, je veux modifier l’état d’une commande 2.1 Élaborer le diagramme de cas d’utilisation, de séquences système, Rami Raddaoui
- 135. Projet de fin d’études Page 135 spécifique. de séquences détaillées et de classes du cas d’utilisation «Modifier état commande» 2.2 Implémenter le cas d’utilisation «Modifier état commande» Rami Raddaoui 2.3 Tester le cas d’utilisation «Modifier état commande» Rami Raddaoui 3 En tant qu’administrateur, je veux afficher la liste des commandes de toute la place de marché. 3.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «Lister les commandes» Rami Raddaoui 3.2 Implémenter le cas d’utilisation «Lister les commandes» Rami Raddaoui 3.3 Tester le cas d’utilisation «Lister les commandes» Rami Raddaoui 4 En tant qu’administrateur, je veux afficher la liste des clients. 4.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «Lister clients» Rami Raddaoui 4.2 Implémenter le cas d’utilisation «Lister clients» Rami Raddaoui 4.3 Tester le cas d’utilisation «Lister clients» Rami Raddaoui 5 En tant qu’administrateur, je veux supprimer un client spécifique. 5.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de Rami Raddaoui
- 136. Projet de fin d’études Page 136 classes du cas d’utilisation «Supprimer client» 5.2 Implémenter le cas d’utilisation «Supprimer client» Rami Raddaoui 5.3 Tester le cas d’utilisation «Supprimer client» Rami Raddaoui 6 En tant que vendeur, je veux afficher des indicateurs et statistiques sur les ventes de ma boutique. 6.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «Afficher les statistiques de ma boutique» Rami Raddaoui 6.2 Implémenter le cas d’utilisation «Afficher les statistiques de ma boutique» Rami Raddaoui 6.3 Tester le cas d’utilisation «Afficher les statistiques de ma boutique» Rami Raddaoui 7 En tant qu’administrateur, je veux afficher des indicateurs et statistiques sur les ventes de toute la place de marché. 7.1 Élaborer le diagramme de cas d’utilisation, de séquences système, de séquences détaillées et de classes du cas d’utilisation «Afficher les statistiques de la place de marché» Rami Raddaoui 7.2 Implémenter le cas d’utilisation «Afficher les statistiques de la place de marché» Rami Raddaoui 7.3 Tester le cas d’utilisation «Afficher les statistiques de la place de marché» Rami Raddaoui Tableau 43 : Backlog du troisième sprint
- 137. Projet de fin d’études Page 137 I.2 Classificationdes cas d’utilisations par acteur : Acteur Cas d’utilisation Vendeur Lister mes commandes Modifier état commande Afficher les statistiques de ma boutique Administrateur Lister les commandes Lister clients Supprimer client Afficher les statistiques de la place de marché Tableau 44 : Classification des cas d’utilisation par acteur I.3 Diagramme de cas d’utilisation La figure 114 représente le diagramme de cas d’utilisation général de notre troisième sprint. Figure 114 : Diagramme de cas d’utilisation du troisième sprint II. Analyse des cas d’utilisation Au cours de cette section, nous allons faire le raffinement des cas d’utilisations afin de prévoir tous les scénarios possibles.
- 138. Projet de fin d’études Page 138 II.1 Analyse du cas d’utilisation «Gérer les clients» Nous procéderons par le raffinement du cas d’utilisation «Gérer les clients». II.1.1 Raffinement du cas d’utilisation «Gérer les clients» Figure 115 : Diagramme de cas d’utilisation : Gérer les clients II.1.1.1 Analyse du cas d’utilisation «Lister les clients» Nous procéderons par la description textuelle puis le diagramme de séquences système du cas «Lister les clients». Description textuelle du cas d’utilisation «Lister les clients» Cas d’utilisation Lister les clients Acteur Administrateur Pré condition Administrateur authentifié. Post condition Liste des clients affichée Description du scénario principal 1. L’administrateur clique sur «Clients». 2. Le système affiche la liste des clients. Exception Néant Tableau 45 : Description textuelle du cas d’utilisation «Lister les clients» Diagramme de séquences système du cas «Lister les clients» Figure 116 : Diagramme de séquences système du cas d’utilisation «Lister les clients»
- 139. Projet de fin d’études Page 139 II.1.1.2 Analyse du cas d’utilisation «Supprimerclient» Nous procéderons par la description textuelle puis le diagramme de séquences système du cas «Supprimer client». Description textuelle du cas d’utilisation «Supprimer client» Cas d’utilisation Supprimer client Acteur Administrateur Pré condition Administrateur authentifié. Liste des clients affichée. Post condition Client supprimé. Description du scénario principal 1. L’administrateur clique sur «Supprimer». 2. Le système affiche une fenêtre de confirmation. 3. L’administrateur confirme la suppression. 4. Le système supprime le client. 5. Le système redirige l’administrateur vers la page «lister les clients» 6. Le système affiche un message indiquant que le client est supprimé avec succès. Exception 2.1 L’opération de suppression est annulée si l’administrateur clique sur le bouton annuler. Tableau 46 : Description textuelle du cas d’utilisation «Supprimer client» Diagramme de séquences système du cas d’utilisation «Supprimer client» Figure 117 : Diagramme de séquences système du cas d’utilisation «Supprimer client»
- 140. Projet de fin d’études Page 140 II.2 Analyse du cas d’utilisation «Gérer mes commandes» Nous procéderons par le raffinement du cas d’utilisation «Gérer mes commandes». II.2.1 Raffinement du cas d’utilisation «Gérer mes commandes» Figure 118 : Diagramme de cas d’utilisation : Gérer mes commandes II.2.1.1 Analyse du cas d’utilisation «Lister mes commandes» Nous procéderons par la description textuelle puis le diagramme de séquences système du cas «Lister mes commandes». Description textuelle du cas d’utilisation «Lister mes commandes» Cas d’utilisation Lister mes commandes Acteur Vendeur Pré condition Vendeur authentifié. Post condition Liste des commandes affichée Description du scénario principal 1. Le vendeur clique sur «Commandes». 2. Le système affiche la liste des commandes. Exception Néant Tableau 47 : Description textuelle du cas d’utilisation «Lister mes commandes» Diagramme de séquences système du cas «Lister mes commandes» Figure 119 : Diagramme de séquences système du cas d’utilisation «Lister mes commandes»
- 141. Projet de fin d’études Page 141 II.2.1.2 Analyse du cas d’utilisation «Modifier état commande» Nous procéderons par la description textuelle puis le diagramme de séquences système du cas «Modifier état commande». Description textuelle du cas d’utilisation «Modifier état commande» Cas d’utilisation Modifier état commande Acteur Vendeur Pré condition Vendeur authentifié Liste des commandes relatives au vendeur affichée Post condition État de commande mis à jour Description du scénario principal 1. Le vendeur clique sur «Modifier état». 2. Le système affiche une liste déroulante contenant l’ensemble des états possibles. 3. Le vendeur sélectionne l’état désiré et valide le formulaire. 4. Le système met à jour l’état de la commande. 5. Le système redirige le vendeur vers la page «lister mes commandes» 6. Le système affiche un message indiquant que l’état de la commande est mis à jour avec succès. Exception Néant Tableau 48 : Description textuelle du cas d’utilisation «Modifier état commande» Diagramme de séquences système du cas «Modifier état commande» Figure 120 : Diagramme de séquences système du cas d’utilisation «Modifier état commande»
- 142. Projet de fin d’études Page 142 II.3 Analyse du cas d’utilisation «Gérer les commandes» Nous procéderons par le raffinement du cas d’utilisation «Gérer les commandes». II.3.1 Raffinement du cas d’utilisation «Gérer les commandes» Figure 121 : Diagramme de cas d’utilisation : Gérer les commandes II.3.1.1 Analyse du cas d’utilisation «Lister les commandes» Nous procéderons par la description textuelle puis le diagramme de séquences système du cas «Lister les commandes». Description textuelle du cas d’utilisation «Lister les commandes» Cas d’utilisation Lister les commandes Acteur Administrateur Pré condition Administrateur authentifié. Post condition Liste des commandes affichée Description du scénario principal 1. L’administrateur clique sur «Commandes». 2. Le système affiche la liste des commandes. Exception Néant Tableau 49 : Description textuelle du cas d’utilisation «Lister les commandes» Diagramme de séquences système du cas «Lister les commandes» Figure 122 : Diagramme de séquences système du cas d’utilisation «Lister les commandes»
- 143. Projet de fin d’études Page 143 II.4 Analyse du cas d’utilisation «Afficher les statistiquesde ma boutique» Nous procéderons par la description textuelle puis le diagramme de séquences système du cas «Afficher les statistiques de ma boutique». Description textuelle du cas d’utilisation «Afficher les statistiques de ma boutique» Cas d’utilisation Afficher les statistiques de ma boutique Acteur Vendeur Pré condition Vendeur authentifié. Post condition Indicateurs et statistiques affichés Description du scénario principal 1. Le vendeur clique sur «Tableau de bord». 2 Le système affiche les indicateurs et les statistiques. Exception Néant Tableau 50 : Description textuelle du cas d’utilisation «Afficher les statistiques de ma boutique» Diagramme de séquences système du cas d’utilisation «Afficher les statistiques de ma boutique» Figure 123 : Diagramme de séquences système du cas d’utilisation «Afficherles statistiques de ma boutique» II.5 Analyse du cas d’utilisation «Afficher les statistiquesde la placede marché» Nous procéderons par la description textuelle puis le diagramme de séquences système du cas «Afficher les statistiques de la place de marché».
- 144. Projet de fin d’études Page 144 Description textuelle du cas d’utilisation «Afficher les statistiques de la place de marché» Cas d’utilisation Afficher les statistiques de la place de marché Acteur Administrateur Pré condition Administrateur authentifié. Post condition Indicateurs et statistiques de la place de marché affichés Description du scénario principal 1. L’administrateur clique sur «Tableau de bord». 3 Le système affiche les indicateurs et les statistiques de la place de marché. Exception Néant Tableau 51 : Description textuelle du cas d’utilisation «Afficher les statistiques de ma boutique» Diagramme de séquences système du cas d’utilisation «Afficher les statistiques de la place de marché» Figure 124 : Diagramme de séquences système du cas d’utilisation «Afficherles statistiques de la place de marché»
- 145. Projet de fin d’études Page 145 III. Conception des cas d’utilisations Dans cette étape, nous allons élaborer les diagrammes de séquences détaillées ainsi que les diagrammes de classes des cas d’utilisations analysés dans la section précédente. Par la suite, nous allons établir le diagramme de classes global de notre troisième et dernier sprint. III.1 Conceptionde cas d’utilisation «Gérer les clients» III.1.1 Conception de cas d’utilisation «Lister les clients» Nous procéderons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Lister les clients». Diagramme de classes participantes au cas d’utilisation «Lister les clients» Figure 125 : Diagramme de classes participantes au cas d’utilisation «Lister les clients» Diagramme de séquences détaillées du cas d’utilisation «Lister les clients» Figure 126 : Diagramme de séquences détaillées du cas d’utilisation «Lister les clients»
- 146. Projet de fin d’études Page 146 III.1.2 Conception de cas d’utilisation «Supprimer client» Nous procéderons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Supprimer client». Diagramme de classes participantes au cas d’utilisation «Supprimer client» Figure 127 : Diagramme de classes participantes au cas d’utilisation «Supprimer client» Diagramme de séquences détaillées du cas d’utilisation «Supprimer client» Figure 128 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer client»
- 147. Projet de fin d’études Page 147 III.2 Conceptionde cas d’utilisation «Gérer mes commandes» III.2.1 Conception de cas d’utilisation «Lister mes commandes» Nous procéderons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Lister mes commandes». Diagramme de classes participantes au cas d’utilisation «Lister mes commandes» Figure 129 : Diagramme de classes participantes au cas d’utilisation «Lister mes commandes» Diagramme de séquences détaillées du cas d’utilisation «Lister mes commandes» Figure 130 : Diagramme de séquences détaillées du cas d’utilisation «Lister mes commandes»
- 148. Projet de fin d’études Page 148 III.2.2 Conception de cas d’utilisation «Modifier état commande» Nous procéderons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Modifier état commande». Diagramme de classes participantes au cas d’utilisation «Modifier état commande» Figure 131 : Diagramme de classes participantes au cas d’utilisation «Modifier état commande» Diagramme de séquences détaillées du cas d’utilisation «Modifier état commande» Figure 132 : Diagramme de séquences détaillées du cas d’utilisation «Modifier état commande»
- 149. Projet de fin d’études Page 149 III.3 Conceptionde cas d’utilisation «Gérer les commandes» III.3.1 Conception de cas d’utilisation «Lister les commandes» Nous procéderons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Lister les commandes». Diagramme de classes participantes au cas d’utilisation «Lister les commandes» Figure 133 : Diagramme de classes participantes au cas d’utilisation «Lister les commandes» Diagramme de séquences détaillées du cas d’utilisation «Lister les commandes» Figure 134 : Diagramme de séquences détaillées du cas d’utilisation «Lister les commandes»
- 150. Projet de fin d’études Page 150 III.4 Conceptionde cas d’utilisation «Afficher les statistiquesde ma boutique» Nous procéderons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Afficher les statistiques de ma boutique». Diagramme de classes participantes au cas d’utilisation «Afficher les statistiques de ma boutique» Figure 135 : Diagramme de classes participantes au cas d’utilisation «Afficher les statistiques de ma boutique» Diagramme de séquences détaillées du cas d’utilisation «Afficher les statistiques de ma boutique» Figure 136 : Diagramme de séquences détaillées du cas d’utilisation «Afficher les statistiques de ma boutique»
- 151. Projet de fin d’études Page 151 III.5 Conceptionde cas d’utilisation «Afficher les statistiquesde la placede marché» Nous procéderons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Afficher les statistiques de la place de marché». Diagramme de classes participantes au cas d’utilisation «Afficher les statistiques de la place de marché» Figure 137 : Diagramme de classes participantes au cas d’utilisation «Afficher les statistiques de la place de marché» Diagramme de séquences détaillées du cas d’utilisation «Afficher les statistiques de la place de marché» Figure 138 : Diagramme de séquences détaillées du cas d’utilisation «Afficher les statistiques de la place de marché»
- 152. Projet de fin d’études Page 152 IV. Les Services WEB Un service web est une technologie qui permet à des applications éloignés de communiquer ensemble à travers l’internet. Cette communication est établie indépendamment des plates-formes et langages de programmation associés aux applications. Il est identifié par un URL et son contenu est représenté avec un format de données spécifique comme JSON (JavaScript Object Notation) ou XML (eXtensible Markup Language). [Voir annexe A] Description des APIs URL Méthode(s) supportée(s) Rôle /api/get/client POST Cette API a pour rôle d’intercepter les données d’un client spécifique qui a remplit et validé le formulaire d’inscription au niveau de l’application mobile. Ces données récupérées sont insérées dans la table associée de notre base de données. /api/verif/client POST Cette API a pour rôle d’intercepter les données d’un client spécifique qui a remplit et validé le formulaire de connexion au niveau de l’application mobile. Ces données récupérées seront chargées dans le système qui va vérifier la validité de ces identifiants. La méthode associée à cet API retourne une réponse pour permettre à l’application mobile soit de passer à la page d’accueil du client, soit de lui indiquer que les identifiants sont incorrects. /api/catégories/boutiques GET Cette API a pour rôle de retourner les catégories de boutiques existantes dans la base de données sous le format de données JSON. /api/boutiques/favoris GET Cette API a pour rôle de retourner les boutiques ajoutées aux favoris. /api/boutiques/catégories/ {catégorie_id} GET Cette API a pour rôle de retourner les boutiques qui appartiennent à la catégorie de boutiques ayant comme identifiant le contenu de la variable {catégorie_id}. /api/boutiques/produits/ {boutique_id} GET Cette API a pour rôle de retourner les produits qui appartiennent à la boutique ayant comme identifiant le contenu de la variable {boutique_id}. /api/catégories/produits/ GET Cette API a pour rôle de retourner
- 153. Projet de fin d’études Page 153 {boutique_id} les catégories de produits qui appartiennent à la boutique ayant comme identifiant le contenu de la variable {boutique_id}. /api/boutiques/produits/ catégories/{catégorie_id} GET Cette API a pour rôle de retourner les produits qui appartiennent à la catégorie de produits ayant comme identifiant le contenu de la variable {catégorie_id}. /api/catégories/boutiques/ libelle/{id_catégorie} GET Cette API a pour rôle de retourner le libellé de la catégorie de boutiques ayant comme identifiant le contenu de la variable {id_catégorie}. /api/info/boutique/ {id_boutique} GET Cette API a pour rôle de retourner les informations de la boutique ayant comme identifiant le contenu de la variable {id_boutique}. /api/info/produit /{id_produit} GET Cette API a pour rôle de retourner les informations du produit ayant comme identifiant le contenu de la variable {id_produit}. /api/favoris/produits GET Cette API a pour rôle de retourner les produits ajoutés aux favoris. /api/recherche /{id_boutique}/{chaine} GET Cette API a pour rôle de retourner les produits dont le nom contient le contenu de la variable {chaine} et qui appartiennent à la boutique ayant comme identifiant le contenu de la variable {id_boutique}. Il s’agit d’une API servant pour une barre de recherche des produits à l’intérieur d’une boutique. /api/get/images/{id_produit} GET Cette API a pour rôle de retourner la liste des images du produit ayant comme identifiant le contenu de la variable {id_produit}. /api/get/commande/client POST Cette API a pour rôle d’intercepter les données relatives à une commande passée par un client. Ces données récupérées sont insérées dans les tables associées de notre base de données. Tableau 52 : Description des APIs
- 154. Projet de fin d’études Page 154 IV.1 Conceptiondes services WEB «La conception d’un service Web nécessite les étapes suivantes : • Définir et créer un service Web • Publier le service Web sur le serveur d’application • Utiliser un service Web en créant un client.»[N14] Figure 139 : Mise en place d’un service WEB [N14] IV.1.1 Conception de l’API «Inscription client» Diagramme de classes participantes à l’API «Inscription client» Figure 140 : Diagramme de classes participantes à l’API «Inscription client»
- 155. Projet de fin d’études Page 155 Diagramme de séquences détaillées de l’API «Inscription client» Figure 141 : Diagramme de séquences détaillées de l’API «Inscription client» IV.1.2 Conception de l’API «Authentification client» Diagramme de classes participantes à l’API «Authentification client» Figure 142 : Diagramme de classes participantes à l’API «Authentification client»
- 156. Projet de fin d’études Page 156 Diagramme de séquences détaillées de l’API «Authentification client» Figure 143 : Diagramme de séquences détaillées de l’API «Authentification client» IV.1.3 Conception de l’API «GET catégories boutiques» Diagramme de classes participantes à l’API «GET catégories boutiques» Figure 144 : Diagramme de classes participantes à l’API «GET catégories boutiques»
- 157. Projet de fin d’études Page 157 Diagramme de séquences détaillées de l’API «GET catégories boutiques» Figure 145 Diagramme de séquences détaillées de l’API «GET catégories boutiques» IV.1.4 Conceptionde l’API «GET boutiquesfavoris» Diagramme de classes participantes à l’API «GET boutiques favoris» Figure 146 : Diagramme de classes participantes à l’API «GET boutiques favoris»
- 158. Projet de fin d’études Page 158 Diagramme de séquences détaillées de l’API «GET boutiques favoris» Figure 147 : Diagramme de séquences détaillées de l’API «GET boutiques favoris» IV.1.5 Conception de l’API «GET boutiques By Catégorie» Diagramme de classes participantes à l’API «GET boutiques By Catégorie» Figure 148 : Diagramme de classes participantes à l’API «GET boutiques By Catégorie»
- 159. Projet de fin d’études Page 159 Diagramme de séquences détaillées de l’API «GET boutiques By Catégorie» Figure 149 : Diagramme de séquences détaillées de l’API «GET boutiques By Catégorie» IV.1.6 Conception de l’API «GET produits By Boutique» Diagramme de classes participantes à l’API «GET produits By Boutique» Figure 150 : Diagramme de classes participantes à l’API «GET produits By Boutique»
- 160. Projet de fin d’études Page 160 Diagramme de séquences détaillées de l’API «GET produits By Boutique» Figure 151 : Diagramme de séquences détaillées de l’API «GET produits By Boutique» IV.1.7 Conception de l’API «GET produits By Catégorie» Diagramme de classes participantes à l’API «GET produits By Catégorie» Figure 152 : Diagramme de classes participantes à l’API «GET produits By Catégorie»
- 161. Projet de fin d’études Page 161 Diagramme de séquences détaillées de l’API «GET produits By Catégorie» Figure 153 : Diagramme de séquences détaillées de l’API «GET produits By Catégorie» IV.1.8 Conception de l’API «GET Catégories produits By Boutique» Diagramme de classes participantes à l’API «GET Catégories produits By Boutique» Figure 154 : Diagramme de classes participantes à l’API «GET Catégories produits By Boutique»
- 162. Projet de fin d’études Page 162 Diagramme de séquences détaillées de l’API «GET Catégories produits By Boutique» Figure 155 : Diagramme de séquences détaillées de l’API «GET Catégories produits By Boutique» IV.1.9 Conception de l’API «GET libellé By ID catégorie» Diagramme de classes participantes à l’API «GET libellé By ID catégorie» Figure 156 : Diagramme de classes participantes à l’API «GET Libellé By ID Catégorie»
- 163. Projet de fin d’études Page 163 Diagramme de séquences détaillées de l’API «GET libellé By ID catégorie» Figure 157 : Diagramme de séquences détaillées de l’API «GET libellé By ID catégorie» IV.1.10 Conception de l’API «GET produit By ID» Diagramme de classes participantes à l’API «GET produit By ID» Figure 158 : Diagramme de classes participantes à l’API «GET Produit By ID»
- 164. Projet de fin d’études Page 164 Diagramme de séquences détaillées de l’API «GET Produit By ID» Figure 159 : Diagramme de séquences détaillées de l’API «GET Produit By ID» IV.1.11 Conception de l’API «GET produits Favoris» Diagramme de classesparticipantes à l’API «GETproduitsFavoris» Figure 160 : Diagramme de classes participantes à l’API «GET produits Favoris»
- 165. Projet de fin d’études Page 165 Diagramme de séquences détaillées de l’API «GET produits Favoris» Figure 161 : Diagramme de séquences détaillées de l’API «GET produits favoris» IV.1.12 Conception de l’API «GET Images By ID Produit» Diagramme de classes participantes à l’API «GET Images By ID Produit» Figure 162 : Diagramme de classes participantes à l’API «GET Images By ID Produit»
- 166. Projet de fin d’études Page 166 Diagramme de séquences détaillées de l’API «GET Images By ID Produit» Figure 163 : Diagramme de séquences détaillées de l’API «GET Images By ID Produit» IV.1.13 Conception de l’API «GET Commande Client» Diagramme de classes participantes à l’API «GET Commande Client» Figure 164 : Diagramme de classes participantes à l’API «GET Commande Client» Diagramme de séquences détaillées de l’API «GET Commande Client» Lorsqu’un client clique sur le bouton «Commander» de l’interface «Commande» de l’application mobile, il va implicitement déclencher un service web et par conséquent l’exécution de la méthode «getCommandeClientAction» au sein du contrôleur «APIController». Le système va vérifier les données reçues. En cas de succès, le système retourne une réponse indiquant que l’opération a été effectuée avec succès. Dans le cas échéant, le système retourne une réponse indiquant que les données sont invalides et par conséquent la commande n’a pas été enregistrée.
- 167. Projet de fin d’études Page 167 Figure 165 : Diagramme de séquences détaillées de l’API «GET Commande Client» IV.1.14 Diagramme de classes global du troisième sprint Figure 166 : Diagramme de classes global du troisième sprint
- 168. Projet de fin d’études Page 168 V. Implémentation Dans cette étape, nous allons implémenter les histoires utilisateurs définit au niveau du backlog de sprint lors de l’initiation de cette itération. De plus, nous allons implémenter les APIs nécessaires pour permettre la communication avec l’application mobile (le front office) à travers l’échange des données. Nous allons définir la structure de la base de données du sprint courant tout en appliquant les règles de passage du modèle entité/association au modèle relationnel. Schéma de la base de données : Champs Types Contraintes Id INT(11) PRIMARY KEY Nom VARCHAR(50) Prenom VARCHAR(50) Email VARCHAR(50) UNIQUE Password VARCHAR(50) Adresse VARCHAR(50) Tel INT(8) UNIQUE Tableau 53 : Table «Client» Champs Types Contraintes Id INT(11) PRIMARY KEY Nom VARCHAR(50) Description VARCHAR(50) Poids DOUBLE Quantité INT(11) Prix DOUBLE Favoris BOOLEAN Boutique_id INT(11) FOREIGN KEY Categorie_produit_id INT(11) FOREIGN KEY Marque_id INT(11) FOREIGN KEY Tableau 54 : Table «Produit» Champs Types Contraintes Id INT(11) PRIMARY KEY État VARCHAR(50) DATE DATETIME Client_id INT(11) FOREIGN KEY Tableau 55 : Table «Commande» Champs Types Contraintes Produit_id INT(11) PRIMARY KEY FOREIGN KEY Commande_id INT(11) PRIMARY KEY FOREIGN KEY Quantité INT(11) Tableau 56 : Table «ligne_commande»
- 169. Projet de fin d’études Page 169 Interface du cas «Lister mes commandes» Figure 167 : Interface du cas «Lister mes commandes» Interface du cas «Afficher les statistiques de ma boutique» Figure 168 : Interface du cas «Afficher les statistiques de ma boutique»
- 170. Projet de fin d’études Page 170 VI. Tests Durant cette étape, on va comparer les résultats attendus avec les résultats obtenus. Nous aurons ainsi l’occasion de s’assurer du bon fonctionnement des unités (méthodes) implémentées précédemment. VI.1 Les tests unitaires Nous continuons toujours à travailler avec le Framework de tests unitaires open source PHPUnit. Nous allons montrer dans cette section quelques cas de tests unitaires effectués ainsi que le raisonnement adopté pour la réalisation de ces derniers. VI.1.1 Le test unitaire de l’API «GET catégories boutiques» Raisonnement Pour tester l’API «GET catégories boutiques», nous avons suivi le raisonnement suivant : 1. Établir une requête d’accès à l’API à travers la méthode qu’elle autorise. 2. Tester le code d’état de la réponse qui doit être égale à 200 si on a bien reçu une réponse. 3. Tester le contenu de la réponse qui doit être un JSON valide. 4. Décoder la réponse JSON reçue. 5. Récupérer la première catégorie de boutiques. 6. Vérifier si l’attribut «Libellé» existe dans la catégorie récupérée pour s’assurer encore de la validité du résultat. En cas de succès, chaque sous-test effectué doit renvoyer un résultat positif. Code source de la méthode de test de l’API «GET catégories boutiques» Figure 169 : Code source de la méthode de test de l’API «GET Catégories boutiques»
- 171. Projet de fin d’études Page 171 Capture d’écran représentant le résultat du test de l’API «GET Catégories boutiques» Figure 170 : Interface de résultat du test de l’API «GET Catégories boutiques» VI.1.2 Le test unitaire de l’API «GET produits By Boutique» Raisonnement Pour tester l’API «GET produits By Boutique», nous avons suivi le raisonnement suivant : 1. Établir une requête d’accès à l’API à travers la méthode qu’elle autorise et en spécifiant l’identifiant de la boutique à l’emplacement prévu dans l’URL. 2. Tester le code d’état de la réponse qui doit être égale à 200 si on a bien reçu une réponse. 3. Tester le contenu de la réponse qui doit être un JSON valide. 4. Décoder la réponse JSON reçue. 5. Récupérer le premier produit. 6. Vérifier si l’attribut «Description» existe dans le produit récupéré pour s’assurer encore de la validité du résultat. En cas de succès, chaque sous-test effectué doit renvoyer un résultat positif. Code source de la méthode de test de l’API «GET produits By Boutique» Figure 171 : Code source de la méthode de test de l’API «GET produits By Boutique»
- 172. Projet de fin d’études Page 172 Capture d’écran représentant le résultat du test de l’API «GET produits By Boutique» Figure 172 : Interface de résultat du test de l’API «GET produits By Boutique» VI.1.3 Le test unitaire du cas d’utilisation «Modifier état commande» Raisonnement Pour tester le cas «Modifier état commande», nous avons suivi le raisonnement suivant : 1. Récupérer une commande ayant comme état «En attente» 2. Mettre à jour l’état de la commande à «Confirmée» 3. Récupérer une autre fois la même commande à partir de la base de données 4. Vérifier si la commande récupérée est confirmée ou non En cas de succès, on obtiendra : L’attribut «État» de la commande récupérée vaut «Confirmée». Code source de la méthode de test du cas d’utilisation «Modifier état commande» Figure 173 : Code source de la méthode de test du cas d’utilisation «Modifier état commande»
- 173. Projet de fin d’études Page 173 Capture d’écran représentant le résultat du test du cas d’utilisation «Modifier état commande» Figure 174 : Interface de résultat du test de modification d’état d’une commande Après avoir terminé la phase de test de notre troisième et dernier sprint, nous allons commencer à penser à faire la liaison et enchainements entre les trois sprints développés. VII. Revue de sprint «À la fin du sprint, l'équipe Scrum et les parties-prenantes invitées se réunissent pour effectuer la revue de sprint, qui dure au maximum quatre heures. L'objectif de la revue de sprint est de valider l'incrément de produit qui a été réalisé pendant le sprint. L'équipe énonce les éléments du carnet de produit sélectionnés en début de sprint. L'équipe présente les éléments finis (complètement réalisés). Les éléments non finis (partiellement réalisés) ne sont pas présentés.»[N10] VII.1. Diagramme de «BurndownChart» «Un burndown chart (graphique d'avancement) est une représentation graphique de l'évolution de quantité de travail restante par rapport au temps sur une période de temps donnée. Ce type de représentation est souvent utilisé pour suivre une activité gérée en boite de temps, puisque la quantité de travail à réaliser ainsi que la date de fin sont connues dès le début de la période couverte par le graphique.»[N12]
- 174. Projet de fin d’études Page 174 Figure 175 : Diagramme de Burndown Chart du troisième sprint VI.2 Calcul de vélocité Nous avons indiqué précédemment qu’on s’est mis d’accord d’attribuer un nombre de points aux histoires utilisateurs en fonction de leur complexité. Le tableau 57 montre le nombre de points attribués à chaque User Story. ID User Story Estimation 1 10 2 5 3 10 4 10 5 10 6 25 7 25 19 (Sprint2) 10 20 (Sprint2) 20 21 (Sprint2) 20 22 (Sprint2) 10 Vélocité estimée 155 points Tableau 57 : Calcul de vélocité estimée
- 175. Projet de fin d’études Page 175 La figure 175 comporte le diagramme de Burndown Chart et un tableau à gauche comportant une colonne nommée ‘Done Today’ qui indique l’ensemble des points réalisés pour chaque jour durant ce troisième sprint. La somme de cette colonne est égale à 155 ça veut dire : Vélocité estimée = Vélocité réelle L’équipe Scrum a donc réussi à implémenter les fonctionnalités du backlog de sprint courant et les fonctionnalités qui ont été reportées pour ce sprint. Ces derniers ont été validés par le Product Owner. Conclusion Dans ce chapitre, nous nous sommes concentrés sur le développement de notre troisième et dernier sprint. Nous avons donc réussi à produire un produit fonctionnel et livrable. Dans le chapitre suivant nous allons présenter l’ensemble des ressources utilisées lors de la concrétisation de notre solution.
- 176. Projet de fin d’études Page 176 Chapitre 6 Phase de clôture
- 177. Projet de fin d’études Page 177 Introduction Ce chapitre représente le dernier volet de ce rapport. En concrétisant notre solution, nous étions face à un choix de l’environnement matériel et logiciel que nous utilisons et les outils de développement que nous adoptons. Dans le présent chapitre, nous allons expliciter les choix effectué. I. Environnement de développement Nous commençons par la présentation de l’environnement matériel et logiciel que nous utilisons. I.1 Environnement matériel Propriétaire Rami Raddaoui Processeur Core i3 RAM 4Go Disque Dur 500Go Système d’exploitation Windows 8.1 Professionnel (x64) Tableau 58 : Environnement matériel I.2 Environnement logiciel Wamp Server «Wamp server est une plateforme de développement Web de type wamp, permettant de faire fonctionner localement (sans avoir à se connecter à un serveur externe) des scripts PHP.»[N15] phpMyAdmin phpMyAdmin est une application web ayant une interface graphique permettant une administration flexible des bases de données MySQL. SQLYog SQLYog est un logiciel qui permet la gestion des bases de données MySQL. Il offre une interface graphique pour manipuler facilement une base de données. Il est utilisé surtout pour la connexion à des bases de données distantes. MySQL «MySQL et en l'occurrence MySQL Community Server est une base de données multi-plateforme, libre, gratuite et pourtant très performante et offrant de nombreuses possibilités. Elle est très populaire auprès des concepteurs de site internet en PHP et est proposée par la plupart des hébergeurs web.» [N16]
- 178. Projet de fin d’études Page 178 Filezilla FTP Client «FileZilla est un logiciel client libre qui permet aux utilisateurs de relier un ordinateur local à un serveur Web dans le but d’échanger des données. Les chargements et téléchargements sont effectués via un protocole de réseau FTP (File Transfer Protocol), aussi appelé SFTP (SSH File Transfert Protocol) ou FTPS (FTP over SSL/TLS).» [N17] Microsoft Word Microsoft Word est un logiciel de traitement de texte propre à Microsoft. Microsoft Excel Microsoft Excel est un logiciel tableur propre à Microsoft. NetBeans «NetBeans est un environnement de développement intégré (EDI) open source. En plus de Java, NetBeans permet la prise en charge native de divers langages tels le C, le C++, le JavaScript, le XML, le Groovy, le PHP et le HTML, ou d'autres (dont Python et Ruby) par l'ajout de greffons. Il offre toutes les facilités d'un IDE moderne (éditeur en couleurs, projets multi-langage, refactoring, éditeur graphique d'interfaces et de pages Web).» [N18] Power AMC «Power AMC est un logiciel de conception créé par la société SAP, qui permet de modéliser les traitements informatiques et leurs bases de données associées. Il permet de réaliser tous les types de modèles informatiques.» [N19] TortoiseGit TortoiseGit est un client du logiciel de gestion de versions Git, implémenté comme une extension shell de Windows. C'est un logiciel libre diffusé sous licence publique générale GNU. [N20] Time Performance Time Performance est un logiciel de gestion de projets facile à utiliser et efficace II. Choix technologiques II.1. L’architecture MVC L’architecture MVC (Model View Controller) est une architecture ayant 3 couches destinées aux interfaces graphiques et servant pour la programmation client/serveur. Il s’agit d’un modèle architectural très puissant et très utilisé de nos jours.
- 179. Projet de fin d’études Page 179 L’architecture MVC est venue essentiellement pour faciliter la maintenabilité des applications en offrant une organisation du code très puissante. L’objectif de cette architecture est de séparer les données(Model) de l’affichage(View) et des actions (Controller). En résumé, on peut définir les 3 couches du modèle MVC comme suit : Modèle Il contient l’ensemble des données à afficher et qui sont le plus souvent stocké dans la base de données de notre application. Pour les langages de programmation orientés objet, l’exploitation de ces données se fait à travers les classes. Vue Elle contient l’ensemble des données qui concernent l’affichage. Elle n’a pas un accès direct à la base de données. Son rôle est limité par l’affichage de ce qu’elle reçoit sans demander d’où proviennent les données. Il s’agit tout simplement d’une interface homme/machine. Contrôleur Il s’agit d’un intermédiaire entre les 2 couches modèle et vue. Il récupère les informations par l’intermédiaire du modèle, fait les traitements nécessaires et transmet les données à la vue correspondante. Figure 176 : Architecture MVC [N21] II.2. Le Framework Symfony «Symfony est un ensemble de composants PHP ainsi qu'un Framework MVC libre écrit en PHP. Il fournit des fonctionnalités modulables et adaptables qui permettent de faciliter et d’accélérer le développement d'un site web. Symfony propose entre autres : Une séparation du code en trois couches, selon le modèle MVC, pour une plus grande maintenabilité et évolutivité. Des performances optimisées et un système de cache afin d'assurer des temps de réponse optimaux.
- 180. Projet de fin d’études Page 180 Une gestion des URL parlante, permettant à une page d'avoir une URL distincte de sa position dans l'arborescence. Un système de configuration en cascade utilisant pleinement le langage YAML ; L'internationalisation native. Le support d'AJAX. Une architecture extensible permettant créations et utilisations de plugins. Symfony fournit une interface en ligne de commande pour améliorer la productivité en créant un code de base modifiable à volonté.»[N22] II.2.1. Le Gestionnaire ORM «Un ORM (Object Relational Mapping) est une technique de programmation informatique qui crée l'illusion d'une base de données orientée objet à partir d'une base de données relationnelle en définissant des correspondances entre cette base de données et les objets du langage utilisé. On pourrait le désigner par "correspondance entre monde objet et monde relationnel."»[N23] Pour nous, nous avons opté pour l’utilisation de l’ORM par défaut de Symfony Doctrine. II.2.2. Pourquoi Symfony ? Le choix d’un Framework se fait toujours en fonction des besoins du client. Symfony est utilisé généralement pour le développement des projets complexes dont les fonctionnalités ne peuvent pas être traitées par les CMS (Content Management System) vu qu’ils sont des boites noires et ne permettent pas la modification de leur code source. Nous avons donc opté pour l’utilisation du Framework Symfony pour l’implémentation de notre projet. II.3.L’outil de versionning GIT «Git est un système de gestion de versionnement décentralisé (DVCS). Il est notamment utilisé pour le noyau Linux ou pour PHP. C'est un logiciel libre créé par Linus Torvalds en 2005. Git permet notamment de "commiter" localement puis de pousser aux autres développeurs un ensemble de commits locaux. Il permet également d'utiliser un workflow de développement en soumettant par exemple l'envoi de code à l'approbation d'un des développeurs. La faculté de Git à créer des branches facilement ainsi que de permettre leur administration de façon simple en fait un outil de choix dans le cadre de développement de projets open source.»[N24] II.4. REST «REST est un style d'architecture réseau pour Web Services qui met l'accent sur la définition de ressources identifiées par des URI, et utilise les messages du protocole HTTP pour définir la sémantique de la communication client/serveur: GET pour le rapatriement d'une ressource, POST pour une création.»[N25] REST n’est pas réellement un protocole. Il s’agit d’un ensemble de conventions servant pour l’implémentation et qui respectent un ensemble de principes bien définis.
- 181. Projet de fin d’études Page 181 Un service WEB utilisant HTTP et qui respecte l’ensemble de ces principes sera considéré comme un RESTful Web Service. [Voir annexe A] II.5. JSON JSON (JavaScript Object Notation) est un format d’échange de données basé sur un sous ensemble du langage de programmation JavaScript. La particularité de ce format d’échange de données c’est qu’on peut le manipuler d’une façon abstraite par rapport aux langages de programmation existants. Il est facilement compréhensible par les êtres humains. [Voir annexe A] III. Gestion de projet III.1 Tableau des tâches Nous allons présenter quelques captures d’écrans illustrant la répartition des tâches à des moments données au cours du développement de notre projet. Répartition des tâches du premier sprint Figure 177 : Répartition des tâches du premier sprint Répartition des tâches du deuxième sprint Figure 178 : Répartition des tâches du deuxième sprint
- 182. Projet de fin d’études Page 182 Répartition des tâches du troisième sprint Figure 179 : Répartition des tâches du troisième sprint III.2 Diagramme de GANTT Le diagramme de GANTT nous permet de visualiser progressivement l’avancement des différentes tâches relatives à notre projet. Figure 180 : Diagramme de GANTT Conclusion Tout au long de ce chapitre, nous avons exposé, le choix de l’environnement matériel et logiciel utilisés et les outils de développement adoptés. Nous avons également attaché quelques captures d’écrans illustrant la répartition des tâches des différents sprints ainsi que le diagramme de GANTT. Nous clôturons notre rapport par ce dernier chapitre.
- 183. Projet de fin d’études Page 183 Conclusion et perspectives Ce présent mémoire a été rédigé dans le cadre du projet de fin d’études pour l’obtention du diplôme de licence fondamentale en informatique de gestion. Sur le plan professionnel, nous avons eu l’occasion de participer à un projet de grande envergure et de se familiariser avec la conduite des projets informatiques ainsi que le travail en équipe. C’était une très bonne opportunité pour nous qui nous a permis d’exercer nos compétences et d’apprendre à travailler en équipe surtout en appliquant une méthodologie qui favorise le travail collaboratif comme Scrum. Malgré l’ensemble des changements survenus au cours du développement et surtout les obstacles techniques rencontrés, nous pouvons considérer que notre travail a parfaitement atteint ses objectifs spécifiés au niveau du backlog de produit sous forme des histoires utilisateurs. Nous avons réussi même à développer des fonctionnalités supplémentaires qui n’ont pas été planifiées au début. Comme tout autre projet, notre projet ne prétend pas la perfection. Il reste toujours un sujet qui peut faire l’objet d’améliorations et d’évolutions. Ces améliorations constituent les futures perspectives de notre projet. En effet, ce travail n’est qu’un début d’un long processus. Une évolution possible de notre application consiste à inclure un système pour gérer les différents types de promotions (par client, par panier, par produit, etc…). Nous avons aussi pensé à intégrer un système de notifications qui sert à notifier les utilisateurs par des informations utiles. Pour le cas des vendeurs, il est utile par exemple de les notifier à partir d’une quantité minimale restante pour un produit spécifique afin de prendre les mesures nécessaires.
- 184. Projet de fin d’études Page 184 ANNEXE A Les services WEB
- 185. Projet de fin d’études Page 185 A.1 Présentationdes services WEB Les services web (ou Web Services en anglais) sont des fonctionnalités qui peuvent être exécutées à distance et dont on peut les développer avec divers langages comme PHP, JAVA, .NET, etc… Un service WEB peut être consommé par plusieurs types de clients et permet à l’application appelante d’extraire un ensemble de données qui servent pour ses propres analyses. Par exemple, pour une application mobile de géo localisation des voitures, on peut consommer à un instant t un service web qui contient les cordonnées GPS des voitures (latitude et longitude) afin de pouvoir les dessiner sur le Map et déterminer la position exacte des véhicules. L’application mobile a donc extrait un ensemble de données servant pour ses traitements. On dit qu’elle a consommé un service WEB avec la méthode GET. Un des majeurs avantages des services WEB c’est qu’on peut les appeler à partir d’un langage différent de celui qui a été utilisé pour les développer. Par exemple, on peut appeler un service WEB codé en PHP au sein d’un code C#. A.2 REST REST est un style d’architecture reposant sur le protocole HTTP : On peut accéder à une ressource spécifique via son URL qui doit être unique pour bénéficier de multiples opérations (GET pour lire, POST pour écrire, PUT pour modifier et enfin DELETE pour supprimer), opérations supportés par le protocole HTTP. «Le principe de REST est d'utiliser HTTP pour l'implémentation d'un Web Service, non plus comme simple protocole de transport, mais également pour définir l'API (Application Programming Interface) de chaque service c'est à dire la définition même des messages entre clients et serveur. REST décrit un style d'architecture logicielle permettant de construire une application devant fonctionner sur des systèmes distribués (typiquement internet). En résumé, REST est donc le style d'architecture soutenant le Web.» [N25] Principes directeurs «La construction d'un Web Service RESTful implique l'utilisation des éléments suivants: • Architecture client serveur. • Des requêtes sans état (2 requêtes d'un client sont indépendantes). • L'utilisation de mécanismes de cache possible. • Une interface uniforme.»[N25]
- 186. Projet de fin d’études Page 186 A.3 Représentationdes ressources «REST n’impose ni ne revendique un format d’échange entre client et serveur. Vous êtes libre de représenter vos données en XML, en JSON, en PHP sérialisé, en MessagePack ou dans tout autre dialecte de votre propre cru (sans oublier que le but est souvent d’exposer des services vers l’extérieur). Il n’est pas rare que les services REST permettent au client d’indiquer le format dans lequel ils souhaitent dialoguer, sous la forme par exemple d’un paramètre supplémentaire dans l’URL, ou plus simplement grâce aux en tête HTTP en spécifiant le content-type.» [N26] A.4 JSON «JSON est un format léger d’échange de données. Il est facile à lire ou à écrire pour des humains. Il est aisément analysable ou générable par des machines. Il est basé sur un sous- ensemble du langage de programmation JavaScript. JSON est un format texte complètement indépendant de tout langage, mais les conventions qu’il utilise seront familières à tout programmeur habitué aux langages descendant du C, comme par exemple : C lui-même, C++, C#, Java, JavaScript, Perl, Python et bien d’autres. Ces propriétés font de JSON un langage d’échange de données idéal. JSON se base sur deux structures : Une collection de couples nom/valeur. Divers langages la réifient par un objet, un enregistrement, une structure, un dictionnaire, une table de hachage, une liste typée ou un tableau associatif. Une liste de valeurs ordonnées. La plupart des langages la réifient par un tableau, un vecteur, une liste ou une suite. Ces structures de données sont universelles. Pratiquement tous les langages de programmation modernes les proposent sous une forme ou une autre. Il est raisonnable qu’un format de données interchangeable avec des langages de programmation se base aussi sur ces structures. En JSON, elles prennent les formes suivantes : Un objet, qui est un ensemble de couples nom/valeur non ordonnés. Un objet commence par une accolade gauche et se termine par une accolade droite. Chaque nom est suivi de : (deux-points) et les couples nom/valeur sont séparés par , (virgule). Un tableau est une collection de valeurs ordonnées. Un tableau commence par [ (crochet gauche) et se termine par ] (crochet droit) . Les valeurs sont séparées par , (virgule). Une valeur peut être soit une chaine de caractères entre guillemets, soit un nombre, soit true ou false ou null, soit un objet soit un tableau. Ces structures peuvent être imbriquées. Une chaine de caractères est une suite de zéro ou plus caractères Unicode, entre guillemets, et utilisant les échappements avec antislash. Un caractère est représenté par une chaîne d’un seul caractère.» [N27]
- 187. Projet de fin d’études Page 187 ANNEXE B Analyse et conception des cas d’utilisations
- 188. Projet de fin d’études Page 188 I. Analyse des cas d’utilisation I.1 Analyse du cas d’utilisation «Gérer catégories produits» Nous commençons par le raffinement du cas d’utilisation «Gérer catégories produits». I.1.1 Raffinement du cas d’utilisation «Gérer catégories produits» Figure 181 : Diagramme de cas d’utilisation du cas «Gérer catégories produits» I.1.1.1 Analyse du cas d’utilisation «Lister catégories produits» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Lister catégories produits». Description textuelle du cas d’utilisation «Lister catégories de produits» Cas d’utilisation Lister catégories produits Acteur Vendeur Pré condition Vendeur authentifié. Post condition Liste des catégories de produits affichée Description du scénario principal 1. Le vendeur clique sur «Catégories produits». 2. Le système affiche la liste des catégories de produits Exception Néant Tableau 59 : Description textuelle du cas d’utilisation «Lister catégories produits»
- 189. Projet de fin d’études Page 189 Diagramme de séquences système du cas d’utilisation «Lister catégories produits» Figure 182 : Diagramme de séquences système du cas d’utilisation «Lister catégories de produits» I.1.1.2 Analyse du cas d’utilisation «Ajouter catégorie produits» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Ajouter catégorie produits». Description textuelle du cas d’utilisation «Ajouter catégorie produits» Cas d’utilisation Ajouter catégorie produits Acteur Vendeur Pré condition Vendeur authentifié Liste des catégories de produits affichée. Post condition Catégorie de produit ajoutée Description du scénario principal 1. Le vendeur clique sur le bouton «Ajouter une catégorie». 2. Le système affiche le formulaire d’ajout d’une catégorie de produit. 3. Le vendeur remplit le formulaire. 4. Le vendeur valide le formulaire. 5. Le système vérifie les informations saisies par le vendeur. 6. Le système affiche un message indiquant que la catégorie de produits est ajoutée avec succès. Exception 5.1 Un message d’erreur est affiché si l’un des champs obligatoire est vide et/ou invalide Tableau 60 : Description textuelle du cas d’utilisation «Ajouter catégorie produits»
- 190. Projet de fin d’études Page 190 Diagramme de séquences système du cas d’utilisation «Ajouter catégorie produits» Figure 183 : Diagramme de séquences système du cas d’utilisation «Ajouter catégorie produits» I.1.1.3 Analyse du cas d’utilisation «Modifier catégorie produits» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Modifier catégorie produits». Description textuelle du cas d’utilisation «Modifier catégorie produits» Cas d’utilisation Modifier catégorie produits Acteur Vendeur Pré condition Vendeur authentifié Liste des catégories de produits affichée. Catégorie de produit existante. Post condition Catégorie de produit modifiée Description du scénario principal 1. Le vendeur clique sur «Modifier». 2. Le système affiche le formulaire de modification d’une catégorie de produits.
- 191. Projet de fin d’études Page 191 3. Le vendeur remplit le formulaire. 4. Le vendeur valide le formulaire. 5. Le système vérifie les informations saisies par le vendeur. 6. Le système affiche un message indiquant que la catégorie de produits est mise à jour. Exception 5.1 Un message d’erreur est affiché si l’un des champs obligatoire est vide et/ou invalide Tableau 61 : Description textuelle du cas d’utilisation «Modifier catégorie produits» Diagramme de séquences système du cas d’utilisation «Modifier catégorie produits» Figure 184 : Diagramme de séquences système du cas d’utilisation «Modifier catégorie produits» I.1.1.4 Analyse du cas d’utilisation «Supprimer catégorie produits» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Supprimer catégorie produits».
- 192. Projet de fin d’études Page 192 Description textuelle du cas d’utilisation «Supprimer catégorie produits» Cas d’utilisation Supprimer catégorie produits Acteur Vendeur Pré condition Vendeur authentifié. Liste des catégories de produits affichée. Catégorie de produits existante. Post condition Catégorie de produits supprimée. Description du scénario principal 1. Le vendeur clique sur «Supprimer». 2. Le système affiche une fenêtre de confirmation. 3. Le vendeur confirme la suppression. 4. Le système supprime la catégorie de produits. 5. Le système affiche un message indiquant que la catégorie de produits est supprimée avec succès. 6. Le système redirige le vendeur vers la page «Lister les catégories de produits» Exception 2.1 L’opération de suppression est annulée si le vendeur clique sur le bouton annuler. Tableau 62 : Description textuelle du cas d’utilisation «Supprimer catégorie produits» Diagramme de séquences système du cas d’utilisation «Supprimer catégorie produits» Figure 185 : Diagramme de séquences système du cas d’utilisation «Supprimer catégorie produits»
- 193. Projet de fin d’études Page 193 I.2 Analyse du cas d’utilisation «Gérer marques» Nous commençons par le raffinement du cas d’utilisation «Gérer marques». I.2.1 Raffinement du cas d’utilisation «Gérer marques» Figure 186 : Diagramme de cas d’utilisation du cas «Gérer marques» I.2.1.1 Analyse du cas d’utilisation «Lister marques» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Lister marques». Description textuelle du cas d’utilisation «Lister marques» Cas d’utilisation Lister marques Acteur Vendeur Pré condition Vendeur authentifié. Post condition Liste des marques affichée Description du scénario principal 1. Le vendeur clique sur «Marques». 2. Le système affiche la liste des marques Exception Néant Tableau 63 : Description textuelle du cas d’utilisation «Lister marques» Diagramme de séquences système du cas d’utilisation «Lister marques» Figure 187 : Diagramme de séquences système du cas d’utilisation «Lister marques»
- 194. Projet de fin d’études Page 194 I.2.1.2 Analyse du cas d’utilisation «Ajouter marque» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Ajouter marque». Description textuelle du cas d’utilisation «Ajouter marque» Cas d’utilisation Ajouter marque Acteur Vendeur Pré condition Vendeur authentifié Liste des marques affichée. Post condition Marque ajoutée Description du scénario principal 1. Le vendeur clique sur le bouton «Ajouter une marque». 2. Le système affiche le formulaire d’ajout d’une marque. 3. Le vendeur remplit le formulaire. 4. Le vendeur valide le formulaire. 5. Le système vérifie les informations saisies par le vendeur. 6. Le système affiche un message indiquant que la marque est ajoutée avec succès. Exception 5.1 Un message d’erreur est affiché si l’un des champs obligatoire est vide et/ou invalide Tableau 64 : Description textuelle du cas d’utilisation «Ajouter marque» Diagramme de séquences système du cas d’utilisation «Ajouter marque» Figure 188 : Diagramme de séquences système du cas d’utilisation «Ajouter marque»
- 195. Projet de fin d’études Page 195 I.2.1.3 Analyse du cas d’utilisation «Modifier marque» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Modifier marque». Description textuelle du cas d’utilisation «Modifier marque» Cas d’utilisation Modifier marque Acteur Vendeur Pré condition Vendeur authentifié Liste des marques affichée. Marque existante. Post condition Marque modifiée Description du scénario principal 1. Le vendeur clique sur «Modifier». 2. Le système affiche le formulaire de modification d’une marque. 3. Le vendeur remplit le formulaire. 4. Le vendeur valide le formulaire. 5. Le système vérifie les informations saisies par le vendeur. 6. Le système affiche un message indiquant que la marque est mise à jour. Exception 5.1 Un message d’erreur est affiché si l’un des champs obligatoire est vide et/ou invalide Tableau 65 : Description textuelle du cas d’utilisation «Modifier marque» Diagramme de séquences système du cas d’utilisation «Modifier marque» Figure 189 : Diagramme de séquences système du cas d’utilisation «Modifier marque»
- 196. Projet de fin d’études Page 196 I.2.1.4 Analyse du cas d’utilisation «Supprimer marque» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Supprimer marque». Description textuelle du cas d’utilisation «Supprimer marque» Cas d’utilisation Supprimer marque Acteur Vendeur Pré condition Vendeur authentifié. Liste des marques affichée. Marque existante. Post condition Marque supprimée. Description du scénario principal 1. Le vendeur clique sur «Supprimer». 2. Le système affiche une fenêtre de confirmation. 3. Le vendeur confirme la suppression. 4. Le système supprime la marque. 5. Le système affiche un message indiquant que la marque est supprimée avec succès. 6. Le système redirige le vendeur vers la page «Lister les marques» Exception 2.1 L’opération de suppression est annulée si le vendeur clique sur le bouton annuler. Tableau 66 : Description textuelle du cas d’utilisation «Supprimer marque» Diagramme de séquences système du cas d’utilisation «Supprimer marque» Figure 190 : Diagramme de séquences système du cas d’utilisation «Supprimer marque»
- 197. Projet de fin d’études Page 197 I.3 Analyse du cas d’utilisation «Déverrouillerboutique» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Déverrouiller boutique». Description textuelle du cas d’utilisation «Déverrouiller boutique» Cas d’utilisation Déverrouiller boutique Acteur Administrateur Pré condition Administrateur authentifié. Liste des boutiques affichée. Boutique confirmée. Boutique verrouillée. Post condition Boutique déverrouillée Description du scénario principal 1. L’administrateur clique sur «Déverrouiller». 2. Le système affiche une fenêtre de confirmation du choix. 3. L’administrateur confirme son choix. 4. Le système déverrouille la boutique. 5. Le système met à jour l’état de verrouillage de la boutique dans la liste des boutiques affichée. 6. Le système redirige l’administrateur vers la page «lister les boutiques» Exception 2.1 L’opération de déverrouillage est annulée si l’administrateur clique sur le bouton annuler. Tableau 67 : Description textuelle du cas d’utilisation «Déverrouiller boutique» Diagramme de séquences système du cas d’utilisation «Déverrouiller boutique» Figure 191 : Diagramme de séquences système du cas d’utilisation «Déverrouiller boutique»
- 198. Projet de fin d’études Page 198 I.4 Analyse du cas d’utilisation «Supprimerboutiquedu favoris» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Supprimer boutique du favoris». Description textuelle du cas d’utilisation «Supprimer boutique du favoris» Cas d’utilisation Supprimer boutique du favoris Acteur Administrateur Pré condition Administrateur authentifié. Liste des boutiques affichée. Boutique confirmée. Boutique ajoutée aux favoris. Post condition Boutique supprimée du favoris Description du scénario principal 1. L’administrateur clique sur «Supprimer du favoris». 2. Le système affiche une fenêtre de confirmation du choix. 3. L’administrateur confirme son choix. 4. Le système supprime la boutique du favoris. 5. Le système met à jour l’état de favoris de la boutique dans la liste des boutiques affichée. 6. Le système redirige l’administrateur vers la page «lister les boutiques» Exception 2.1 L’opération de suppression du favoris est annulée si l’administrateur clique sur le bouton annuler. Tableau 68 : Description textuelle du cas d’utilisation «Supprimer boutique du favoris» Diagramme de séquences système du cas d’utilisation «Supprimer boutique du favoris» Figure 192 : Diagramme de séquences système du cas d’utilisation «Supprimer boutique du favoris»
- 199. Projet de fin d’études Page 199 I.5 Analyse du cas d’utilisation «Ajouter produitaux favoris» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Ajouter produit aux favoris». Description textuelle du cas d’utilisation «Ajouter produit aux favoris» Cas d’utilisation Ajouter produit aux favoris Acteur Administrateur Pré condition Administrateur authentifié. Liste des produits d’une boutique spécifique affichée. Post condition Produit ajouté aux favoris Description du scénario principal 1. L’administrateur clique sur «Ajouter aux favoris». 2. Le système affiche une fenêtre de confirmation du choix. 3. L’administrateur confirme son choix. 4. Le système ajoute le produit aux favoris. 5. Le système met à jour l’état du produit dans la liste des produits affichée. 6. Le système redirige l’administrateur vers la page «lister les produits» Exception 2.1 L’opération d’ajout aux favoris est annulée si l’administrateur clique sur le bouton annuler. Tableau 69 : Description textuelle du cas d’utilisation «Ajouter produit aux favoris» Diagramme de séquences système du cas d’utilisation «Ajouter produit aux favoris» Figure 193 : Diagramme de séquences système du cas d’utilisation «Ajouter produit aux favoris»
- 200. Projet de fin d’études Page 200 I.6 Analyse du cas d’utilisation «Supprimerproduitdu favoris» Nous commençons par la description textuelle puis le diagramme de séquences système du cas «Supprimer produit du favoris». Description textuelle du cas d’utilisation «Supprimer produit du favoris» Cas d’utilisation Supprimer produit du favoris Acteur Administrateur Pré condition Administrateur authentifié. Liste des produits d’une boutique spécifique affichée. Produit ajouté aux favoris. Post condition Produit supprimé du favoris Description du scénario principal 1. L’administrateur clique sur «Supprimer du favoris». 2. Le système affiche une fenêtre de confirmation du choix. 3. L’administrateur confirme son choix. 4. Le système supprime le produit du favoris. 5. Le système met à jour l’état de favoris du produit dans la liste des produits affichée. 6. Le système redirige l’administrateur vers la page «lister les produits» Exception 2.1 L’opération de suppression du favoris est annulée si l’administrateur clique sur le bouton annuler. Tableau 70 : Description textuelle du cas d’utilisation «Supprimer produit du favoris» Diagramme de séquences système du cas d’utilisation «Supprimer produit du favoris» Pour supprimer un produit du favoris, l’administrateur accède en premier lieu à la fonctionnalité «Lister produits boutique» pour avoir la liste des produits d’une boutique spécifique. Il clique ensuite sur le lien «Supprimer produit du favoris» devant le produit qu’il envisage enlever de la liste des favoris. Le système affiche alors une fenêtre de confirmation pour s’assurer de l’action prise par l’administrateur. Dans le cas où l’administrateur clique sur le bouton «Confirmer», le système supprime le produit du favoris et met à jour l’état de favoris du produit dans la liste affichée. Dans le cas échéant, le système redirige l’administrateur vers la page «Lister produits boutique» et l’action prise par l’administrateur est annulée. La figure 194 représente le diagramme de séquences système du cas «Supprimer produit du favoris»
- 201. Projet de fin d’études Page 201 Figure 194 : Diagramme de séquences système du cas d’utilisation «Supprimer produit du favoris» II. Conception des cas d’utilisations Dans cette étape, nous allons élaborer les diagrammes de séquences détaillées ainsi que les diagrammes de classes participantes aux cas d’utilisations analysés dans la section précédente. II.1 Conceptionde cas d’utilisation «Gérer catégories produits» II.1.1 Conception de cas d’utilisation «Lister catégories produits» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Lister catégories produits». Diagramme de classes participantes au cas d’utilisation «Lister catégories produits» Figure 195 : Diagramme de classes participantes au cas d’utilisation «Lister catégories produits»
- 202. Projet de fin d’études Page 202 Diagramme de séquences détaillées du cas d’utilisation «Lister catégories produits» Figure 196 : Diagramme de séquences détaillées du cas d’utilisation «Lister catégories produits» II.1.2 Conception de cas d’utilisation «Ajouter catégorie produit» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Ajouter catégorie produit». Diagramme de classes participantes au cas d’utilisation «Ajouter catégorie produit» Figure 197 : Diagramme de classes participantes au cas d’utilisation «Ajouter catégorie produit» Diagramme de séquences détaillées du cas d’utilisation «Ajouter catégorie produit» Pour ajouter une nouvelle catégorie de produits, le vendeur clique sur le bouton «Ajouter une catégorie» de l’interface «Catégories produits» qui va déclencher une méthode déclarée dans le contrôleur «Catégorie_produitController». Cette méthode déclenchée va renvoyer la vue «Ajouter catégorie produit» qui contient le formulaire d’ajout d’une nouvelle catégorie de produits. Le vendeur remplit ainsi le formulaire affiché et clique sur le bouton «Confirmer». Les données transmises seront chargées dans le système qui va vérifier leur validité. En cas de succès, le système affiche un message indiquant que l’ajout de la catégorie de produits a été effectué avec succès. Dans le cas échéant, le système affiche un message indiquant que le libellé saisi est invalide. La figure 198 représente le diagramme de séquences détaillées du cas «Ajouter catégorie produit».
- 203. Projet de fin d’études Page 203 Figure 198 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter catégorie produit» II.1.3 Conception de cas d’utilisation «Modifier catégorie produit» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Modifier catégorie produit». Diagramme de classes participantes au cas d’utilisation «Modifier catégorie produit» Figure 199 : Diagramme de classes participantes au cas d’utilisation «Modifier catégorie produit»
- 204. Projet de fin d’études Page 204 Diagramme de séquences détaillées du cas d’utilisation «Modifier catégorie produit» Figure 200 : Diagramme de séquences détaillées du cas d’utilisation «Modifier catégorie produit» II.1.4 Conception de cas d’utilisation «Supprimer catégorie produit» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Supprimer catégorie produit». Diagramme de classes participantes au cas d’utilisation «Supprimer catégorie produit» Figure 201 : Diagramme de classes participantes au cas d’utilisation «Supprimer catégorie produit»
- 205. Projet de fin d’études Page 205 Diagramme de séquences détaillées du cas d’utilisation «Supprimer catégorie produit» Figure 202 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer catégorie produit» II.2 Conceptionde cas d’utilisation «Gérer marques» II.2.1 Conception de cas d’utilisation «Lister marques» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Lister marques». Diagramme de classes participantes au cas d’utilisation «Lister marques» Figure 203 : Diagramme de classes participantes au cas d’utilisation «Lister marques»
- 206. Projet de fin d’études Page 206 Diagramme de séquences détaillées du cas d’utilisation «Lister marques» Figure 204 : Diagramme de séquences détaillées du cas d’utilisation «Lister marques» II.2.2 Conception de cas d’utilisation «Ajouter marque» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Ajouter marque». Diagramme de classes participantes au cas d’utilisation «Ajouter marque» Figure 205 : Diagramme de classes participantes au cas d’utilisation «Ajouter marque»
- 207. Projet de fin d’études Page 207 Diagramme de séquences détaillées du ca d’utilisation «Ajouter marque» Figure 206 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter marque» II.2.3 Conception de cas d’utilisation «Modifier marque» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Modifier marque». Diagramme de classes participantes au cas d’utilisation «Modifier marque» Figure 207 : Diagramme de classes participantes au cas d’utilisation «Modifier marque»
- 208. Projet de fin d’études Page 208 Diagramme de séquences détaillées du cas d’utilisation «Modifier marque» Figure 208 : Diagramme de séquences détaillées du cas d’utilisation «Modifier marque» II.2.4 Conception de cas d’utilisation «Supprimer marque» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Supprimer marque». Diagramme de classes participantes au cas d’utilisation «Supprimer marque» Figure 209 : Diagramme de classes participantes au cas d’utilisation «Supprimer marque»
- 209. Projet de fin d’études Page 209 Diagramme de séquences détaillées du cas d’utilisation «Supprimer marque» Figure 210 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer marque» II.3 Conceptionde cas d’utilisation «Déverrouillerboutique» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Déverrouiller boutique». Diagramme de classes participantes au cas d’utilisation «Déverrouiller boutique» Figure 211 : Diagramme de classes participantes au cas d’utilisation «Déverrouiller boutique»
- 210. Projet de fin d’études Page 210 Diagramme de séquences détaillées du cas d’utilisation «Déverrouiller boutique» Figure 212 : Diagramme de séquences détaillées du cas d’utilisation «Déverrouiller boutique» II.4 Conceptionde cas d’utilisation «Supprimerboutique du favoris» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Supprimer boutique du favoris». Diagramme de classes participantes au cas d’utilisation «Supprimer boutique du favoris» Figure 213 : Diagramme de classes participantes au cas d’utilisation «Supprimer boutique du favoris»
- 211. Projet de fin d’études Page 211 Diagramme de séquences détaillées du cas d’utilisation «Supprimer boutique du favoris» Figure 214 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer boutique du favoris» II.5 Conceptionde cas d’utilisation «Ajouter produitaux favoris» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Ajouter produit aux favoris». Diagramme de classes participantes au cas d’utilisation «Ajouter produit aux favoris» Figure 215 : Diagramme de classes participantes au cas d’utilisation «Ajouter produit aux favoris»
- 212. Projet de fin d’études Page 212 Diagramme de séquences détaillées du cas d’utilisation «Ajouter produit aux favoris» Figure 216 : Diagramme de séquences détaillées du cas d’utilisation «Ajouter produit aux favoris» II.6 Conceptionde cas d’utilisation «Supprimerproduitdu favoris» Nous commençons par le diagramme de classes participantes puis le diagramme de séquences détaillées du cas «Supprimer produit du favoris». Diagramme de classes participantes au cas d’utilisation «Supprimer produit du favoris» Figure 217 : Diagramme de classes participantes au cas d’utilisation «Supprimer produit du favoris»
- 213. Projet de fin d’études Page 213 Diagramme de séquences détaillées du cas d’utilisation «Supprimer produit du favoris» Figure 218 : Diagramme de séquences détaillées du cas d’utilisation «Supprimer produit du favoris» Conclusion Tout au long de cette annexe, nous avons présenté l’analyse et la conception des cas d’utilisations restants de notre deuxième sprint.
- 214. Projet de fin d’études Page 214 ANNEXE C L’outil de versionning GIT
- 215. Projet de fin d’études Page 215 C.1 Présentation des gestionnaires de version «Les gestionnaires de version sont, de nos jours, fortement utilisés par les développeurs. Et ceci pour plusieurs raisons, tout d'abord ils permettent d'archiver et de conserver les différentes étapes de développement d'un projet. Ce qui procure l'avantage de pouvoir revenir à une version antérieure à tout moment. Il est également possible de consulter les différences entre les révisions. Et enfin, c'est également utilisé pour le travail collaboratif. Chaque développeur dispose du projet en local, et peut à tout moment envoyer ses changements vers le repository principal afin que les autres développeurs puissent bénéficier de son travail.»[N28] C.2 Utilisation des gestionnaires de version Les logiciels de gestion de version sont fortement utilisés dans les projets de développement logiciel et surtout dans les projets WEB. Ils permettent de garder trace de toute modification affectant le code source et sauvegardent ainsi des informations pouvant être utiles tel que le nom de la personne qui a apporté la modification et la date. De cette manière, une équipe de développement travaillant sur un projet et ayant rencontré un bug peut revenir à une version précédente et même savoir la source du bug à travers la consultation de l’historique des modifications du code source. C.3 GIT : L’outil de versionning décentralisé «GIT est un logiciel de gestion de versions décentralisé. Son rôle principal est d'assurer le suivi des modifications dans un ensemble de fichiers. Il repose sur un système d'archivage de fichiers adressable par le contenu via l'utilisation de fonctions de hachage cryptographiques (SHA-1) pour indexer les fichiers. Comme tout logiciel de gestion de version, il permet d'enregistrer les modifications successives de l'ensemble des fichiers, de visualiser l'historique des modifications, de gérer des branches de modifications parallèles. Son aspect distribué rend cette dernière fonctionnalité particulièrement puissante. Chaque utilisateur disposant d'une copie locale de l'historique du projet, il est possible de travailler hors-ligne, les outils de fusion des branches permettant ensuite de résoudre les éventuels conflits. Enfin git permet de gérer de nombreux types de flux de travail, que ce soit pour un utilisateur isolé, des petits groupes de travail informel ou des gros projets nécessitant le respect de règles précises.» [N29]
- 216. Projet de fin d’études Page 216 Nétographie [N1] http://aujourdhui.ma/economie/e-commerce-le-grand-boom [Accès le 01/03/2017] [N2] https://www.ecommerce-nation.fr/quelle-strategie-adopter-sur-les-places-de-marche [Accès le 04/03/2017] [N3] http://www.itcane.com [Accès le 04/03/2017] [N4] https://www.ideematic.com/actualites/2015/01/methodes-agiles-definition/ [Accès le 09/03/2017] [N5] http://www.groupeafg.com/methodes-agiles-scrum/ [Accès le 15/03/2017] [N6] http://www.roxecom.fr/blog/scrum-gestion-de-projet-agile [Accès le 15/03/2017] [N7]https://fr.wikipedia.org/wiki/Burndown_chart [Accès le 17/03/2017] [N8] https://fr.atlassian.com/agile/ceremonies [Accès le 17/03/2017] [N9] http://www.additeam.com/SSII/uml/ [Accès le 18/03/2017] [N10] https://fr.wikipedia.org/wiki/Scrum_(Boite_%C3%A0_outils) [Accès le 20/03/2017] [N11]https://fr.wikipedia.org/wiki/Diagramme_des_cas_d%27utilisation [Accès le 20/03/2017] [N12] https://fr.wikipedia.org/wiki/Burndown_chart [Accès le 27/03/2017] [N13] http://www.agiliste.fr/guide-de-demarrage-scrum/ [Accès le 31/03/2017] [N14] http://www.lsis.org/sellamis/Cours%20SW%20S1.pdf [Accès le 18/04/2017] [N15] https://fr.wikipedia.org/wiki/WampServer [Accès le 22/04/2017] [N16] http://www.sqlfacile.com/apprendre_bases_de_donnees/mysql_1 [Accès le 22/04/2017] [N17] https://www.1and1.fr/digitalguide/serveur/configuration/filezilla-tutoriel-du-logiciel-client-ftp/ [Accès le 22/04/2017] [N18] https://fr.wikipedia.org/wiki/NetBeans [Accès le 23/04/2017] [N19] https://fr.wikipedia.org/wiki/PowerAMC [Accès le 23/04/2017] [N20] https://fr.wikipedia.org/wiki/TortoiseGit [Accès le 23/04/2017] [N21] http://www.adventy.org/le-mvc [Accès le 26/04/2017] [N22] https://fr.wikipedia.org/wiki/Symfony [Accès le 26/04/2017] [N23] https://fr.wikipedia.org/wiki/Mapping_objet-relationnel [Accès le 27/04/2017] [N24]http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Outils- de-developpement/Git [Accès le 29/04/2017] [N25] https://www.tala-informatique.fr/wiki/images/8/8b/Webservices.pdf [Accès le 30/04/2017] [N26] www.tondeurh.fr/document_146.html [Accès le 30/04/2017] [N27] http://www.json.org/json-fr.html [Accès le 02/05/2017] [N28] http://igm.univ-mlv.fr/~dr/XPOSE2008/git/gestionnaires.html [Accès le 04/05/2017] [N29] https://www.projet-plume.org/fiche/git [Accès le 10/05/2017]
- 217. Projet de fin d’études Page 217 Bibliographie [B1] Pascal Roques, UML2 par la pratique, édition Eyrolles, 2007.