Memoire 1

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

REPUBLIQUE DEMOCRATIQUE DU CONGO

ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE

"Analyse métier et conception par la


méthode UP d'une plate-forme e-
commerce dans le domaine
vestimentaire"(CAS DE DEV MODE)
NUMBI/WA KYUNGU/ENOCK

Mémoire soumis pour l’obtention du diplôme de Licence en


Sciences Informatiques à l’Université Protestante de Lubumbashi

Promotion : NUMBI WA KYUNGU ENOCK


Matricule : 2020022169

Octobre 2023
REPUBLIQUE DEMOCRATIQUE DU CONGO

ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE

"Analyse métier et conception par la


méthode UP d'une plate-forme e-
commerce dans le domaine
vestimentaire"(CAS DE DEV MODE)

NUMBI/WA KYUNGU/ENOCK

Mémoire soumis pour l’obtention du diplôme de Licence en


Sciences Informatiques à l’Université Protestante de Lubumbashi

Directeur: CT. DANIEL KATUAL


Co-directeur: CT. Rose KAMWANG MUSANS

Promotion : BAC 3 IG
Matricule : 2020022169

Octobre 2023
DEDICACE

A toute la communauté scientifique

A toutes les autorités académiques de l’université protestante de Lubumbashi

A ma très chère famille KYUNGU

i
REMERCIEMENT

Le présent travail n'est pas seulement le fruit de nos propres efforts, mais aussi les efforts de bien
de personnes à qui nous exprimons nos vifs remerciements.

Nous exprimons nos remerciements d'abord au recteur de l'Université Protestante de


Lubumbashi (U.P.L), Professeur Docteur LEE KWANG SOO qui nous a donné l'opportunité de
poursuivre nos études.

Nos remerciements sont ensuite adressés au Directeur de ce mémoire, le Doyen de la faculté de


sc. informatique le CT DANIEL KATWAL qui, malgré ses multiples occupations, a bien voulu
diriger ce travail.

Nous ne pouvons pas terminer, sans remercier à nos camarades de promotion qui n'ont cessé de
nous encourager au cours de notre parcours estudiantin.

Enfin, à tous ceux qui de près ou de loin ont contribué moralement ou matériellement à
l'aboutissement de ce travail. Nous disons merci.

Enock NUMBI WA KYUNGU

ii
TABLE DE MATIERE

INTRODUCTION .......................................................................................................................... 10

1.1 Concept central de la recherche............................................................ 10

1.1.1 Concept 1 ................................................................................................... 10

1.1.2 Concept 2 ................................................................................................... 10

1.1.3 Concept 3 ................................................................................................... 11

1.2 Enoncée du problème et questions de la recherche ............................ 11

1.3 Présentation et limitations des solutions existantes (s’il y en a) ........ 12

1.4 Délimitation de la recherche .................................................................. 13

1.5 Motivation de la recherche et objectifs ................................................. 14

1.5.1 Motivation de la recherche ........................................................................... 14

1.5.2 Objectifs de la recherché .............................................................................. 15

1.6 Methodology de la recherche ................................................................ 16

1.7 Subdivision du travail ............................................................................ 18

CHAPTER 1 REVUE DE LITERATURE. ............................................................................... 19

1.1 INTRODUCTION ...................................................................................... 19

1.2 Conclusion .............................................................................................. 32

CHAPTER 2 : ANALYE METIER DU PROCESSUS DE VENTE DES VETEMENTS


CHEZ DEV MODE .............................................................................................. 34

1.1 PRESENTATION DU DOMAINES D’ETUDE ........................................... 34

2.0.1. Description textuelle du processus métiers ..................................................... 34

iii
2.0.2. Diagramme de processus métier .................................................................... 34

2.0.3. Diagramme de description de processus métiers ............................................. 35

2.1. Expression de besoins fonctionnels de vente des vêtements ............... i

2.1.1. Identification des cas d’utilisation .................................................................... i

2.1.2. Diagramme de cas d’utilisation du métier.........................................................iv

2.1.3. Modèle du domaine .......................................................................................iv

2.2. CRITIQUE DE L’EXISTANT ...................................................................... vi

2.2.1. PROPOSITION DE LA SOLUTION ........................................................... vi

CONCLUSION PARTIELLE ..................................................................................................... VII

CHAPTER 3 : CONCEPTION DU NOUVEAU SYSTEME DE COMMANDES MODE


SOFT ................................................................................................................... VIII

1.1. Introduction ........................................................................................... viii

3.1 3.1. Identification de besoins fonctionnels du système MODE SOFT viii

3.1.1 3.1.1. Diagramme de cas d’utilisation du système MODE SOFT ......................... x

3.1.2 3.1.2. Planification des itérations grâce aux cas d’utilisation ............................... x

3.2 3.1.3. Description textuelle des scénarios cas d’utilisations............... xi

ALTERNATIVES ........................................................................................................................ XII

3.2.1 xvi

3.2.2 3.1.4. Modélisation des interactions : Diagramme de séquences ........................ xvi

a) Diagramme de séquences système de création compte client ........................... xvii

3.2.3 Suivant la description textuelle du cas d’utilisation « créer compte client, l’acteur
client interagit avec le système : ................................................................... xvii

iv
b) Diagramme de séquences système d’authentification ...................................... xvii

c) Diagramme de séquences système du cas d’utilisation « Mettre à jour le


catalogue » ............................................................................................... xviii

3.2. Réalisation de cas d’utilisation : Diagramme de classes


Participantes .......................................................................................... xxi

3.2.1. Diagramme de classes participantes du cas d’utilisation « Mettre à jour catalogue


vêtement» l’administrateur .......................................................................... xxii

3.2.2. Diagramme de classes participantes du cas d’utilisation « Consulter catalogue


Article ».................................................................................................... xxii

3.2.3. Diagramme de classes participantes du cas d’utilisation « Passer commande » . xxiii

3.2.4. Diagramme de classes participantes du cas d’utilisation «Consulter horaire


livraison » ................................................................................................ xxiv

3.2.5. Diagramme de classes participantes du cas d’utilisation «Gérer plan de


livraison » ................................................................................................. xxv

3.2.6. Diagramme de classes participantes du cas d’utilisation «S’authentifier» ......... xxvi

3.2.7. Diagramme de classes participantes du cas d’utilisation «Créer compte client» xxvii

3.2.8. Diagramme d’Etats-transitions .................................................................. xxviii

3.3. Conception détaillées de l’architecture MODE SOFT ..................... xxviii

3.3.1. Diagramme de classes de conception .......................................................... xxxv

3.3.2. Dérivation du Logique de données ............................................................ xxxvi

3.3.3. Diagramme de composants du système MODE SOFT ................................ xxxvii

CONCLUSION PARTIELLE ............................................................................................ XXXVIII

CHAPTER 4 RESULTAT DE LA RECHERCHE. ......................................................... XXXIX

Introduction xxxix

v
L'objectif de cette recherche était de confirmer ou d'infirmer les hypothèses
suivantes : .......................................................................................... xxxix

Validité des recherches ........................................................................................... xxxix

Conclusions finales ................................................................................................. xxxix

Limites des résultats ................................................................................................ xxxix

Recommandations ......................................................................................................... xl

Architecture de fonctionnement de la plate-forme MODE SOFT ............................... xl

CONCLUSION GENERALE .................................................................................................... XLII

vi
LISTE DES FIGURES

Figure 1 architecture Client-Serveur ................................................................................ 21

Figure 2—Hypertext Transfert Protocol ........................................................................... 22

Figure 3—Architecture 3 tiers .......................................................................................... 24

Figure 4—Model Vue Contrôleur d'une architecture Web[5] ............................................ 25

Figure 5—Architecture Clean .......................................................................................... 27

Figure 6—Architecture traditionnelle et Moderne avec Ajax ............................................ 28

Figure 7—Technologie SPA ............................................................................................ 30

Figure 8—Architecture Web de type Back-end ................................................................ 30

Figure 9—Diagramme de processus métier de vente des vêtements .............................. 35

Figure 10—Diagramme de contexte ................................................................................... i

Figure 11—Cas d’utilisation de l’acteur Client ....................................................................ii

Figure 12—Cas d’utilisation de l’agent commercial ........................................................... iii

Figure 13—Cas d’utilisation de l’acteur Service client .......................................................iv

Figure 14—Cas d’utilisation de l’acteur Service client .......................................................iv

Figure 15—Diagramme d'activité....................................................................................... v

Figure 16—Diagramme de classe du domaine ..................................................................vi

Figure 17—Digramme de cas d’utilisation du système MODE SOFT ................................ x

Figure 18—Diagramme de séquences système du cas ‘utilisation « Créer compte client


».......................................................................................................... xvii

Figure 19—Diagramme de séquences système du cas ‘utilisation « s’authentifier » ..... xviii

vii
Figure 20—Diagramme de séquences système du cas d’utilisation « Mettre à jour le
catalogue ............................................................................................. xix

Figure 21—Diagramme de séquences du cas d’utilisation « Consulter catalogue article


»............................................................................................................xx

Figure 22—Diagramme de séquences du cas d’utilisation « Passer commande » .......... xxi

Figure 23—diagramme de classes participantes du cas d'utilisation Mettre à jour


catalogue ............................................................................................ xxii

Figure 24Fig.3. 8—Diagramme de classes participantes du cas d'utilisation « Consulter


catalogue vêtement » ......................................................................... xxiii

Figure 25—Diagramme de classes participantes du cas d'utilisation « Passer commande


»......................................................................................................... xxiv

Figure 26—Diagramme de classes participantes du cas d'utilisation « Consulter plan de


livraison» ............................................................................................. xxv

Figure 27—Diagramme de classes participantes du cas d'utilisation « Gérer plan de


livraison.............................................................................................. xxvi

Figure 28—Diagramme de classes participantes du cas d'utilisation « S’authentifier» . xxvii

Figure 29—Diagramme de classes participantes du cas d'utilisation « Créer compte


client» ............................................................................................... xxvii

Figure 30—Diagramme de séquence détaillée de l'opération « recherche Article


vestimentaire...................................................................................... xxix

Figure 31—diagramme de séquences détaillées de l’opération système « recherche


avancée » ........................................................................................... xxx

Figure 32diagramme de séquences détaillées de l’opération système « afficher détails


Article » .............................................................................................. xxxi

Figure 33—diagramme de séquences détaillées de l’opération système « valider


commande » .................................................................................... xxxiii

viii
Figure 34—diagramme de séquences détaillées de l’opération système « éditer un article
»........................................................................................................ xxxv

Figure 35—Diagramme de classes de conception détaillée ........................................ xxxvi

Figure 36—modèle logique de données ..................................................................... xxxvii

Figure 37—Diagramme de composants du système MODE SOFT ............................ xxxvii

Figure 38—architecture de composant de l'application ..................................................... xli

ix
INTRODUCTION

Vue les réalités du monde actuels et les problèmes au quelle le monde fait face toute entreprises
qui projette à un rendement incomparable et un service plus performent, l’apport de l’outil
informatique s’avérer indispensable pour réaliser ses rêve. Il est vrai qu’une organisation doit
avoir une bonne gestion aussi qu’un bon fonctionnement afin d’atteindre certains objectifs
qu’elle se fixe.

Cette évolution technologique a stimulé des mutations profondes dans le secteur économique
des entreprises et la création d’une nouvelle économie ou d’un nouveau marché dit «marché
virtuel». Ce nouveau commerce à travers Internet se démontre par une croissance très rapide,
touchant des secteurs importants de l’économie: distribution, secteur bancaire, secteur
touristique et hôtelier. Désormais, les chances de développement du commerce électronique
dans un secteur économique sont fortement influencées par ses capacités à apporter des
avantages concurrentiels aux divers acteurs économiques.

1.1 Concept central de la recherche

Le concept central de la recherche consiste à concevoir une plate-forme e-commerce dans le


domaine vestimentaire qui non seulement répond aux besoins métier spécifiques de l'industrie,
mais qui offre également une expérience utilisateur exceptionnelle, garantit la sécurité des
données, et intègre les technologies et les pratiques actuelles pour rester compétitif dans ce
secteur en constante évolution. La méthodologie UP offre une structure itérative pour atteindre
ces objectifs de manière organisée et contrôlée.

