SlideShare une entreprise Scribd logo
M. Fakher Ben Ftima
Mme. Sana Hamdi
M. Ramzi Mahmoudi
M. Ayoub Maatallaoui
Conception et développement d'une marketplace basée sur l'architecture microservices
Conception et développement d'une marketplace basée sur l'architecture microservices
Remerciement
Nous aimerions commencer par remercier l'ensemble de l'équipe
pédagogique de l’ISIMM et les intervenants professionnels
responsables de la formation sciences de l’informatique, pour avoir
assuré la partie théorique de celle-ci.
Nous tenons à exprimer également notre profonde gratitude et nos
remerciements les plus sincères à :
Dr. Ramzi Mahmoudi
Vous avez été bien plus qu'un simple encadrant pédagogique. Vous
avez été un mentor attentionné, toujours prêt à écouter nos idées, à
nous encourager et à nous pousser à donner le meilleur de nous-
même. Vos retours constructifs et vos suggestions pertinentes ont
contribué à affiner nos réflexions et à améliorer la qualité de notre
travail.
Mr. Ayoub Maatallaoui
Pour votre encadrement et votre mentorat pendant cette période
de stage. Votre expérience et vos conseils nous ont aidés à grandir
professionnellement et à acquérir une compréhension approfondie
du monde du travail. Les compétences que nous avons développées
grâce à votre encadrement seront un atout précieux tout au long de
nos carrière.
Les membres du jury
Qui ont accepté d’évaluer ce projet de fin d’études en espérant
qu’ils trouvent dans ce rapport les qualités de clarté et de
motivations qu’ils attendent.
Dédicace
Au moment où s'achève ce travail, il me tient à cœur d'exprimer ma
gratitude envers :
Mes Très chères Parents
Que ce travail soit l'expression profonde de ma reconnaissance envers
vous pour les sacrifices que vous avez consentis et le soutien moral et
matériel que vous n'avez cessé de prodiguer. Que Dieu vous préserve
en bonne santé et vous accorde une longue vie.
Mes chères sœurs.
Pour votre soutien tout au long de mes études, je tiens à exprimer ma
reconnaissance infinie. Vous avez été présentes à chaque étape de ma
vie académique, et grâce à vous, je suis devenu la personne que je suis
aujourd'hui.
Adem Amen Allah Thabti
Dédicace
Je dédie ce travail :
À mes parents, pour tous les sacrifices qu’ils ont fait et pour
tout le soutien qu’ils ont divulgué tout au long de mes études.
J’espère qu’ils puissent trouver dans ce modeste
travail un témoignage d’amour et d’affection envers eux.
À chaque membre de ma famille pour leurs encouragements et
leur continuel soutien...
Pour n’en oublier aucun, à tous mes amis, qui ont été toujours
présents...
À tous ceux qui m’ont aidé afin de réaliser ce travail.
À tous ceux que j’aime et qui m’aiment.
Merci !
Mohamed Yassine Essid
Table des matières
Introduction générale 1
1 Contexte et Objectifs 2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Contexte générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Présentation de l’entreprise d’accueil . . . . . . . . . . . . . . . . 3
1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Méthodologie de développement et modélisation . . . . . . . . . . . . . . 9
1.5.1 Étude de Méthodologie de développement . . . . . . . . . . . . . 10
1.5.2 Choix de la méthodologie de travail . . . . . . . . . . . . . . . . 12
1.6 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Capture des besoins 15
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
i
2.4 Besoins techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.1 Etude technologique . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.2 Etude architecturale . . . . . . . . . . . . . . . . . . . . . . . . . 25
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3 Conception 32
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Conception générique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Urbanisation fonctionnelle en microservices . . . . . . . . . . . . . . . . 36
3.3 Microservice de « Gestion des utilisateurs » . . . . . . . . . . . . . . . . . 37
3.3.1 Diagramme de Cas d’utilisation associé au microservice « Gestion
des utilisateurs » . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2 Description détaillée des cas d’utilisation associés au microservice
« Gestion des utilisateurs » . . . . . . . . . . . . . . . . . . . . . . 38
3.3.3 Diagramme de séquence « S’authentifier » . . . . . . . . . . . . . 39
3.3.4 Description textuelle du cas d’utilisation « S’authentifier » . . . . 40
3.3.5 Diagramme de séquence « Modifier coordonnées » . . . . . . . . . 41
3.3.6 Description textuelle de cas d’utilisation « Modifier coordonnées » 42
3.3.7 Diagramme de séquence « Consulter les réclamations » . . . . . . 42
3.3.8 Description textuelle de cas d’utilisation « Consulter les réclama-
tions » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.9 Diagramme de composant « Gestion des utilisateurs » . . . . . . 44
3.3.10 L’architecture logicielle de Microservice « Gestion des utilisateurs » 45
3.4 Microservice de « Gestion des produits » . . . . . . . . . . . . . . . . . . 45
3.4.1 Diagramme de Cas d’utilisation associés au microservice « Gestion
des Produits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.2 Description détaillée des cas d’utilisations associé au microservices
« Gestion des Produits » . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.3 Diagramme de séquence « Ajouter produit » . . . . . . . . . . . . 48
3.4.4 Description textuelle du cas d’utilisation « Ajouter un produit » . 48
ii
3.4.5 Diagramme de séquence « Evaluer produit » . . . . . . . . . . . . 49
3.4.6 Description textuelle du cas d’utilisation « Evaluer produit » . . . 50
3.4.7 Diagramme de composant associé au microservice « Gestion des
produits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.8 L’architecture logicielle de microservice « Gestion des produits » 52
3.5 Microservice de « Gestion des commandes » . . . . . . . . . . . . . . . . 53
3.5.1 Diagramme de cas d’utilisation associé au microservice « Gestion
des commandes » . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.5.2 Description détaillée des cas d’utilisation associé au microservice
« Gestion des commandes » . . . . . . . . . . . . . . . . . . . . . 54
3.5.3 Diagramme de séquence « Passer une commande » . . . . . . . . . 54
3.5.4 Description textuelle du cas d’utilisation « Passer une commande » 56
3.5.5 Diagramme de composant associé au microservice « Gestion des
produits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5.6 L’architecture logicielle de microservice « Gestion des commandes » 58
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4 Réalisation 59
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . 59
4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Présentation de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.1 Présentation de la solution web . . . . . . . . . . . . . . . . . . . 62
4.2.2 Présentation de la solution Mobile . . . . . . . . . . . . . . . . . . 66
4.2.3 Realisation des microservices . . . . . . . . . . . . . . . . . . . . . 71
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
iii
Table des figures
1.1 Veredent Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 DentalPlanet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Jumia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 eBay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Pictogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 2TUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 Diagramme de gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Les bases de données relationnelles les plus populaires . . . . . . . . . . . 24
2.2 Les bases de données non relationnelles les plus populaires . . . . . . . . 25
2.3 Architecture Monolithique . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Domain-Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5 Architecture Microservice . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6 Architecture API Gateway Pattern . . . . . . . . . . . . . . . . . . . . . 30
2.7 Choix technologique de notre application . . . . . . . . . . . . . . . . . 31
3.1 Maquette préliminaire de l’interface login . . . . . . . . . . . . . . . . . . 33
3.2 Maquette préliminaire de l’interface d’accueil . . . . . . . . . . . . . . . . 34
3.3 Maquette préliminaire de l’interface dashboard de l’admin . . . . . . . . 34
3.4 Diagramme de classe globale . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Diagramme de classe orienté microservices . . . . . . . . . . . . . . . . . 37
3.6 Diagramme de cas d’utilisation associé au microservice « Gestion des uti-
lisateurs » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
iv
3.7 Les cas d’utilisation associés au microservice « Gestion des utilisateurs » 39
3.8 Diagramme de séquence« S’authentifier » . . . . . . . . . . . . . . . . . . 40
3.9 Diagramme de séquence « Modifier coordonnées » . . . . . . . . . . . . . 41
3.10 Diagramme de séquence« Consulter les réclamations » . . . . . . . . . . . 43
3.11 Diagramme de composant « Gestion des utilisateurs » . . . . . . . . . . 44
3.12 Architecture logicielle de microservice « Gestion des utilisateurs » . . . . 45
3.13 Diagramme de cas d’utilisation associés au microservice « Gestion des pro-
duits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.14 Diagramme de séquence « Ajouter un produit » . . . . . . . . . . . . . . 48
3.15 Diagramme de séquence « Evaluer produit » . . . . . . . . . . . . . . . . 50
3.16 Diagramme de composant associé au microservice « Gestion des produits » 52
3.17 Architecture logicielle de microservice « Gestion des produits » . . . . . 53
3.18 Diagramme de cas d’utilisation associé au Microservice « Gestion des com-
mendes » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.19 Diagramme de sequence « Passer une commande » . . . . . . . . . . . . . 55
3.20 Diagramme de composant associé au microservice « Gestion des commandes » 57
3.21 Architecture logicielle de microservice « Gestion des produits » . . . . . 58
4.1 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4 Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5 Swagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.6 Nginx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.7 LYX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.8 LucidChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.9 RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.10 Interface d’acceuil Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.11 Interface d’acceuil Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.12 Interface SignIn Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
v
4.13 Interface Login Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.14 Interface vendeur-dashboard . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.15 Interface authentification application mobile. . . . . . . . . . . . . . . . . 67
4.16 Authentification cas d’erreur . . . . . . . . . . . . . . . . . . . . . . . . 68
4.17 Interface d’accueil application mobile . . . . . . . . . . . . . . . . . . . . 68
4.18 Interface catégorie application mobile . . . . . . . . . . . . . . . . . . . . 69
4.19 Interface produit application mobile . . . . . . . . . . . . . . . . . . . . . 70
4.20 Interface evaluer produit application mobile . . . . . . . . . . . . . . . . 71
4.21 Les images docker des microservices . . . . . . . . . . . . . . . . . . . . 71
4.22 Swagger Figure 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.23 Swagger Figure2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.24 Communication synchrone avec RabbitMq . . . . . . . . . . . . . . . . . 75
4.25 Liste des queues RabbitMq . . . . . . . . . . . . . . . . . . . . . . . . . . 75
vi
Liste des tableaux
1.1 Points forts et points faibles de DentalPlanet . . . . . . . . . . . . . . . 5
1.2 Point fort et point faible de Jumia . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Points forts et points faibles de eBay . . . . . . . . . . . . . . . . . . . . 7
1.4 Tableau compartif des solutions existantes . . . . . . . . . . . . . . . . . 8
1.5 Tableau comparatif des méthodologies de développement . . . . . . . . . 12
2.1 Besoins non fonctionelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 Point forts et points faibles de React js . . . . . . . . . . . . . . . . . . . 19
2.3 Points forts et points faibles de Angular . . . . . . . . . . . . . . . . . . 20
2.4 Tableau comparatif entre les différents technologies Front-End Web . . . 20
2.5 Points forts et points faibles de React native . . . . . . . . . . . . . . . . 21
2.6 Points forts et points faibles de Flutter . . . . . . . . . . . . . . . . . . . 21
2.7 Tableau comparatif entre les différents technologies Front-End Mobile . . 21
2.8 Points forts et points faibles Spring Boot . . . . . . . . . . . . . . . . . . 22
2.9 Points forts et points faibles de NestJs . . . . . . . . . . . . . . . . . . . 23
2.10 Avantages et inconvénients des bases de données relationnels . . . . . . . 23
2.11 Avantages et inconvénients des bases de données non relationnels . . . . . 24
3.1 Description textuelle du cas d’utilisation « S’authentifier » . . . . . . . . 41
3.2 Description textuelle du cas d’utilisation « Modifier cordonnées » . . . . . 42
3.3 Description textuelle du cas d’utilisation« Consulter les réclamations » . 43
3.4 Les cas d’utilisation associés au microservice « Gestion des produits » . . 47
3.5 Description textuelle du cas d’utilisation « Ajouter Produit » . . . . . . . 49
vii
3.6 Description textuelle du cas d’utilisation « Evaluer produit » . . . . . . . 51
3.7 Tablau des cas d’utilisation associés au microservice « Gestion des com-
mendes » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.8 Description scénariste du cas d’utilisation « Passer une commande » . . . 56
viii
Liste des symboles
2TUP Two tracks unified process
ACID Atomicity Consistency Isolation Durability
AMQP Advanced Message Queuing Protocol
API Application programming interface
DDD Domain-Driven Design
JSON JavaScript Object Notation
REST REpresentational State Transfer
1
LISTE DES SYMBOLES
Introduction générale
L’informatique joue un rôle de plus en plus important dans l’évolution de notre
marché au cours des dernières décennies. Les technologies informatiques ont permis de
nombreuses innovations, notamment dans le domaine de la communication, de l’automa-
tisation des processus, de la gestion des données et de la connectivité entre les personnes
et les organisations.
Au vu de ce constat et de cette croissance, on ne peut pas négliger le passage des
priorités des opérations de vente de main en main vers des ventes virtuelles ce qui nous
oblige à donner plus d’importance à la vente électronique. Ce sont les boutiques élec-
troniques qui accélèrent et facilitent les traitements traditionnels tels que les processus
de commande et de facturation en offrant un accès facile et rapide aux produits. Le défi
est alors de faire des internautes d’aujourd’hui nos futurs clients à travers une inter-
face agréable et une plate-forme performante qui répondent aux besoins du client et lui
facilitent la procédure d’achat des biens et des services.
Les marketplaces jouent un rôle de plus en plus important dans le marché actuel en
permettant aux entreprises de vendre leurs produits et services en ligne via une plate-
forme unique. Elles ont créé un nouvel écosystème commercial, qui offre aux vendeurs
une audience plus large et aux acheteurs une expérience d’achat plus pratique et plus
complète. Les marketplaces offrent une variété de fonctionnalités telles que la gestion de
stocks, la gestion des commandes et des paiements, ainsi que des outils de marketing, de
communication et de service client. Elles permettent aux petites et moyennes entreprises
de concurrencer les grands acteurs du marché en proposant leurs produits à un public
plus large, sans avoir à investir dans des infrastructures coûteuses
1
Chapitre 1
Contexte et Objectifs
Introduction :
Dans ce chapitre, nous présentons le contexte général de notre projet. Nous commen-
çons par une introduction de l’organisation d’accueil. La deuxième partie sera consacrée à
notre contexte global du projet, dans lequel nous présenterons la problématique et l’étude
de ce qui existe, suivie de la solution proposée. Enfin, la dernière partie sera consacrée à
la méthodologie de travail adoptée.
1.1 Contexte générale
1.1.1 Cadre du projet
Le présent travail s’inscrit dans le cadre du projet de fin d’études en vue de l’obtention
du diplôme National de Licence en Sciences Informatique de l’Institut Supérieur d’Infor-
matique et Mathématiques de Monastir (ISIMM) pour l’année universitaire 2022/2023,
dans lequel nous allons concevoir et implémenter une solution web et mobile d’une mar-
ketplace basée sur l’architecture microservice de la société Veredent spécialisée dans le
domaine dentaire.
2
CHAPITRE 1. CONTEXTE ET OBJECTIFS
1.1.2 Présentation de l’entreprise d’accueil
Veredent est une startup dédiée à faciliter la connexion des praticiens dentaires avec
leur communauté et à les aider à rester à jour avec les dernières avancées de leur domaine.
Grâce à une application mobile, Dentallx, et d’autres outils innovants, Dentallx permet
aux dentistes de se connecter et d’échanger avec d’autres professionnels de la santé bucco-
dentaire, de partager leurs connaissances et d’accéder à des ressources précieuses. De
plus, Dentallx facilite la relation entre les praticiens et leurs fournisseurs de produits en
offrant un accès simplifié à un large éventail de fournisseurs, de promotions exclusives
et d’informations sur les produits. Cette plateforme interactive permet aux dentistes de
rester à l’avant-garde de leur profession, en améliorant leur pratique quotidienne et en
renforçant leur réseau professionnel. Avec Dentallx, les praticiens dentaires sont connectés,
informés et prêts à offrir des soins de qualité supérieure à leurs patients.
Figure 1.1 – Veredent Logo
1.2 Problématique
Malgré l’avènement de la technologie et d’Internet, l’achat et la vente de produits
et de services en ligne sont confrontés à des problèmes de fiabilité et de sécurité. Les
systèmes complexes peuvent rendre les transactions en ligne difficiles et peu fiables pour
3
CHAPITRE 1. CONTEXTE ET OBJECTIFS
les utilisateurs. Mais Il est important de souligner que pour s’aligner davantage sur les
besoins du client, les développeurs peuvent opter pour des solutions sur mesure, qui
répondent à des exigences spécifiques. Cela permet aux clients de bénéficier d’un système
personnalisé qui répond à leurs besoins spécifiques, tout en offrant des avantages tels que
des fonctionnalités uniques et une expérience utilisateur améliorée. Cela peut sembler
pratique au début, mais à mesure que le système grandit, il devient de plus en plus
difficile de le gérer et de le maintenir. Les développeurs peuvent avoir du mal à comprendre
comment le code est structuré, ce qui peut rendre la détection et la correction des erreurs
plus difficiles.
En 2018, Amazon a connu une panne technique majeure lors de son événement annuel
Prime Day. Le site Web et l’application ont été indisponibles pendant plusieurs heures,
empêchant les utilisateurs d’accéder au site Web, d’effectuer des achats et de profiter
d’offres exclusives. Certains ont émis l’hypothèse que le trafic important sur le site Web
pendant l’événement aurait pu surcharger les serveurs de l’entreprise et provoquer la
panne. La panne a provoqué l’insatisfaction des clients et la perte de ventes sur Amazon.
Amazon s’est par la suite excusé et s’est engagé à travailler pour éviter de tels problèmes
à l’avenir.
1.3 Etude de l’existant
La réalisation de tout projet doit être précédée par une étude de l’existant qui dé-
termine les points faibles et les points forts des systèmes actuels et les besoins du client
en vue de les prendre en considération lors de la conception et de la réalisation. Cette
étude nous permet de dégager et donner leurs atouts et leurs faiblesses an de déterminer
les besoins et les traiter.
1.3.1 Solutions existantes
• DentalPlanet
Dental Planet, Figure1.2, est une plateforme en ligne complète dédiée à l’industrie den-
taire. Elle est conçue comme une destination unique pour les professionnels dentaires et
les patients, offrant une large gamme de ressources et de services[1].
4
CHAPITRE 1. CONTEXTE ET OBJECTIFS
Figure 1.2 – DentalPlanet
Points forts Points faibles
-Vaste sélection de produits : Dental
Planet propose un catalogue étendu de
matériel dentaire, de fournitures et
d’instruments, offrant aux
professionnels dentaires un large choix
pour répondre à leurs besoins
spécifiques.
- Limitations géographiques : Dental
Planet peut avoir des limitations
géographiques en termes de livraison et
de disponibilité de services. Certains
utilisateurs peuvent être exclus de
certains avantages ou options offerts
par la plateforme en raison de leur
emplacement géographique.
- Support client limité : Il peut arriver
que le support client de Dental Planet
ne soit pas aussi réactif ou disponible
que souhaité. Cela peut entraîner des
retards dans le traitement des
questions ou des problèmes rencontrés
par les utilisateurs.
Table 1.1 – Points forts et points faibles de DentalPlanet
• Jumia
Jumia, illustrée par la figure 1.3, est une marketplace en ligne, présent dans 14 pays afri-
cains. Il met en relation des vendeurs et des acheteurs en mettant à leur disposition des
fonctionnalités basiques tel que Gestion de commande, de profil la consultation de l’his-
torique d’achats, la recherche filtrée, le retours et remboursements et les notifications[2].
5
CHAPITRE 1. CONTEXTE ET OBJECTIFS
Figure 1.3 – Jumia
Le tableau ci-dessous représente quelques points forts et points faibles de Jumia.
Points Forts Points Faibles
-Accessibilité facile et disponible sur
Web,Android et IOS
- interface chargé de publicité.
Table 1.2 – Point fort et point faible de Jumia
• eBay
eBay ,voir figure1.4 , est une plateforme de commerce électronique qui permet aux utilisa-
teurs d’acheter et de vendre une grande variété de produits, allant des produits neufs aux
articles d’occasion. Fondée en 1995, eBay est devenue l’une des plus grandes entreprises
de vente en ligne dans le monde, avec des millions d’utilisateurs actifs chaque jour. Les
utilisateurs peuvent acheter des produits dans une grande variété de catégories, y compris
l’électronique, la mode, la maison et le jardin, les bijoux, les jouets et les jeux, et bien
plus encore. Les vendeurs peuvent créer des annonces pour leurs produits, ajouter des
images et des descriptions détaillées, et fixer des prix de vente aux enchères ou des prix
d’achat immédiat. eBay propose également une large gamme d’options de paiement et de
livraison pour les acheteurs et les vendeurs [3] .
6
CHAPITRE 1. CONTEXTE ET OBJECTIFS
Figure 1.4 – eBay
Le tableau 1.3 représente quelque point forts et faible de eBay.
Points Forts Points Faibles
- Grande Audience
- Un système de protection de
l’acheteur : eBay dispose d’un système
de protection de l’acheteur qui peut
aider à protéger les acheteurs contre les
vendeurs malhonnêtes ou les produits
défectueux.
- Risque de fraudes : Comme eBay est
une plateforme de commerce
électronique ouverte, il peut y avoir un
risque de fraudes ou d’arnaques de la
part de certains vendeurs malhonnêtes.
- Enchères compétitives : Alors que les
enchères peuvent être une bonne façon
de trouver des produits rares ou
difficiles à trouver, cela peut également
conduire à des enchères compétitives et
à des prix élevés.
Table 1.3 – Points forts et points faibles de eBay
1.3.2 Critique de l’existant
Nous pouvons classer le résultat de l’analyse des applications web existantes mention-
nées précédemment selon cinq critères pris en considération dans le processus d’évaluation
de ses applications :
• Interface utilisateur et Attirance :
Le visiteur doit se sentir ciblé, il faut qu’il soit attiré par le site et que sa navigation soit
orientée et balisée. C’est ici que l’apparence du site sera évaluée.
7
CHAPITRE 1. CONTEXTE ET OBJECTIFS
• Application Mobile associé :
Avoir un site n’est pas de tout repos, avec une société et des internautes toujours plus
exigeants. Il faut être en mesure de leur fournir une meilleure expérience et améliore
la disponibilité du contenu, pour cela on a pris en considération dans l’évaluation si
l’application admet-elle une version mobile ou non ?
• Espace client :
Un espace client permet de faciliter les actions des utilisateurs tel que gérer ses coordon-
nées, ses préférences, son adresse, etc.
• Existance d’un Tableau de Bord :
Un tableau de bord qui permet d’analyser et gérer les produits et les ventes dans chaque
market .
• Paiement en ligne sécurisé :
Le paiement en ligne est aujourd’hui la méthode la plus simple et le plus rapide, en plus
il est plus sécurisé que les méthodes classiques, donc pour cela on a choisi le paiement en
ligne comme un critère dans l’évaluation des sites.
Le tableau ci-dessous présente une comparaison entre les solution existantes.
DentalPlanet Jumia eBay
Interface utilisateur et attirance Passable Passable Passable
Application Mobile associé Non Oui Oui
Espace client Oui Oui Oui
Gestion des Produits Non Oui Oui
Paiement en ligne sécurisé Non Oui Oui
Table 1.4 – Tableau compartif des solutions existantes
1.4 Solution proposée
La solution proposée est l’utilisation d’une architecture de microservices pour construire
une place de marché efficace et fiable. Cette approche permet de maintenir une sépara-
tion claire entre les différentes fonctions de la plateforme, ce qui facilite la maintenance et
l’extension de la plateforme tout en améliorant la fiabilité et la sécurité des transactions
en ligne. En plus de cette architecture de microservices, il est également possible de déve-
lopper une application web et mobile pour la plateforme. Cette application permettrait
aux vendeurs de créer leur propre marché personnalisé avec leur liste de produits, des
8
CHAPITRE 1. CONTEXTE ET OBJECTIFS
catégories et des descriptions détaillées. Les acheteurs pourraient facilement naviguer et
acheter des produits en utilisant cette application. Cette solution permettrait d’offrir une
expérience de transaction en ligne simple et pratique pour tous les utilisateurs de la place
de marché.
Pictogramme
Un pictogramme est une représentation visuelle simplifiée qui utilise des symboles
ou des icônes pour transmettre rapidement et efficacement des informations.
La figure ci-dessous présente notre solution sous forme d’un pictogramme illustrant
graphiquement ses caractéristiques.
Figure 1.5 – Pictogramme
1.5 Méthodologie de développement et modélisation
Une méthodologie de travail est un ensemble de techniques et de procédures permet-
tant d’organiser et de structurer efficacement le travail. Elle vise à améliorer la qualité
du travail accompli et à optimiser le temps et les ressources utilisés pour atteindre des
9
CHAPITRE 1. CONTEXTE ET OBJECTIFS
objectifs spécifiques. Cette méthodologie comprend la planification, l’organisation, la prio-
risation, l’exécution, le suivi et l’évaluation des phases, ainsi que l’utilisation d’outils et
de techniques de gestion du temps.
1.5.1 Étude de Méthodologie de développement
Devant le nombre de méthodes disponibles, le choix parmi elles devient difficile,
beaucoup de questions peuvent se poser à un chef de projet lors d’un démarrage de
projet. À cet égard, nous envisagerons plusieurs méthodes de développement, et selon
cette recherche, nous choisissons au mieux la méthodologie qui correspend à notre projet.
Méthodologie Two Tracked Unified Process
La méthodologie 2TUP (Two Tracks Unified Process) est une méthode de dévelop-
pement de logiciels qui combine deux approches de développement : l’approche dirigée
par les cas d’utilisation (Use Case-Driven) et l’approche dirigée par les fonctionnalités
(Feature-Driven). Cette méthode est basée sur le processus unifié (Unified Process) qui
est un cadre de développement logiciel itératif et incrémental. L’approche dirigée par
les cas d’utilisation (Use Case-Driven) se concentre sur la définition des exigences du
système à partir des cas d’utilisation et sur la modélisation de ces exigences pour créer
une représentation graphique du système. Cette approche est particulièrement utile pour
comprendre les besoins des utilisateurs et les fonctionnalités du système.
La figure ci-dessous présente un schéma de la La méthodologie 2TUP.
Méthode Scrum
Il s’agit d’une méthodologie de développement itérative et incrémentale qui met l’ac-
cent sur la collaboration entre les membres de l’équipe et la fourniture de fonctionnalités
utilisables aussi rapidement que possible. Elle est hautement adaptable et peut être uti-
lisé dans des projets dont les exigences évoluent rapidement. Il s’agit d’une méthode agile
axée sur la livraison de petits produits viables dans un court laps de temps. Les sprints
(phases de travail intensives) sont utilisés pour atteindre les objectifs, et les membres de
l’équipe se voient attribuer des rôles spécifiques[8].
La figure 1.7 illustre la méthodologie Scrum .
10
CHAPITRE 1. CONTEXTE ET OBJECTIFS
Figure 1.6 – 2TUP
Figure 1.7 – Scrum
Comparaison des méthodologies de développement
Le tableau 1.5 représente une comparaison des méthodologies de développement :
11
CHAPITRE 1. CONTEXTE ET OBJECTIFS
Méthodologies Avantages Inconvénients
2 Track Unified
Process (2TUP)
- Documentation rigoureuse
- Structuration claire
- Facilité de validation
-Économie d’espace
-Fiabilité et tolérance aux pannes
- Longue durée de développement
- Inflexibilité
Scrum - Livraison rapide de
fonctionnalités
- Collaboration : Scrum favorise la
collaboration entre les membres de
l’équipe, besoins de
développement, les parties
prenantes et le client, ce qui
permet d’identifier rapidement les
problèmes et de les résoudre de
manière proactive.
- Nécessité d’une implication
continue des parties prenantes
- Dépendance à l’égard de l’équipe
auto-organisée
- Difficulté de planification précise
Table 1.5 – Tableau comparatif des méthodologies de développement
1.5.2 Choix de la méthodologie de travail
Notre projet est basé sur un processus de développement bien défini qui va de la
détermination des besoins fonctionnels attendus du système jusqu’à la conception et le
codage final. Étant donné que nous avons une équipe de taille réduite, il est essentiel
d’adopter une approche de développement qui dissocie les aspects techniques des aspects
fonctionnels, tout en commençant par une étude préliminaire approfondie.
Après une analyse comparative approfondie des différentes méthodes de développement[24],
nous avons opté pour la méthode 2TUP. Cette méthode s’est avérée être une option adap-
tée à notre projet, car elle offre une approche nouvelle et originale tout en respectant le
cadre et les contraintes spécifiques de notre équipe et de notre projet.
Mise en pratique du processus 2TUP
2TUP est un processus de développement logiciel qui implémente le processus unifié
(c.à.d. itératif, incrémental, basé sur UML). Il propose un cycle de développement qui
sépare les aspects techniques des aspects fonctionnels en partant du constat que toute
évolution peut se traiter parallèlement, suivant un axe fonctionnel et un axe technique.
Ensuite, et en fusionnant les résultats de ces deux axes (branches), on arrive à réaliser le
système désiré.
12
CHAPITRE 1. CONTEXTE ET OBJECTIFS
1. L’étude préliminaire : Elle a pour objectif de définir les grandes lignes du projet
et d’évaluer sa faisabilité.
2. la capture des besoins fonctionnnels : Cette étape consiste à identifier et
à documenter les fonctions et les caractéristiques du logiciel qui sont nécessaires
pour satisfaire les besoins et les attentes des parties prenantes.
3. l’analyse : Elle consiste à examiner en détail les besoins des parties prenantes,
à comprendre leurs problèmes et leurs attentes, à identifier les processus et les
flux de travail impliqués dans le projet et à déterminer les contraintes techniques,
financières et temporell es qui s’appliquent au projet.
4. la capture des besoins techniques : Elle consiste à identifier et à documenter
les exigences techniques du logiciel, y compris les normes, les plateformes, les
outils et les technologies nécessaires à la conception, au développement et à la
maintenance du logiciel.
5. la conception générique : La conception générique consiste à élaborer la solu-
tion qui répond aux exigences techniques qu’on à spécifié dans la partie « capture
des besoins techniques »
6. la conception détaillée : Elle consiste à concevoir en détail chaque composant
logiciel identifié lors de l’analyse et à décrire comment ces composants seront im-
plémentés.La conception détaillée inclut des éléments tels que la modélisation des
données, l’architecture logicielle, la conception de l’interface utilisateur, la concep-
tion des algorithmes et des fonctions, ainsi que la définition de la structure et de
la hiérarchie du code.
7. le codage et les tests : Le codage consiste à écrire le code source du logiciel en
utilisant un langage de programmation approprié.Le but des tests est de s’assurer
que le logiciel fonctionne correctement et répond aux spécifications de conception.
1.6 Diagramme de Gantt
Un diagramme de Gantt est un outil de gestion de projet qui permet de visualiser
les différentes tâches de votre projet et leur avancement dans le temps. Nommé d’après
son inventeur Henry Gantt.
13
CHAPITRE 1. CONTEXTE ET OBJECTIFS
Figure 1.8 – Diagramme de gantt
Conclusion
Dans ce premier chapitre, nous avons réalisé une étude approfondie existante, ce
qui nous a permis d’obtenir une base solide pour notre projet en mettant en évidence la
solution souhaitable. Nous avons comparé plusieurs méthodes et conclu ce chapitre en
présentant la méthodologie 2TUP que nous adopterons pour le développement de notre
projet. Le chapitre suivant sera consacré à l’identification des besoins.
14
Chapitre 2
Capture des besoins
Introduction
L’étape d’analyse et de spécification des besoins vise à déterminer les diverses fonc-
tionnalités attendues du système. Dans ce chapitre, nous allons explorer comment les
besoins fonctionnels, non fonctionnels et techniques peuvent être capturés en utilisant la
méthode 2TUP.
2.1 Identification des acteurs
Pour notre système nous avons identifié les acteurs suivants :
• Internaute : c’est un visiteur de site , il peut consulter les Produits sur la page
d’acceuil, comme il peut les rechercher. Il peut aussi créer un profil et devenir un
client de la plateforme.
• Client : c’est un internaute qui est inscrit, possède un compte, dans la plateforme.
Il peut commander, consulter l’état de sa commande et évaluer des produits.
• Vendeur : Est un fournisseur de produits qui utilise notre système pour vendre
leurs produits à un large public.
• Administrateur : L’administrateur est responsable de la maintenance et de la
surveillance de la marketplace. Ses tâches incluent la gestion des utilisateurs, la
15
CHAPITRE 2. CAPTURE DES BESOINS
résolution des problèmes techniques et la conformité aux réglementations.
2.2 Besoins fonctionnels
Les besoins fonctionnels sont les exigences qui décrivent ce que le système doit faire
ou comment il doit fonctionner. Ils décrivent les fonctionnalités ou les services que le
système doit fournir pour répondre aux besoins de l’utilisateur final.
Dans la suite, nous allons exposer les besoins fonctionnels de notre application en
étroite relation avec les acteurs précédemment mentionnés.
L’internaute (Visiteur) détient le droit de :
• Consulter le site : consiste à accéder à la plateforme via un navigateur web ou
l’application mobile et à consulter les produits et les markets proposés.
• Créer compte : consiste à s’inscrire dans la platefrome en fournissant des infor-
mations personnelles.
• Rechercher un produit : consiste à effectuer une recherche pour trouver un
produit ou une boutique (fournisseur de produits).
le client (acheteur) détient le droit de :
• Gérer Panier : permet aux utilisateurs d’ajouter, modifier et supprimer des
produits de leur panier sur notre marketplace, avant de passer à la commande.
• Passer commande : consiste à passer la commande en ligne en validant les
produits selectionnées, en saisissant les informations nécessaire pour valider la
commande.
• Evaluer un produit : consiste à attribuer une note et à laisser un commentaire
sur un produit acheté ou utilisé précédemment sur la plateforme.
• Passer une réclamation : consiste à signaler un problème ou une insatisfaction
concernant un produit ou un service acheté auprès d’un vendeur ou d’un service
client sur la plateforme.
• Modifier Coordonnées : permet aux utilisateurs de mettre à jour leurs infor-
mations personnelles telles que leur adresse, leur numéro
16
CHAPITRE 2. CAPTURE DES BESOINS
le vendeur détient le droit de :
• Ajouter un nouveau produit : consiste à créer une nouvelle fiche produit en y
ajoutant les informations du produit, telles que la description, les images, le prix,
etc.
• Modifier un produit : consiste à mettre à jour les propriété d’un produit déja
ajouter dans la plateforme.
• Gérer ses commandes : consiste à suivre et à traiter les commandes passées par
les clients, en expédiant les produits et en mettant à jour les statuts de commande.
• Supprimer un produit : consiste à retirer une fiche produit existante, généra-
lement en raison de la fin de la disponibilité ou de la décision de ne plus proposer
le produit.
• Modifier infromations personnelle et boutique : permet aux vendeur de
mettre à jour leurs informations personnelles telles que leur adresse, leur numéro
L’administrateur détient le droit de :
• Gérer les comptes des clients : consiste à surveiller et à gérer les informations
des utilisateurs, en traitant les demandes de suppression de compte, en vérifiant
les informations d’identification et en gérant les problèmes de sécurité.
• Gérer les Produits : consiste à superviser et contrôler les différentes fonction-
nalités liées aux produits sur la plateforme
• Consulter les réclamations : recevoir, traiter et résoudre les réclamations des
clients, telles que les retours, les remboursements, les plaintes et les litiges, en
veillant à ce que les politiques et procédures de l’entreprise soient suivies et que
les clients soient satisfaits.
2.3 Besoins non fonctionnels
Les besoins non fonctionnels décrivent toutes les conditions requises permettant d’as-
surer le bon fonctionnement du système et d’améliorer la qualité des services pour l’uti-
lisateur. Pour notre platform ces exigences fonctionnelles doivent être décomposées en
17
CHAPITRE 2. CAPTURE DES BESOINS
microservices pour une architecture flexible, évolutive et maintenable. On a défini les
besoins non fonctionnels suivants :
Ergonomie : Tous les standards d’ergonomie doivent être res-
pectés dont la convivialité et la compréhensibilité des interfaces
graphiques. De plus, le choix des couleurs, la densité et l’or-
ganisation des éléments sur l’écran et aussi l’utilisation des
messages informatifs et des messages d’erreurs bien formées et
bien lisibles.
Disponibilité : Le système doit être hautement disponible,
avec une faible tolérance aux pannes, pour garantir une expé-
rience utilisateur fluide et ininterrompue.
Évolutivité : L’architecture microservices doit permettre
l’évolutivité facile des différents services, en fonction des be-
soins du système, sans affecter les autres services.
Intégration : Les différents services doivent être facilement
intégrables et compatibles avec d’autres applications tierces,
afin de permettre une intégration facile avec des systèmes exis-
tants.
Cohérence : L’ensemble du système doit être cohérent et fonc-
tionner de manière homogène, afin de garantir une expérience
utilisateur transparente et cohérente.
Performance : Le système doit être rapide et répondre rapi-
dement aux demandes des utilisateurs, en minimisant les temps
de latence et les temps d’arrêt.
Sécurité : Le système doit être sécurisé et protéger les don-
nées sensibles des utilisateurs, telles que les informations de
paiement et les données personnelles.
Table 2.1 – Besoins non fonctionelles
2.4 Besoins techniques
Nous nous intéressons ici à la branche droite du cycle en Y « Capture des besoins
techniques » qui capitalise le savoir-faire technique. Afin de bien expliquer nos choix
technologiques, nous avons fait recours à une étude comparative entre les différentes
technologies qui peuvent être utilisés durant notre projet.
18
CHAPITRE 2. CAPTURE DES BESOINS
2.4.1 Etude technologique
Dans la partie suivante nous présentons les Framework Front-End et Back-End que
nous allons utiliser pour le développement de notre application Web et Mobile.
Front-End Web
Le nombre des technologies de développement des applications web (coté client) est
en croissance continue. Parmi les langages les plus populaires nous citons :
React.js est une bibliothèque JavaScript open-source qui est
utilisée pour construire des interfaces utilisateur spécifique-
ment pour des applications d’une seule page. Elle est utilisée
pour gérer la couche d’affichage des applications web.React
permet aux développeurs de créer de grandes applications web
qui peuvent modifier les données, sans avoir à recharger la
page.
Points forts Points faibles
-Virtual DOM efficace
-Composants réutilisables
-Flux de données unidirectionnel
-Grande communauté de développeurs
-Courbe d’apprentissage initiale
-Complexité croissante avec des
applications complexes
-Taille de la bibliothèque et temps de
chargement potentiellement plus longs.
Table 2.2 – Point forts et points faibles de React js
AngularJS est un framework JavaScript open-source déve-
loppé par Google en 2010. Il est conçu pour simplifier la créa-
tion d’applications web complexes en offrant une approche
structurée pour organiser le code.
19
CHAPITRE 2. CAPTURE DES BESOINS
Points Forts Points Faibles
- Angular est basé sur une architecture
MVC qui facilite la structuration et la
maintenance du code.
- Il dispose d’une vaste gamme de
fonctionnalités et de modules prêts à
l’emploi pour faciliter le
développement.
- Angular est compatible avec de
nombreux autres outils et technologies,
tels que TypeScript, RxJS, Ionic, etc.,
ce qui permet de créer des applications
multiplateformes.
- Les directives personnalisées
d’Angular peuvent nécessiter une
configuration et un développement
supplémentaires, ce qui peut prendre
du temps et ajouter de la complexité
au projet.
- Les mises à jour fréquentes d’Angular
peuvent également poser des problèmes
de compatibilité avec les anciennes
versions, ce qui peut nécessiter des
efforts supplémentaires pour la
maintenance et la mise à jour des
applications existantes.
Table 2.3 – Points forts et points faibles de Angular
Vue Js React Js Angular Js
Performance Moyen Haute Haute
Scalabilité Faible Haute Haute
Apprentissage Facile Facile Moyen
Communité des développeurs Petite Très grande Grande
Acceptation et confiance Faible Haute Haute
Table 2.4 – Tableau comparatif entre les différents technologies Front-End Web
Front-End Mobile
Le développement mobile peut être divisé en deux catégories principales : le déve-
loppement natif et le développement multiplateforme.
• Le développement natif : implique la création d’applications spécifiques à une
plateforme particulière .
• Le développement multiplateforme : permet de créer une application unique
qui peut être déployée sur plusieurs plateformes différentes.
Le développement multiplateforme est une option intéressante lorsque vous souhaitez
réduire les coûts et les efforts de développement en créant des applications qui doivent
fonctionner sur plusieurs plateformes différentes. Cependant, cela peut entraîner une ex-
périence utilisateur sous-optimale et des performances plus lentes que le développement
natif.
Il existe plusieurs technologies multiplateformes populaires qui vous permettent de
développer des applications mobiles pour plusieurs plates-formes différentes à l’aide d’un
20
CHAPITRE 2. CAPTURE DES BESOINS
seul ensemble de code source. Les trois technologies multiplateformes les plus couramment
utilisées sont React Native, Xamarin et Flutter.
React Native est une plateforme de développement multipla-
teforme open source développée par Facebook qui vous aide à
développer des applications mobiles pour iOS et Android à
l’aide de JavaScript et React.
Points Forts Points Faibles
- Grande communauté de soutien
- Développement rapide et facile grâce
à l’utilisation de JavaScript
- Performances moins rapides que le
développement natif
- Peut nécessiter des configurations
spécifiques pour les différentes
plateformes
Table 2.5 – Points forts et points faibles de React native
Flutter est une plate-forme de développement multiplate-
forme open source développée par Google pour développer des
applications mobiles pour iOS, Android et le Web à l’aide du
langage de programmation Dart.
Points Forts Points Faibles
- Offre une qualité d’interface
utilisateur élevée grâce à son
architecture moderne
- Développement rapide et facile grâce
à l’utilisation de Dart et du hot
reloading
- Moins de support et de
documentation par rapport à React
Native ou Xamarin.
- Peut nécessiter des connaissances en
Dart
Table 2.6 – Points forts et points faibles de Flutter
React Native flutter
Performance Moyen Haute
Scalabilité Moyen Haute
Apprentissage Moyen Moyen
Communité des développeurs Très grande Tres grande
Acceptation et confiance Moyen Haute
Table 2.7 – Tableau comparatif entre les différents technologies Front-End Mobile
Back-End
Le Back-End, qui est invisible pour le client, représente une grande partie du déve-
loppement de notre projet. On peut décomposer le Back-End en deux parties essentielles :
21
CHAPITRE 2. CAPTURE DES BESOINS
Services métier les services métier occupent une place centrale en tant que respon-
sables de la logique applicative qui gère les fonctionnalités clés de la plateforme. Ils sont
chargés de mettre en œuvre les règles métier spécifiques à la marketplace .
Les services métier peuvent être développés en utilisant différents frameworks adap-
tés, tels que Spring Boot et NestJS, qui offrent des fonctionnalités de développement
robustes et une structure modulaire.
Examinons de plus près les caractéristiques de chacun de ces frameworks
Spring Boot est l’un des frameworks les plus utilisés pour le
développement d’applications backend, y compris les Services
Métier. Basé sur Java, un langage de programmation largement
adopté dans l’industrie, Spring Boot offre un écosystème riche
et mature. Il dispose d’une vaste gamme de bibliothèques et
de modules pour gérer des fonctionnalités telles que l’injection
de dépendances, la persistance des données et la sécurité.
Points Forts Points Faibles
- Spring Boot bénéficie d’un
écosystème Java mature et étendu,
offrant une multitude de bibliothèques,
de modules et d’outils pour le
développement d’applications backend.
- Spring Boot dispose d’une
communauté très active et d’une
documentation complète.
- il peut y avoir une courbe
d’apprentissage initiale plus longue
pour les développeurs moins familiers
avec le framework ou le paradigme de
programmation Spring.
- Configuration parfois complexe
Table 2.8 – Points forts et points faibles Spring Boot
NestJs NestJS est un framework basé sur JavaS-
cript/TypeScript qui gagne en popularité pour le déve-
loppement d’applications backend, y compris les Services
Métier. Il offre une architecture basée sur les modules, ce qui
facilite l’organisation du code en composants réutilisables.
22
CHAPITRE 2. CAPTURE DES BESOINS
Points Forts Points Faibles
- Fortement basé sur TypeScript,
offrant une expérience de
développement plus solide grâce à la
typage statique, à l’autocomplétion et
à la détection précoce des erreurs.
- Adopte une architecture modulaire
qui facilite la structuration du code en
composants réutilisables. Cela permet
de développer des applications bien
organisées et faciles à maintenir.
- Communauté relativement plus petite
Table 2.9 – Points forts et points faibles de NestJs
Base de Données
Les bases de données sont essentielles pour gérer des informations de manière orga-
nisée et cohérente, offrant ainsi un support précieux pour la prise de décision et l’analyse
des données, on peut citer deux types de base de données (relationnels et non relation-
nels). Dans le cas de notre application nous allons utiliser les deux types de bases de
données selon les besoins de chaques services.
• Base de données relationnels[5] : Une base de données relationnelle est un
type de base de données où les données sont liées à d’autres informations au
sein des bases de données. Les bases de données relationnelles sont composées
d’un ensemble de tables qui peuvent être accessibles et reconstruites de différentes
manières, sans qu’il soit nécessaire de réarranger ces tables de quelque façon que
ce soit. Le langage de requête structuré (SQL) est l’interface standard pour une
base de données relationnelle.
Avatages Inconvénients
- Capacité de gérer des relations complexes
- Puissance des requêtes complexes
- Structure et intégrité des données
- Normalisation des données
- Difficulté avec les données
semi-structurées ou non structurées
- Complexité des requêtes et de la
modélisation
- Rigidité du schéma
Table 2.10 – Avantages et inconvénients des bases de données relationnels
23
CHAPITRE 2. CAPTURE DES BESOINS
Figure 2.1 – Les bases de données relationnelles les plus populaires
• Base de données non relationnels (NOSQL)[5] : Les bases de données non rela-
tionnelles sont conçues pour gérer de grandes quantités de données non structurées
ou semi-structurées, telles que des documents, des graphes, des paires clé-valeur
ou des données en colonnes. Elles offrent une flexibilité accrue pour évoluer hori-
zontalement et supporter des charges de travail distribuées à grande échelle.
Avatages Inconvénients
- Gestion de données non structurées
- Évolutivité horizontale
- Flexibilité de schéma
- Haute performance
- Moins adaptées aux requêtes complexes
- Moins de support et de documentation
- Manque de normalisation
Table 2.11 – Avantages et inconvénients des bases de données non relationnels
24
CHAPITRE 2. CAPTURE DES BESOINS
Figure 2.2 – Les bases de données non relationnelles les plus populaires
2.4.2 Etude architecturale
Dans cette partie , nous explorerons les principes fondamentaux des différentes ar-
chitecture, en mettant l’accent sur les avantages et les considérations clés de chacune.
Nous examinerons également les principes de conception sous-jacents qui guident la mise
en œuvre de chaque architecture.
Architecture Monolithique
Une architecture monolithique est un style de développement logiciel dans lequel
toutes les fonctionnalités d’une application sont regroupées dans un seul bloc de code.
Cela signifie que l’application est construite, testée et déployée comme une seule unité.
Les architectures monolithiques sont généralement utilisées pour des applications simples
et peu complexes, mais peuvent devenir difficiles à gérer à mesure que les applications
deviennent plus grandes et plus complexes. Les mises à jour et les modifications peuvent
également être plus difficiles à mettre en œuvre dans une architecture monolithique[4].
25
CHAPITRE 2. CAPTURE DES BESOINS
Figure 2.3 – Architecture Monolithique
Inconvénients de l’architecture monolithique Les principaux inconvénients de
l’approche monolithique sont les suivants :
• Risque accru de défaillance : si une partie de l’application échoue, cela peut
entraîner l’arrêt de l’ensemble du système.
• Difficulté de mise à l’échelle : Lorsque le trafic augmente et que l’application
doit être mise à l’échelle pour gérer la charge, l’architecture monolithique peut
poser des défis.
• Inconvénients Extensibilité limitée : L’architecture monolithique peut devenir
difficile à étendre lorsque de nouvelles fonctionnalités doivent être ajoutées.
• Déploiement complexe : Les applications monolithiques nécessitent souvent un
déploiement complet pour apporter des modifications, ce qui peut entraîner des
temps d’arrêt plus longs.
Architectures microservices
Ce partie se focalise sur les concepts fondamentaux en lien avec notre travail. Tout
d’abord, nous abordons les concepts liés à l’architecture Microservices
Les concepts liés à l’architecture microservices
• Le Domain Driven Design
Le DDD pour « Domain-Driven Design » [9]est appelé en français «Conception pilotée
par le domaine» est une approche de conception logicielle qui se concentre sur la com-
préhension approfondie du domaine métier d’une application. Cette approche permet de
26
CHAPITRE 2. CAPTURE DES BESOINS
développer des logiciels plus proches des besoins réels des utilisateurs, en utilisant un
vocabulaire et des concepts communs à tous les acteurs du projet. Le Domain Driven
Design (DDD) utilise le principe de Bounded Context pour découper le domaine métier
d’une application en plusieurs parties cohérentes et autonomes. Chaque Bounded Context
possède son propre vocabulaire, modèles et règles métier, et est délimité par des interfaces
claires et précises qui définissent les interactions avec les autres contextes. Cette approche
permet de mieux gérer la complexité des applications en permettant à chaque contexte
de gérer sa propre logique métier de manière indépendante.
La mise en œuvre de Bounded Context peut aider à résoudre des problèmes tels que
la coordination des équipes de développement et la mise à l’échelle de l’application.
Figure 2.4 – Domain-Driven Design
• Le développement à base de composants
Le développement à base de composant est une branche de l’ingénierie logicielle consiste à
découper une application en plusieurs composants autonomes, chacun étant responsable
d’une fonctionnalité spécifique. Les composants sont conçus pour être réutilisables, ce qui
permet de les assembler de manière flexible pour créer des applications plus grandes et
plus complexes.
• Programmation polyglotte
En 2000, Scott Leberknight [6] a introduit le terme "programmation polyglotte" (Polyglot
Programming), qui consiste à utiliser plusieurs langages de programmation pour résoudre
différents types de problèmes dans une application. Les applications complexes peuvent
bénéficier de cette approche en choisissant le langage le mieux adapté à chaque tâche. Ce
concept peut également s’appliquer aux bases de données .
27
CHAPITRE 2. CAPTURE DES BESOINS
• Iolation des microservices dans des conteneurs (conteneurisation) :
L’isolation des microservices dans des conteneurs est une pratique clé de l’architecture
microservice. Chaque microservice est encapsulé dans un conteneur léger et autonome
qui contient tous les éléments nécessaires à son fonctionnement. Cette isolation assure
une meilleure stabilité et résilience de l’architecture, tout en permettant une gestion
plus flexible des ressources informatiques. En résumé, l’isolation des microservices dans
des conteneurs est un élément essentiel pour une architecture microservice efficace et
évolutive[10].
Définition de l’architecture Microservice
L’architecture microservices[4] est une approche de développement logiciel qui consiste
à construire une application en la décomposant en un ensemble de services indépendants,
autonomes et spécialisés, chacun exécutant une tâche spécifique. Chaque service est conçu
pour fonctionner de manière autonome, en communiquant avec les autres services via
une interface bien définie. Cette architecture est basée sur le principe de la séparation
des préoccupations et de la modularité, ce qui permet une plus grande flexibilité et une
évolutivité accrue.
Figure 2.5 – Architecture Microservice
Les avantages de l’architecture microservice Les avantages de l’architecture de
microservices incluent :
• Évolutivité : Les services peuvent être développés, déployés et évalués indépen-
damment les uns des autres, permettant une évolutivité horizontale et une utili-
28
CHAPITRE 2. CAPTURE DES BESOINS
sation plus efficace des ressources.
• Agilité : Les petites équipes peuvent travailler sur des services individuels, ce qui
permet une plus grande flexibilité et une itération plus rapide.
• Résilience : Si un service tombe en panne, les autres services continuent de
fonctionner, réduisant l’impact des pannes.
• Réutilisation : Les services peuvent être réutilisés dans différentes applications
et les nouvelles fonctionnalités peuvent être développées sans perturber les services
existants.
• Technologie adaptée : Les services peuvent être développés dans différents lan-
gages de programmation et utiliser différentes technologies de stockage de données
en fonction de leurs besoins spécifiques.
• Mise à l’échelle : Les services peuvent être mis à l’échelle individuellement en
fonction des besoins de l’application.
Choix architectural et technologique
Choix architectural
Pour la mise en œuvre de notre application, nous avons choisi une architecture basée
sur les microservices. Cette approche architecturale divise notre système en plusieurs
services indépendants et spécialisés, appelés microservices, qui interagissent entre eux
pour offrir les fonctionnalités de l’application. Chaque microservice est responsable d’une
partie spécifique du système, ce qui permet une séparation claire des préoccupations et
une évolutivité horizontale.
Nous adoptons le patron de passerelle API, qui permet de centraliser la ges-
tion des requêtes provenant des clients en fournissant une interface unique. Il offre des
fonctionnalités telles que la mise en cache, la limitation du débit, la transformation des
données et la sécurité. Au lieu de devoir contacter chaque service individuellement, les
clients envoient leurs requêtes à l’API Gateway, qui se charge de les router vers les services
appropriés. [7].
29
CHAPITRE 2. CAPTURE DES BESOINS
Figure 2.6 – Architecture API Gateway Pattern
Choix technologique
Nous avons sélectionné un ensemble de technologies robustes et performantes pour
la mise en œuvre de notre solution :
• Angular pour le frontend web
• Flutter pour l’application mobile
• Nginx en tant que passerelle API « Api Gateway »
— Pour gérer et sécuriser la communication entre nos microservices et les clients,
nous utiliserons Nginx en tant que passerelle API. Nginx agit comme un proxy
inverse, gérant les requêtes des clients et les redirigeant vers les microservices
appropriés.
• Nous avons décidé d’adopter une approche hybride en utilisant à la fois
PostgreSQL et MongoDB.
— Nous avons opté pour MongoDB pour les services qui nécessitent une grande
flexibilité de schéma et une évolutivité horizontale.
— D’autre part, pour les services qui exigent un modèle de données relationnel
plus strict et des transactions ACID nous avons choisi PostgreSQL.
• RabbitMQ comme courtier de messages « Message Broker »
— Pour faciliter la communication asynchrone et découpler les services, nous avons
intégré RabbitMQ en tant que courtier de messages. RabbitMQ prend en charge
le modèle d’édition-souscription, permettant aux microservices d’échanger des
30
CHAPITRE 2. CAPTURE DES BESOINS
messages de manière efficace. Cela permet une communication évolutive et
résiliente entre les différentes composantes de notre système.
La figure ci-dessous illustre l’architecture technologique choisie pour notre solution .
Figure 2.7 – Choix technologique de notre application
Conclusion
Dans ce chapitre, nous avons également documenté diverses exigences du projet.
Nous classons ces besoins en besoins fonctionnels, besoins non fonctionnels et besoins
techniques.
31
Chapitre 3
Conception
Introduction
Cette partie traite des aspects conceptuels de la conception orientée microservices de
l’application. Contrairement aux approches traditionnelles, cette conception se base sur
la création de services indépendants et autonomes, chacun ayant une fonctionnalité spéci-
fique. La mise en œuvre de cette architecture repose sur une méthodologie de conception
par service, où chaque service est conçu de manière autonome, indépendante des autres
services. Cette approche offre une flexibilité marquante, permettant une évolutivité facile
et une meilleure gestion de la complexité de l’application. Nous utiliserons pour cela le
format UML, en créant des diagrammes spécifiques pour chaque service.
3.1 Conception générique
La phase de conception permet de décrire de manière ambigüe, le plus souvent en uti-
lisant un langage de modélisation, le fonctionnement futur du système, afin d’en faciliter
la réalisation.
32
CHAPITRE 3. CONCEPTION
Le language UML
Pour faciliter notre tâche nous avons fait recours au langage de modélisation unifié
« UML » (Unified Modeling Language) qui permet de modéliser un problème de façon
standard. Ce langage qui est né de la fusion de plusieurs méthodes existantes auparavant
est devenu une référence en termes de modélisation objet[23] :
• Il permet le gain, encourage l’utilisation d’outils et constitue à cet effet un gage
de stabilité.
• Il cadre l’analyse et facilite la compréhension de représentations abstraites com-
plexes.
• Il est formel et normalisé : son caractère polyvalent et sa souplesse en font un
langage universel.
Conception préliminaire des interfaces-Prototypes
Une maquette est un produit jetable donnant aux utilisateurs une vue concrète mais
non définitive de la future interface de l’application. Elle est développée rapidement afin
d’améliorer la relation développeur-client. Les maquettes de notre application sont les
suivantes :
Figure 3.1 – Maquette préliminaire de l’interface login
33
CHAPITRE 3. CONCEPTION
Figure 3.2 – Maquette préliminaire de l’interface d’accueil
Figure 3.3 – Maquette préliminaire de l’interface dashboard de l’admin
34
CHAPITRE 3. CONCEPTION
Diagramme de classe globale
Un diagramme de classe dans le langage UML est un type de diagramme de structure
statique qui décrit la structure d’un système en montrant le système de classes, leurs
attributs, les opérations (ou) les méthodes et les relations entre les classes.
La figure ci-dessous illustre bien le diagramme de classe globale de notre système.
Figure 3.4 – Diagramme de classe globale
35
CHAPITRE 3. CONCEPTION
3.2 Urbanisation fonctionnelle en microservices
Dans le cadre de notre application, nous avons adopté une architecture basée sur
les microservices en nous appuyant sur les principes de la conception orientée domaine
(DDD). Cette approche nous permet de diviser notre système en services indépendants
et orientés, alignés sur les concepts clés de notre domaine métier.
Nous avons défini précédemment le DDD comme étant la « Conception pilotée par
le domaine », une approche de conception logicielle qui se concentre sur la compréhension
approfondie du domaine métier de notre application (voir page 27 pour plus de détails).
nous avons identifié plusieurs services, dont User Management, Product Management,
Command Management, et Payment.
• Le micro-service Gestion des utilisateurs est responsable de la gestion de tous
les utilisateurs liés, y compris les clients et les vendeurs.
• Le micro-service Gestion des produits est chargé de la gestion des produits
proposés par les vendeurs.
• Le micro-service Gestion des commandes se concentre sur la gestion des com-
mandes passées par les clients et recus aux vendeurs.
• Enfin, le micro-service Paiement est spécifiquement dédié à la gestion des paie-
ments.
Pour mieux illustrer l’implémentation pratique de notre architecture, nous avons créé un
deuxième diagramme de classe, dans la figure ci-dessous, qui regroupe chaque classe avec
le service auquel elle appartient. Nous utilisons des cercles pour représenter ces regrou-
pements, ce qui permet de visualiser clairement l’organisation des classes en fonction des
services.
36
CHAPITRE 3. CONCEPTION
Figure 3.5 – Diagramme de classe orienté microservices
3.3 Microservice de « Gestion des utilisateurs »
Dans le contexte des microservices, la gestion d’utilisateurs peut être traitée comme
un service autonome, responsable de toutes les opérations liées aux comptes utilisateurs.
Cela permet de simplifier la maintenance et l’évolution de ces fonctionnalités, tout en
offrant des interfaces claires pour les autres services qui ont besoin d’interagir avec les
utilisateurs.
37
CHAPITRE 3. CONCEPTION
3.3.1 Diagramme de Cas d’utilisation associé au microservice
« Gestion des utilisateurs »
La figure ci-dessous illustre le diagramme de cas d’utilisation « Gestion des utilisa-
teurs » qui détermine le role (les fonctionnalités) de ce microservice.
Figure 3.6 – Diagramme de cas d’utilisation associé au microservice « Gestion des
utilisateurs »
3.3.2 Description détaillée des cas d’utilisation associés au mi-
croservice « Gestion des utilisateurs »
Dans cette section nous allons présenter une description détaillée de quelques cas
d’utilisation
38
CHAPITRE 3. CONCEPTION
Cas
d’utilisation
Acteur Description
S’authentifier Client,
Vendeur,
Admin
Permet aux utilisateurs de s’authentifier au système .
Créer
Compte
Internaute Le visiteur de site peut faire une inscription pour qu’il
soit un Client ou bien un vendeur.
Modifier
coordonnées
Client Permet au client de mettre à jour ses informations
personnelles dans son compte sur la marketplace. Cela
peut inclure le nom, l’adresse, les coordonnées, les
préférences de communication, etc.
Passer une
réclamation
Client Consiste a signaler un problème ou une insatisfaction
concernant un produit acheté auprès d’un vendeur ou
d’un service client sur le site ou l’application.
Modifier les
informations
personnelles
et boutique
Vendeur Permet au vendeur de mettre à jour ses informations
personnelles dans son compte et son boutique. Cela
peut inclure le nom, l’adresse, les coordonnées, les
informations de paiement, etc.
Gérer les
comptes des
clients
Admin Cela consiste à surveiller et gérer les informations des
utilisateurs enregistrés sur un site ou une application
de commerce électronique, en vérifiant les informations
d’identification et en gérant les problèmes de sécurité.
Gérer les
comptes des
vendeur
Admin Cela consiste à surveiller et gérer les informations des
vendeur,en traitant les demandes de modification,
implique également la gestion des contrats conclus avec
les vendeurs sur la marketplace.
Consulter les
reclamation
Admin Cela consiste a examine les réclamations soumises par
les utilisateurs (clients/vendeur) .
Figure 3.7 – Les cas d’utilisation associés au microservice « Gestion des utilisateurs »
3.3.3 Diagramme de séquence « S’authentifier »
La Figure 3.8 décrit les différentes interactions entre l’utilisateur et les différents
objets du sytème pour le traitement du cas d’utilisation « S’authentifier »
39
CHAPITRE 3. CONCEPTION
Figure 3.8 – Diagramme de séquence« S’authentifier »
3.3.4 Description textuelle du cas d’utilisation « S’authentifier »
La description textuelle suivante présente en détail les différentes étapes et interac-
tions impliquées dans le cas d’utilisation « S’authentifier ». Ce cas d’utilisation permet
aux utilisateurs de s’authentifier(se connecter/créer un compte) à la plateforme. Le ta-
bleau qui suit fournit une vue détaillée des acteurs impliqués, des pré-conditions, des
post-conditions, des scénarios principaux et alternatifs de ce cas d’utilisation.
40
CHAPITRE 3. CONCEPTION
Cas d’utilisation S’authentifier
Acteur principal Internaute
Pré-conditions L’internaute n’est pas connecté à l’application
Scénario nominal 1.L’internaute accède à la page d’authentification
2.l’internaute saisie son email et son password pour se
connecter
3.L’internaute envoie la demande de connexion
Scénario alternatif 2a.l’internaute accède à la page de création de compte
2b.l’internaute saisie les données de son nouveau
compte
2c.l’internaute envoie la demande de création de
compte
Post-conditions l’internaute sera redirigé vers la page correspondonte
selon le type de son compte
Table 3.1 – Description textuelle du cas d’utilisation « S’authentifier »
3.3.5 Diagramme de séquence « Modifier coordonnées »
La Figure 3.9 décrit le diagramme de séquence de cas d’utilisation « Modifier coordon-
nées » qui nous explique comment la modification des cordonnées sera traité intérigissant
avec les différents objets système.
Figure 3.9 – Diagramme de séquence « Modifier coordonnées »
41
CHAPITRE 3. CONCEPTION
3.3.6 Description textuelle de cas d’utilisation « Modifier coor-
données »
La description textuelle suivante présente en détail les différentes étapes et interac-
tions impliquées dans le cas d’utilisation « Modifier cordonnées ». Ce cas d’utilisation vise
à permettre aux utilisateurs de modifier les cordonnées personnelles de leurs profils. Le
tableau qui suit fournit une vue détaillée des acteurs impliqués, des pré-conditions, des
post-conditions, des scénarios principaux et alternatifs de ce cas d’utilisation.
Cas d’utilisation Modifier coordonnées
Acteur principal Client
Pré-conditions Le client est connecté à l’application ou site web à
travers un compte actif
Scénario nominal 1.Le client accède à la page de modification de profil.
2.Le client modifie les informations de profil qu’il
souhaite mettre à jour.
3.Le client sauvegarde les modifications effectuées.
4.Le service de gestion de clients met à jour les
informations de profil du client dans la base de
données.
Scénario alternatif 2a.Le client ne souhaite pas modifier toutes les
informations de profil et laisse des champs vides.
2b.Le client rencontre une erreur lors de la modification
des informations de profil et reçoit un message d’erreur.
Post-conditions Les informations de profil du client sont mises à jour
dans la plateforme.
Table 3.2 – Description textuelle du cas d’utilisation « Modifier cordonnées »
3.3.7 Diagramme de séquence « Consulter les réclamations »
La Figure 3.10 décrit le diagramme de séquence de cas d’utilisation « Consulter les
réclamations » qui nous explique comment l’admin peut consulter les réclamations en
illustrant les interactions avec les différents objets système.
42
CHAPITRE 3. CONCEPTION
Figure 3.10 – Diagramme de séquence« Consulter les réclamations »
3.3.8 Description textuelle de cas d’utilisation « Consulter les
réclamations »
La description textuelle suivante présente en détail les différentes étapes et interac-
tions impliquées dans le cas d’utilisation « Consulter les réclamations ». Ce cas d’utili-
sation vise à permettre aux administrateurs de consulter les réclamations envoyées par
des clients ou des vendeurs. Le tableau qui suit fournit une vue détaillée des acteurs
impliqués, des pré-conditions, des post-conditions, des scénarios principaux et alternatifs
de ce cas d’utilisation.
Cas d’utilisation Consulter les reclamations
Acteur principal Administrateur
Pré-conditions L’administrateur est connecté à la plateforme .
Scénario nominal 1.L’administrateur accède à la page de gestion des
signalements.
2.L’administrateur demande d’afficher les réclamations.
3.Le système affiche les réclamtions.
4.L’administrateur consulte les réclamations.
Scénario alternatif 4a.L’administrateur choisit de supprimer ou pas la
réclamation consulté.
4b.L’administrateur choisit de filtrer les réclamations
selon la date.
Post-conditions Les réclamations sont afficheé par le système.
Table 3.3 – Description textuelle du cas d’utilisation« Consulter les réclamations »
43
CHAPITRE 3. CONCEPTION
3.3.9 Diagramme de composant « Gestion des utilisateurs »
La figure ci dessous contient le diagramme de composant de service gestion des
utilisateurs, il met l’accent sur les différentes parties qui composent le services « Gestion
des utilisateurs ».
Figure 3.11 – Diagramme de composant « Gestion des utilisateurs »
44
CHAPITRE 3. CONCEPTION
3.3.10 L’architecture logicielle de Microservice « Gestion des
utilisateurs »
La figure 3.12 représente l’architecture logicielle de Microservice « Gestion des utili-
sateurs ».
l’objectif de cette représentation est de fournir une compréhension visuelle de l’inter-
action du Microservice "Gestion des utilisateurs" avec les autres composants du système.
Elle met en évidence les connexions et les relations entre le microservice et les autres
composants :
• L’API Gateway, en tant que composant central de notre architecture, joue le rôle
de point d’entrée principal pour les requêtes des clients.
• Conteneur RabbitMQ pour la communication asynchrone entre les différents ser-
vices.
• Le conteneur de la base de données est responsable du stockage et de la persistance
des données du système.
Figure 3.12 – Architecture logicielle de microservice « Gestion des utilisateurs »
3.4 Microservice de « Gestion des produits »
La conception du service de gestion des produits constitue une étape cruciale de
notre architecture microservices. Ce service est chargé de gérer toutes les fonctionnalités
liées aux produits proposés sur notre marketplace.
45
CHAPITRE 3. CONCEPTION
3.4.1 Diagramme de Cas d’utilisation associés au microservice
« Gestion des Produits »
La figure 3.13 illustre un diagramme de cas d’utilisation qui contient les principaux
fonctionnalitées du microservices « Gestion des Produits ».
Figure 3.13 – Diagramme de cas d’utilisation associés au microservice « Gestion des
produits »
46
CHAPITRE 3. CONCEPTION
3.4.2 Description détaillée des cas d’utilisations associé au mi-
croservices « Gestion des Produits »
Dans cette section nous allons présenter une description textuelle de quelques cas
d’utilisation
Cas
d’utilisation
Acteur Description
Evaluer un
produit
Client Permet aux clients de soumettre des évaluations pour
un produit donné, en fournissant une note et un
commentaire.
Consulter les
produits
Client Consiste à fournir aux utilisateurs une vue d’ensemble
des produits disponibles, en affichant des détails tels
que les images, les descriptions, les prix et les
évaluations .
Rechercher
un produit
Client Permet aux clients de rechercher des produits en
fonction de différents critères tels que le nom, le prix,
la catégorie, etc .
Gérer panier Client Permet aux clients d’ajouter des produits à son panier
en vue d’un achat ultérieur. De plus, l’utilisateur a la
capacité de supprimer des produits et modifier la
quantité .
Gérer les
stocks
Vendeur Le vendeur peut surveiller les niveaux de stock de ses
produits, mettre à jour les quantités disponibles en
fonction des ventes ou des arrivées de nouveaux stocks,
et recevoir des notifications lorsque les niveaux de
stock sont bas.
Ajouter un
produit
Vendeur,
Admin
Consiste à ajouter un nouveau produit à la vente sur la
Marketpalce .
Modifier un
produit
Vendeur,
Admin
Permet aux vendeurs, Administrateurs de mettre à
jour les informations d’un produit existant, telles que
le prix, la quantité en stock, la description, les images,
etc .
Supprimer
un produit
Vendeur,
Admin
Cette fonctionnalité permet aux vendeurs,
Administrateurs de supprimer un produit qui n’est
plus disponible à la vente.
Gérer les
avis
Admin L’administrateur peut modérer les évaluations et les
commentaires pour s’assurer qu’ils sont pertinents et
utiles pour les autres utilisateurs.
Gérer les
catégories
Admin permettre aux administrateurs de gérer les catégories
de produits disponibles, Ils peuvent créer de nouvelles
catégories, modifier ou supprimer des catégories
existantes .
Table 3.4 – Les cas d’utilisation associés au microservice « Gestion des produits »
47
CHAPITRE 3. CONCEPTION
3.4.3 Diagramme de séquence « Ajouter produit »
La Figure ci-dessous décrit le diagramme de séquence de cas d’utilisation « Ajouter
un produit » qui nous explique comment le vendeur peut ajouter son nouveau produit
dans la platforme en illustrant les interactions avec les différents objets système.
Figure 3.14 – Diagramme de séquence « Ajouter un produit »
3.4.4 Description textuelle du cas d’utilisation « Ajouter un
produit »
La description textuelle suivante présente en détail les différentes étapes et inter-
actions impliquées dans le cas d’utilisation « Ajouter un produit ». Ce cas d’utilisation
permet aux vendeurs d’ajouter un produit. Le tableau qui suit fournit une vue détaillée
des acteurs impliqués, des pré-conditions, des post-conditions, des scénarios principaux
48
CHAPITRE 3. CONCEPTION
et alternatifs de ce cas d’utilisation.
Cas
d’utilisation
Ajouter un produit
Acteur
principal
Vendeur
Pré-
conditions
Le vendeur est connecté à la plateforme avec un
compte actif et a accès à la page d’ajout de produit.
Scénario
nominal
1.Le vendeur accède à la page d’ajout de produit.
2.Le vendeur entre les détails du produit, y compris le
nom, la description, les images et le prix.
3.Le vendeur choisit une catégorie appropriée pour le
produit.
4.Le vendeur sauvegarde le produit.
5.Le service de gestion de produits vérifie que toutes les
informations obligatoires ont été saisies correctement.
6.Le produit est ajouté à la liste des produits
disponibles sur la plateforme de microservices de place
de marché.
Scénario
alternatif
5a Le service de gestion de produits détecte des
informations manquantes ou incorrectes et demande au
vendeur de les corriger avant de pouvoir ajouter le
produit.
Post-
conditions
Le produit est ajouté à la liste des produits disponibles
sur la plateforme de microservices de place de marché
et est visible pour les acheteurs potentiels. Le vendeur
peut également accéder au produit pour le modifier ou
le supprimer si nécessaire.
Table 3.5 – Description textuelle du cas d’utilisation « Ajouter Produit »
3.4.5 Diagramme de séquence « Evaluer produit »
La Figure 3.15 représente le diagramme de séquence de cas d’utilisation « Evaluer
un produit » qui nous explique comment le client peut attribuer une note à un produit
dans la platforme en illustant les interactions avec les différents objets système.
49
CHAPITRE 3. CONCEPTION
Figure 3.15 – Diagramme de séquence « Evaluer produit »
3.4.6 Description textuelle du cas d’utilisation « Evaluer pro-
duit »
La description textuelle suivante présente en détail les différentes étapes et interac-
tions impliquées dans le cas d’utilisation « Evaluer produit ». Ce cas d’utilisation permet
aux clients de notter un produit. Le tableau qui suit fournit une vue détaillée des acteurs
impliqués, des pré-conditions, des post-conditions, des scénarios principaux et alternatifs
de ce cas d’utilisation.
50
CHAPITRE 3. CONCEPTION
Cas d’utilisation Evaluer produit
Acteur principal Client
Pré-conditions Le client est connecté à la plateforme avec un compte
actif
Scénario nominal 1.Le client accède à la page de notation et de
commentaire du produit.
2.Le client donne une note (sur 5) et un commentaire
pour le produit.
3.Le service de gestion des produit vérifie que la
notation et le commentaire sont conformes aux règles
de la plateforme
5.Le service de gestion des produits ajoute la note au
produit
Scénario alternatif 2a.Si le client a noté deja le produit il modifie son
ancien note ou le supprime.
3a.Si la notation ou le commentaire ne respecte pas les
règles de la plateforme le service de gestion des
produits demande au client de les modifier.
Post-conditions La notation et le commentaire sont publiés/supprimé
sur la page du produit pour les autres clients à voir.
Table 3.6 – Description textuelle du cas d’utilisation « Evaluer produit »
3.4.7 Diagramme de composant associé au microservice « Ges-
tion des produits »
La figure ci dessous contient le diagramme de composant de service Gestion des
produits, il met l’accent sur les différentes parties qui composent le services « Gestion des
utilisateurs ».
51
CHAPITRE 3. CONCEPTION
Figure 3.16 – Diagramme de composant associé au microservice « Gestion des produits »
3.4.8 L’architecture logicielle de microservice « Gestion des pro-
duits »
La figure 3.17 présente l’architecture logicielle de microservice Gestion des produits
l’objectif de cette représentation est de fournir une compréhension visuelle de l’in-
52
CHAPITRE 3. CONCEPTION
teraction du Microservice "Gestion des produits" avec les autres composants du système.
Figure 3.17 – Architecture logicielle de microservice « Gestion des produits »
3.5 Microservice de « Gestion des commandes »
Dans le contexte des microservices, le service de gestion des commandes peut être
traité comme un service autonome, responsable de toutes les opérations liées à la gestion
des commandes.
3.5.1 Diagramme de cas d’utilisation associé au microservice
« Gestion des commandes »
Figure 3.18 – Diagramme de cas d’utilisation associé au Microservice « Gestion des
commendes »
53
CHAPITRE 3. CONCEPTION
3.5.2 Description détaillée des cas d’utilisation associé au mi-
croservice « Gestion des commandes »
Dans cette section nous allons présenter une description de quelques cas d’utilisation
Cas
d’utilisation
Acteur Description
Passer une
commande
Client Le client peut passer une nouvelle commande en
sélectionnant les produits souhaités, en fournissant les
informations de livraison
Consulter
l’historique
des
commandes
Client Le client peut consulter l’historique de ses commandes
précédentes, y compris les détails de chaque
commande, l’état actuel, les produits commandés et les
informations de livraison.
Suivre l’état
de la
commande
Client Le client peut suivre l’état en temps réel de sa
commande, de la préparation à la livraison. Il peut
savoir à quelle étape se trouve sa commande et obtenir
des mises à jour sur son statut.
Gérer les
commandes
entrantes
Vendeur Le vendeur peut consulter les commandes entrantes, y
compris les détails des produits commandés, les
informations de livraison et les coordonnées du client.
Le vendeur peut prendre les mesures nécessaires pour
traiter et préparer les commandes.
Mettre à
jour l’état de
la commande
Vendeur Le vendeur peut mettre à jour l’état des commandes en
fonction de leur progression
Table 3.7 – Tablau des cas d’utilisation associés au microservice « Gestion des com-
mendes »
3.5.3 Diagramme de séquence « Passer une commande »
La Figure 3.18 et la tableau 3.8 décrivent le diagramme de séquence de cas d’uti-
lisation « Passer une commande » qui nous explique comment le client peut passer une
commande dans la platforme en illustrant les interactions avec les différents objets sys-
tème.
54
CHAPITRE 3. CONCEPTION
Figure 3.19 – Diagramme de sequence « Passer une commande »
55
CHAPITRE 3. CONCEPTION
3.5.4 Description textuelle du cas d’utilisation « Passer une
commande »
La description textuelle suivante présente en détail les différentes étapes et interac-
tions impliquées dans le cas d’utilisation « Passer une commandet ». Ce cas d’utilisation
permet aux clients de passer une commande. Le tableau qui suit fournit une vue détaillée
des acteurs impliqués, des pré-conditions, des post-conditions, des scénarios principaux
et alternatifs de ce cas d’utilisation.
Cas d’utilisation Passer une commande
Acteur principal Client
Pré-conditions Le client est connecté à la plateforme de commerce
électronique et a des produits dans son panier.
Scénario nominal 1.Le client sélectionne les produits dans son panier.
2.Le client fournit les informations de livraison
3.Le client choisit une option de paiement
4.Le client confirme la commande
5.Le système de gestion des commandes vérifie la
disponibilité des produits chez les vendeurs respectifs.
6.Le système de gestion des commandes enregistre la
commande pour chaque vendeur.
7.Le client reçoit une confirmation de commande.
Scénario alternatif 2a.Le client modifie les informations de livraison ou
choisit une autre option de livraison.
5a.L’un des produits sélectionnés par le client n’est pas
disponible.
Post-conditions La commande est enregistrée dans le système pour
chaque vendeur, les paiements sont traités, et le client
reçoit une confirmation de commande. Les vendeurs
sont notifiés des commandes et prêts à traiter et
expédier les produits commandés.
Table 3.8 – Description scénariste du cas d’utilisation « Passer une commande »
3.5.5 Diagramme de composant associé au microservice « Ges-
tion des produits »
La figure 3.20 représente le diagramme de composants du microservice de gestion de
commandes. Ce diagramme met en évidence les différents composants et leur intercon-
nexion, permettant de comprendre la structure et l’organisation du service de gestion des
commandes. Il montre comment les différents composants du système se connectent et
56
CHAPITRE 3. CONCEPTION
interagissent pour assurer le bon fonctionnement du service de gestion des commandes.
Figure 3.20 – Diagramme de composant associé au microservice « Gestion des com-
mandes »
57
CHAPITRE 3. CONCEPTION
3.5.6 L’architecture logicielle de microservice « Gestion des com-
mandes »
La figure 3.21 présente l’architecture logicielle de microservice « Gestion des com-
mandes »
Le composant Message Broker est responsable de la communication avec les autres
microservices
Figure 3.21 – Architecture logicielle de microservice « Gestion des produits »
Conclusion
Dans le chapitre de conception de notre projet, nous avons adopté une approche de
conception en microservices. Cette approche nous a permis de diviser notre application en
plusieurs services indépendants, chacun se concentrant sur une fonctionnalité spécifique.
Dans le chapitre de la réalisation qui suivra, nous mettrons en œuvre la conception que
nous avons élaborée. Nous aborderons les détails techniques de la mise en place des
microservices et les interfaces web et mobile .
58
Chapitre 4
Réalisation
Introduction
Dans ce chapitre, nous aborderons en détail les aspects pratiques de la mise en place
de notre solution, on va présenter l’environnement matériel et logiciel ainsi que les outils
de développement.
4.1 Environnement de développement
Dans cette partie, nous présentons les différents outils matériels et logiciels néces-
saires pour le développement de notre application.
4.1.1 Environnement matériel
Pour la réalisation de ce projet on a disposé d’ :
1. Un ordinateur :
• Marque Dell
• Processeur : 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
• RAM : 12 GO
• Système d’exploitation : Windows 10
59
CHAPITRE 4. RÉALISATION
2. Un ordinateur :
• Marque Dell
• Processeur : 8th Gen Intel(R) Core(TM) i7-8650U @2.10GHz
• RAM : 16 GO
• Système d’exploitation : Windows 10
4.1.2 Environnement logiciel
Cette section décrit l’environnement logiciel avec lequel nous avons réalisé ce projet
.
Figure 4.1 – Visual Studio Code
Visual Studio Code : est un éditeur de code source léger, mais puissant, qui s’exécute
sur votre bureau et est disponible pour Windows, macOS et Linux[12].
Figure 4.2 – Git
Git : est un système de contrôle de version distribué et open-source largement utilisé
pour le suivi des modifications apportées aux fichiers et aux projets de développement
logiciel[13].
Figure 4.3 – Docker
Docker : est une plateforme open-source qui permet de créer, de déployer et d’exécuter
des applications dans des conteneurs[14].
60
CHAPITRE 4. RÉALISATION
Figure 4.4 – Postman
Postman : est un outil populaire utilisé par les développeurs pour tester, documenter
et collaborer sur les API (Interfaces de programmation d’application)[15].
Figure 4.5 – Swagger
Swagger (OpenAPI Specification) est un ensemble de spécifications et d’outils pour
concevoir, documenter et tester des API RESTful.
Figure 4.6 – Nginx
Nginx : est un serveur web léger, performant et open-source, ainsi qu’un proxy
inverse[16].
Figure 4.7 – LYX
Pour rédiger ce rapport, nous avions utilisé LyX pour cette tâche, c’est un éditeur
de texte gratuit, open source et multiplateforme qui permet l’édition de texte à base de
LaTeX [17].
61
CHAPITRE 4. RÉALISATION
Figure 4.8 – LucidChart
LucidChart est un outil pour créer des diagrammes,des figures et des illustrations[18].
Figure 4.9 – RabbitMQ
RabbitMQ est un courtier de messages open-source qui permet à différents systèmes
logiciels de communiquer et d’échanger des messages. Il met en œuvre le protocole de
messagerie avancée (AMQP), qui est un protocole standardisé pour la messagerie entre
applications.[19].
4.2 Présentation de la solution
Cette partie dédiée à la mise en valeur de notre solution, nous explorons en détail
les aspects clés qui la composent. Nous abordons la solution web, la solution mobile et la
réalisation des microservices, mettant en évidence leur importance et leur contribution à
l’expérience utilisateur. Chaque sous-partie apporte une dimension unique à notre solu-
tion, créant ainsi une plateforme attrayante, conviviale et évolutive pour nos utilisateurs.
4.2.1 Présentation de la solution web
Cette partie présente certaines interfaces de l’application Web et montre les carac-
téristiques les plus importantes de notre travail.
62
CHAPITRE 4. RÉALISATION
La page d’acceuil
L’utilisateur a un accès à l’application via la page d’acceuil, il peut naviguer dans les
produits, les catégories, effectuer une recherche sur un produit spécifique une boutique,
ou une catégorie, il peut aussi s’authentifier et ajouter des produits à un panier et com-
mander ces produits. La figure 4.10 présente l’interface d’acceuil implémentée dans notre
application web.
Figure 4.10 – Interface d’acceuil Web
La page de commande
L’utilisateur peut consulter les produits ajoutées au panier il peut les modifier en
supprimant quelques-uns ou en augmentant leurs quantité. Il peut aussi passer une com-
mande avec les produits du panier en ajoutant son adresse et en passant par le payement.
La figure 4.11 ci-dessous présente l’interface de commande implémentée dans notre ap-
plication web.
63
CHAPITRE 4. RÉALISATION
Figure 4.11 – Interface d’acceuil Web
La page de création de compte
L’interface de création de compte dans notre projet offre une expérience conviviale
et intuitive pour les utilisateurs. Elle permet aux visiteurs d’accéder rapidement à la
fonctionnalité d’inscription en fournissant les informations nécessaires(tels que le nom
complet, l’adresse e-mail, le mot de passe, et d’autres informations pertinentes) pour
créer un compte personnel. La figure 4.12 présente l’interface de création de compte
implémentée dans notre application web.
Figure 4.12 – Interface SignIn Web
64
CHAPITRE 4. RÉALISATION
La page se connecter
La page de connexion est conçue de manière à ce que les utilisateurs puissent accéder
rapidement à leur compte personnel en fournissant leurs informations d’identification(leur
adresse e-mail, ainsi que leur mot de passe associé). La figure 4.13 ci-dessous présente
l’interface de connexion au compte implémentée dans notre application web dans le cas
ou l’utilsateur a un compte.
Figure 4.13 – Interface Login Web
La page de l’espace vendeur
Chaque vendeur a un espace composé d’un ensemble des fonctionalités(services) tel
qu’un affichage de ses produits, l’ensembles des commandes recus , les cordonnées de son
boutique ,etc. Cette interface est accessible au utilisaeur via
La figure 4.14 présente l’interface de l’espace vendeur implémentée dans notre appli-
cation web.
65
CHAPITRE 4. RÉALISATION
Figure 4.14 – Interface vendeur-dashboard
4.2.2 Présentation de la solution Mobile
Cette partie présente certaines interfaces de l’application Mobile et montre les ca-
ractéristiques les plus importantes de notre travail.
La page d’authentification
Pour qu’un utilisateur ait un accès à l’application, une phase d’authentification est
nécessaire.
1. L’interface de connexion capturée présente un formulaire de connexion élégant et
simple. L’écran affiche un champ pour l’adresse e-mail et un champ pour le mot
de passe.
2. L’interface d’inscription capturée présente un formulaire convivial permettant aux
utilisateurs de créer un nouveau compte. L’écran propose des champs pour saisir
les informations nécessaires, tels que le nom, l’adresse e-mail, le mot de passe et
numéro de téléphone.
3. L’interface de vérification d’e-mail capturée est conçue pour permettre aux utili-
sateurs de confirmer leur adresse e-mail après leur inscription.
66
CHAPITRE 4. RÉALISATION
La figure 4.15 ci-dessous présente les interfaces d’authentification implémentée dans notre
application.
Figure 4.15 – Interface authentification application mobile.
Lorsque les utilisateurs saisissent des identifiants incorrects ou rencontrent un pro-
blème de connexion, un message d’erreur clair et concis est affiché à l’écran. Ce message
les informe de la nature de l’erreur et les invite à vérifier leurs informations de connexion.
La figure 4.16 ci-dessous illustre cette interface d’erreur.
67
CHAPITRE 4. RÉALISATION
Figure 4.16 – Authentification cas d’erreur
Page d’accueil
Dans notre application MarketHive, la page d’accueil est conçue pour offrir aux
utilisateurs un aperçu complet des produits disponibles, des catégories et des publicités.
La figure 4.17 ci-dessous présente l’interface de la page d’accueil.
Figure 4.17 – Interface d’accueil application mobile
68
CHAPITRE 4. RÉALISATION
Interface catégorie
L’interface des catégories dans notre application est conçue pour permettre aux uti-
lisateurs de naviguer facilement parmi les différentes catégories de produits disponibles.
1. Au sommet de l’interface, vous trouverez une vue en liste affichant les catégories
parentes. Chaque catégorie est représentée par son nom .
2. Lorsque vous cliquez sur l’une des catégories parentes, l’interface se met à jour pour
afficher les sous-catégories associées à cette catégorie. Cela permet de présenter une
hiérarchie des catégories.
3. lorsque vous cliquez sur l’une des sous-catégories présentées dans l’interface pré-
cédente. Elle présente une grille (grid view) de produits liés à cette sous-catégorie
spécifique. Chaque produit est représenté par une image, un nom, un prix et un
notation. La figure 4.18 ci-dessous présente cette interface.
Figure 4.18 – Interface catégorie application mobile
Interface produit
L’interface de détails du produit offre une vue détaillée et complète d’un produit
spécifique. Elle est organisée de manière à fournir toutes les informations nécessaires aux
utilisateurs pour prendre une décision d’achat éclairée. La figure 4.19 ci-dessous présente
cette interface.
69
Conception et développement d'une marketplace basée sur l'architecture microservices
Conception et développement d'une marketplace basée sur l'architecture microservices
Conception et développement d'une marketplace basée sur l'architecture microservices
Conception et développement d'une marketplace basée sur l'architecture microservices
Conception et développement d'une marketplace basée sur l'architecture microservices
Conception et développement d'une marketplace basée sur l'architecture microservices
Conception et développement d'une marketplace basée sur l'architecture microservices
Conception et développement d'une marketplace basée sur l'architecture microservices
Conception et développement d'une marketplace basée sur l'architecture microservices
Conception et développement d'une marketplace basée sur l'architecture microservices