1.1.1 Concept 1

Compréhension du Marché Vestimentaire en Ligne : Comprendre les tendances, les


préférences des clients et la dynamique du marché de la vente de vêtements en ligne est
essentiel. Cela inclut la connaissance des segments de marché, des saisons de la mode, et des
concurrents.

1.1.2 Concept 2

1. Expérience Utilisateur : L'expérience utilisateur est cruciale pour le succès d'une plate-
forme e-commerce dans le secteur vestimentaire. La recherche doit se concentrer sur la

10
conception d'interfaces utilisateur conviviales, la personnalisation, les évaluations de
convivialité et les retours des utilisateurs.
1.1.3 Concept 3

Gestion des Commandes et des Stocks : Comprendre les processus de gestion des
commandes, de gestion des stocks et de traitement des retours est essentiel pour garantir une
efficacité opérationnelle. Cela peut inclure la gestion des tailles, des couleurs et des variantes
de produits.

1.2 Enoncée du problème et questions de la recherche

La recherche vise à répondre à ces questions de manière à concevoir une plate-forme e-


commerce réussie et compétitive dans le domaine vestimentaire en utilisant la méthode UP
comme cadre méthodologique

La recherche vise à répondre à ces questions de manière à concevoir une plate-forme e-


commerce réussie et compétitive dans le domaine vestimentaire en utilisant la méthode UP
comme cadre méthodologique.

1. Quelles sont les tendances actuelles de l'industrie de la vente de vêtements en ligne, et


comment ces tendances influencent-elles la conception de la plate-forme e-commerce ?

2. Quels sont les besoins métier spécifiques du secteur vestimentaire en ce qui concerne la
gestion des produits, des stocks, des commandes et des paiements ?

3. Comment concevoir une interface utilisateur conviviale et personnalisée pour les clients
cherchant des vêtements en ligne, en intégrant éventuellement des fonctionnalités telles que
l'essai virtuel ?

4. Quelles sont les meilleures pratiques en matière de sécurité des données pour protéger les
informations personnelles et financières des clients lors des transactions en ligne ?

5. Quels sont les choix technologiques et les Framework les plus adaptés pour le développement
d'une plate-forme e-commerce dans le domaine vestimentaire ?

6. Comment intégrer des pratiques durables dans la plate-forme e-commerce, notamment la


gestion responsable des stocks et la sensibilisation environnementale ?

7. Comment appliquer efficacement la méthode Unified Process (UP) pour gérer le projet de
conception et de développement de la plate-forme e-commerce de manière itérative et
contrôlée ?

8. Quelles stratégies de marketing en ligne sont les plus appropriées pour attirer et fidéliser les
clients dans l'industrie de la mode en ligne ?

11
9. Comment garantir la scalabilité et l'évolutivité de la plate-forme pour faire face à la croissance
des utilisateurs et des produits ?

10. Quelles méthodes d'évaluation peuvent être utilisées pour mesurer et améliorer la
performance de la plate-forme e-commerce une fois qu'elle est en production ?

1.3 Présentation et limitations des solutions existantes (s’il y en a)

Bien qu'il existe de nombreuses solutions e-commerce dans le domaine vestimentaire, elles
présentent des avantages et des limitations. Concevoir une nouvelle plate-forme e-commerce
dans ce secteur nécessite une analyse minutieuse des besoins métier spécifiques pour répondre
aux défis tout en tirant parti des leçons apprises des solutions existantes.

1. Plateformes E-commerce Établies : Des plateformes telles que Shopify, WooCommerce


(pour WordPress), Magento et BigCommerce sont couramment utilisées pour la création de
boutiques en ligne. Elles offrent des fonctionnalités prêtes à l'emploi, des thèmes
personnalisables et des passerelles de paiement intégrées.

2. Marchés en Ligne : Des marchés en ligne tels qu'Amazon, eBay et Alibaba permettent aux
vendeurs de mode de lister leurs produits et d'atteindre un public mondial sans avoir à créer
leur propre site web. Cependant, ces marchés ont des règles strictes et des frais associés.

3. Plateformes Personnalisées : Certaines entreprises de mode choisissent de développer leurs


propres plateformes e-commerce personnalisées pour un contrôle total sur l'expérience client.
Cela nécessite des ressources considérables en développement.

4. Solutions D2C (Direct-to-Consumer) : Les marques de mode D2C se tournent vers des
solutions e-commerce pour établir des relations directes avec leurs clients, éliminant ainsi les
intermédiaires. Cela nécessite des fonctionnalités spécifiques, telles que la personnalisation.

5. Solutions de Mode Durable : Certaines plateformes e-commerce se spécialisent dans la


vente de vêtements et d'accessoires durables, mettant l'accent sur la transparence des
matériaux et des pratiques de fabrication.
Limitations des Solutions Existantes :

1. Coûts Élevés : Certaines plateformes e-commerce établies ont des coûts mensuels élevés,
ainsi que des frais de transaction. Cela peut représenter une charge financière pour les petites
entreprises.

2. Personnalisation Limitée : Les solutions prêtes à l'emploi peuvent avoir des limites en
termes de personnalisation de l'interface utilisateur, de fonctionnalités spécifiques à l'industrie
de la mode, et de flexibilité.

12
3. Dépendance aux Tiers : L'utilisation de marchés en ligne signifie souvent une dépendance à
l'égard de tiers pour les règles de la plateforme, la visibilité et les frais.

4. Complexité Technique : Le développement et la maintenance d'une plateforme e-commerce


personnalisée sont techniquement exigeants et nécessitent des compétences en développement
web.

5. Sécurité et Conformité : Toutes les plateformes ne répondent pas nécessairement aux


normes de sécurité et de conformité, ce qui peut compromettre la protection des données des
clients et la conformité aux réglementations telles que le RGPD.

6. Expérience Client : Les plateformes existantes peuvent parfois ne pas offrir une expérience
utilisateur optimale pour la recherche de produits, l'essai virtuel ou les recommandations de
produits personnalisées.

7. Durabilité : Les plateformes existantes peuvent ne pas intégrer efficacement des pratiques
durables pour répondre à la demande croissante de mode éthique et responsable.

1.4 Délimitation de la recherche

Toutefois, il est important de noter que cette étude est délimitée à plusieurs égards afin de cibler
efficacement le sujet et de garantir sa pertinence. Les délimitations suivantes sont énoncées
pour orienter la portée de cette recherche :

1. Domaine Vestimentaire : Notre recherche se concentre exclusivement sur le secteur de la


mode et des vêtements dans l'e-commerce. Bien que d'autres produits puissent être vendus en
ligne, notre étude se limite aux spécificités de ce secteur.

2. Méthode UP : Nous utilisons la méthode Unified Process (UP) comme principal cadre
méthodologique pour l'analyse et la conception. D'autres méthodes de développement de
logiciels ne seront pas examinées en profondeur dans cette étude.

3. Conception et Analyse : Notre travail se penche principalement sur la phase d'analyse métier
et de conception de la plate-forme e-commerce. La mise en œuvre et d'autres phases du cycle
de vie du logiciel seront hors du champ d'application.

4. Plate-forme e-commerce : Nous nous concentrons sur la création d'une plate-forme e-


commerce complète pour la vente de vêtements, y compris les fonctionnalités essentielles
liées à cette activité.
La combinaison de ces délimitations permettra une exploration en profondeur du sujet, tout en
offrant des résultats spécifiques et applicables au contexte de l'e-commerce dans le domaine
vestimentaire.

13
Dans les chapitres à venir, nous plongerons dans l'analyse des besoins métier, la conception de
l'architecture logicielle et les étapes pratiques de la méthode UP pour la création d'une plate-
forme e-commerce performante et compétitive.

1.5 Motivation de la recherche et objectifs

L'industrie du commerce électronique a connu une croissance explosive au cours des dernières
années, bouleversant les modèles commerciaux traditionnels et transformant la manière dont
les consommateurs effectuent leurs achats. Parmi les secteurs les plus dynamiques de l'e-
commerce, le domaine vestimentaire occupe une place de choix. L'achat de vêtements en ligne
est devenu courant, offrant aux consommateurs un accès à une variété de styles, de marques et
de tailles, le tout depuis le confort de leur domicile.

Cependant, le succès dans le secteur du commerce électronique, en particulier dans le domaine


vestimentaire, repose sur une combinaison complexe de facteurs, notamment la convivialité de
la plate-forme, la gestion efficace des stocks, la personnalisation de l'expérience client et la
capacité à suivre les tendances changeantes de la mode. Les entreprises qui parviennent à
maîtriser ces aspects peuvent se démarquer dans un marché hautement compétitif.

1.5.1 Motivation de la recherché

La motivation de cette recherche réside dans la nécessité de comprendre en profondeur les


processus d'analyse métier et de conception d'une plate-forme e-commerce dans le domaine
vestimentaire. En combinant la méthodologie Unified Process (UP) avec une compréhension
approfondie des besoins et des exigences spécifiques de ce secteur, nous visons à contribuer à
l'amélioration des pratiques de développement logiciel dans l'e-commerce

14
1.5.2 Objectifs de la recherché

1. Analyse Métier Approfondie : Effectuer une analyse approfondie des besoins et des
exigences métier dans le domaine vestimentaire pour comprendre les défis spécifiques
auxquels les entreprises de mode sont confrontées dans l'environnement e-commerce.

2. Conception de Plate-forme E-commerce : Concevoir une plate-forme e-commerce


complète, en mettant l'accent sur l'architecture logicielle, les fonctionnalités essentielles, la
gestion de l'inventaire, la personnalisation de l'expérience client et la prise en compte des
tendances de la mode.

3. Application de la Méthode UP : Appliquer la méthodologie Unified Process (UP) pour


guider le processus d'analyse métier et de conception, en mettant en évidence les avantages et
les meilleures pratiques de cette méthodologie dans le contexte du commerce électronique.

4. Contributions Pratiques : Fournir des recommandations pratiques aux professionnels de


l'informatique et aux entreprises du secteur vestimentaire pour améliorer leurs approches de
développement logiciel dans le commerce électronique.

5. Validation et Évaluation : Évaluer la plate-forme conçue à l'aide de scénarios de test


pertinents pour garantir sa conformité aux exigences métier identifiées.

6. Documentation Complète : Produire une documentation complète du processus d'analyse et


de conception, facilitant la réplication et la mise en œuvre des résultats.

1. Objectif primaire
L’objectif primaire de cette recherche est de créer une plate-forme e-commerce spécifiquement
adaptée au secteur vestimentaire, en utilisant la méthodologie UP comme guide, et de démontrer
comment cette approche peut être bénéfique pour les entreprises opérant dans ce domaine.
L'objectif est de fournir des contributions pratiques et une compréhension approfondie du
processus d'analyse métier et de conception dans le contexte du commerce électronique
vestimentaire

2. Objectif secondaire

1. Évaluation Comparative des Méthodologies : Comparer la méthodologie UP avec d'autres


méthodologies de développement logiciel couramment utilisées dans le secteur e-commerce,
telles que Agile ou Waterfall, pour déterminer les avantages et les inconvénients de chaque
approche dans le contexte du commerce électronique vestimentaire.

15
2. Analyse des Tendances de la Mode : Intégrer une analyse des tendances de la mode
actuelles dans la conception de la plate-forme e-commerce, en mettant en évidence comment
ces tendances influencent les choix de conception et les fonctionnalités de la plate-forme.

3. Mesure de la Performance : Établir des indicateurs clés de performance (KPI) pour évaluer
l'efficacité de la plate-forme e-commerce dans le secteur vestimentaire, notamment en ce qui
concerne la conversion des visiteurs en clients, la rétention des clients, et les taux de
conversion par rapport aux produits vestimentaires.

4. Sécurité et Confidentialité des Données : Accorder une attention particulière à la sécurité et


à la confidentialité des données des clients dans le cadre de la conception de la plate-forme, en
garantissant la conformité aux réglementations en vigueur telles que le RGPD (Règlement
général sur la protection des données).

5. Évolutivité et Gestion des Pics de Charge : Concevoir la plate-forme en tenant compte de la