Contenu connexe

Tendances

Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
Ayoub Mkharbach
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
Mohamed Boubaya
 
iRecruite
iRecruiteiRecruite
iRecruite
Donia Hammami
 
réalisation une application web de gestion des informations météorologiques
réalisation une application web de gestion des informations météorologiquesréalisation une application web de gestion des informations météorologiques
réalisation une application web de gestion des informations météorologiques
Medk Salhi
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
Siwar GUEMRI
 
Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
Ahmed rebai
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
Mohamed Boubaya
 
Front office back office caisse
Front office back office caisseFront office back office caisse
Front office back office caisse
Ben Sassi Mohamed Ridha
 
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
safwenbenfredj
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
Ilef Ben Slima
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Hajer Dahech
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
ahmed oumezzine
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
Nader Somrani
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammami
Donia Hammami
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
Nassim Bahri
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Raoua Bennasr
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
Sid Ahmed Benkraoua
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
Hicham Ben
 
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Raef Ghribi
 

Tendances (20)

Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
 
iRecruite
iRecruiteiRecruite
iRecruite
 
réalisation une application web de gestion des informations météorologiques
réalisation une application web de gestion des informations météorologiquesréalisation une application web de gestion des informations météorologiques
réalisation une application web de gestion des informations météorologiques
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 
Rapport pfev7
Rapport pfev7Rapport pfev7
Rapport pfev7
 
Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
 