capacité à gérer efficacement les pics de charge, notamment lors d'événements promotionnels
ou de saisons de vente à fort volume dans le secteur vestimentaire.

6. Analyse des Rétroactions des Utilisateurs : Collecter et analyser les commentaires et les
réactions des utilisateurs de la plate-forme pour identifier des améliorations potentielles et des
opportunités d'optimisation continue.

7. Reproductibilité de la Méthodologie : Mettre en évidence comment la méthodologie UP


peut être reproduite dans d'autres domaines de l'e-commerce ou dans d'autres secteurs pour
créer des plate-formes adaptées aux besoins métier spécifiques.

8. Impact sur la Rentabilité : Évaluer comment la conception de la plate-forme e-commerce


affecte la rentabilité de l'entreprise, en mesurant l'impact sur les ventes, la réduction des coûts
opérationnels et la fidélisation des clients.
Ces objectifs secondaires peuvent enrichir votre recherche en fournissant des perspectives plus
larges et en explorant des aspects spécifiques du développement d'une plate-forme e-commerce
dans le secteur vestimentaire. Ils contribuent à une compréhension plus complète de
l'application de la méthode UP dans ce contexte.

1.6 Methodology de la recherche

1. Revue de la Littérature

 Commencez par une revue de la littérature pour comprendre les tendances actuelles du
commerce électronique dans le secteur vestimentaire. Identifiez les principaux défis et
opportunités.
2. Collecte de Données

16
 Collectez des données pertinentes sur le secteur vestimentaire, y compris les données de
marché, les statistiques de vente en ligne, les préférences des consommateurs et les tendances
de la mode actuelles.
3. Analyse des Besoins Métier

 Utilisez des méthodes de collecte de données telles que des entretiens avec des experts de
l'industrie et des questionnaires pour analyser les besoins métier spécifiques du secteur
vestimentaire en matière de commerce électronique.
4. Conception de la Plate-forme E-commerce

 Appliquez la méthode Unified Process (UP) pour la conception de la plate-forme e-


commerce. Cela inclut la modélisation des cas d'utilisation, la définition de l'architecture
logicielle, la création de diagrammes de séquence, et la planification des itérations.
5. Développement et Mise en Œuvre

 Mettez en œuvre la conception de la plate-forme e-commerce en utilisant les principes de


développement logiciel itératif de la méthode UP. Assurez-vous d'intégrer les fonctionnalités
spécifiques au secteur vestimentaire.
6. Validation et Évaluation

 Évaluez la plate-forme en utilisant des scénarios de test pertinents, en mesurant les


performances, la convivialité et la satisfaction des utilisateurs. Identifiez les éventuels
problèmes et effectuez des ajustements.
7. Documentation

 Documentez de manière exhaustive toutes les étapes de la recherche, y compris l'analyse des
besoins métier, la conception de la plate-forme, les résultats de validation, et les leçons
apprises.
8. Analyse des Résultats

 Analysez les résultats de la recherche pour déterminer dans quelle mesure la méthode UP est
efficace pour la conception d'une plate-forme e-commerce dans le domaine vestimentaire.
Identifiez les avantages, les limitations et les domaines d'amélioration potentiels.
9. Recommandations et Implications Pratiques

 Fournissez des recommandations pratiques aux entreprises du secteur vestimentaire et aux


professionnels de l'informatique sur la manière d'appliquer la méthodologie UP pour le
développement de plate-formes e-commerce adaptées aux besoins métier.
10. Conclusion et Contributions

 Résumez les principales conclusions de la recherche et mettez en évidence les contributions


spécifiques apportées à la compréhension du développement de plate-formes e-commerce
dans le secteur vestimentaire.

17
La méthodologie décrite ci-dessus devrait vous permettre de mener une recherche approfondie
et systématique, tout en utilisant la méthode UP comme cadre pour l'analyse métier et la
conception de la plate-forme e-commerce. N'oubliez pas d'adapter cette méthodologie en
fonction de vos ressources et de vos besoins spécifiques de recherche.

1.7 Subdivision du travail

Ce travail est subdivisé en chapitres et ils sont en leurs tournes sont subdivisés en
différentes parties :

Le premier chapitre, Revue de literature.

; dans ce chapitre il est question d’établir un contexte solide et comprendre les travaux antérieurs
liés à notre sujet.

Le second chapitre ; parlera de l’analyse métier de la vente de vêtements chez DEV MODE. Il
s’agit donc de faire connaitre les processus de vente existant et d’en tirer des conclusions sur la
poursuite ou non du projet. *

Le troisième chapitre est la conception du nouveau système d’information de vente de


vêtements; il est question de créer un système qui sera fonctionnel pour une vente à distance
avec commande des vêtements et une livraison à domicile. Enfin nous allons finir par la
réalisation de l’application MODESOFT au quatrième chapitre.

18
REVUE DE LITERATURE.

1.8 INTRODUCTION

Le secteur du commerce électronique a révolutionné la manière dont les consommateurs


interagissent avec les marques et effectuent leurs achats. Parmi les domaines les plus
dynamiques de l'e-commerce, le secteur vestimentaire occupe une place centrale, offrant aux
consommateurs un accès inégalé à une gamme variée de produits et de styles. Dans ce contexte
en évolution rapide, la conception et la mise en œuvre de plateformes e-commerce efficaces et
adaptées au secteur vestimentaire sont devenues des éléments essentiels de la réussite des
entreprises.

Cette revue de littérature vise à établir un cadre conceptuel solide pour comprendre les enjeux
clés liés à l'analyse métier et à la conception de plateformes e-commerce dans le domaine
vestimentaire, en mettant l'accent sur l'application de la méthodologie Unified Process (UP).
Cette méthodologie, axée sur l'architecture logicielle et le développement itératif, offre un cadre
structuré pour répondre aux besoins complexes des entreprises du secteur vestimentaire.

3. Évolution du Commerce Électronique Vestimentaire :

Le commerce électronique dans le secteur vestimentaire a connu une croissance significative


ces dernières années. Les consommateurs sont de plus en plus enclins à acheter des vêtements
en ligne en raison de la commodité et du choix offerts par les plateformes e-commerce. La revue
de littérature devrait inclure des données sur l'augmentation des ventes en ligne de vêtements,
ainsi que des informations sur les facteurs qui ont contribué à cette croissance, tels que la
numérisation des catalogues de produits, l'amélioration de l'expérience client en ligne, etc.

4. Tendances Actuelles du Commerce Électronique Vestimentaire :

Explorez les tendances actuelles qui façonnent le commerce électronique dans le secteur
vestimentaire. Cela peut inclure des sujets tels que la personnalisation des achats en ligne, les
technologies de réalité augmentée pour l'essayage virtuel, la durabilité et la mode éthique, la
gestion des retours, ainsi que l'influence des médias sociaux sur les tendances de la mode en
ligne.

5. Méthodologies de Conception de Plate-forme E-commerce :

19
Analysez différentes méthodologies de conception de plate-forme e-commerce, en mettant
l'accent sur la méthode Unified Process (UP). Comparez UP à d'autres méthodologies de
développement logiciel courantes telles qu'Agile et Waterfall, en identifiant les avantages
spécifiques d'UP pour la conception de plateformes e-commerce dans le domaine vestimentaire.

6. Analyse des Besoins Métier dans le Commerce Vestimentaire :

Explorez comment les entreprises du secteur vestimentaire abordent l'analyse des besoins
métier pour leurs plateformes e-commerce. Mettez en évidence les défis spécifiques tels que la
gestion des stocks, la gestion des tailles et des modèles, la personnalisation des
recommandations de produits, etc.

7. Sécurité et Confidentialité des Données :

En raison de la sensibilité des données personnelles des clients, examinez les questions de
sécurité et de confidentialité des données dans le commerce électronique vestimentaire. Incluez
des informations sur les réglementations telles que le RGPD (Règlement général sur la
protection des données) et leur impact sur la collecte et le traitement des données client.

8. Performances et Évolutivité des Plateformes E-commerce Vestimentaires :

Discutez de l'importance de la performance et de l'évolutivité dans le commerce électronique


vestimentaire, en tenant compte des défis liés à la gestion des pics de charge pendant les
périodes de soldes ou de promotions.

9. Rétroaction des Utilisateurs et Amélioration Continue :

Analysez comment les plateformes e-commerce dans le secteur vestimentaire recueillent les
commentaires des utilisateurs et les intègrent dans leurs processus d'amélioration continue.

10. Impact Économique du Commerce Électronique Vestimentaire :

Évaluez l'impact économique du commerce électronique vestimentaire, notamment son rôle


dans la création d'emplois, la croissance du secteur, et la transformation des modèles
commerciaux traditionnels.

Cette revue de littérature devrait vous aider à établir un cadre conceptuel solide pour votre
recherche et à identifier les lacunes dans la littérature existante que vous pourriez explorer dans

20
votre propre étude. Assurez-vous de citer correctement toutes les sources et de les intégrer dans
votre recherche pour étayer vos conclusions

11. Clients et serveurs http

Le cœur de l’architecture technique du Web est le protocole HTTP, qui repose sur un
modèle client-serveur.

Figure 1 architecture Client-Serveur

Cette architecture est très classique et n’est pas née avec le Web, mais on doit plus
précisément parler d’un serveur et de multiples clients qui s’y connectent. Sur le Web, et dans
HTTP, les serveurs sont conçus pour communiquer systématiquement avec de multiples clients.
On rappelle qu’il est très fréquent qu’un même client parle avec différents serveurs pour des
tâches très courantes, comme la consultation de pages Web dans un navigateur, qui nécessite
de charger des contenus sur différents serveurs HTTP indépendants.

12. Client et serveur Web

Le protocole de communication entre clients et serveurs est HTTP (HyperText Transfer


Protocol). Le client peut être tout type de programme (navigateur, robot, etc.).

- Le Client appelé user agent dans les spécs


- Serveur appelé origin server dans les spécs La notion d’origin server (serveur
d’origine), permet de distinguer le serveur d’un éventuel proxy (serveurs mandataire)
présent entre ce serveur et le client.
- Les détails d’HTTP concernant les proxies ne seront pas abordés dans ce cours. On
étudiera le protocole HTTP plus en détails dans la prochaine séquence de cours
magistral.

21
Figure 2—Hypertext Transfert Protocol

13. Dialogue entre client et serveur

Communication en 3 étapes simples :

(a) Le client (navigateur) fait une requête d’accès à une ressource auprès d’un serveur
Web selon le protocole http

(b) Le serveur vérifie la demande, les autorisations et transmet éventuellement


l’information demandée.

(c) Le client interprète la réponse reçue (et l’affiche)

On recommence pour des ressources complémentaires (images, …).

1.1.1.1. Concepts de base d’HTTP

Interaction avec des ressources hypertexte :

Quoi : Ressources accessibles via Internet (documents hypertextes, images, etc.)

Où : URL pour localiser les ressources sur des serveurs Internet

Comment : HTTP comme protocole de communication pour un client souhaitant faire des
actions sur les ressources hébergées sur un serveur On parle en fait plutôt d’URI que d’URL
dans les spécifications, même si pour l’instant cette subtilité a peu d’importance.

1.1.1.2. Construction de la toile (Web)

22
Les ressources référencent d’autres ressources (attribut href dans HTML)

Les liens sont unidirectionnels

Aucune garantie de disponibilité, cohérence

Parcourir la toile :

(a) trouver les liens,

(b) accéder aux ressources liées

(c) enrichir le modèle applicatif

(d) recommencer …

14. 1.1.2.6. Architecture 3 tiers

Les applications Web sont ubiquitaires aujourd’hui, mais on n’a pas forcément toujours
des idées très claires sur ce qui permet de faire fonctionner ces applications. Cette séquence va
nous permettre d’examiner les mécanismes et protocoles nécessaires au fonctionnement d’une
application Web.

Une architecture logicielle contient trois couches à savoir :

- couche de présentation ;
- couche de traitement ;
- couche d’accès aux données.

Simplification de l’approche générale d’une architecture à plusieurs niveaux (multi tier)

L’objectif de cette décomposition en couches est de mieux comprendre la logique des