Front office back office caisse
Front office back office caisseFront office back office caisse
Front office back office caisse
 
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
Rapport de projet_de_fin_d__tudes__pfe__safwen (8)
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammami
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
 
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
 

Similaire à Conception et développement d'une marketplace basée sur l'architecture microservices

Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
Belwafi Bilel
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
Glei Hadji
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Mohamed Amine Mahmoudi
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Sofien Benrhouma
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
Ben Ahmed Zohra
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Yasmine Lachheb
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
Yosra ADDALI
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
Taieb Kristou
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Houssem Eddine Jebri
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
mouafekmazia
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
Mohamed Aziz Chetoui
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
Hosni Mansour
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
nesrine haloui
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Benjamin Vidal
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
Slimane Akaliâ , سليمان أقليع
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
Ilyas CHAOUA
 
Deploy automatic in the cloud
Deploy automatic in the cloudDeploy automatic in the cloud
Deploy automatic in the cloud
Abdelhalim KADDOUR GUETTAOUI
 
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
younes elmorabit
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
ichrafkhalfaoui
 

Similaire à Conception et développement d'une marketplace basée sur l'architecture microservices (20)

Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Belwafi bilel
Belwafi bilelBelwafi bilel
Belwafi bilel
 
Projet de conception et de développement
Projet de conception et de développementProjet de conception et de développement
Projet de conception et de développement
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
Rapport pfe isi_Big data Analytique
Rapport pfe isi_Big data AnalytiqueRapport pfe isi_Big data Analytique
Rapport pfe isi_Big data Analytique
 
OpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revientOpenERP - Gestion de prix de revient
OpenERP - Gestion de prix de revient
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
 
pfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdfpfe_rapport_poste_licence_LFIG.pdf
pfe_rapport_poste_licence_LFIG.pdf
 
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmesEvaluation de la quantité de travail (in)utile dans l’exécution des programmes
Evaluation de la quantité de travail (in)utile dans l’exécution des programmes
 
Fourth year internship report
Fourth year internship reportFourth year internship report
Fourth year internship report
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 
Deploy automatic in the cloud
Deploy automatic in the cloudDeploy automatic in the cloud
Deploy automatic in the cloud
 
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 

Dernier

Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024
Friends of African Village Libraries
 
Auguste Herbin.pptx Peintre français
Auguste   Herbin.pptx Peintre   françaisAuguste   Herbin.pptx Peintre   français
Auguste Herbin.pptx Peintre français
Txaruka
 
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
Editions La Dondaine
 
1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif
NadineHG
 
1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire
NadineHG
 
Zineb Mekouar.pptx Écrivaine marocaine
Zineb Mekouar.pptx   Écrivaine  marocaineZineb Mekouar.pptx   Écrivaine  marocaine
Zineb Mekouar.pptx Écrivaine marocaine
Txaruka
 
Chap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdfChap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdf
TimogoTRAORE
 