interactions entre différents composants logiciels mis en œuvre pour faire fonctionner une
application. Il s’agit ici d’une architecture logicielle/système, indépendant des fonctionnalités
fournies par telle ou telle application (on parlerait d’architecture fonctionnelle). On parle aussi
d’architecture à trois niveaux ou architecture à trois couches. Le mot tiers est une traduction
approximative de l’anglais tiers signifiant étage ou niveau.

23
Figure 3—Architecture 3 tiers

L’application fonctionne sur un serveur accessible depuis le réseau via le protocole


HTTP. Un navigateur Web permet de s’y connecter et de consulter des pages Web présentant
le résultat de l’exécution d’un programme fonctionnant dans la mémoire du serveur. Attention,
ici, plusieurs clients Web peuvent accéder simultanément à la même application fonctionnant
sur le serveur Web.

15. Rôles dans l’architecture du Web

Déploiement sur le Web des différentes couches :

- Présentation : pages HTML transmises via le réseau :


 serveur qui les construit
 client (navigateur) qui les affiche
 Traitements : programmes
 serveur Web (dialogue HTTP, invocation des applications)
 serveur d’applications (exécute des programmes PHP, par exemple)
- Accès aux données : SGB

16. Défis de l’architecture du Web


Ainsi la maintenance d’une application Web passe par la maitrise de son architecture.
Elle garantit donc la pérennité de l’application Web durant son cycle de vie ; et lors de la
conception de l’architecture il faut pouvoir éviter les problèmes suivants :

24
 Faible testabilité du logique métier. Si cette logique est liée à la base de données et au
client, il sera alors très difficile d'écrire des tests automatisés qui puissent être exécutés en
quelques secondes. Si tous les développeurs perdent plusieurs minutes pour vérifier que la
suite de test

 s ne retourne pas d'erreurs, c'est une perte importante de productivité.

 Choix techniques erronés. Avec une mauvaise architecture il est impossible de revenir en
arrière comme expliqué dans le point précédent. Si un choix technique se trouve être bloquant
durant le développement, revenir en arrière sera impossible et le projet devra être repris à
partir de zéro.

 Duplication du code. Sans architecture cohérente, la duplication de code sera inévitable. Par
exemple, deux éléments de l'application voudront faire la même chose mais l'architecture ne
le permettra pas, la duplication sera la seule solution. Il faut éviter cela à tout prix
En général quand on développe une application web, on utilise une architecture trois
tiers (ou trois couches) incluant : l'interface utilisateur, la logique métier, et l'accès aux
données[4].

Figure 4—Model Vue Contrôleur d'une architecture Web[5]

Ce modèle d’architecture se décompose comme suit :

 Les modèles communiquent avec la base de données

 Les vues sont faites pour la présentation de l'interface utilisateur

25
 Les contrôleurs incluent les actions effectuées par les utilisateurs
En séparant le code d'une application web de cette manière, l'accès aux données est
totalement séparé du reste de l'application. Sans dépendance à l'interface utilisateur ou à la
logique des actions de l'utilisateur, il est bien plus simple d'écrire des tests automatisés. De
plus, la duplication de code sera considérablement amoindrie.
Mais ce pattern n'est pas parfait. Premièrement les contrôleurs et les vues restent liés
et un changement d'un côté entrainera souvent un changement de l'autre. De plus, si des
changements d'infrastructure interviennent, comme des modifications de base de données, il
faudra probablement réécrire une partie importante du code. Ces évolutions sont normalement
rares, mais cela arrivera sûrement à un moment ou à un autre.
Pour gagner en maintenance et en évolutivité il peut être nécessaire d'avoir une
architecture où l'infrastructure n'est pas liée aux modèles :

17. Clean architecture

La clean architecture, aussi connue sous le nom d'architecture oignon ou encore


architecture hexagonale, permet de supprimer la dépendance du logique métier avec les autres
composants de l'application (interface utilisateur, Framework, base de données, infrastructure,
mais aussi les services externes). Le modèle MVC et la clean architecture sont des concepts
importants quel que soit le type d'application. Isoler la couche métier de l'infrastructure
permettra de s'adapter plus facilement aux changements, quels qu'ils soient.

En plus des avantages déjà présents avec le pattern MVC, les changements techniques
vont pouvoir intervenir rapidement et efficacement et des choix techniques problématiques vont
pouvoir être corrigés avec une perte de temps minimum.

26
Figure 5—Architecture Clean

18. Architecture web modern

Les applications web ont été pendant longtemps, et le sont encore fréquemment
aujourd'hui, des monolithes. Cela signifie que toutes les parties de l'application sont
interconnectées occasionnant ainsi des problèmes techniques[6] :

 Mise en production de tout ou rien. En effet si tout est lié, un petit changement sur une
partie du code demande la mise à production de toutes les parties. Mais si d'autres parties ont
des changements en cours, la mise en production est bloquée.

 Duplication des interfaces. Dans le cas où des API ouvertes vers l'extérieur existent, ce qui
est souvent le cas, il y a de possibles duplications d'interface. Les mêmes actions doivent être
programmées pour l'API que pour l'interface utilisateur.

 Montée en charge. Certaines fonctionnalités ont tendance à avoir des besoins spécifiques
pour la montée en charge. Mais avec un bloc unique, la montée en charge se fait sur toutes
les parties de l'application, même si le besoin n'est présent que sur une seule.

19. L'architecture front-end


Depuis le début du web dynamique, les vues étaient générées par le serveur. À chaque
changement d'URL, il y avait un aller-retour avec le serveur. JavaScript était simplement utilisé
pour les actions de l'utilisateur sans interaction avec le serveur.

27
20. Architecture Front-end avec Ajax

Asynchrones JavaScript ans XML (Ajax) constitue de nos jours une architecture pour les
applications web utilisant JavaScript pour faire des requêtes au serveur[7]. Le serveur envoyait
une réponse en XML ou JSON qui était utilisé pour modifier le client. Ajax a permis à de
nouvelles classes d'applications web de voir le jour, notamment Google Maps[8]. Pouvoir
appeler le serveur pour modifier le client sans rechargement permet de répondre aux
actions des utilisateurs bien plus rapidement.

Avec des navigateurs toujours plus puissants et avec toujours plus de fonctionnalités, cette
architecture est toujours utilisée même si le terme l'est beaucoup moins. De plus en plus
d'actions ont été déplacées du backend vers le frontend, ce qui a eu pour effet d'ajouter beaucoup
de code sur le frontend ce qui peut facilement devenir un cauchemar à maintenir sans la
bonne architecture.

Figure 6—Architecture traditionnelle et Moderne avec Ajax

[7]

21. Single Page Applications


Dans le cadre de la refonte ou la création d’un site internet puissante, plusieurs
technologies existent. Et ces technologies évoluent.

Un Single Page Applications (SPA) est donc une application qui utilise le navigateur de
l’utilisateur pour générer la page qu’il doit afficher[9]. Généralement le code s’exécute côté

28
client. Cela permet de naviguer sur toute l’application web sans rechargement de la page.
L’exécution du code côté client est le concept principalement utilisé par les SPA, au moyen du
langage JavaScript et ses différentes librairies. Le terme signifie que le rendu par le serveur est
fait juste une seule fois, pour charger le code JavaScript. Grâce à cette architecture l'interface
utilisateur est plus réactive, se rapprochant des applications natives.

L'application à page unique (SPA) est composée de composants individuels qui


peuvent être remplacés/mis à jour indépendamment, sans rafraîchir/recharger la page
entière afin que la page entière n'a pas besoin d'être rechargée sur chaque utilisateur
action[9].

1) Composants individuels : la page entière est divisée en composants plus petits qui
interagissent les uns avec les autres.

2) Remplacé/mis à jour : un composant/une région/une partie d'un page remplacée /


mise à jour avec tout changement sur les demandes des utilisateurs.

3) Rafraîchissement/Rechargement : la page entière n'est jamais rechargé/rafraîchi,


plutôt du nouveau contenu est chargé dans certains partie ou section selon les nouvelles
données.

4) Actions de l'utilisateur : l'application à page unique est responsable pour gérer


toutes les interactions utilisateur telles que le clic sur un bouton, la saisie du clavier, etc.
très rapide et donc très fluide interface utilisateur. SPA permet une manière plus flexible
et élégante de traiter avec des données. Rafraîchir une partie particulière ou une section
d'une page sans rafraîchir une page entière est l'objectif principal de SPA

29
Figure 7—Technologie SPA

Le front-end des applications web fonctionne dans ce cas comme les applications mobiles,
ce qui va permettre d'éviter la duplication des interfaces et consolider l'API comme source
unique pour tous les clients[9].

Néanmoins, l'indépendance du front-end par rapport au back-end n'est pas forcément


bénéfique. En effet, si le client a besoin d'appeler l'API très fréquemment, les performances
peuvent se dégrader rapidement par rapport à une application monolithique.

22. L'architecture web back-end


Avec une application monolithique, l'utilisateur navigue vers une URL, le back-end
accède à la base de données pour faire toutes les requêtes nécessaires et fait le rendu de
l'interface utilisateur.

Mais avec des SPAs, le back-end va accéder à la base de données non pas pour faire le
rendu de l'interface utilisateur, mais pour renvoyer les données que le client a demandé via
l'API. Cependant une mauvaise architecture de l'API peut avoir des conséquences désastreuses
sur les performances.

Figure 8—Architecture Web de type Back-end

23. Les changements d'infrastructure qui en résultent


La séparation du front-end avec le back-end permet donc à chacune des deux parties d'être
mise en production indépendamment.

30
Le front-end n'étant plus que du HTML, CSS et JavaScript, il n'a plus besoin d'être sur le
même serveur que le back-end. Cela change l'infrastructure et offre plus de libertés au
back-end.

En effet, les différentes parties du back-end peuvent être séparées en services, toutes
hébergées sur différents serveurs adaptés aux besoins de chaque service pour une optimisation
de la montée en charge maximale.

24. Référencement d’une application Web:


L'optimisation pour les moteurs de recherche est le processus de augmenter le classement
de la page d’un site Web afin que de plus en plus le trafic peut venir à votre site Web. Le
contenu construit par Les SPA sont dynamiques et les moteurs de recherche ont du mal leur
traitement, cela peut entraîner un mauvais classement de la page. À faites de votre SPA S.E.O.
convivial, vous devriez créer du HTML des instantanés et une maintenance régulière sont
nécessaires. La suite est l'aperçu de base de la façon dont l'optimisation des moteurs de
recherche œuvre :

- Crawler examinera certaines


- URL.(https://upl-univ.ac/student)
- Le robot demande au serveur Web de récupérer le contenu de cette URL.
- Le serveur Web renvoie l'instantané HTML au robot.
- L'instantané HTML est traité par le robot.
- Le résultat de la recherche affiche l'URL d'origine.

25. Cycle de vie de développement du Web


Le cycle de vie du développement d’une application Web comprend l’analyse la
conception, le déploiement et l'exécution exigences pour chacun des rôles : Serveur Web,
Serveur de base de données et le Client ou demandeur de services. Le rôle a des exigences
spécifiques pour chaque élément du cycle de développement. Le développement et le
déploiement d'une application reste la réoccupation du présent travail. Le cycle de
développement peut comporter quatre phases :

1. Construire

La phase de construction du cycle de vie comprend le développement et le test d’une


application Web mise en œuvre, la définition de la description de l'interface. Les

31
implémentations d’une application Web peuvent être fournies par créer de nouveaux services
Web, transformer des applications existantes en services Web, et composer de nouveaux
services Web à partir d'autres services Web et applications.

2. Déployer

La phase de déploiement comprend la publication de l'interface de service et du service


définition de la mise en œuvre à un demandeur de service ou à un registre de service et
déploiement du exécutables pour le service Web dans un environnement d'exécution
(généralement, une application Web serveur).

3. Tester

Pendant la phase d'exécution, le service Web est disponible pour l'appel. À ce stade, le Web le
service est entièrement déployé, opérationnel et accessible par le réseau du fournisseur de
services. À présent le demandeur de service peut effectuer les opérations de recherche et de
liaison.

4. Gérer

La phase de gestion couvre la gestion et l'administration continues du service Web application.


Sécurité, disponibilité, performance, qualité de service et processus métier doivent tous être
abordés.

Les détails de chacune de ces phases du cycle de vie sont abordés dans le développement des
services Web

1.9 Conclusion

En conclusion, cette revue de littérature établit un cadre solide pour la compréhension des
enjeux et des opportunités liés à l'analyse métier et à la conception de plateformes e-commerce
dans le secteur vestimentaire. Elle met en lumière l'importance de la méthodologie UP en tant
qu'outil puissant pour aborder ces défis. Cependant, elle souligne également la nécessité d'une

32
approche adaptée aux besoins spécifiques de ce secteur en constante évolution. Cette revue sert
de base pour la recherche ultérieure qui explorera plus en détail l'application de la méthode UP
dans le contexte du commerce électronique vestimentaire.

33
: ANALYE METIER DU PROCESSUS DE VENTE DES VETEMENTS CHEZ
DEV MODE

1.1 PRESENTATION DU DOMAINES D’ETUDE

Le magasin DEV MODE est parmi ceux qui vendent des bons vêtements.

- SITUATION GEOGRAPHIQUE

DEV MODE est située au numéro 2131, de la commune Lubumbashi avenues Kasa vubu.

2.0.1. Description textuelle du processus métiers


Pour la première fois, visite l’établissement si il trouve un vêtement qui lui intéressent,
il s’est renseigne sur la taille voulus, si la taille du vêtement est disponible le client passe sa
commande, l’agent commercial enregistre la commande du client et prépare sa commande si
la commande est prêt le client en sont tour paye la facture et l’agent commercial encaisse le
payement et livre l’article.

2.0.2. Diagramme de processus métier


L’utilisation du BPMN (Business Process Management Notation) est recommandation de
l’OMG (Object Management Group)[10]. L’objectif de cette technologie est modéliser les
processus d’une organisation afin d’avoir une vision claire de l’organisation avant
l’informatisation. Il sied de signaler quoi qu’il soit proche du digramme d’activité UML, la
notation BPMN reste abstrait sur le fonctionnement interne des applications[11].

Pour consolider cette description textuelle, un diagramme de processus métier ici de la


notation BPMN a été donné, où deux pools à savoir : celui de client qui en fait pas parti de
l’organisation et un deuxième contenant les participants interne au processus. La
communication entre le deux pools n’est possible que par l’envoi de message.

34
2.0.3. Diagramme de description de processus métiers
Figure 9—Diagramme de processus métier de vente des vêtements

BPEL BPEL Model


«Lane» Client

visite choisir valider reception payer


expo vetement commande reponse facture
besoin des soumission Attendre vendre
vetements commande 3min vetement
«Lane» processys de vente

ADMINISTRATEUR mettre commande encaisser


en attente paiement
DEV MODE

verfie attendre
edition
disponibilite 2min
facture
reception stock
commande fin
verfier existence
client

35
2.1. Expression de besoins fonctionnels de vente des vêtements

Une application informatique est conçue pour répondre premièrement au besoin des
utilisateurs ; lesquels utilisateurs sont considérés chacun comme un acteur jouant un rôle dans le
système.

Ainsi les acteurs important de notre système de vente et distributions des vêtements sont les
suivants :

1) Le client : le client est toute personne physique ou morale achetant des vêtements
à la boutique DEV MODE. Il touche le système pour effectuer commande, régler facture ou faire
une réclamation.
2) gestionnaire : c’est le rôle joué par un agent de la boutique DEV MODE ayant
dans ses responsabilités la vente et d’étaler des vêtements. Il touche le système pour traiter de
commande client, facturer, ordonner la distribution.
3) caissier : il s’occupe de la caisse du magasin, il reçoit l’argent
Schématiquement nous donnons dans le Figure 2.2 suivant un diagramme de contexte où
chaque acteur est relié par une association trait plein au système, symbolisant ainsi les échanges
d’informations.

uc Use Case Model

DEV MODE

Gestionnaire
Client

caissier

Figure 10—Diagramme de contexte

2.1.1. Identification des cas d’utilisation


Les cas d’utilisations constituent la pierre angulaire de la démarche UP. Ils représentent la
volonté des utilisateurs par rapport au système. Une application informatique est conçue sur base
de ces besoins et tout modèle logiciel tire son origine sur les besoins des utilisateurs.
i
Ainsi pour notre système, nous allons répondre à la question « pourquoi tel acteur touche le
système ? ». Répondre à cette question revient à ressortir l’utilisation du système par un acteur
donné.

a) Pour l’acteur client : pourquoi le client touche-t-il le système ? il touche le système


pour :
 CU Effectuer commande : ce cas permet à un client de commander les vêtements de son
choix et de payer la facture avant de faire une réclamation ;
uc Use Case Model

effectuer commande

Client

payer facture

Figure 11—Cas d’utilisation de l’acteur Client

b) Pourquoi l’agent commercial touche-t-il le système ? il touche le système pour :


 Traiter commande : ce cas d’utilisation permet à l’agent commercial de vérifier a
disponibilité du stock, de facturer la commande, d’encaisser le paiement ;
 Encaisser paiement : ce cas d’utilisation permet à l’agent commercial d’encaisser le
paiement.

ii
uc cas d'utilisation de l'agent commercial

mettre en
attente

Traiter
commande
Facturer
commande
Agent
Commercial

Encaisser
paiement

Figure 12—Cas d’utilisation de l’agent commercial

c) Pourquoi le service client touche le client ? : il touche le système pour :


 Gérer client : ce cas permet d’ajouter un nouveau client, de prospecter d’autre, de
modifier des informations sur un client existant.

uc Use Case Model

ajouter
nouveau client

Gerer client

Service client

modifier client

iii
Figure 13—Cas d’utilisation de l’acteur Service client

2.1.2. Diagramme de cas d’utilisation du métier


Ce diagramme montre globalement les fonctionnalités du système. Ainsi le diagramme de cas
d’utilisation de notre système est donné dans la Figure 2.7 suivant :

uc

verification nouveau

visite boutique

«extend» mettre a jour stock


Administrateur
client
choisit vetement

Encaisser paiement
payer facture
caissier

carte bancaire Espece

Figure 14—Cas d’utilisation de l’acteur Service client

2.1.3. Modèle du domaine


Le modèle du domaine représente les concepts ou documents utilisés dans le métier, les
propriétés les caractérisant ainsi que les relations entre eux. Dans nos articles, nous identifions
facilement les concepts suivants : Client, commande vêtement, facture, bon de livraison, Adresse
de livraison.

Les activités considérer ici est l’activité de la commande d’un client, ainsi nous pouvons
présenter ce diagramme de la manier suivante :

iv
act Use Case Model

CLIENT GERANT CAISSIER

RECHERCHE
VETEMENT

CHOIX VETEMENT

VALIDER RECEPTION COMMANDE

EVALUATION FACTURATION EMBALAGE

PAYER

Figure 15—Diagramme d'activité

Nous allons modéliser ce concepts sous-forme de diagramme de classe du métier comme


illustré dans la figure 2.9 suivant :

v
class Diagramme de classe metier

Client Commande
vetement
- code: int - /total: double: int
- nbrVetement: int
- nom: int passer - date: Date: int
- ref: int
- telephone: int - numero: int: int
- taille: int
+ ajouter(): void + calculer(): void
+ compter(): void

appartenir

Facture
- date: Date
- montant: double
- numero: int
+ valider(): void

Figure 16—Diagramme de classe du domaine

2.2. CRITIQUE DE L’EXISTANT

Le système actuel fonctionne radicalement bien avec les objectifs poursuivis par
l’Entreprise, ceux qui consiste à vendre, poursuivre à la loupe la gestion du stock ainsi la sécurité
de leurs vêtements dans le stock.

C’est évident que le système actuel pour faire ses achats, il faut se présenter en personne,
c’est un obstacle pour la plupart de personnes à cause du temps, des dépenses du transport, voire
même à cause de leur rang social.

2.2.1. PROPOSITION DE LA SOLUTION

Il est vrai que le système fonctionne à merveille comme il est souhaitable qu’un magasin
puisse fonctionner, certes notre objectif n’est pas celui de livrer les articles en ligne mais à
effectuer les commandes en ligne, où les clients achètent en ligne est la livraison se fait à domicile.

vi
Cependant, nous demandons à l’organisation ciblée ou toute autre qui voudrait un système
d’information qui comprendra également la vente de ses produits via internet, devrait opter pour
ce système qui leur permettra la synchronisation des opérations.

En guise de quoi, le développement d’une application web va permettra la vente dans un


Magasin en ligne. Avec cette proposition, le système sera autonome dans son fonctionnement
habituel.

CONCLUSION PARTIELLE

Dans ce chapitre, il été question d’analyser l’existant afin de comprendre son


fonctionnement. A ce point, nous avons décrit le processus métier au moyen de la notation BPMN
après une description textuelle. Nous avons procéder à l’identification des besoins fonctionnels au
moyen de cas d’utilisation et enfin représenter les concepts du domaine sous forme de classes
UML.

Dans le troisième chapitre suivant, nous allons identifier les besoins fonctionnels tenant
compte de l’aspect technique, analyser et conception notre application MODESOFT.

vii
: CONCEPTION DU NOUVEAU SYSTEME DE COMMANDES MODE SOFT

1.1. Introduction

Dans chapitre, nous allons devoir concevoir l’architecture logicielle de MODE SOFT au moyen
des artéfacts UML afin d’en spécifier le fonctionnement. Pour y parvenir, une enquête de besoins
du nouveau système en termes d’utilisateurs finaux, fonctionnalités ainsi que les contraintes
techniques. Cette conception sera articulée en deux étapes à savoir : la conception préliminaire où
nous présentons les modèles de cas d’utilisations, les descriptions textuelles, les classes
participantes, la description dynamique de cas d’utilisation ; et la conception détaillée où tous les
modèles précédents en intégrant les détails d’implémentation.

1.10 3.1. Identification de besoins fonctionnels du système MODE SOFT

Le système doit répondre aux attentes des utilisateurs finaux en termes avec de services. Pour cela
nous avons retenus des acteurs suivants pour le système MODE SOFT :

1) Client : le client touche le système pour consulter le catalogue de vêtements, effectuer une
commande en ligne de vêtements
2) L’Internaute : L’Internaute peut consulter le catalogue, créer un compte et choisir ses
vêtements à commander
3) Administrateur : l’administrateur touche le système pour traiter les commandes de clients
et actionner la livraison
4) Livreur : le livreur touche le système pour consulter les clients et leurs adresses de
livraison.
5) Le Système de paiement : est un système informatique tiers sollicité par le système MODE
SOFT pour autoriser un paiement d’un client avant la livraison ;
Tableau 1—Modélisation du contexte

Acteur Cas d’utilisation Expression de besoins

 Le système doit permettre au client de :


- S’authentifier
- Rechercher un vêtement

viii
- Choisir un vêtement
- Commander un vêtement
- Payer un vêtement
 Le système émet :
- Catalogue de vêtement
- Panier du client
- Devis de la commande
Client Effectuer commande - Confirmation paiement

 Le système permet au service commercial


de :
- S’authentifier
- Consulter les commandes
- Valider la livraison
- Vérifier le paiement
- Créer plan de livraison
 Le système affiche :
Administrateur - Liste de commandes en attente
- Liste de commande payée
- Liste des adresses de clients
Traiter commande

 Le système reçoit :
- Nouveau produit
- Editer prix
- Editer détails
- Valider catalogue
 Le système émet :
Mettre à jour - Liste de produits
catalogue - Version du catalogue
- Tarif de produits

 Le système permet au Livreur de :


Consulter plan de - S’authentifier
- Consulter le plan de livraison
Livraison - Localiser un client
Livreur - Signaler une livraison

Consulter catalogue
produit  Le système permet à l’Internaute de :
Internaute - Rechercher un produit
- Sélectionner un produit
- Créer un compte

ix
1.10.1 3.1.1. Diagramme de cas d’utilisation du système MODE SOFT

Les fonctionnalités de notre système sont représentées dans la Fig.3.1 suivante

uc BPEL Model

Editer Nouveau
S'inscrire

Visiteur Mettre a jour