Dernier (7)

Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024
 
Auguste Herbin.pptx Peintre français
Auguste   Herbin.pptx Peintre   françaisAuguste   Herbin.pptx Peintre   français
Auguste Herbin.pptx Peintre français
 
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
La Révolution Bénédictine Casadéenne du Livradois-Forez: De Charlemagne à Fra...
 
1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif1e Espaces productifs 2024.Espaces productif
1e Espaces productifs 2024.Espaces productif
 
1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire
 
Zineb Mekouar.pptx Écrivaine marocaine
Zineb Mekouar.pptx   Écrivaine  marocaineZineb Mekouar.pptx   Écrivaine  marocaine
Zineb Mekouar.pptx Écrivaine marocaine
 
Chap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdfChap1 Généralités sur les réseaux informatiques.pdf
Chap1 Généralités sur les réseaux informatiques.pdf
 

Conception et développement d'une marketplace basée sur l'architecture microservices

  • 1. M. Fakher Ben Ftima Mme. Sana Hamdi M. Ramzi Mahmoudi M. Ayoub Maatallaoui
  • 4. Remerciement Nous aimerions commencer par remercier l'ensemble de l'équipe pédagogique de l’ISIMM et les intervenants professionnels responsables de la formation sciences de l’informatique, pour avoir assuré la partie théorique de celle-ci. Nous tenons à exprimer également notre profonde gratitude et nos remerciements les plus sincères à : Dr. Ramzi Mahmoudi Vous avez été bien plus qu'un simple encadrant pédagogique. Vous avez été un mentor attentionné, toujours prêt à écouter nos idées, à nous encourager et à nous pousser à donner le meilleur de nous- même. Vos retours constructifs et vos suggestions pertinentes ont contribué à affiner nos réflexions et à améliorer la qualité de notre travail. Mr. Ayoub Maatallaoui Pour votre encadrement et votre mentorat pendant cette période de stage. Votre expérience et vos conseils nous ont aidés à grandir professionnellement et à acquérir une compréhension approfondie du monde du travail. Les compétences que nous avons développées grâce à votre encadrement seront un atout précieux tout au long de nos carrière. Les membres du jury Qui ont accepté d’évaluer ce projet de fin d’études en espérant qu’ils trouvent dans ce rapport les qualités de clarté et de motivations qu’ils attendent.
  • 5. Dédicace Au moment où s'achève ce travail, il me tient à cœur d'exprimer ma gratitude envers : Mes Très chères Parents Que ce travail soit l'expression profonde de ma reconnaissance envers vous pour les sacrifices que vous avez consentis et le soutien moral et matériel que vous n'avez cessé de prodiguer. Que Dieu vous préserve en bonne santé et vous accorde une longue vie. Mes chères sœurs. Pour votre soutien tout au long de mes études, je tiens à exprimer ma reconnaissance infinie. Vous avez été présentes à chaque étape de ma vie académique, et grâce à vous, je suis devenu la personne que je suis aujourd'hui. Adem Amen Allah Thabti
  • 6. Dédicace Je dédie ce travail : À mes parents, pour tous les sacrifices qu’ils ont fait et pour tout le soutien qu’ils ont divulgué tout au long de mes études. J’espère qu’ils puissent trouver dans ce modeste travail un témoignage d’amour et d’affection envers eux. À chaque membre de ma famille pour leurs encouragements et leur continuel soutien... Pour n’en oublier aucun, à tous mes amis, qui ont été toujours présents... À tous ceux qui m’ont aidé afin de réaliser ce travail. À tous ceux que j’aime et qui m’aiment. Merci ! Mohamed Yassine Essid
  • 7. Table des matières Introduction générale 1 1 Contexte et Objectifs 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Contexte générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.1 Cadre du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.2 Présentation de l’entreprise d’accueil . . . . . . . . . . . . . . . . 3 1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3.1 Solutions existantes . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.5 Méthodologie de développement et modélisation . . . . . . . . . . . . . . 9 1.5.1 Étude de Méthodologie de développement . . . . . . . . . . . . . 10 1.5.2 Choix de la méthodologie de travail . . . . . . . . . . . . . . . . 12 1.6 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2 Capture des besoins 15 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 i
  • 8. 2.4 Besoins techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.1 Etude technologique . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.2 Etude architecturale . . . . . . . . . . . . . . . . . . . . . . . . . 25 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3 Conception 32 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.1 Conception générique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2 Urbanisation fonctionnelle en microservices . . . . . . . . . . . . . . . . 36 3.3 Microservice de « Gestion des utilisateurs » . . . . . . . . . . . . . . . . . 37 3.3.1 Diagramme de Cas d’utilisation associé au microservice « Gestion des utilisateurs » . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3.2 Description détaillée des cas d’utilisation associés au microservice « Gestion des utilisateurs » . . . . . . . . . . . . . . . . . . . . . . 38 3.3.3 Diagramme de séquence « S’authentifier » . . . . . . . . . . . . . 39 3.3.4 Description textuelle du cas d’utilisation « S’authentifier » . . . . 40 3.3.5 Diagramme de séquence « Modifier coordonnées » . . . . . . . . . 41 3.3.6 Description textuelle de cas d’utilisation « Modifier coordonnées » 42 3.3.7 Diagramme de séquence « Consulter les réclamations » . . . . . . 42 3.3.8 Description textuelle de cas d’utilisation « Consulter les réclama- tions » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3.9 Diagramme de composant « Gestion des utilisateurs » . . . . . . 44 3.3.10 L’architecture logicielle de Microservice « Gestion des utilisateurs » 45 3.4 Microservice de « Gestion des produits » . . . . . . . . . . . . . . . . . . 45 3.4.1 Diagramme de Cas d’utilisation associés au microservice « Gestion des Produits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.4.2 Description détaillée des cas d’utilisations associé au microservices « Gestion des Produits » . . . . . . . . . . . . . . . . . . . . . . . 47 3.4.3 Diagramme de séquence « Ajouter produit » . . . . . . . . . . . . 48 3.4.4 Description textuelle du cas d’utilisation « Ajouter un produit » . 48 ii
  • 9. 3.4.5 Diagramme de séquence « Evaluer produit » . . . . . . . . . . . . 49 3.4.6 Description textuelle du cas d’utilisation « Evaluer produit » . . . 50 3.4.7 Diagramme de composant associé au microservice « Gestion des produits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.4.8 L’architecture logicielle de microservice « Gestion des produits » 52 3.5 Microservice de « Gestion des commandes » . . . . . . . . . . . . . . . . 53 3.5.1 Diagramme de cas d’utilisation associé au microservice « Gestion des commandes » . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.5.2 Description détaillée des cas d’utilisation associé au microservice « Gestion des commandes » . . . . . . . . . . . . . . . . . . . . . 54 3.5.3 Diagramme de séquence « Passer une commande » . . . . . . . . . 54 3.5.4 Description textuelle du cas d’utilisation « Passer une commande » 56 3.5.5 Diagramme de composant associé au microservice « Gestion des produits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.5.6 L’architecture logicielle de microservice « Gestion des commandes » 58 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4 Réalisation 59 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.1 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . 59 4.1.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . 59 4.1.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . 60 4.2 Présentation de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2.1 Présentation de la solution web . . . . . . . . . . . . . . . . . . . 62 4.2.2 Présentation de la solution Mobile . . . . . . . . . . . . . . . . . . 66 4.2.3 Realisation des microservices . . . . . . . . . . . . . . . . . . . . . 71 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 iii
  • 10. Table des figures 1.1 Veredent Logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 DentalPlanet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Jumia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 eBay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Pictogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.6 2TUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.7 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.8 Diagramme de gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1 Les bases de données relationnelles les plus populaires . . . . . . . . . . . 24 2.2 Les bases de données non relationnelles les plus populaires . . . . . . . . 25 2.3 Architecture Monolithique . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4 Domain-Driven Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.5 Architecture Microservice . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.6 Architecture API Gateway Pattern . . . . . . . . . . . . . . . . . . . . . 30 2.7 Choix technologique de notre application . . . . . . . . . . . . . . . . . 31 3.1 Maquette préliminaire de l’interface login . . . . . . . . . . . . . . . . . . 33 3.2 Maquette préliminaire de l’interface d’accueil . . . . . . . . . . . . . . . . 34 3.3 Maquette préliminaire de l’interface dashboard de l’admin . . . . . . . . 34 3.4 Diagramme de classe globale . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.5 Diagramme de classe orienté microservices . . . . . . . . . . . . . . . . . 37 3.6 Diagramme de cas d’utilisation associé au microservice « Gestion des uti- lisateurs » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 iv
  • 11. 3.7 Les cas d’utilisation associés au microservice « Gestion des utilisateurs » 39 3.8 Diagramme de séquence« S’authentifier » . . . . . . . . . . . . . . . . . . 40 3.9 Diagramme de séquence « Modifier coordonnées » . . . . . . . . . . . . . 41 3.10 Diagramme de séquence« Consulter les réclamations » . . . . . . . . . . . 43 3.11 Diagramme de composant « Gestion des utilisateurs » . . . . . . . . . . 44 3.12 Architecture logicielle de microservice « Gestion des utilisateurs » . . . . 45 3.13 Diagramme de cas d’utilisation associés au microservice « Gestion des pro- duits » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.14 Diagramme de séquence « Ajouter un produit » . . . . . . . . . . . . . . 48 3.15 Diagramme de séquence « Evaluer produit » . . . . . . . . . . . . . . . . 50 3.16 Diagramme de composant associé au microservice « Gestion des produits » 52 3.17 Architecture logicielle de microservice « Gestion des produits » . . . . . 53 3.18 Diagramme de cas d’utilisation associé au Microservice « Gestion des com- mendes » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.19 Diagramme de sequence « Passer une commande » . . . . . . . . . . . . . 55 3.20 Diagramme de composant associé au microservice « Gestion des commandes » 57 3.21 Architecture logicielle de microservice « Gestion des produits » . . . . . 58 4.1 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.2 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.3 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.4 Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.5 Swagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.6 Nginx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.7 LYX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.8 LucidChart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.9 RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.10 Interface d’acceuil Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.11 Interface d’acceuil Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.12 Interface SignIn Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 v
  • 12. 4.13 Interface Login Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.14 Interface vendeur-dashboard . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.15 Interface authentification application mobile. . . . . . . . . . . . . . . . . 67 4.16 Authentification cas d’erreur . . . . . . . . . . . . . . . . . . . . . . . . 68 4.17 Interface d’accueil application mobile . . . . . . . . . . . . . . . . . . . . 68 4.18 Interface catégorie application mobile . . . . . . . . . . . . . . . . . . . . 69 4.19 Interface produit application mobile . . . . . . . . . . . . . . . . . . . . . 70 4.20 Interface evaluer produit application mobile . . . . . . . . . . . . . . . . 71 4.21 Les images docker des microservices . . . . . . . . . . . . . . . . . . . . 71 4.22 Swagger Figure 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.23 Swagger Figure2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.24 Communication synchrone avec RabbitMq . . . . . . . . . . . . . . . . . 75 4.25 Liste des queues RabbitMq . . . . . . . . . . . . . . . . . . . . . . . . . . 75 vi
  • 13. Liste des tableaux 1.1 Points forts et points faibles de DentalPlanet . . . . . . . . . . . . . . . 5 1.2 Point fort et point faible de Jumia . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Points forts et points faibles de eBay . . . . . . . . . . . . . . . . . . . . 7 1.4 Tableau compartif des solutions existantes . . . . . . . . . . . . . . . . . 8 1.5 Tableau comparatif des méthodologies de développement . . . . . . . . . 12 2.1 Besoins non fonctionelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2 Point forts et points faibles de React js . . . . . . . . . . . . . . . . . . . 19 2.3 Points forts et points faibles de Angular . . . . . . . . . . . . . . . . . . 20 2.4 Tableau comparatif entre les différents technologies Front-End Web . . . 20 2.5 Points forts et points faibles de React native . . . . . . . . . . . . . . . . 21 2.6 Points forts et points faibles de Flutter . . . . . . . . . . . . . . . . . . . 21 2.7 Tableau comparatif entre les différents technologies Front-End Mobile . . 21 2.8 Points forts et points faibles Spring Boot . . . . . . . . . . . . . . . . . . 22 2.9 Points forts et points faibles de NestJs . . . . . . . . . . . . . . . . . . . 23 2.10 Avantages et inconvénients des bases de données relationnels . . . . . . . 23 2.11 Avantages et inconvénients des bases de données non relationnels . . . . . 24 3.1 Description textuelle du cas d’utilisation « S’authentifier » . . . . . . . . 41 3.2 Description textuelle du cas d’utilisation « Modifier cordonnées » . . . . . 42 3.3 Description textuelle du cas d’utilisation« Consulter les réclamations » . 43 3.4 Les cas d’utilisation associés au microservice « Gestion des produits » . . 47 3.5 Description textuelle du cas d’utilisation « Ajouter Produit » . . . . . . . 49 vii
  • 14. 3.6 Description textuelle du cas d’utilisation « Evaluer produit » . . . . . . . 51 3.7 Tablau des cas d’utilisation associés au microservice « Gestion des com- mendes » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.8 Description scénariste du cas d’utilisation « Passer une commande » . . . 56 viii
  • 15. Liste des symboles 2TUP Two tracks unified process ACID Atomicity Consistency Isolation Durability AMQP Advanced Message Queuing Protocol API Application programming interface DDD Domain-Driven Design JSON JavaScript Object Notation REST REpresentational State Transfer 1
  • 16. LISTE DES SYMBOLES Introduction générale L’informatique joue un rôle de plus en plus important dans l’évolution de notre marché au cours des dernières décennies. Les technologies informatiques ont permis de nombreuses innovations, notamment dans le domaine de la communication, de l’automa- tisation des processus, de la gestion des données et de la connectivité entre les personnes et les organisations. Au vu de ce constat et de cette croissance, on ne peut pas négliger le passage des priorités des opérations de vente de main en main vers des ventes virtuelles ce qui nous oblige à donner plus d’importance à la vente électronique. Ce sont les boutiques élec- troniques qui accélèrent et facilitent les traitements traditionnels tels que les processus de commande et de facturation en offrant un accès facile et rapide aux produits. Le défi est alors de faire des internautes d’aujourd’hui nos futurs clients à travers une inter- face agréable et une plate-forme performante qui répondent aux besoins du client et lui facilitent la procédure d’achat des biens et des services. Les marketplaces jouent un rôle de plus en plus important dans le marché actuel en permettant aux entreprises de vendre leurs produits et services en ligne via une plate- forme unique. Elles ont créé un nouvel écosystème commercial, qui offre aux vendeurs une audience plus large et aux acheteurs une expérience d’achat plus pratique et plus complète. Les marketplaces offrent une variété de fonctionnalités telles que la gestion de stocks, la gestion des commandes et des paiements, ainsi que des outils de marketing, de communication et de service client. Elles permettent aux petites et moyennes entreprises de concurrencer les grands acteurs du marché en proposant leurs produits à un public plus large, sans avoir à investir dans des infrastructures coûteuses 1
  • 17. Chapitre 1 Contexte et Objectifs Introduction : Dans ce chapitre, nous présentons le contexte général de notre projet. Nous commen- çons par une introduction de l’organisation d’accueil. La deuxième partie sera consacrée à notre contexte global du projet, dans lequel nous présenterons la problématique et l’étude de ce qui existe, suivie de la solution proposée. Enfin, la dernière partie sera consacrée à la méthodologie de travail adoptée. 1.1 Contexte générale 1.1.1 Cadre du projet Le présent travail s’inscrit dans le cadre du projet de fin d’études en vue de l’obtention du diplôme National de Licence en Sciences Informatique de l’Institut Supérieur d’Infor- matique et Mathématiques de Monastir (ISIMM) pour l’année universitaire 2022/2023, dans lequel nous allons concevoir et implémenter une solution web et mobile d’une mar- ketplace basée sur l’architecture microservice de la société Veredent spécialisée dans le domaine dentaire. 2
  • 18. CHAPITRE 1. CONTEXTE ET OBJECTIFS 1.1.2 Présentation de l’entreprise d’accueil Veredent est une startup dédiée à faciliter la connexion des praticiens dentaires avec leur communauté et à les aider à rester à jour avec les dernières avancées de leur domaine. Grâce à une application mobile, Dentallx, et d’autres outils innovants, Dentallx permet aux dentistes de se connecter et d’échanger avec d’autres professionnels de la santé bucco- dentaire, de partager leurs connaissances et d’accéder à des ressources précieuses. De plus, Dentallx facilite la relation entre les praticiens et leurs fournisseurs de produits en offrant un accès simplifié à un large éventail de fournisseurs, de promotions exclusives et d’informations sur les produits. Cette plateforme interactive permet aux dentistes de rester à l’avant-garde de leur profession, en améliorant leur pratique quotidienne et en renforçant leur réseau professionnel. Avec Dentallx, les praticiens dentaires sont connectés, informés et prêts à offrir des soins de qualité supérieure à leurs patients. Figure 1.1 – Veredent Logo 1.2 Problématique Malgré l’avènement de la technologie et d’Internet, l’achat et la vente de produits et de services en ligne sont confrontés à des problèmes de fiabilité et de sécurité. Les systèmes complexes peuvent rendre les transactions en ligne difficiles et peu fiables pour 3
  • 19. CHAPITRE 1. CONTEXTE ET OBJECTIFS les utilisateurs. Mais Il est important de souligner que pour s’aligner davantage sur les besoins du client, les développeurs peuvent opter pour des solutions sur mesure, qui répondent à des exigences spécifiques. Cela permet aux clients de bénéficier d’un système personnalisé qui répond à leurs besoins spécifiques, tout en offrant des avantages tels que des fonctionnalités uniques et une expérience utilisateur améliorée. Cela peut sembler pratique au début, mais à mesure que le système grandit, il devient de plus en plus difficile de le gérer et de le maintenir. Les développeurs peuvent avoir du mal à comprendre comment le code est structuré, ce qui peut rendre la détection et la correction des erreurs plus difficiles. En 2018, Amazon a connu une panne technique majeure lors de son événement annuel Prime Day. Le site Web et l’application ont été indisponibles pendant plusieurs heures, empêchant les utilisateurs d’accéder au site Web, d’effectuer des achats et de profiter d’offres exclusives. Certains ont émis l’hypothèse que le trafic important sur le site Web pendant l’événement aurait pu surcharger les serveurs de l’entreprise et provoquer la panne. La panne a provoqué l’insatisfaction des clients et la perte de ventes sur Amazon. Amazon s’est par la suite excusé et s’est engagé à travailler pour éviter de tels problèmes à l’avenir. 1.3 Etude de l’existant La réalisation de tout projet doit être précédée par une étude de l’existant qui dé- termine les points faibles et les points forts des systèmes actuels et les besoins du client en vue de les prendre en considération lors de la conception et de la réalisation. Cette étude nous permet de dégager et donner leurs atouts et leurs faiblesses an de déterminer les besoins et les traiter. 1.3.1 Solutions existantes • DentalPlanet Dental Planet, Figure1.2, est une plateforme en ligne complète dédiée à l’industrie den- taire. Elle est conçue comme une destination unique pour les professionnels dentaires et les patients, offrant une large gamme de ressources et de services[1]. 4
  • 20. CHAPITRE 1. CONTEXTE ET OBJECTIFS Figure 1.2 – DentalPlanet Points forts Points faibles -Vaste sélection de produits : Dental Planet propose un catalogue étendu de matériel dentaire, de fournitures et d’instruments, offrant aux professionnels dentaires un large choix pour répondre à leurs besoins spécifiques. - Limitations géographiques : Dental Planet peut avoir des limitations géographiques en termes de livraison et de disponibilité de services. Certains utilisateurs peuvent être exclus de certains avantages ou options offerts par la plateforme en raison de leur emplacement géographique. - Support client limité : Il peut arriver que le support client de Dental Planet ne soit pas aussi réactif ou disponible que souhaité. Cela peut entraîner des retards dans le traitement des questions ou des problèmes rencontrés par les utilisateurs. Table 1.1 – Points forts et points faibles de DentalPlanet • Jumia Jumia, illustrée par la figure 1.3, est une marketplace en ligne, présent dans 14 pays afri- cains. Il met en relation des vendeurs et des acheteurs en mettant à leur disposition des fonctionnalités basiques tel que Gestion de commande, de profil la consultation de l’his- torique d’achats, la recherche filtrée, le retours et remboursements et les notifications[2]. 5
  • 21. CHAPITRE 1. CONTEXTE ET OBJECTIFS Figure 1.3 – Jumia Le tableau ci-dessous représente quelques points forts et points faibles de Jumia. Points Forts Points Faibles -Accessibilité facile et disponible sur Web,Android et IOS - interface chargé de publicité. Table 1.2 – Point fort et point faible de Jumia • eBay eBay ,voir figure1.4 , est une plateforme de commerce électronique qui permet aux utilisa- teurs d’acheter et de vendre une grande variété de produits, allant des produits neufs aux articles d’occasion. Fondée en 1995, eBay est devenue l’une des plus grandes entreprises de vente en ligne dans le monde, avec des millions d’utilisateurs actifs chaque jour. Les utilisateurs peuvent acheter des produits dans une grande variété de catégories, y compris l’électronique, la mode, la maison et le jardin, les bijoux, les jouets et les jeux, et bien plus encore. Les vendeurs peuvent créer des annonces pour leurs produits, ajouter des images et des descriptions détaillées, et fixer des prix de vente aux enchères ou des prix d’achat immédiat. eBay propose également une large gamme d’options de paiement et de livraison pour les acheteurs et les vendeurs [3] . 6
  • 22. CHAPITRE 1. CONTEXTE ET OBJECTIFS Figure 1.4 – eBay Le tableau 1.3 représente quelque point forts et faible de eBay. Points Forts Points Faibles - Grande Audience - Un système de protection de l’acheteur : eBay dispose d’un système de protection de l’acheteur qui peut aider à protéger les acheteurs contre les vendeurs malhonnêtes ou les produits défectueux. - Risque de fraudes : Comme eBay est une plateforme de commerce électronique ouverte, il peut y avoir un risque de fraudes ou d’arnaques de la part de certains vendeurs malhonnêtes. - Enchères compétitives : Alors que les enchères peuvent être une bonne façon de trouver des produits rares ou difficiles à trouver, cela peut également conduire à des enchères compétitives et à des prix élevés. Table 1.3 – Points forts et points faibles de eBay 1.3.2 Critique de l’existant Nous pouvons classer le résultat de l’analyse des applications web existantes mention- nées précédemment selon cinq critères pris en considération dans le processus d’évaluation de ses applications : • Interface utilisateur et Attirance : Le visiteur doit se sentir ciblé, il faut qu’il soit attiré par le site et que sa navigation soit orientée et balisée. C’est ici que l’apparence du site sera évaluée. 7
  • 23. CHAPITRE 1. CONTEXTE ET OBJECTIFS • Application Mobile associé : Avoir un site n’est pas de tout repos, avec une société et des internautes toujours plus exigeants. Il faut être en mesure de leur fournir une meilleure expérience et améliore la disponibilité du contenu, pour cela on a pris en considération dans l’évaluation si l’application admet-elle une version mobile ou non ? • Espace client : Un espace client permet de faciliter les actions des utilisateurs tel que gérer ses coordon- nées, ses préférences, son adresse, etc. • Existance d’un Tableau de Bord : Un tableau de bord qui permet d’analyser et gérer les produits et les ventes dans chaque market . • Paiement en ligne sécurisé : Le paiement en ligne est aujourd’hui la méthode la plus simple et le plus rapide, en plus il est plus sécurisé que les méthodes classiques, donc pour cela on a choisi le paiement en ligne comme un critère dans l’évaluation des sites. Le tableau ci-dessous présente une comparaison entre les solution existantes. DentalPlanet Jumia eBay Interface utilisateur et attirance Passable Passable Passable Application Mobile associé Non Oui Oui Espace client Oui Oui Oui Gestion des Produits Non Oui Oui Paiement en ligne sécurisé Non Oui Oui Table 1.4 – Tableau compartif des solutions existantes 1.4 Solution proposée La solution proposée est l’utilisation d’une architecture de microservices pour construire une place de marché efficace et fiable. Cette approche permet de maintenir une sépara- tion claire entre les différentes fonctions de la plateforme, ce qui facilite la maintenance et l’extension de la plateforme tout en améliorant la fiabilité et la sécurité des transactions en ligne. En plus de cette architecture de microservices, il est également possible de déve- lopper une application web et mobile pour la plateforme. Cette application permettrait aux vendeurs de créer leur propre marché personnalisé avec leur liste de produits, des 8
  • 24. CHAPITRE 1. CONTEXTE ET OBJECTIFS catégories et des descriptions détaillées. Les acheteurs pourraient facilement naviguer et acheter des produits en utilisant cette application. Cette solution permettrait d’offrir une expérience de transaction en ligne simple et pratique pour tous les utilisateurs de la place de marché. Pictogramme Un pictogramme est une représentation visuelle simplifiée qui utilise des symboles ou des icônes pour transmettre rapidement et efficacement des informations. La figure ci-dessous présente notre solution sous forme d’un pictogramme illustrant graphiquement ses caractéristiques. Figure 1.5 – Pictogramme 1.5 Méthodologie de développement et modélisation Une méthodologie de travail est un ensemble de techniques et de procédures permet- tant d’organiser et de structurer efficacement le travail. Elle vise à améliorer la qualité du travail accompli et à optimiser le temps et les ressources utilisés pour atteindre des 9
  • 25. CHAPITRE 1. CONTEXTE ET OBJECTIFS objectifs spécifiques. Cette méthodologie comprend la planification, l’organisation, la prio- risation, l’exécution, le suivi et l’évaluation des phases, ainsi que l’utilisation d’outils et de techniques de gestion du temps. 1.5.1 Étude de Méthodologie de développement Devant le nombre de méthodes disponibles, le choix parmi elles devient difficile, beaucoup de questions peuvent se poser à un chef de projet lors d’un démarrage de projet. À cet égard, nous envisagerons plusieurs méthodes de développement, et selon cette recherche, nous choisissons au mieux la méthodologie qui correspend à notre projet. Méthodologie Two Tracked Unified Process La méthodologie 2TUP (Two Tracks Unified Process) est une méthode de dévelop- pement de logiciels qui combine deux approches de développement : l’approche dirigée par les cas d’utilisation (Use Case-Driven) et l’approche dirigée par les fonctionnalités (Feature-Driven). Cette méthode est basée sur le processus unifié (Unified Process) qui est un cadre de développement logiciel itératif et incrémental. L’approche dirigée par les cas d’utilisation (Use Case-Driven) se concentre sur la définition des exigences du système à partir des cas d’utilisation et sur la modélisation de ces exigences pour créer une représentation graphique du système. Cette approche est particulièrement utile pour comprendre les besoins des utilisateurs et les fonctionnalités du système. La figure ci-dessous présente un schéma de la La méthodologie 2TUP. Méthode Scrum Il s’agit d’une méthodologie de développement itérative et incrémentale qui met l’ac- cent sur la collaboration entre les membres de l’équipe et la fourniture de fonctionnalités utilisables aussi rapidement que possible. Elle est hautement adaptable et peut être uti- lisé dans des projets dont les exigences évoluent rapidement. Il s’agit d’une méthode agile axée sur la livraison de petits produits viables dans un court laps de temps. Les sprints (phases de travail intensives) sont utilisés pour atteindre les objectifs, et les membres de l’équipe se voient attribuer des rôles spécifiques[8]. La figure 1.7 illustre la méthodologie Scrum . 10
  • 26. CHAPITRE 1. CONTEXTE ET OBJECTIFS Figure 1.6 – 2TUP Figure 1.7 – Scrum Comparaison des méthodologies de développement Le tableau 1.5 représente une comparaison des méthodologies de développement : 11
  • 27. CHAPITRE 1. CONTEXTE ET OBJECTIFS Méthodologies Avantages Inconvénients 2 Track Unified Process (2TUP) - Documentation rigoureuse - Structuration claire - Facilité de validation -Économie d’espace -Fiabilité et tolérance aux pannes - Longue durée de développement - Inflexibilité Scrum - Livraison rapide de fonctionnalités - Collaboration : Scrum favorise la collaboration entre les membres de l’équipe, besoins de développement, les parties prenantes et le client, ce qui permet d’identifier rapidement les problèmes et de les résoudre de manière proactive. - Nécessité d’une implication continue des parties prenantes - Dépendance à l’égard de l’équipe auto-organisée - Difficulté de planification précise Table 1.5 – Tableau comparatif des méthodologies de développement 1.5.2 Choix de la méthodologie de travail Notre projet est basé sur un processus de développement bien défini qui va de la détermination des besoins fonctionnels attendus du système jusqu’à la conception et le codage final. Étant donné que nous avons une équipe de taille réduite, il est essentiel d’adopter une approche de développement qui dissocie les aspects techniques des aspects fonctionnels, tout en commençant par une étude préliminaire approfondie. Après une analyse comparative approfondie des différentes méthodes de développement[24], nous avons opté pour la méthode 2TUP. Cette méthode s’est avérée être une option adap- tée à notre projet, car elle offre une approche nouvelle et originale tout en respectant le cadre et les contraintes spécifiques de notre équipe et de notre projet. Mise en pratique du processus 2TUP 2TUP est un processus de développement logiciel qui implémente le processus unifié (c.à.d. itératif, incrémental, basé sur UML). Il propose un cycle de développement qui sépare les aspects techniques des aspects fonctionnels en partant du constat que toute évolution peut se traiter parallèlement, suivant un axe fonctionnel et un axe technique. Ensuite, et en fusionnant les résultats de ces deux axes (branches), on arrive à réaliser le système désiré. 12
  • 28. CHAPITRE 1. CONTEXTE ET OBJECTIFS 1. L’étude préliminaire : Elle a pour objectif de définir les grandes lignes du projet et d’évaluer sa faisabilité. 2. la capture des besoins fonctionnnels : Cette étape consiste à identifier et à documenter les fonctions et les caractéristiques du logiciel qui sont nécessaires pour satisfaire les besoins et les attentes des parties prenantes. 3. l’analyse : Elle consiste à examiner en détail les besoins des parties prenantes, à comprendre leurs problèmes et leurs attentes, à identifier les processus et les flux de travail impliqués dans le projet et à déterminer les contraintes techniques, financières et temporell es qui s’appliquent au projet. 4. la capture des besoins techniques : Elle consiste à identifier et à documenter les exigences techniques du logiciel, y compris les normes, les plateformes, les outils et les technologies nécessaires à la conception, au développement et à la maintenance du logiciel. 5. la conception générique : La conception générique consiste à élaborer la solu- tion qui répond aux exigences techniques qu’on à spécifié dans la partie « capture des besoins techniques » 6. la conception détaillée : Elle consiste à concevoir en détail chaque composant logiciel identifié lors de l’analyse et à décrire comment ces composants seront im- plémentés.La conception détaillée inclut des éléments tels que la modélisation des données, l’architecture logicielle, la conception de l’interface utilisateur, la concep- tion des algorithmes et des fonctions, ainsi que la définition de la structure et de la hiérarchie du code. 7. le codage et les tests : Le codage consiste à écrire le code source du logiciel en utilisant un langage de programmation approprié.Le but des tests est de s’assurer que le logiciel fonctionne correctement et répond aux spécifications de conception. 1.6 Diagramme de Gantt Un diagramme de Gantt est un outil de gestion de projet qui permet de visualiser les différentes tâches de votre projet et leur avancement dans le temps. Nommé d’après son inventeur Henry Gantt. 13
  • 29. CHAPITRE 1. CONTEXTE ET OBJECTIFS Figure 1.8 – Diagramme de gantt Conclusion Dans ce premier chapitre, nous avons réalisé une étude approfondie existante, ce qui nous a permis d’obtenir une base solide pour notre projet en mettant en évidence la solution souhaitable. Nous avons comparé plusieurs méthodes et conclu ce chapitre en présentant la méthodologie 2TUP que nous adopterons pour le développement de notre projet. Le chapitre suivant sera consacré à l’identification des besoins. 14
  • 30. Chapitre 2 Capture des besoins Introduction L’étape d’analyse et de spécification des besoins vise à déterminer les diverses fonc- tionnalités attendues du système. Dans ce chapitre, nous allons explorer comment les besoins fonctionnels, non fonctionnels et techniques peuvent être capturés en utilisant la méthode 2TUP. 2.1 Identification des acteurs Pour notre système nous avons identifié les acteurs suivants : • Internaute : c’est un visiteur de site , il peut consulter les Produits sur la page d’acceuil, comme il peut les rechercher. Il peut aussi créer un profil et devenir un client de la plateforme. • Client : c’est un internaute qui est inscrit, possède un compte, dans la plateforme. Il peut commander, consulter l’état de sa commande et évaluer des produits. • Vendeur : Est un fournisseur de produits qui utilise notre système pour vendre leurs produits à un large public. • Administrateur : L’administrateur est responsable de la maintenance et de la surveillance de la marketplace. Ses tâches incluent la gestion des utilisateurs, la 15
  • 31. CHAPITRE 2. CAPTURE DES BESOINS résolution des problèmes techniques et la conformité aux réglementations. 2.2 Besoins fonctionnels Les besoins fonctionnels sont les exigences qui décrivent ce que le système doit faire ou comment il doit fonctionner. Ils décrivent les fonctionnalités ou les services que le système doit fournir pour répondre aux besoins de l’utilisateur final. Dans la suite, nous allons exposer les besoins fonctionnels de notre application en étroite relation avec les acteurs précédemment mentionnés. L’internaute (Visiteur) détient le droit de : • Consulter le site : consiste à accéder à la plateforme via un navigateur web ou l’application mobile et à consulter les produits et les markets proposés. • Créer compte : consiste à s’inscrire dans la platefrome en fournissant des infor- mations personnelles. • Rechercher un produit : consiste à effectuer une recherche pour trouver un produit ou une boutique (fournisseur de produits). le client (acheteur) détient le droit de : • Gérer Panier : permet aux utilisateurs d’ajouter, modifier et supprimer des produits de leur panier sur notre marketplace, avant de passer à la commande. • Passer commande : consiste à passer la commande en ligne en validant les produits selectionnées, en saisissant les informations nécessaire pour valider la commande. • Evaluer un produit : consiste à attribuer une note et à laisser un commentaire sur un produit acheté ou utilisé précédemment sur la plateforme. • Passer une réclamation : consiste à signaler un problème ou une insatisfaction concernant un produit ou un service acheté auprès d’un vendeur ou d’un service client sur la plateforme. • Modifier Coordonnées : permet aux utilisateurs de mettre à jour leurs infor- mations personnelles telles que leur adresse, leur numéro 16
  • 32. CHAPITRE 2. CAPTURE DES BESOINS le vendeur détient le droit de : • Ajouter un nouveau produit : consiste à créer une nouvelle fiche produit en y ajoutant les informations du produit, telles que la description, les images, le prix, etc. • Modifier un produit : consiste à mettre à jour les propriété d’un produit déja ajouter dans la plateforme. • Gérer ses commandes : consiste à suivre et à traiter les commandes passées par les clients, en expédiant les produits et en mettant à jour les statuts de commande. • Supprimer un produit : consiste à retirer une fiche produit existante, généra- lement en raison de la fin de la disponibilité ou de la décision de ne plus proposer le produit. • Modifier infromations personnelle et boutique : permet aux vendeur de mettre à jour leurs informations personnelles telles que leur adresse, leur numéro L’administrateur détient le droit de : • Gérer les comptes des clients : consiste à surveiller et à gérer les informations des utilisateurs, en traitant les demandes de suppression de compte, en vérifiant les informations d’identification et en gérant les problèmes de sécurité. • Gérer les Produits : consiste à superviser et contrôler les différentes fonction- nalités liées aux produits sur la plateforme • Consulter les réclamations : recevoir, traiter et résoudre les réclamations des clients, telles que les retours, les remboursements, les plaintes et les litiges, en veillant à ce que les politiques et procédures de l’entreprise soient suivies et que les clients soient satisfaits. 2.3 Besoins non fonctionnels Les besoins non fonctionnels décrivent toutes les conditions requises permettant d’as- surer le bon fonctionnement du système et d’améliorer la qualité des services pour l’uti- lisateur. Pour notre platform ces exigences fonctionnelles doivent être décomposées en 17
  • 33. CHAPITRE 2. CAPTURE DES BESOINS microservices pour une architecture flexible, évolutive et maintenable. On a défini les besoins non fonctionnels suivants : Ergonomie : Tous les standards d’ergonomie doivent être res- pectés dont la convivialité et la compréhensibilité des interfaces graphiques. De plus, le choix des couleurs, la densité et l’or- ganisation des éléments sur l’écran et aussi l’utilisation des messages informatifs et des messages d’erreurs bien formées et bien lisibles. Disponibilité : Le système doit être hautement disponible, avec une faible tolérance aux pannes, pour garantir une expé- rience utilisateur fluide et ininterrompue. Évolutivité : L’architecture microservices doit permettre l’évolutivité facile des différents services, en fonction des be- soins du système, sans affecter les autres services. Intégration : Les différents services doivent être facilement intégrables et compatibles avec d’autres applications tierces, afin de permettre une intégration facile avec des systèmes exis- tants. Cohérence : L’ensemble du système doit être cohérent et fonc- tionner de manière homogène, afin de garantir une expérience utilisateur transparente et cohérente. Performance : Le système doit être rapide et répondre rapi- dement aux demandes des utilisateurs, en minimisant les temps de latence et les temps d’arrêt. Sécurité : Le système doit être sécurisé et protéger les don- nées sensibles des utilisateurs, telles que les informations de paiement et les données personnelles. Table 2.1 – Besoins non fonctionelles 2.4 Besoins techniques Nous nous intéressons ici à la branche droite du cycle en Y « Capture des besoins techniques » qui capitalise le savoir-faire technique. Afin de bien expliquer nos choix technologiques, nous avons fait recours à une étude comparative entre les différentes technologies qui peuvent être utilisés durant notre projet. 18
  • 34. CHAPITRE 2. CAPTURE DES BESOINS 2.4.1 Etude technologique Dans la partie suivante nous présentons les Framework Front-End et Back-End que nous allons utiliser pour le développement de notre application Web et Mobile. Front-End Web Le nombre des technologies de développement des applications web (coté client) est en croissance continue. Parmi les langages les plus populaires nous citons : React.js est une bibliothèque JavaScript open-source qui est utilisée pour construire des interfaces utilisateur spécifique- ment pour des applications d’une seule page. Elle est utilisée pour gérer la couche d’affichage des applications web.React permet aux développeurs de créer de grandes applications web qui peuvent modifier les données, sans avoir à recharger la page. Points forts Points faibles -Virtual DOM efficace -Composants réutilisables -Flux de données unidirectionnel -Grande communauté de développeurs -Courbe d’apprentissage initiale -Complexité croissante avec des applications complexes -Taille de la bibliothèque et temps de chargement potentiellement plus longs. Table 2.2 – Point forts et points faibles de React js AngularJS est un framework JavaScript open-source déve- loppé par Google en 2010. Il est conçu pour simplifier la créa- tion d’applications web complexes en offrant une approche structurée pour organiser le code. 19
  • 35. CHAPITRE 2. CAPTURE DES BESOINS Points Forts Points Faibles - Angular est basé sur une architecture MVC qui facilite la structuration et la maintenance du code. - Il dispose d’une vaste gamme de fonctionnalités et de modules prêts à l’emploi pour faciliter le développement. - Angular est compatible avec de nombreux autres outils et technologies, tels que TypeScript, RxJS, Ionic, etc., ce qui permet de créer des applications multiplateformes. - Les directives personnalisées d’Angular peuvent nécessiter une configuration et un développement supplémentaires, ce qui peut prendre du temps et ajouter de la complexité au projet. - Les mises à jour fréquentes d’Angular peuvent également poser des problèmes de compatibilité avec les anciennes versions, ce qui peut nécessiter des efforts supplémentaires pour la maintenance et la mise à jour des applications existantes. Table 2.3 – Points forts et points faibles de Angular Vue Js React Js Angular Js Performance Moyen Haute Haute Scalabilité Faible Haute Haute Apprentissage Facile Facile Moyen Communité des développeurs Petite Très grande Grande Acceptation et confiance Faible Haute Haute Table 2.4 – Tableau comparatif entre les différents technologies Front-End Web Front-End Mobile Le développement mobile peut être divisé en deux catégories principales : le déve- loppement natif et le développement multiplateforme. • Le développement natif : implique la création d’applications spécifiques à une plateforme particulière . • Le développement multiplateforme : permet de créer une application unique qui peut être déployée sur plusieurs plateformes différentes. Le développement multiplateforme est une option intéressante lorsque vous souhaitez réduire les coûts et les efforts de développement en créant des applications qui doivent fonctionner sur plusieurs plateformes différentes. Cependant, cela peut entraîner une ex- périence utilisateur sous-optimale et des performances plus lentes que le développement natif. Il existe plusieurs technologies multiplateformes populaires qui vous permettent de développer des applications mobiles pour plusieurs plates-formes différentes à l’aide d’un 20
  • 36. CHAPITRE 2. CAPTURE DES BESOINS seul ensemble de code source. Les trois technologies multiplateformes les plus couramment utilisées sont React Native, Xamarin et Flutter. React Native est une plateforme de développement multipla- teforme open source développée par Facebook qui vous aide à développer des applications mobiles pour iOS et Android à l’aide de JavaScript et React. Points Forts Points Faibles - Grande communauté de soutien - Développement rapide et facile grâce à l’utilisation de JavaScript - Performances moins rapides que le développement natif - Peut nécessiter des configurations spécifiques pour les différentes plateformes Table 2.5 – Points forts et points faibles de React native Flutter est une plate-forme de développement multiplate- forme open source développée par Google pour développer des applications mobiles pour iOS, Android et le Web à l’aide du langage de programmation Dart. Points Forts Points Faibles - Offre une qualité d’interface utilisateur élevée grâce à son architecture moderne - Développement rapide et facile grâce à l’utilisation de Dart et du hot reloading - Moins de support et de documentation par rapport à React Native ou Xamarin. - Peut nécessiter des connaissances en Dart Table 2.6 – Points forts et points faibles de Flutter React Native flutter Performance Moyen Haute Scalabilité Moyen Haute Apprentissage Moyen Moyen Communité des développeurs Très grande Tres grande Acceptation et confiance Moyen Haute Table 2.7 – Tableau comparatif entre les différents technologies Front-End Mobile Back-End Le Back-End, qui est invisible pour le client, représente une grande partie du déve- loppement de notre projet. On peut décomposer le Back-End en deux parties essentielles : 21
  • 37. CHAPITRE 2. CAPTURE DES BESOINS Services métier les services métier occupent une place centrale en tant que respon- sables de la logique applicative qui gère les fonctionnalités clés de la plateforme. Ils sont chargés de mettre en œuvre les règles métier spécifiques à la marketplace . Les services métier peuvent être développés en utilisant différents frameworks adap- tés, tels que Spring Boot et NestJS, qui offrent des fonctionnalités de développement robustes et une structure modulaire. Examinons de plus près les caractéristiques de chacun de ces frameworks Spring Boot est l’un des frameworks les plus utilisés pour le développement d’applications backend, y compris les Services Métier. Basé sur Java, un langage de programmation largement adopté dans l’industrie, Spring Boot offre un écosystème riche et mature. Il dispose d’une vaste gamme de bibliothèques et de modules pour gérer des fonctionnalités telles que l’injection de dépendances, la persistance des données et la sécurité. Points Forts Points Faibles - Spring Boot bénéficie d’un écosystème Java mature et étendu, offrant une multitude de bibliothèques, de modules et d’outils pour le développement d’applications backend. - Spring Boot dispose d’une communauté très active et d’une documentation complète. - il peut y avoir une courbe d’apprentissage initiale plus longue pour les développeurs moins familiers avec le framework ou le paradigme de programmation Spring. - Configuration parfois complexe Table 2.8 – Points forts et points faibles Spring Boot NestJs NestJS est un framework basé sur JavaS- cript/TypeScript qui gagne en popularité pour le déve- loppement d’applications backend, y compris les Services Métier. Il offre une architecture basée sur les modules, ce qui facilite l’organisation du code en composants réutilisables. 22
  • 38. CHAPITRE 2. CAPTURE DES BESOINS Points Forts Points Faibles - Fortement basé sur TypeScript, offrant une expérience de développement plus solide grâce à la typage statique, à l’autocomplétion et à la détection précoce des erreurs. - Adopte une architecture modulaire qui facilite la structuration du code en composants réutilisables. Cela permet de développer des applications bien organisées et faciles à maintenir. - Communauté relativement plus petite Table 2.9 – Points forts et points faibles de NestJs Base de Données Les bases de données sont essentielles pour gérer des informations de manière orga- nisée et cohérente, offrant ainsi un support précieux pour la prise de décision et l’analyse des données, on peut citer deux types de base de données (relationnels et non relation- nels). Dans le cas de notre application nous allons utiliser les deux types de bases de données selon les besoins de chaques services. • Base de données relationnels[5] : Une base de données relationnelle est un type de base de données où les données sont liées à d’autres informations au sein des bases de données. Les bases de données relationnelles sont composées d’un ensemble de tables qui peuvent être accessibles et reconstruites de différentes manières, sans qu’il soit nécessaire de réarranger ces tables de quelque façon que ce soit. Le langage de requête structuré (SQL) est l’interface standard pour une base de données relationnelle. Avatages Inconvénients - Capacité de gérer des relations complexes - Puissance des requêtes complexes - Structure et intégrité des données - Normalisation des données - Difficulté avec les données semi-structurées ou non structurées - Complexité des requêtes et de la modélisation - Rigidité du schéma Table 2.10 – Avantages et inconvénients des bases de données relationnels 23
  • 39. CHAPITRE 2. CAPTURE DES BESOINS Figure 2.1 – Les bases de données relationnelles les plus populaires • Base de données non relationnels (NOSQL)[5] : Les bases de données non rela- tionnelles sont conçues pour gérer de grandes quantités de données non structurées ou semi-structurées, telles que des documents, des graphes, des paires clé-valeur ou des données en colonnes. Elles offrent une flexibilité accrue pour évoluer hori- zontalement et supporter des charges de travail distribuées à grande échelle. Avatages Inconvénients - Gestion de données non structurées - Évolutivité horizontale - Flexibilité de schéma - Haute performance - Moins adaptées aux requêtes complexes - Moins de support et de documentation - Manque de normalisation Table 2.11 – Avantages et inconvénients des bases de données non relationnels 24
  • 40. CHAPITRE 2. CAPTURE DES BESOINS Figure 2.2 – Les bases de données non relationnelles les plus populaires 2.4.2 Etude architecturale Dans cette partie , nous explorerons les principes fondamentaux des différentes ar- chitecture, en mettant l’accent sur les avantages et les considérations clés de chacune. Nous examinerons également les principes de conception sous-jacents qui guident la mise en œuvre de chaque architecture. Architecture Monolithique Une architecture monolithique est un style de développement logiciel dans lequel toutes les fonctionnalités d’une application sont regroupées dans un seul bloc de code. Cela signifie que l’application est construite, testée et déployée comme une seule unité. Les architectures monolithiques sont généralement utilisées pour des applications simples et peu complexes, mais peuvent devenir difficiles à gérer à mesure que les applications deviennent plus grandes et plus complexes. Les mises à jour et les modifications peuvent également être plus difficiles à mettre en œuvre dans une architecture monolithique[4]. 25
  • 41. CHAPITRE 2. CAPTURE DES BESOINS Figure 2.3 – Architecture Monolithique Inconvénients de l’architecture monolithique Les principaux inconvénients de l’approche monolithique sont les suivants : • Risque accru de défaillance : si une partie de l’application échoue, cela peut entraîner l’arrêt de l’ensemble du système. • Difficulté de mise à l’échelle : Lorsque le trafic augmente et que l’application doit être mise à l’échelle pour gérer la charge, l’architecture monolithique peut poser des défis. • Inconvénients Extensibilité limitée : L’architecture monolithique peut devenir difficile à étendre lorsque de nouvelles fonctionnalités doivent être ajoutées. • Déploiement complexe : Les applications monolithiques nécessitent souvent un déploiement complet pour apporter des modifications, ce qui peut entraîner des temps d’arrêt plus longs. Architectures microservices Ce partie se focalise sur les concepts fondamentaux en lien avec notre travail. Tout d’abord, nous abordons les concepts liés à l’architecture Microservices Les concepts liés à l’architecture microservices • Le Domain Driven Design Le DDD pour « Domain-Driven Design » [9]est appelé en français «Conception pilotée par le domaine» est une approche de conception logicielle qui se concentre sur la com- préhension approfondie du domaine métier d’une application. Cette approche permet de 26
  • 42. CHAPITRE 2. CAPTURE DES BESOINS développer des logiciels plus proches des besoins réels des utilisateurs, en utilisant un vocabulaire et des concepts communs à tous les acteurs du projet. Le Domain Driven Design (DDD) utilise le principe de Bounded Context pour découper le domaine métier d’une application en plusieurs parties cohérentes et autonomes. Chaque Bounded Context possède son propre vocabulaire, modèles et règles métier, et est délimité par des interfaces claires et précises qui définissent les interactions avec les autres contextes. Cette approche permet de mieux gérer la complexité des applications en permettant à chaque contexte de gérer sa propre logique métier de manière indépendante. La mise en œuvre de Bounded Context peut aider à résoudre des problèmes tels que la coordination des équipes de développement et la mise à l’échelle de l’application. Figure 2.4 – Domain-Driven Design • Le développement à base de composants Le développement à base de composant est une branche de l’ingénierie logicielle consiste à découper une application en plusieurs composants autonomes, chacun étant responsable d’une fonctionnalité spécifique. Les composants sont conçus pour être réutilisables, ce qui permet de les assembler de manière flexible pour créer des applications plus grandes et plus complexes. • Programmation polyglotte En 2000, Scott Leberknight [6] a introduit le terme "programmation polyglotte" (Polyglot Programming), qui consiste à utiliser plusieurs langages de programmation pour résoudre différents types de problèmes dans une application. Les applications complexes peuvent bénéficier de cette approche en choisissant le langage le mieux adapté à chaque tâche. Ce concept peut également s’appliquer aux bases de données . 27
  • 43. CHAPITRE 2. CAPTURE DES BESOINS • Iolation des microservices dans des conteneurs (conteneurisation) : L’isolation des microservices dans des conteneurs est une pratique clé de l’architecture microservice. Chaque microservice est encapsulé dans un conteneur léger et autonome qui contient tous les éléments nécessaires à son fonctionnement. Cette isolation assure une meilleure stabilité et résilience de l’architecture, tout en permettant une gestion plus flexible des ressources informatiques. En résumé, l’isolation des microservices dans des conteneurs est un élément essentiel pour une architecture microservice efficace et évolutive[10]. Définition de l’architecture Microservice L’architecture microservices[4] est une approche de développement logiciel qui consiste à construire une application en la décomposant en un ensemble de services indépendants, autonomes et spécialisés, chacun exécutant une tâche spécifique. Chaque service est conçu pour fonctionner de manière autonome, en communiquant avec les autres services via une interface bien définie. Cette architecture est basée sur le principe de la séparation des préoccupations et de la modularité, ce qui permet une plus grande flexibilité et une évolutivité accrue. Figure 2.5 – Architecture Microservice Les avantages de l’architecture microservice Les avantages de l’architecture de microservices incluent : • Évolutivité : Les services peuvent être développés, déployés et évalués indépen- damment les uns des autres, permettant une évolutivité horizontale et une utili- 28
  • 44. CHAPITRE 2. CAPTURE DES BESOINS sation plus efficace des ressources. • Agilité : Les petites équipes peuvent travailler sur des services individuels, ce qui permet une plus grande flexibilité et une itération plus rapide. • Résilience : Si un service tombe en panne, les autres services continuent de fonctionner, réduisant l’impact des pannes. • Réutilisation : Les services peuvent être réutilisés dans différentes applications et les nouvelles fonctionnalités peuvent être développées sans perturber les services existants. • Technologie adaptée : Les services peuvent être développés dans différents lan- gages de programmation et utiliser différentes technologies de stockage de données en fonction de leurs besoins spécifiques. • Mise à l’échelle : Les services peuvent être mis à l’échelle individuellement en fonction des besoins de l’application. Choix architectural et technologique Choix architectural Pour la mise en œuvre de notre application, nous avons choisi une architecture basée sur les microservices. Cette approche architecturale divise notre système en plusieurs services indépendants et spécialisés, appelés microservices, qui interagissent entre eux pour offrir les fonctionnalités de l’application. Chaque microservice est responsable d’une partie spécifique du système, ce qui permet une séparation claire des préoccupations et une évolutivité horizontale. Nous adoptons le patron de passerelle API, qui permet de centraliser la ges- tion des requêtes provenant des clients en fournissant une interface unique. Il offre des fonctionnalités telles que la mise en cache, la limitation du débit, la transformation des données et la sécurité. Au lieu de devoir contacter chaque service individuellement, les clients envoient leurs requêtes à l’API Gateway, qui se charge de les router vers les services appropriés. [7]. 29
  • 45. CHAPITRE 2. CAPTURE DES BESOINS Figure 2.6 – Architecture API Gateway Pattern Choix technologique Nous avons sélectionné un ensemble de technologies robustes et performantes pour la mise en œuvre de notre solution : • Angular pour le frontend web • Flutter pour l’application mobile • Nginx en tant que passerelle API « Api Gateway » — Pour gérer et sécuriser la communication entre nos microservices et les clients, nous utiliserons Nginx en tant que passerelle API. Nginx agit comme un proxy inverse, gérant les requêtes des clients et les redirigeant vers les microservices appropriés. • Nous avons décidé d’adopter une approche hybride en utilisant à la fois PostgreSQL et MongoDB. — Nous avons opté pour MongoDB pour les services qui nécessitent une grande flexibilité de schéma et une évolutivité horizontale. — D’autre part, pour les services qui exigent un modèle de données relationnel plus strict et des transactions ACID nous avons choisi PostgreSQL. • RabbitMQ comme courtier de messages « Message Broker » — Pour faciliter la communication asynchrone et découpler les services, nous avons intégré RabbitMQ en tant que courtier de messages. RabbitMQ prend en charge le modèle d’édition-souscription, permettant aux microservices d’échanger des 30
  • 46. CHAPITRE 2. CAPTURE DES BESOINS messages de manière efficace. Cela permet une communication évolutive et résiliente entre les différentes composantes de notre système. La figure ci-dessous illustre l’architecture technologique choisie pour notre solution . Figure 2.7 – Choix technologique de notre application Conclusion Dans ce chapitre, nous avons également documenté diverses exigences du projet. Nous classons ces besoins en besoins fonctionnels, besoins non fonctionnels et besoins techniques. 31
  • 47. Chapitre 3 Conception Introduction Cette partie traite des aspects conceptuels de la conception orientée microservices de l’application. Contrairement aux approches traditionnelles, cette conception se base sur la création de services indépendants et autonomes, chacun ayant une fonctionnalité spéci- fique. La mise en œuvre de cette architecture repose sur une méthodologie de conception par service, où chaque service est conçu de manière autonome, indépendante des autres services. Cette approche offre une flexibilité marquante, permettant une évolutivité facile et une meilleure gestion de la complexité de l’application. Nous utiliserons pour cela le format UML, en créant des diagrammes spécifiques pour chaque service. 3.1 Conception générique La phase de conception permet de décrire de manière ambigüe, le plus souvent en uti- lisant un langage de modélisation, le fonctionnement futur du système, afin d’en faciliter la réalisation. 32
  • 48. CHAPITRE 3. CONCEPTION Le language UML Pour faciliter notre tâche nous avons fait recours au langage de modélisation unifié « UML » (Unified Modeling Language) qui permet de modéliser un problème de façon standard. Ce langage qui est né de la fusion de plusieurs méthodes existantes auparavant est devenu une référence en termes de modélisation objet[23] : • Il permet le gain, encourage l’utilisation d’outils et constitue à cet effet un gage de stabilité. • Il cadre l’analyse et facilite la compréhension de représentations abstraites com- plexes. • Il est formel et normalisé : son caractère polyvalent et sa souplesse en font un langage universel. Conception préliminaire des interfaces-Prototypes Une maquette est un produit jetable donnant aux utilisateurs une vue concrète mais non définitive de la future interface de l’application. Elle est développée rapidement afin d’améliorer la relation développeur-client. Les maquettes de notre application sont les suivantes : Figure 3.1 – Maquette préliminaire de l’interface login 33
  • 49. CHAPITRE 3. CONCEPTION Figure 3.2 – Maquette préliminaire de l’interface d’accueil Figure 3.3 – Maquette préliminaire de l’interface dashboard de l’admin 34
  • 50. CHAPITRE 3. CONCEPTION Diagramme de classe globale Un diagramme de classe dans le langage UML est un type de diagramme de structure statique qui décrit la structure d’un système en montrant le système de classes, leurs attributs, les opérations (ou) les méthodes et les relations entre les classes. La figure ci-dessous illustre bien le diagramme de classe globale de notre système. Figure 3.4 – Diagramme de classe globale 35
  • 51. CHAPITRE 3. CONCEPTION 3.2 Urbanisation fonctionnelle en microservices Dans le cadre de notre application, nous avons adopté une architecture basée sur les microservices en nous appuyant sur les principes de la conception orientée domaine (DDD). Cette approche nous permet de diviser notre système en services indépendants et orientés, alignés sur les concepts clés de notre domaine métier. Nous avons défini précédemment le DDD comme étant la « Conception pilotée par le domaine », une approche de conception logicielle qui se concentre sur la compréhension approfondie du domaine métier de notre application (voir page 27 pour plus de détails). nous avons identifié plusieurs services, dont User Management, Product Management, Command Management, et Payment. • Le micro-service Gestion des utilisateurs est responsable de la gestion de tous les utilisateurs liés, y compris les clients et les vendeurs. • Le micro-service Gestion des produits est chargé de la gestion des produits proposés par les vendeurs. • Le micro-service Gestion des commandes se concentre sur la gestion des com- mandes passées par les clients et recus aux vendeurs. • Enfin, le micro-service Paiement est spécifiquement dédié à la gestion des paie- ments. Pour mieux illustrer l’implémentation pratique de notre architecture, nous avons créé un deuxième diagramme de classe, dans la figure ci-dessous, qui regroupe chaque classe avec le service auquel elle appartient. Nous utilisons des cercles pour représenter ces regrou- pements, ce qui permet de visualiser clairement l’organisation des classes en fonction des services. 36
  • 52. CHAPITRE 3. CONCEPTION Figure 3.5 – Diagramme de classe orienté microservices 3.3 Microservice de « Gestion des utilisateurs » Dans le contexte des microservices, la gestion d’utilisateurs peut être traitée comme un service autonome, responsable de toutes les opérations liées aux comptes utilisateurs. Cela permet de simplifier la maintenance et l’évolution de ces fonctionnalités, tout en offrant des interfaces claires pour les autres services qui ont besoin d’interagir avec les utilisateurs. 37
  • 53. CHAPITRE 3. CONCEPTION 3.3.1 Diagramme de Cas d’utilisation associé au microservice « Gestion des utilisateurs » La figure ci-dessous illustre le diagramme de cas d’utilisation « Gestion des utilisa- teurs » qui détermine le role (les fonctionnalités) de ce microservice. Figure 3.6 – Diagramme de cas d’utilisation associé au microservice « Gestion des utilisateurs » 3.3.2 Description détaillée des cas d’utilisation associés au mi- croservice « Gestion des utilisateurs » Dans cette section nous allons présenter une description détaillée de quelques cas d’utilisation 38
  • 54. CHAPITRE 3. CONCEPTION Cas d’utilisation Acteur Description S’authentifier Client, Vendeur, Admin Permet aux utilisateurs de s’authentifier au système . Créer Compte Internaute Le visiteur de site peut faire une inscription pour qu’il soit un Client ou bien un vendeur. Modifier coordonnées Client Permet au client de mettre à jour ses informations personnelles dans son compte sur la marketplace. Cela peut inclure le nom, l’adresse, les coordonnées, les préférences de communication, etc. Passer une réclamation Client Consiste a signaler un problème ou une insatisfaction concernant un produit acheté auprès d’un vendeur ou d’un service client sur le site ou l’application. Modifier les informations personnelles et boutique Vendeur Permet au vendeur de mettre à jour ses informations personnelles dans son compte et son boutique. Cela peut inclure le nom, l’adresse, les coordonnées, les informations de paiement, etc. Gérer les comptes des clients Admin Cela consiste à surveiller et gérer les informations des utilisateurs enregistrés sur un site ou une application de commerce électronique, en vérifiant les informations d’identification et en gérant les problèmes de sécurité. Gérer les comptes des vendeur Admin Cela consiste à surveiller et gérer les informations des vendeur,en traitant les demandes de modification, implique également la gestion des contrats conclus avec les vendeurs sur la marketplace. Consulter les reclamation Admin Cela consiste a examine les réclamations soumises par les utilisateurs (clients/vendeur) . Figure 3.7 – Les cas d’utilisation associés au microservice « Gestion des utilisateurs » 3.3.3 Diagramme de séquence « S’authentifier » La Figure 3.8 décrit les différentes interactions entre l’utilisateur et les différents objets du sytème pour le traitement du cas d’utilisation « S’authentifier » 39
  • 55. CHAPITRE 3. CONCEPTION Figure 3.8 – Diagramme de séquence« S’authentifier » 3.3.4 Description textuelle du cas d’utilisation « S’authentifier » La description textuelle suivante présente en détail les différentes étapes et interac- tions impliquées dans le cas d’utilisation « S’authentifier ». Ce cas d’utilisation permet aux utilisateurs de s’authentifier(se connecter/créer un compte) à la plateforme. Le ta- bleau qui suit fournit une vue détaillée des acteurs impliqués, des pré-conditions, des post-conditions, des scénarios principaux et alternatifs de ce cas d’utilisation. 40
  • 56. CHAPITRE 3. CONCEPTION Cas d’utilisation S’authentifier Acteur principal Internaute Pré-conditions L’internaute n’est pas connecté à l’application Scénario nominal 1.L’internaute accède à la page d’authentification 2.l’internaute saisie son email et son password pour se connecter 3.L’internaute envoie la demande de connexion Scénario alternatif 2a.l’internaute accède à la page de création de compte 2b.l’internaute saisie les données de son nouveau compte 2c.l’internaute envoie la demande de création de compte Post-conditions l’internaute sera redirigé vers la page correspondonte selon le type de son compte Table 3.1 – Description textuelle du cas d’utilisation « S’authentifier » 3.3.5 Diagramme de séquence « Modifier coordonnées » La Figure 3.9 décrit le diagramme de séquence de cas d’utilisation « Modifier coordon- nées » qui nous explique comment la modification des cordonnées sera traité intérigissant avec les différents objets système. Figure 3.9 – Diagramme de séquence « Modifier coordonnées » 41
  • 57. CHAPITRE 3. CONCEPTION 3.3.6 Description textuelle de cas d’utilisation « Modifier coor- données » La description textuelle suivante présente en détail les différentes étapes et interac- tions impliquées dans le cas d’utilisation « Modifier cordonnées ». Ce cas d’utilisation vise à permettre aux utilisateurs de modifier les cordonnées personnelles de leurs profils. Le tableau qui suit fournit une vue détaillée des acteurs impliqués, des pré-conditions, des post-conditions, des scénarios principaux et alternatifs de ce cas d’utilisation. Cas d’utilisation Modifier coordonnées Acteur principal Client Pré-conditions Le client est connecté à l’application ou site web à travers un compte actif Scénario nominal 1.Le client accède à la page de modification de profil. 2.Le client modifie les informations de profil qu’il souhaite mettre à jour. 3.Le client sauvegarde les modifications effectuées. 4.Le service de gestion de clients met à jour les informations de profil du client dans la base de données. Scénario alternatif 2a.Le client ne souhaite pas modifier toutes les informations de profil et laisse des champs vides. 2b.Le client rencontre une erreur lors de la modification des informations de profil et reçoit un message d’erreur. Post-conditions Les informations de profil du client sont mises à jour dans la plateforme. Table 3.2 – Description textuelle du cas d’utilisation « Modifier cordonnées » 3.3.7 Diagramme de séquence « Consulter les réclamations » La Figure 3.10 décrit le diagramme de séquence de cas d’utilisation « Consulter les réclamations » qui nous explique comment l’admin peut consulter les réclamations en illustrant les interactions avec les différents objets système. 42
  • 58. CHAPITRE 3. CONCEPTION Figure 3.10 – Diagramme de séquence« Consulter les réclamations » 3.3.8 Description textuelle de cas d’utilisation « Consulter les réclamations » La description textuelle suivante présente en détail les différentes étapes et interac- tions impliquées dans le cas d’utilisation « Consulter les réclamations ». Ce cas d’utili- sation vise à permettre aux administrateurs de consulter les réclamations envoyées par des clients ou des vendeurs. Le tableau qui suit fournit une vue détaillée des acteurs impliqués, des pré-conditions, des post-conditions, des scénarios principaux et alternatifs de ce cas d’utilisation. Cas d’utilisation Consulter les reclamations Acteur principal Administrateur Pré-conditions L’administrateur est connecté à la plateforme . Scénario nominal 1.L’administrateur accède à la page de gestion des signalements. 2.L’administrateur demande d’afficher les réclamations. 3.Le système affiche les réclamtions. 4.L’administrateur consulte les réclamations. Scénario alternatif 4a.L’administrateur choisit de supprimer ou pas la réclamation consulté. 4b.L’administrateur choisit de filtrer les réclamations selon la date. Post-conditions Les réclamations sont afficheé par le système. Table 3.3 – Description textuelle du cas d’utilisation« Consulter les réclamations » 43
  • 59. CHAPITRE 3. CONCEPTION 3.3.9 Diagramme de composant « Gestion des utilisateurs » La figure ci dessous contient le diagramme de composant de service gestion des utilisateurs, il met l’accent sur les différentes parties qui composent le services « Gestion des utilisateurs ». Figure 3.11 – Diagramme de composant « Gestion des utilisateurs » 44
  • 60. CHAPITRE 3. CONCEPTION 3.3.10 L’architecture logicielle de Microservice « Gestion des utilisateurs » La figure 3.12 représente l’architecture logicielle de Microservice « Gestion des utili- sateurs ». l’objectif de cette représentation est de fournir une compréhension visuelle de l’inter- action du Microservice "Gestion des utilisateurs" avec les autres composants du système. Elle met en évidence les connexions et les relations entre le microservice et les autres composants : • L’API Gateway, en tant que composant central de notre architecture, joue le rôle de point d’entrée principal pour les requêtes des clients. • Conteneur RabbitMQ pour la communication asynchrone entre les différents ser- vices. • Le conteneur de la base de données est responsable du stockage et de la persistance des données du système. Figure 3.12 – Architecture logicielle de microservice « Gestion des utilisateurs » 3.4 Microservice de « Gestion des produits » La conception du service de gestion des produits constitue une étape cruciale de notre architecture microservices. Ce service est chargé de gérer toutes les fonctionnalités liées aux produits proposés sur notre marketplace. 45
  • 61. CHAPITRE 3. CONCEPTION 3.4.1 Diagramme de Cas d’utilisation associés au microservice « Gestion des Produits » La figure 3.13 illustre un diagramme de cas d’utilisation qui contient les principaux fonctionnalitées du microservices « Gestion des Produits ». Figure 3.13 – Diagramme de cas d’utilisation associés au microservice « Gestion des produits » 46
  • 62. CHAPITRE 3. CONCEPTION 3.4.2 Description détaillée des cas d’utilisations associé au mi- croservices « Gestion des Produits » Dans cette section nous allons présenter une description textuelle de quelques cas d’utilisation Cas d’utilisation Acteur Description Evaluer un produit Client Permet aux clients de soumettre des évaluations pour un produit donné, en fournissant une note et un commentaire. Consulter les produits Client Consiste à fournir aux utilisateurs une vue d’ensemble des produits disponibles, en affichant des détails tels que les images, les descriptions, les prix et les évaluations . Rechercher un produit Client Permet aux clients de rechercher des produits en fonction de différents critères tels que le nom, le prix, la catégorie, etc . Gérer panier Client Permet aux clients d’ajouter des produits à son panier en vue d’un achat ultérieur. De plus, l’utilisateur a la capacité de supprimer des produits et modifier la quantité . Gérer les stocks Vendeur Le vendeur peut surveiller les niveaux de stock de ses produits, mettre à jour les quantités disponibles en fonction des ventes ou des arrivées de nouveaux stocks, et recevoir des notifications lorsque les niveaux de stock sont bas. Ajouter un produit Vendeur, Admin Consiste à ajouter un nouveau produit à la vente sur la Marketpalce . Modifier un produit Vendeur, Admin Permet aux vendeurs, Administrateurs de mettre à jour les informations d’un produit existant, telles que le prix, la quantité en stock, la description, les images, etc . Supprimer un produit Vendeur, Admin Cette fonctionnalité permet aux vendeurs, Administrateurs de supprimer un produit qui n’est plus disponible à la vente. Gérer les avis Admin L’administrateur peut modérer les évaluations et les commentaires pour s’assurer qu’ils sont pertinents et utiles pour les autres utilisateurs. Gérer les catégories Admin permettre aux administrateurs de gérer les catégories de produits disponibles, Ils peuvent créer de nouvelles catégories, modifier ou supprimer des catégories existantes . Table 3.4 – Les cas d’utilisation associés au microservice « Gestion des produits » 47
  • 63. CHAPITRE 3. CONCEPTION 3.4.3 Diagramme de séquence « Ajouter produit » La Figure ci-dessous décrit le diagramme de séquence de cas d’utilisation « Ajouter un produit » qui nous explique comment le vendeur peut ajouter son nouveau produit dans la platforme en illustrant les interactions avec les différents objets système. Figure 3.14 – Diagramme de séquence « Ajouter un produit » 3.4.4 Description textuelle du cas d’utilisation « Ajouter un produit » La description textuelle suivante présente en détail les différentes étapes et inter- actions impliquées dans le cas d’utilisation « Ajouter un produit ». Ce cas d’utilisation permet aux vendeurs d’ajouter un produit. Le tableau qui suit fournit une vue détaillée des acteurs impliqués, des pré-conditions, des post-conditions, des scénarios principaux 48
  • 64. CHAPITRE 3. CONCEPTION et alternatifs de ce cas d’utilisation. Cas d’utilisation Ajouter un produit Acteur principal Vendeur Pré- conditions Le vendeur est connecté à la plateforme avec un compte actif et a accès à la page d’ajout de produit. Scénario nominal 1.Le vendeur accède à la page d’ajout de produit. 2.Le vendeur entre les détails du produit, y compris le nom, la description, les images et le prix. 3.Le vendeur choisit une catégorie appropriée pour le produit. 4.Le vendeur sauvegarde le produit. 5.Le service de gestion de produits vérifie que toutes les informations obligatoires ont été saisies correctement. 6.Le produit est ajouté à la liste des produits disponibles sur la plateforme de microservices de place de marché. Scénario alternatif 5a Le service de gestion de produits détecte des informations manquantes ou incorrectes et demande au vendeur de les corriger avant de pouvoir ajouter le produit. Post- conditions Le produit est ajouté à la liste des produits disponibles sur la plateforme de microservices de place de marché et est visible pour les acheteurs potentiels. Le vendeur peut également accéder au produit pour le modifier ou le supprimer si nécessaire. Table 3.5 – Description textuelle du cas d’utilisation « Ajouter Produit » 3.4.5 Diagramme de séquence « Evaluer produit » La Figure 3.15 représente le diagramme de séquence de cas d’utilisation « Evaluer un produit » qui nous explique comment le client peut attribuer une note à un produit dans la platforme en illustant les interactions avec les différents objets système. 49
  • 65. CHAPITRE 3. CONCEPTION Figure 3.15 – Diagramme de séquence « Evaluer produit » 3.4.6 Description textuelle du cas d’utilisation « Evaluer pro- duit » La description textuelle suivante présente en détail les différentes étapes et interac- tions impliquées dans le cas d’utilisation « Evaluer produit ». Ce cas d’utilisation permet aux clients de notter un produit. Le tableau qui suit fournit une vue détaillée des acteurs impliqués, des pré-conditions, des post-conditions, des scénarios principaux et alternatifs de ce cas d’utilisation. 50
  • 66. CHAPITRE 3. CONCEPTION Cas d’utilisation Evaluer produit Acteur principal Client Pré-conditions Le client est connecté à la plateforme avec un compte actif Scénario nominal 1.Le client accède à la page de notation et de commentaire du produit. 2.Le client donne une note (sur 5) et un commentaire pour le produit. 3.Le service de gestion des produit vérifie que la notation et le commentaire sont conformes aux règles de la plateforme 5.Le service de gestion des produits ajoute la note au produit Scénario alternatif 2a.Si le client a noté deja le produit il modifie son ancien note ou le supprime. 3a.Si la notation ou le commentaire ne respecte pas les règles de la plateforme le service de gestion des produits demande au client de les modifier. Post-conditions La notation et le commentaire sont publiés/supprimé sur la page du produit pour les autres clients à voir. Table 3.6 – Description textuelle du cas d’utilisation « Evaluer produit » 3.4.7 Diagramme de composant associé au microservice « Ges- tion des produits » La figure ci dessous contient le diagramme de composant de service Gestion des produits, il met l’accent sur les différentes parties qui composent le services « Gestion des utilisateurs ». 51
  • 67. CHAPITRE 3. CONCEPTION Figure 3.16 – Diagramme de composant associé au microservice « Gestion des produits » 3.4.8 L’architecture logicielle de microservice « Gestion des pro- duits » La figure 3.17 présente l’architecture logicielle de microservice Gestion des produits l’objectif de cette représentation est de fournir une compréhension visuelle de l’in- 52
  • 68. CHAPITRE 3. CONCEPTION teraction du Microservice "Gestion des produits" avec les autres composants du système. Figure 3.17 – Architecture logicielle de microservice « Gestion des produits » 3.5 Microservice de « Gestion des commandes » Dans le contexte des microservices, le service de gestion des commandes peut être traité comme un service autonome, responsable de toutes les opérations liées à la gestion des commandes. 3.5.1 Diagramme de cas d’utilisation associé au microservice « Gestion des commandes » Figure 3.18 – Diagramme de cas d’utilisation associé au Microservice « Gestion des commendes » 53
  • 69. CHAPITRE 3. CONCEPTION 3.5.2 Description détaillée des cas d’utilisation associé au mi- croservice « Gestion des commandes » Dans cette section nous allons présenter une description de quelques cas d’utilisation Cas d’utilisation Acteur Description Passer une commande Client Le client peut passer une nouvelle commande en sélectionnant les produits souhaités, en fournissant les informations de livraison Consulter l’historique des commandes Client Le client peut consulter l’historique de ses commandes précédentes, y compris les détails de chaque commande, l’état actuel, les produits commandés et les informations de livraison. Suivre l’état de la commande Client Le client peut suivre l’état en temps réel de sa commande, de la préparation à la livraison. Il peut savoir à quelle étape se trouve sa commande et obtenir des mises à jour sur son statut. Gérer les commandes entrantes Vendeur Le vendeur peut consulter les commandes entrantes, y compris les détails des produits commandés, les informations de livraison et les coordonnées du client. Le vendeur peut prendre les mesures nécessaires pour traiter et préparer les commandes. Mettre à jour l’état de la commande Vendeur Le vendeur peut mettre à jour l’état des commandes en fonction de leur progression Table 3.7 – Tablau des cas d’utilisation associés au microservice « Gestion des com- mendes » 3.5.3 Diagramme de séquence « Passer une commande » La Figure 3.18 et la tableau 3.8 décrivent le diagramme de séquence de cas d’uti- lisation « Passer une commande » qui nous explique comment le client peut passer une commande dans la platforme en illustrant les interactions avec les différents objets sys- tème. 54
  • 70. CHAPITRE 3. CONCEPTION Figure 3.19 – Diagramme de sequence « Passer une commande » 55
  • 71. CHAPITRE 3. CONCEPTION 3.5.4 Description textuelle du cas d’utilisation « Passer une commande » La description textuelle suivante présente en détail les différentes étapes et interac- tions impliquées dans le cas d’utilisation « Passer une commandet ». Ce cas d’utilisation permet aux clients de passer une commande. Le tableau qui suit fournit une vue détaillée des acteurs impliqués, des pré-conditions, des post-conditions, des scénarios principaux et alternatifs de ce cas d’utilisation. Cas d’utilisation Passer une commande Acteur principal Client Pré-conditions Le client est connecté à la plateforme de commerce électronique et a des produits dans son panier. Scénario nominal 1.Le client sélectionne les produits dans son panier. 2.Le client fournit les informations de livraison 3.Le client choisit une option de paiement 4.Le client confirme la commande 5.Le système de gestion des commandes vérifie la disponibilité des produits chez les vendeurs respectifs. 6.Le système de gestion des commandes enregistre la commande pour chaque vendeur. 7.Le client reçoit une confirmation de commande. Scénario alternatif 2a.Le client modifie les informations de livraison ou choisit une autre option de livraison. 5a.L’un des produits sélectionnés par le client n’est pas disponible. Post-conditions La commande est enregistrée dans le système pour chaque vendeur, les paiements sont traités, et le client reçoit une confirmation de commande. Les vendeurs sont notifiés des commandes et prêts à traiter et expédier les produits commandés. Table 3.8 – Description scénariste du cas d’utilisation « Passer une commande » 3.5.5 Diagramme de composant associé au microservice « Ges- tion des produits » La figure 3.20 représente le diagramme de composants du microservice de gestion de commandes. Ce diagramme met en évidence les différents composants et leur intercon- nexion, permettant de comprendre la structure et l’organisation du service de gestion des commandes. Il montre comment les différents composants du système se connectent et 56
  • 72. CHAPITRE 3. CONCEPTION interagissent pour assurer le bon fonctionnement du service de gestion des commandes. Figure 3.20 – Diagramme de composant associé au microservice « Gestion des com- mandes » 57
  • 73. CHAPITRE 3. CONCEPTION 3.5.6 L’architecture logicielle de microservice « Gestion des com- mandes » La figure 3.21 présente l’architecture logicielle de microservice « Gestion des com- mandes » Le composant Message Broker est responsable de la communication avec les autres microservices Figure 3.21 – Architecture logicielle de microservice « Gestion des produits » Conclusion Dans le chapitre de conception de notre projet, nous avons adopté une approche de conception en microservices. Cette approche nous a permis de diviser notre application en plusieurs services indépendants, chacun se concentrant sur une fonctionnalité spécifique. Dans le chapitre de la réalisation qui suivra, nous mettrons en œuvre la conception que nous avons élaborée. Nous aborderons les détails techniques de la mise en place des microservices et les interfaces web et mobile . 58
  • 74. Chapitre 4 Réalisation Introduction Dans ce chapitre, nous aborderons en détail les aspects pratiques de la mise en place de notre solution, on va présenter l’environnement matériel et logiciel ainsi que les outils de développement. 4.1 Environnement de développement Dans cette partie, nous présentons les différents outils matériels et logiciels néces- saires pour le développement de notre application. 4.1.1 Environnement matériel Pour la réalisation de ce projet on a disposé d’ : 1. Un ordinateur : • Marque Dell • Processeur : 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz • RAM : 12 GO • Système d’exploitation : Windows 10 59
  • 75. CHAPITRE 4. RÉALISATION 2. Un ordinateur : • Marque Dell • Processeur : 8th Gen Intel(R) Core(TM) i7-8650U @2.10GHz • RAM : 16 GO • Système d’exploitation : Windows 10 4.1.2 Environnement logiciel Cette section décrit l’environnement logiciel avec lequel nous avons réalisé ce projet . Figure 4.1 – Visual Studio Code Visual Studio Code : est un éditeur de code source léger, mais puissant, qui s’exécute sur votre bureau et est disponible pour Windows, macOS et Linux[12]. Figure 4.2 – Git Git : est un système de contrôle de version distribué et open-source largement utilisé pour le suivi des modifications apportées aux fichiers et aux projets de développement logiciel[13]. Figure 4.3 – Docker Docker : est une plateforme open-source qui permet de créer, de déployer et d’exécuter des applications dans des conteneurs[14]. 60
  • 76. CHAPITRE 4. RÉALISATION Figure 4.4 – Postman Postman : est un outil populaire utilisé par les développeurs pour tester, documenter et collaborer sur les API (Interfaces de programmation d’application)[15]. Figure 4.5 – Swagger Swagger (OpenAPI Specification) est un ensemble de spécifications et d’outils pour concevoir, documenter et tester des API RESTful. Figure 4.6 – Nginx Nginx : est un serveur web léger, performant et open-source, ainsi qu’un proxy inverse[16]. Figure 4.7 – LYX Pour rédiger ce rapport, nous avions utilisé LyX pour cette tâche, c’est un éditeur de texte gratuit, open source et multiplateforme qui permet l’édition de texte à base de LaTeX [17]. 61
  • 77. CHAPITRE 4. RÉALISATION Figure 4.8 – LucidChart LucidChart est un outil pour créer des diagrammes,des figures et des illustrations[18]. Figure 4.9 – RabbitMQ RabbitMQ est un courtier de messages open-source qui permet à différents systèmes logiciels de communiquer et d’échanger des messages. Il met en œuvre le protocole de messagerie avancée (AMQP), qui est un protocole standardisé pour la messagerie entre applications.[19]. 4.2 Présentation de la solution Cette partie dédiée à la mise en valeur de notre solution, nous explorons en détail les aspects clés qui la composent. Nous abordons la solution web, la solution mobile et la réalisation des microservices, mettant en évidence leur importance et leur contribution à l’expérience utilisateur. Chaque sous-partie apporte une dimension unique à notre solu- tion, créant ainsi une plateforme attrayante, conviviale et évolutive pour nos utilisateurs. 4.2.1 Présentation de la solution web Cette partie présente certaines interfaces de l’application Web et montre les carac- téristiques les plus importantes de notre travail. 62
  • 78. CHAPITRE 4. RÉALISATION La page d’acceuil L’utilisateur a un accès à l’application via la page d’acceuil, il peut naviguer dans les produits, les catégories, effectuer une recherche sur un produit spécifique une boutique, ou une catégorie, il peut aussi s’authentifier et ajouter des produits à un panier et com- mander ces produits. La figure 4.10 présente l’interface d’acceuil implémentée dans notre application web. Figure 4.10 – Interface d’acceuil Web La page de commande L’utilisateur peut consulter les produits ajoutées au panier il peut les modifier en supprimant quelques-uns ou en augmentant leurs quantité. Il peut aussi passer une com- mande avec les produits du panier en ajoutant son adresse et en passant par le payement. La figure 4.11 ci-dessous présente l’interface de commande implémentée dans notre ap- plication web. 63
  • 79. CHAPITRE 4. RÉALISATION Figure 4.11 – Interface d’acceuil Web La page de création de compte L’interface de création de compte dans notre projet offre une expérience conviviale et intuitive pour les utilisateurs. Elle permet aux visiteurs d’accéder rapidement à la fonctionnalité d’inscription en fournissant les informations nécessaires(tels que le nom complet, l’adresse e-mail, le mot de passe, et d’autres informations pertinentes) pour créer un compte personnel. La figure 4.12 présente l’interface de création de compte implémentée dans notre application web. Figure 4.12 – Interface SignIn Web 64
  • 80. CHAPITRE 4. RÉALISATION La page se connecter La page de connexion est conçue de manière à ce que les utilisateurs puissent accéder rapidement à leur compte personnel en fournissant leurs informations d’identification(leur adresse e-mail, ainsi que leur mot de passe associé). La figure 4.13 ci-dessous présente l’interface de connexion au compte implémentée dans notre application web dans le cas ou l’utilsateur a un compte. Figure 4.13 – Interface Login Web La page de l’espace vendeur Chaque vendeur a un espace composé d’un ensemble des fonctionalités(services) tel qu’un affichage de ses produits, l’ensembles des commandes recus , les cordonnées de son boutique ,etc. Cette interface est accessible au utilisaeur via La figure 4.14 présente l’interface de l’espace vendeur implémentée dans notre appli- cation web. 65
  • 81. CHAPITRE 4. RÉALISATION Figure 4.14 – Interface vendeur-dashboard 4.2.2 Présentation de la solution Mobile Cette partie présente certaines interfaces de l’application Mobile et montre les ca- ractéristiques les plus importantes de notre travail. La page d’authentification Pour qu’un utilisateur ait un accès à l’application, une phase d’authentification est nécessaire. 1. L’interface de connexion capturée présente un formulaire de connexion élégant et simple. L’écran affiche un champ pour l’adresse e-mail et un champ pour le mot de passe. 2. L’interface d’inscription capturée présente un formulaire convivial permettant aux utilisateurs de créer un nouveau compte. L’écran propose des champs pour saisir les informations nécessaires, tels que le nom, l’adresse e-mail, le mot de passe et numéro de téléphone. 3. L’interface de vérification d’e-mail capturée est conçue pour permettre aux utili- sateurs de confirmer leur adresse e-mail après leur inscription. 66
  • 82. CHAPITRE 4. RÉALISATION La figure 4.15 ci-dessous présente les interfaces d’authentification implémentée dans notre application. Figure 4.15 – Interface authentification application mobile. Lorsque les utilisateurs saisissent des identifiants incorrects ou rencontrent un pro- blème de connexion, un message d’erreur clair et concis est affiché à l’écran. Ce message les informe de la nature de l’erreur et les invite à vérifier leurs informations de connexion. La figure 4.16 ci-dessous illustre cette interface d’erreur. 67
  • 83. CHAPITRE 4. RÉALISATION Figure 4.16 – Authentification cas d’erreur Page d’accueil Dans notre application MarketHive, la page d’accueil est conçue pour offrir aux utilisateurs un aperçu complet des produits disponibles, des catégories et des publicités. La figure 4.17 ci-dessous présente l’interface de la page d’accueil. Figure 4.17 – Interface d’accueil application mobile 68
  • 84. CHAPITRE 4. RÉALISATION Interface catégorie L’interface des catégories dans notre application est conçue pour permettre aux uti- lisateurs de naviguer facilement parmi les différentes catégories de produits disponibles. 1. Au sommet de l’interface, vous trouverez une vue en liste affichant les catégories parentes. Chaque catégorie est représentée par son nom . 2. Lorsque vous cliquez sur l’une des catégories parentes, l’interface se met à jour pour afficher les sous-catégories associées à cette catégorie. Cela permet de présenter une hiérarchie des catégories. 3. lorsque vous cliquez sur l’une des sous-catégories présentées dans l’interface pré- cédente. Elle présente une grille (grid view) de produits liés à cette sous-catégorie spécifique. Chaque produit est représenté par une image, un nom, un prix et un notation. La figure 4.18 ci-dessous présente cette interface. Figure 4.18 – Interface catégorie application mobile Interface produit L’interface de détails du produit offre une vue détaillée et complète d’un produit spécifique. Elle est organisée de manière à fournir toutes les informations nécessaires aux utilisateurs pour prendre une décision d’achat éclairée. La figure 4.19 ci-dessous présente cette interface. 69