Consulter
catalogue catalogue

«include»

commander Admin
vetement «include» S'authentifier

Gerer sa «include»
Client
commande

Figure 17—Digramme de cas d’utilisation du système MODE SOFT

1.10.2 3.1.2. Planification des itérations grâce aux cas d’utilisation

Pour se conformer au principe dit « Itératif et incrémental de la méthode UP, nous allons
spécifier l’ordre de réalisation de chaque cas d’utilisation [12]. Le découpage en itérations obtenu
est illustré dans le Tableau 2 suivant.
Tableau 2—Planification des itérations grâce aux cas d’utilisation

Cas d’utilisation Priorité Risque Itération #

Consulter catalogue vêtement Haute Moyen 2

Passer commande Haute Moyen 3

Créer un compte Haute Bas 5

Gérer catalogue vêtement Haute Haute 1

x
Traiter commande Moyenne Bas 6

S’authentifier Moyenne Moyen 10

Ayant fait notre découpage, il est temps de passer à la description textuelle de chaque cas
d’utilisation.

1.11 3.1.3. Description textuelle des scénarios cas d’utilisations

Pour illustrer notre démarche, nous allons détailler les cas d’utilisation des quatre premières
itérations, à savoir, dans l’ordre :

- Mettre à jour catalogues de vêtements,


- Consulter catalogue de vêtements,
- Passer commande
- et Traiter commande.

a) Mettre à jour catalogue de produits

- Acteur principal : Administrateur


- Acteurs secondaires : Client, visiteur
- Objectifs : L’Administrateur veut pouvoir contrôler au quotidien les vêtements en
vente et exposés en ligne pour le client.
- Préconditions
 L’Administrateur s’est authentifié sur l’intranet
 La version courante du catalogue de vêtements est accessible.
- Post-conditions
 Une nouvelle version du catalogue est disponible.

- Scénario nominal
Acteur Système

1 Le Gestionnaire alimente le site avec les 2 Le système MODE SOFT met à jour les
nouveaux vêtements. données qui concernent le prix, le détail du,
image vêtements de la boisson.

xi
- Alternatives
1-2aLe Système détecte un dysfonctionnement du catalogue de vêtement.
1. Le Système signale le dysfonctionnement au Gestionnaire.
2. Gestionnaire invalide la mise à jour du catalogue.

b) Consulter Catalogue de produits


- Acteur principal : Visiteur (qu’il soit déjà client)
- Objectifs : Visiteur/client veut trouver le plus rapidement possible un vêtement précis
dans l’ensemble du catalogue.
- Préconditions
1. Le catalogue de vêtement est disponible
- Post-conditions
1. Le visiteur a trouvé le vêtement précis qu’il cherchait, voire plusieurs.
- Scénario nominal
Acteur Système

2. Le Système affiche une page de résultat.


1. Le Client lance une recherche rapide à Les vêtements sont classés par défaut par
partir de mots-clés prix, catégorie
4. Le Système lui présente une fiche
3. Le visiteur sélectionne un article. détaillée pour plusieurs articles
sélectionné. On y trouvera en particulier
:
 une image du vêtement ou des
chaussures
 nom de l’article, nombre de pièce,
 le prix par catégorie et disponibilité
ainsi que le temps de livraison

ALTERNATIVES

1a Le visiteur n’a pas d’idée préconçue et préfère flâner dans le catalogue virtuel. Pour
cela, le Système lui propose un ensemble de pages telles que : CHEMISE, T-SHIRT,
2a Le Système n’a pas trouvé produit correspondant à la recherche.

1. Le Système signale l’échec au visiteur et lui propose d’effectuer une nouvelle


recherche. Le cas d’utilisation redémarre à l’étape 1 du scénario nominal.
c) Passer Commande
- Acteur principal : Le Client.

xii
- Objectifs : À tout moment, le client doit pouvoir accéder au formulaire de commande,
dans lequel il peut saisir ses coordonnées et les informations nécessaires au paiement et
recevoir ses articles commandées où qu’il soit.
- Préconditions : Au moins un vêtement a été sélectionné il s’est identifié.
- Post-conditions
• Une Commande a été enregistrée et transmise au Service commercial de DEV MODE.
• Une transaction cryptée a été réalisée avec le système externe de Paiement sécurisé et
sauvegardée qui peut être Mpesa, Airtel Money ou un paiement en espèce.

- Scénario nominal
Acteur Système

1 Le Client saisit l’ensemble des 2 Le Système affiche un récapitulatif des


informations nécessaires à savoir : informations indiquées et du sa commande à
confirmer.
– les coordonnées (nom, prénom,
adresse complète, téléphone, email),

– les coordonnées du vêtement


choisis.

3 Le Client sélectionne le paiement par 4 Le Système envoie les informations


MEPSA, Airtel Money ou autre et confirme cryptées au système externe de Paiement
sa commande de vêtement. sécurisé.

5 Le Paiement sécurisé autorise la


transaction ou le client verse le cash.

6 Le Système confirme la prise de


commande de vêtement au client en
indiquant (la référence de sa commande du
jour).

7 Le Système envoie la commande validée à


l’administrateur et au Livreur pour préparer
la livraison

xiii
8 Le Système enregistre la commande.

- Alternatives
1-3aLe Client annule sa commande.

1. Le Système revient sur l’affichage de la sélection de vêtement et le cas d’utilisation se


termine en échec.
1 Le Client choisit un paiement différé (chèque, espèce.).
1. Le Système confirme la prise de la commande au client
2. Le Système enregistre la commande dans un état « non finalisée ».
4a Le Système détecte que les informations sur le paiement sont incomplètes ou erronées.
1. Le Système demande au client de modifier ou compléter les informations sur le mode de
paiement.
2. Le cas d’utilisation reprend à l’étape 3 du scénario nominal.
5a Le Paiement sécurisé n’autorise pas la transaction ou ne répond pas.
1. Le Système indique au Client que le mode de paiement choisi a échoué et propose de
choisir un autre type de paiement.

1. 2. Le cas d’utilisation reprend à l’étape 3 du scénario nominal.

d) Traiter commande
- Acteur principal : Service commercial.
- Objectifs : permettre à l’administrateur d’administrer les commandes de clients en ligne
et ordonner la livraison si possible.
- Préconditions
1. L’administrateur est authentifié.
- Post-conditions
 Une commande traitée.
 Un plan de livraison établie

- Scénario nominal
Acteur Système

xiv
2. Afficher liste de commande en attente
1. Traiter commande
4. Etat paiement affiché
3. Sélection commande
6. Ordre de livraison enregistré et
5. Saisir plan de livraison transmis au Livreur
8. Enregistrer commande
7. Archiver livraison

- Alternatives
3a Paiement non effectué.

1. Le Système affiche un message d’erreur à l’administrateur


5a stock non disponible.

e) Créer un compte
- Acteur : visiteur
- Objectif : visiteur veut s’enregistrer afin d’avoir accès à l’espace de commande des
articles en ligne.
- Précondition : la sélection des vêtements déjà effectué
- Post-condition : un compte crée et un nouveau client ajouté
- Scénarios
1. Le visiteur renseigne les informations nécessaires (nom, login, mot de passe, email de
confirmation du compte, téléphone, adresse)
2. Le système vérifie les informations saisies et affiche un récapitulatifs au visiteur et
envoi un email de confirmation
3. Le visiteur valide la création du compte

f) Cas d’utilisation s’authentifier

- Acteur : utilisateur (Client, Administration, Livreur)


- Objectifs : l’utilisateur veut avoir accès au système de manière sécurisée pour ne
voir que ses commandes et ses comptes
- Préconditions : le système MODE SOFT est lancé
- Post-condition : une session utilisateur créée
- Scénarios
1. L’Utilisateur demande au système d’accéder à l’espace Client
2. Le système affiche la page d’authentification
3. Il remplit les coordonnées d’authentification
4. Le système vérifie les coordonnées saisi
- Alternatifs

xv
4a. Echec d’authentification : un message d’erreur est affiché à l’utilisateur pour
réessayer

1.11.1

1.11.2 3.1.4. Modélisation des interactions : Diagramme de séquences

UML propose deux diagrammes pour répondre à ce besoin de représentation des interactions
entre objets ou en l’acteur et le système à savoir Le diagramme de séquence se focalise sur les
aspects temporels et le diagramme de communication se focalise sur la représentation spatiale[13].
Pour notre cas, seuls les diagrammes de séquences seront utilisés pour illustrer le dynamisme du
système.

xvi
a) Diagramme de séquences système de création compte client
1.11.3 Suivant la description textuelle du cas d’utilisation « créer compte
client, l’acteur client interagit avec le système :

sd CREER COMPTE

System

VISITEUR
creeCompteClient()

formulaire inscription()

coordonnesCompte(login, mp, nom, email)

verification()

alt erreur saisie()

[echec]
recaputilatif compre()
[succé]
creerCompte()

sauvegarde()
email de confirmation()

Figure 18—Diagramme de séquences système du cas ‘utilisation « Créer compte client »

b) Diagramme de séquences système d’authentification


Pour accéder au système, chaque utilisateur doit prouver son identité en tapant son nom et le mot
de passe. Si l’une de données rentrée n’est pas correcte, le système rejette la demande de connexion
au système.

xvii
sd S'authentifier

SYSTEM

utiliateur

1: seConnecter()

2: cadre d'authentification affichee()

loop 3: LoginMotDePasse()

alt
break
[IF]
verification()
connexion etablie()

[ELSE]

connexion échouée()

Figure 19—Diagramme de séquences système du cas ‘utilisation « s’authentifier »

c) Diagramme de séquences système du cas d’utilisation « Mettre à jour le catalogue »


La description de scenario du cas d’utilisation Mettre à jour catalogue produit prévoit un acteur
Administrateur, le système et le client ou le visiteur qui est informé de la modification quelconque
de la structure de prix.

xviii
Figure 20—Diagramme de séquences système du cas d’utilisation « Mettre à jour le catalogue

d) Diagramme de séquences du cas d’utilisation « Consulter catalogue produit »


Selon la description textuelle du cas d’utilisation « Consulter le catalogue des article » nous
donnons ci-dessous un diagramme de séquences décrivant les échanges entre l’acteur visiteur et
le Système MODE SOFT lors d’une recherche d’un article dans le catalogue en ligne comme le
montre la Fig.3.5 suivante.

xix
Figure 21—Diagramme de séquences du cas d’utilisation « Consulter catalogue article »

e) Cas d’utilisation « Passer commande »


Selon la description textuelle du cas d’utilisation « Passer commande » nous donnons ci-
dessous un diagramme de séquences décrivant les échanges entre l’acteur Client et le Système
lors d’une commande d’un ou plusieurs articles en ligne après une recherche dans le catalogue
comme le montre la Figure suivante.

xx
Figure 22—Diagramme de séquences du cas d’utilisation « Passer commande »

3.2. Réalisation de cas d’utilisation : Diagramme de classes Participantes

Il s’agit de diagrammes de classes UML qui décrivent, cas d’utilisation par cas d’utilisation,
les trois principales classes d’analyse et leurs relations. Nous distinguerons ensuite trois types de
classes d’analyse :

- les « dialogues » qui représentent les moyens d’interaction avec le système,


- les « contrôles » qui contiennent la logique applicative et
- les « entités » qui sont les objets métier manipulés.
xxi
3.2.1. Diagramme de classes participantes du cas d’utilisation « Mettre à jour
catalogue vêtement» l’administrateur
Veut ajouter un nouvel article dans le catalogue disponible en ligne le plus rapidement
possible. Ces classes sont tirées de la description textuelle du cas d’utilisation « Mettre à jour
catalogue vêtement »

class BPEL Model

"entity"
Catalogue
Administrateur - date: Date
- nuero:: int
- version: int

"entity'' Article
''dialog'' MiseAjourCatalogue
- designation: Sting
- -designation: Sting - imageArticle: Sting
- -ref: String "control" GestionCatalogue - marque: String
- dateCatalogue: Date - prixUnit: float
- detail: String + ajouterNouvelAticle(): void
+ supprimerArticle(): void - ref: int
- image article: Strig - taille: float
- marque: float + validerCatalogue(): void
- prixUnit: float + vediterPrixArticle(): void
- taille: float
- versionCatalogue: int ''entity" "entity" ''entity"
+ ajouterNouvelArticle(): void Chaussure Vetement accessoire
+ editerArticle(): void
- taille: int - taille: int - taille: int
+ supprimerArticle(): void
+ validerCatalogue(): void

Figure 23—diagramme de classes participantes du cas d'utilisation Mettre à jour catalogue

3.2.2. Diagramme de classes participantes du cas d’utilisation « Consulter


catalogue Article »
Le visiteur veut trouver le plus rapidement possible un ou plusieurs articles selon son vœu.
Il veut également pouvoir consulter la fiche détaillée d’un article particulier avant de le de le
commander comme illustré dans la figure suivante :

xxii
class BPEL Model

Catalogue
vetement
- article
- rechercher - desciption
- nom
- prix

Utilisateur
- adresse
- consulter
- nom

Figure 24Fig.3. 8—Diagramme de classes participantes du cas d'utilisation « Consulter catalogue vêtement »

3.2.3. Diagramme de classes participantes du cas d’utilisation « Passer


commande »
Le client veut commander un ou plusieurs articles de vêtements après avoir choisi ce dernier
dans le catalogue. Sur ce, l’acteur Client est relié à l’interface graphique laquelle est reliée au
contrôle qui traite et transmet les données aux entités (commande, article, ligne, client) comme
illustré dans le Figure suivante.

xxiii
class BPEL Model

client Commande
- date: Date Article
- adresse: String
- email: String - numero: int - nom: String
- nom: String - total: float - prix: float
- quantite: int
- reference: String

ligne de Catalogue
Mode de
commande
paiement - article: liste
- date: Date
- numero: int
- numero: int
- type: String
- total: float

Figure 25—Diagramme de classes participantes du cas d'utilisation « Passer commande »

3.2.4. Diagramme de classes participantes du cas d’utilisation «Consulter horaire


livraison »
Le client veut savoir si le véhicule de livraison passera dans son avenu ou connaitre le
programme de livraison de sa commande payée en ligne. Sur ce, l’acteur Client est relié à
l’interface graphique laquelle est reliée au contrôle qui traite et transmet les données aux entités
(plan de livraison) comme illustré dans le Figure suivante.

xxiv
class BPEL Model

Utilisateur
- adresse commande
- consulter - article
- nom - passerCommande()
- suivreLivraison: int - suivreLivaison
- total

Livraison
Catalogue
- dateEstimee
- article
- etat
- rechercher()

Vetement
- description
- nom
- prix

Figure 26—Diagramme de classes participantes du cas d'utilisation « Consulter plan de livraison»

3.2.5. Diagramme de classes participantes du cas d’utilisation «Gérer plan de


livraison »
Le Service commercial veut savoir s’ils existent de commandes en attente de livraison afin
d’expédier les produits au client comme illustré dans le Figure suivante.

xxv
class BPEL Model

Utilisateur
Commande
- adresse
- gererLivraison() - article
- nom - gererLivraison
- livraison
- total

Livaison Catalogue
- dateEstimee - article
- dateReelle - rechercher()
- etat

Vetement

- description
- nom
- prix

Figure 27—Diagramme de classes participantes du cas d'utilisation « Gérer plan de livraison

3.2.6. Diagramme de classes participantes du cas d’utilisation «S’authentifier»


L’utilisateur veut accéder au système, pour cela il est devant un écran d’authentification où
il renseigne ses coordonnés d’authentification ; l’écran à son tour transmet les données au
contrôleur qui lui est en contant avec la table compte comme illustré dans le Figure suivante.

xxvi
Figure 28—Diagramme de classes participantes du cas d'utilisation « S’authentifier»

3.2.7. Diagramme de classes participantes du cas d’utilisation «Créer compte


client»
L’utilisateur veut accéder au système de commande, doit avoir un compte, pour cela il est
devant un écran de création de compte où il choisit ses coordonnés d’authentification ; l’écran à
son tour transmet les données au contrôleur qui lui est en contant avec la table compte comme
illustré dans le Figure suivante.

Figure 29—Diagramme de classes participantes du cas d'utilisation « Créer compte client»

xxvii
3.2.8. Diagramme d’Etats-transitions
Un objet passe par une succession d’états durant son existence. Un état a une durée finie,
variable selon la vie de l’objet, en particulier en fonction des événements qui lui arrivent. Un état
représente une situation durant la vie d’un objet pendant laquelle :

• il satisfait une certaine condition,

• il exécute une certaine activité,

• ou bien il attend un certain événement.

3.3. Conception détaillées de l’architecture MODE SOFT

Nous allons à présent détailler suffisamment les éléments de modèles précédents afin d’être
en mesure d’obtenir toutes les spécifications techniques nécessaires à la réalisation, incluant les
contraintes technologiques. Nous construirons l’aspect dynamique avec de diagrammes de
séquences détaillées contenant les objets techniques ; également une vue statique complétée sous
forme de diagrammes de classes de conception détaillées, intégrant des spécifications
technologiques.

a) Opération système « rechercheArticle»

Cette opération a pour objectif de retrouver un Article rapidement à partir du nom ou d’un
autre mot-clé.
Ce diagramme met en interaction les objets suivants :

- Un acteur Internaute qui sera devant l’écran de consultation

- Un écran de consultation

- Un contrôleur de consultation qui s’occupe de validation des actions de


l’utilisateur et de l’affichage du résultat

- Une entité catalogue sur laquelle s’effectuera la recherche

- Une collection d’article contenu dans une collection.

xxviii
sd diagrame op

Client
EcranRecherche CtrlCatalogue Categorie produit
HasMap<long_Categorie> HashMap<long_Articlet>
loop

rechercheParId(id): article

produitParId(id); Article

fin(id): article

init(myCate): Categorie

neant()

alt
[[echec]]
neant()

create()

EurreurResultat

[[succé]]
detail()

DetailRecherche()

DetailRecherche

opt mettreDansPanier()

Figure 30—Diagramme de séquence détaillée de l'opération « recherche Article vestimentaire

b) Opération système « recherche avancée des articles»


Cette opération a pour objectif de retrouver un article rapidement à partir de plusieurs
paramètres (prix, taille, type de vêtement,…)
Ce diagramme met en interaction les objets suivants :

- Un acteur Internaute / client qui sera devant l’écran de consultation

- Un écran de consultation

- Un contrôleur de consultation qui s’occupe de validation des actions de


l’utilisateur et de l’affichage du résultat
xxix
- Une entité catalogue sur laquelle s’effectuera la recherche

- Une collection d’article.

- Une instance de la classe panier qui sera créée en cours de scénario

sd BPEL Model

''dialogue" ''Control'' "entity" "entity" A:


EcranConsultation GestionCatalogueArticle Catalogue List'Article'
internaute

loop
[nbre article]
consulterAvancee(libelle,taille,model)

rechercheAvancee(libelle,taille,model

rechercheAvancee(P)

trouver()

resultat()

resultats()

"dialogue"
create()
ResultatRecherche

opt
[condition]
selectionerArticle()

selectionArticle()

"entity" Panier
create()

ajouter(article)

Fig.3. 1—diagramme de séquences détaillées de l’opération système « recherche avancée »

Figure 31—diagramme de séquences détaillées de l’opération système « recherche avancée »

c) Opération système « afficher détails Article»

Cette opération a pour objectif d’afficher les détails d’un Article afin de faire le choix par
apport au vœu du client.

xxx
Ce diagramme met en interaction les objets suivants :

- Un acteur Internaute qui sera devant l’écran de consultation

- Un écran de consultation

- Un contrôleur de consultation qui s’occupe de validation des actions de


l’utilisateur et de l’affichage du résultat

- Une entité catalogue sur laquelle s’effectuera la recherche

- Une collection d’article.

sd BPEL Model

<<dialogue>> <<contro>> <<entity>> <<entity>> a: <<entity>>


EcranConsultation GestionCatalogueArticle Catalogue List<Article> Article
internaute

loop
[nbr article]
voirDetailsArticle(a)

afficheDetail(ref)

getinfoArticle(ref)

trouver()

resultat()

getdetail()

details()

rsultats()
opt
<<dialogue>>
[condition] create()
ResultatRecherche

Figure 32diagramme de séquences détaillées de l’opération système « afficher détails Article »

xxxi
d) Opération système « valider commande »
Cette opération a pour objectif de commander un panier contenant des articles préalablement
sélectionné.
Ce diagramme met en interaction les objets suivants :

- Un acteur Client qui sera devant l’écran de commande

- Un écran de commande

- Un contrôleur de consultation qui s’occupe de validation des actions de


l’utilisateur et de la transmission de données aux entités concernées

- Une entité Collection contenant les Articles à commander

- Une collection de commandes existantes.

- Un objet système de paiement Mobile (MpSA ou Airtel Monney)

xxxii
sd BPEL Model

<<dialogue>> <<control>> <<entity>>:Panier <<entity>> p: <<entity>> Si-


EcranCommande GestionCommande List<Commande> Paiement
Client

saisieCommande(n°,date,adresse)

commande(n°,date,article)

getinfoVetement(ref)

add(c,panier)

afficher()

afficher()

afficher()

attentePaiement()

confirmerCommande(paiement)

infosPaiement()

infosPaiement()

alt Autorisé()

[Autorisé]
afficher()

paiement confirmé et livraison encours()

[Refusé] paiement refusé()

afficher()

<<dialogue>>
create()
Execption

Figure 33—diagramme de séquences détaillées de l’opération système « valider commande »

e) Opération système « créer un nouvel Article»


Cette opération a pour objectif d’ajouter un article dans le catalogue afin de publier le
catalogue en ligne.
Ce diagramme met en interaction les objets suivants :

- Un acteur Administrateur

- Un écran d’ajout de catalogue


xxxiii
- Un contrôleur catalogue

- Une entité catalogue sur laquelle sera ajouter les articles

- Une instance de la classe Article qui sera créée en cours de scénario

- Une collection d’article.


sd BPEL Model

<<dialogue>> <<control>> <<entity>> <<entity>> Ip:


EcnanCatalogue GestionCatalogue catalogue List<Article>
Administrateur

ref
S'authentifier

creeArticle(ref,prix,details,photo

editerArticle(ref,prix,detail,photo)

<<entity>> a:
create()
Artcle

ajouter(a)
ajouter
(a)

afficher()

Article crée aveccé()

Fig.3. 2—diagramme de séquences détaillées de l’opération système « créer un Article »

f) Opération système « modifier un nouvel Article »


Cette opération a pour objectif d’éditer un article dans le catalogue afin de publier le
catalogue en ligne.
Ce diagramme met en interaction les objets suivants :

- Un acteur Administrateur

- Un écran d’ajout de catalogue

- Un contrôleur catalogue

- Une entité catalogue sur laquelle sera ajouter les articles

- Une instance de la classe Article sui sera créée en cours de scénario

xxxiv
- Une collection d’article.

sd BPEL Model

<<dialogue>> <<control>> <<Entity>> <<Entity>> a: <<Entity>> Ip:


EcranCatalogue GestionCatalogue catalogue Article List<Article>
Administrateur

ref
S'authentifier

rechercheMenu(ref)

getArticle(ref)

getArticle(ref)

find(ref)

article()

article()

afficher()

details article affiché()

editerArticle(ref,prix,details,photo
editerArticle(ref,prix,detail,photo)

update()

remplace(a)

editer(a)

afficher()

article modifé avec succé()

Fig.3. 3—diagramme de séquences détaillées de l’opération système « éditer un article »

Figure 34—diagramme de séquences détaillées de l’opération système « éditer un article »

3.3.1. Diagramme de classes de conception


La phase de conception a pour objectif de préciser les interfaces de chaque classe afin de
passer l’implémentation. Considérant le modèle d’analyse, nous allons affiner et compléter les
diagrammes de classes participantes obtenus précédemment. Pour cela nous utiliserons les
diagrammes de séquence que nous venons de réaliser pour :

 Ajouter ou préciser les opérations dans les classes (un message ne peut être reçu par un
objet que si sa classe a déclaré l’opération publique correspondante).

xxxv
 Ajouter des types aux attributs et aux paramètres et retours des opérations.
 Affiner les relations entre classes : associations (avec indication de navigabilité),
généralisations ou dépendances.

class BPEL Model

Adresse
Paiement PlanLivraison
- commune: String
- mode: String - chauffeur: String
- nomAvenue: String
- montant: double - date: Date
- numRue: String
- motif: int - heure: Time
- quartier: String
- numero: int - numero: int
- reference: String
- plaque: String
+ ajouter(): void
+ modifier(): void + annuler(): boolean
+ modifier(): boolean
+ Planifier(): boolean
Client
- email: String Article
Commande
- nom: String
- prenom: String - /total: int - nom: String
- reference: String - date: Date - prixUnit: float
- telephone: String - modepaiement: String - ref: String
- numero: int - Taille: int
+ afficher(): Client - uniteVente: String
+ nouveau(): Client + annuler(): boolean
+ calculer(): float + afficher(): Article
+ confirmer(): boolean + Creer(): Article
+ Creer(): Commande + editer(): Article Categorie
+ supprimer(): boolean
Facture - detail: String
- idCat: String
- date: Date - nom: String
- montant: double LigneCommande
- numero: int + ajouter()(): int
- id: int Catalogue
+ creer(): void - qte: int
- total: float - id: Date
- unite: String - periode: int
+ ajouter(): LigneCommande + cree(): void
+ editer(): boolean + editer(): boolean
+ enlever(): boolean + supprimer(): boolean

Figure 35—Diagramme de classes de conception détaillée

3.3.2. Dérivation du Logique de données

Un Modèle Physique de Données (MLD) nous aide à analyser les tables, les vues et autres
objets d'une base de données, y compris les objets multidimensionnels nécessaires à l'utilisation
d'un entrepôt de données.
Pour obtenir un modèle logique de données à partir d’un modèle de classes, les principes
suivants sont à observer :

- Chaque classe devient une table dont les champs sont les attributs élémentaires de cette
classe
- Une relation d’héritage est soit transformée en une table (push-up), soit push down.

xxxvi
- Une classe associative devient un table dont la clé primaire est la concaténation des
identifiants des entités participants à la relation ;
- Une relation d’agrégation impose une clé étrangère à chaque agrégat ;
- Une association de direction avec multiplicité (1..1, 1..*) impose une contrainte d’intégrité
référentielle à l’entité à coté de laquelle la multiplicité est 1..1.
Ainsi le modèle physique obtenu par génération dans Power AMC est le suivant :

Figure 36—modèle logique de données

3.3.3. Diagramme de composants du système MODE SOFT


Les diagrammes de composants UML font partie intégrante de la conception d’un système
logiciel. Réalisés à l'aide d'un logiciel de diagrammes UML, ils permettent une appréhension de la
structure des éléments du système existant et d'en concevoir de nouveaux.

21
Serveur Web
Navigateur GestionClient
80

http
Port_1
80

I_Commabde

GestionComma _
nde s GestionCatalogue
s

ICatalogue

TCP
3306

BaseDonnee

Fig.3. 4—Diagramme de composants du système MODE SOFT

Figure 37—Diagramme de composants du système MODE SOFT

xxxvii
CONCLUSION PARTIELLE

Ce chapitre avait pour objectif de concevoir l’architecture détaillée de l’application MODE


SOFT. Sur ce, nous avons analysé et réalisé les cas d’utilisation au moyen des outils suivants : la
description textuelle, diagramme de classes participantes, les diagrammes de séquences systèmes
et les diagrammes de classes participantes ; pour spécifier d’avantage les détails d’implémentation,
nous avons construit de diagramme de séquences détaillées pour les opérations de système MODE
SOFT identifié précédemment, le diagramme de classes de conception ainsi qu’un modèle de base
de données.

Le prochain chapitre se consacre à l’implémentation dans un langage de programmation les


classes obtenues dans ce chapitre ainsi que le test de modules.

xxxviii
RESULTAT DE LA RECHERCHE.

Introduction

Ce chapitre, a pour objectif de démontré les résultats de la recherche obtenue dans le


chapitre précédant dans langage de programmation afin de faire de tests de la solution de passation
de commandes en ligne. Pour cela, certains choix techniques sont inévitables.

Confirmation ou infirmation des hypothèses du travail

L'objectif de cette recherche était de confirmer ou d'infirmer les hypothèses


suivantes :

 L'analyse métier est un processus essentiel pour la conception d'une plateforme e-commerce
vestimentaire.
 La méthode UP est un processus efficace pour la conception d'une plateforme e-commerce
vestimentaire.

Les résultats de la recherche ont confirmé ces hypothèses. En effet, l'analyse métier permet de
comprendre les besoins des utilisateurs et des parties prenantes, ce qui est essentiel pour la
conception d'une plateforme qui répondra à ces besoins. La méthode UP, quant à elle, permet de
développer une plateforme de manière itérative et incrémentale, ce qui permet de réduire les
risques et de garantir la qualité du produit final.

Validité des recherches

Les recherches menées sont valides car elles sont basées sur une analyse approfondie de la
littérature et de l'expérience pratique. Les résultats sont également cohérents avec les résultats
d'autres études sur le sujet.

Conclusions finales

L'analyse métier et la conception par la méthode UP sont des processus essentiels pour le
développement d'une plateforme e-commerce vestimentaire. Ces processus permettent de
garantir que la plateforme répond aux besoins des utilisateurs et des parties prenantes et qu'elle
est bien conçue et développée.

Limites des résultats

Les résultats de cette recherche sont limités par le fait qu'ils sont basés sur une étude de cas. Il
serait nécessaire de mener des études plus approfondies pour confirmer ces résultats dans
d'autres contextes.

xxxix
Recommandations

Sur la base des résultats de cette recherche, les recommandations suivantes peuvent être
formulées :

 Les entreprises qui souhaitent développer une plateforme e-commerce vestimentaire devraient
accorder une attention particulière à l'analyse métier et à la conception.
 La méthode UP est une approche efficace pour la conception d'une plateforme e-commerce
vestimentaire.
 Les entreprises devraient tenir compte des limites des résultats de cette recherche lors de
l'application des recommandations.

Architecture de fonctionnement de la plate-forme MODE SOFT

Notre application fonctionne comme suit :

1. Le navigateur envoie l'adresse (http + URL) que tapée par l’utilisateur

2. Le serveur web (Apache) cherche dans son arborescence si le fichier existe, et si celui-ci
porte une extension reconnue comme une application PHP (.PHP, .PHP3, .PHP4 par
exemple). Si c'est le cas, le serveur web transmet ce fichier à PHP.

3. PHP parse le fichier, c'est-à-dire qu'il va analyser et exécuter le code PHP qui se trouve
entre les balises <?php et ?>. Si ce code contient des requêtes vers une base de données
MySQL, PHP envoie la requête SQL. La base de données renvoie les informations voulues
au script qui peut les exploiter (pour les afficher par exemple).

4. PHP continue de parser la page, puis retourne le fichier dépourvu du code PHP au serveur
web.

5. Le serveur web renvoie donc un fichier ne contenant plus de PHP, donc seulement du
HTML au navigateur qui l'interprète et l'affiche.

xl
Figure 38—architecture de composant de l'application

xli
CONCLUSION GENERALE

Après ces tournures de langages, nous voici à l’apogée de notre mémoire qui a consisté
sur « l’analyse métier et conception par la méthode up d’une plate-forme E-commerce dans
le domaine vestimentaire (cas de DEV MODE)» qui constitue de nos jours un domaine convoité
de l’ère du numérique. L’objectif de cette étude été de solutionner la problématique de commandes
conditionnées par les empêchements qui occasionnait les manque d’écoulement rapide de articles
de surcroit une perte de la clientèle.

Pour y arriver, la méthodologie UP (Unified Process) avec le langage UML (Unified


Modeling Language) ont été la cible de cette recherche pour la conception de note application
Web MODE SOFT dont la subdivision est la suivante : le premier chapitre nous avions abordé la
revue de littérature sur la conception Web et méthodologie; le second chapitre nous a permis de
faire l’analyse métier afin de comprendre l’existant en termes des activités, acteurs, informations
et règles de gestion sur la passation de commandes, le mode de paiement, la livraison au moyen
de diagrammes UML de cas d’utilisation, d’activité et de classes du domaines ; le troisième
chapitre été pour nous l’application de la méthode UP pour concevoir l’architecture de
l’application de commandes en ligne MODE SOFT ; enfin le quatrième chapitre nous avons donné
les résultat de la recherche de l’architecture logicielle de MODE SOFT afin d’avoir une application
Web permettant aux clients de s’en passer du déplacement.

Eu égard à la problématique de cette étude, nous confirmons que les hypothèses ont été
confirmées. Le prototype réalisé n’est qu’une première itération de l’application MODE SOFT, et
dispose les options suivantes : un module de recherche en ligne des articles, une option de sélection
des articles pour constituer sa commande; un module de commande en ligne incluant une
possibilité de payer par Mobil Money, ou en espèce afin d’entrer en possession de sa commande
dans un bref délai ; un module pour suivre en temps réel l’évolution de sa commande ; et un
module de gestion du catalogue. Désormais les clients de Dev Mode ne peuvent plus se déplacer
pour commander un vêtement car désormais un espace client est disponible en ligne pour effectuer
ses achats ou faire de réclamations.

Signalons que le domaine d’e-commerce restent complexe pour nous, sur ce, nous ouvrons
l’ébauche sur la livraison de la commande en temps réel par des drones comme perspectives pour
des recherches futurs.

xlii
BIBLIOGRAPHIE

[1] G. Y. Raphael, A. M. Ngaingai, J. I. Matumwabiri, et H. N. Mpia, « E-COMMERCE ET


SES CONSEQUENCES SUR L’ACTIVITE COMMERCIALE CLASSIQUE EN RDC: VERS
LES NOUVELLES FORMES DE VENTE VIRTUELLE », Int. J. Innov. Appl. Stud., vol. 27, no
2, p. 616‑631, 2019.

[2] M. Priestley, T. J. Sluckin, et T. Tiropanis, « Innovation on the web: the end of the S-
curve? », Internet Hist., vol. 4, no 4, p. 390‑412, oct. 2020, doi:
10.1080/24701475.2020.1747261.

[3] R. Umar, A. Yudhana, et M. N. Faiz, « Experimental analysis of web browser sessions


using live forensics method », Int J Electr Comput Eng, vol. 8, no 5, p. 2951‑2958, 2018.

[4] S. Agrawal et R. D. Gupta, « Web GIS and its architecture: a review », Arab. J. Geosci.,
vol. 10, no 23, p. 1‑13, 2017.

[5] N. Mérouze, « Architecture des applications web : quelles bonnes pratiques en 2020 ? »
https://www.synbioz.com/blog/architecture-applications-web (consulté le 9 juillet 2022).

[6] V. J. Harward et al., « The ilab shared architecture: A web services infrastructure to build
communities of internet accessible laboratories », Proc. IEEE, vol. 96, no 6, p. 931‑950, 2008.

[7] J. J. Garrett, « Ajax: A new approach to web applications », 2005.

[8] L. D. Paulson, « Building rich web applications with Ajax », Computer, vol. 38, no 10, p.
14‑17, 2005.

[9] M. A. Jadhav, B. R. Sawant, et A. Deshmukh, « Single page application using


angularjs », Int. J. Comput. Sci. Inf. Technol., vol. 6, no 3, p. 2876‑2879, 2015.

[10] M. Chinosi et A. Trombetta, « BPMN: An introduction to the standard », Comput. Stand.


Interfaces, vol. 34, no 1, p. 124‑134, 2012.

[11] B. Fyama et R. Nyami, « Une approche basée sur les réseaux Pétri pour la vérification et
la validation formelle des modèles de processus métier dans les entreprises congolaises », 2018.
xliii
[12] P. Roques, UML 2: Modéliser une application web. Editions Eyrolles, 2008.

[13] L. Debrauwer et F. Van Der Heyde, « UML 2.5 », Barc. Ed. ENI Obtenido Httpsbooks
Google Com Ecbooks, 2016.

xliv

Vous aimerez peut-être aussi