(DRAFT) Document D'architecture Logicielle

Document d’Architecture
Logicielle
Master 2 Génie Informatique et Logiciel
Année 2023 – 2024
Révisions
Versio Date Modifications apportées

n
0.1 01/11/2023 Version initiale du document.
0.2 08/11/2023 Ajout du diagramme d’architecture
0.3 15/11/2023 Spécification technique des composants
OllcAvis - Master II GIL 2023/2024 1

Année 2023 – 2024
Table des matières
Table des matières......................................................................................................

I – Introduction..............................................................................................................
1 – Objet du document...............................................................................................
2 – Documents applicables et référence........................................................................
3 – Terminologie et sigles utilisés.................................................................................
II – Architecture de l’application.......................................................................................
1 – Principes fondamentaux des micro-services..............................................................
2 – Schéma de l’architecture générale...........................................................................
3 – Spécification technique des composants...................................................................
3.1 – MS Opinion...................................................................................................
3.2 – MS Invite.....................................................................................................
3.3 – MS Mailing....................................................................................................
3.5 – Communication entre les Micro-Services...........................................................
4 - Cas d’utilisation......................................................................................................................................
4.1 - Diagramme des cas d’utilisation....................................................................................................
4.2 - Résumé:........................................................................................................................................
4.3. UC_01 : S'authentifier.....................................................................................................................
4.4. UC_02 : Lister les rôles...................................................................................................................
4.5 - UC_03 : Gérer un rôle...................................................................................................................
4.6. UC_03_01 : Créer un rôle...............................................................................................................
4.7. UC_03_02 : Supprimer un rôle.......................................................................................................
4.8. UC_03_03 : Modifier un rôle...........................................................................................................
4.9. UC_04 : Gérer un élément de détails..............................................................................................
4.10. UC_04_01 : Ajouter un élément....................................................................................................
4.11. UC_04_02 : Supprimer un élément...............................................................................................
4.12. UC_04_03 : Modifier un élément..................................................................................................
4.13. UC_05 : Configurer l'algorithme de modération............................................................................
4.14. UC_06 : Lister les avis à modérer.................................................................................................
4.15. UC_07 : Modérer un avis..............................................................................................................
4.16. UC_07_01 : Consulter un avis à modérer.....................................................................................
4.17. UC_07_02 : Accepter un avis.......................................................................................................
4.18. UC_07_03 : Refuser un avis.........................................................................................................
4.19. UC_08 : Recevoir des notifications...............................................................................................
4.20. UC_09 : Lister les avis sur ses produits/magasin.........................................................................
4.21. UC_10 : Répondre à un avis.........................................................................................................
4.22. UC_11 : Signaler un avis..............................................................................................................
4.23. UC_12 : Gérer une réponse..........................................................................................................
4.24. UC_12_01 : Supprimer une réponse............................................................................................

Année 2023 – 2024
4.25. UC_12_02 : Modifier une réponse................................................................................................

4.26. UC_13 : Lister ses avis.................................................................................................................
4.27. UC_14 : Gérer un avis..................................................................................................................
4.28. UC_14_01 : Modifier un avis.........................................................................................................
4.29. UC_14_02 : Supprimer un avis.....................................................................................................
4.30. UC_15 : Rédiger un avis...............................................................................................................
4.31. UC_16 : Recevoir un email d'invitation.........................................................................................
4.32. UC_17 : Consulter les avis sur les magasins................................................................................
4.33. UC_18 : Consulter les avis sur les produits..................................................................................
4.34. UC_19 : Signaler un avis..............................................................................................................

Année 2023 – 2024
I – Introduction
1 – Objet du document
Ce document a pour objectif de décrire l’architecture logicielle du système OllcAvis. Il

présente les différentes couches du système, ainsi que les micro-services et l’interface
utilisateur (IHM) qui le composent. Il explique également les ressources techniques et les
protocoles nécessaires à la mise en place du système, ainsi que les considérations de
performance, de stabilité et de sécurité qui ont été prises en compte. Le document vise à
fournir une vue d’ensemble claire et détaillée de l’architecture logicielle du système
OllcAvis afin de faciliter sa mise en œuvre et son maintien à long terme.
2 – Documents applicables et référence
La réalisation du présent document s’appuie sur la liste des documents et applications

suivantes :
⮚ Cahier des Clauses Techniques Particulières (CCTP) : ce document décrit le

contexte et le périmètre de l’application. C’est sur ce document que se base notre
modélisation et conception de notre application aussi bien sur le plan fonctionnel
que technique.
⮚ Figma : outil de maquettage et prototypage utilisé pour dessiner la maquette de

l’application.
⮚ Lucidchart : éditeur de diagramme d’architecture collaboratif.
⮚ DrawSQL : éditeur de diagramme permettant de concevoir des schémas de base

de données.
⮚ PlantUML : éditeur de diagramme UML en ligne.

Année 2023 – 2024
3 – Terminologie et sigles utilisés
API (Application Programming Interface) : est une interface logicielle qui permet de
connecter un logiciel (ou service) à un autre logiciel (ou service) afin d’échanger des
données et des fonctionnalités.
REST (Representational State Transfer) ou RESTful : style d’architecture permettant de

construire des applications (Web, Intranet, Web service). Il s’agit d’un ensemble de
conventions et de bonnes pratiques à respecter et non d’une technologie à part entière.
Front-end : ensemble des éléments visibles par les visiteurs/utilisateurs et accessibles

directement sur un site web (voire sur une application web ou une application mobile) qui
représente l’interface graphique d’une application.
Back-end : domaine de développement web qui se concentre sur tous les processus
d’arrière-plan nécessaires qui se produisent du côté serveur d’un site web (voire une
application web ou une application mobile). C’est la partie invisible d’une application.
MS (Micro-service) : une façon de construire des applications en découpant leur

fonctionnalité en petits services indépendants qui communiquent entre eux. Cela permet
un développement plus flexible et agile, ainsi qu’une meilleure évolutivité et maintenance
de l’application à long terme. Chaque service est responsable d’une fonction spécifique et
peut être développé et déployé indépendamment des autres.
HTTP (Hypertext Transfer Protocol) : protocole de communication client-serveur de la

couche application qui peut fonctionner sur n’importe quelle connexion fiable utilisant le
protocole TCP sur le port 80 (443 pour HTTPS).
IHM (Interface Homme Machine) : composant logiciel permettant aux utilisateurs

d’interagir avec le système.
Composant : dans le cadre de ce document, un composant est défini comme une partie
de l’application web définissant une page ou un menu coté front-end.
Sous-Composant : morceau d’un composant permettant de réaliser une action précise

lorsque l’on interagit avec cet élément. On les retrouve à l’intérieur des composants.
JSON (Javascript Object Notation) : format des données permettant aux applications
d’échanger des informations de façon structurée.
Framework : ensemble cohérent d’outils et de composants logiciels structurels

organisés conformément à un plan d’architecture permettant de créer la base d’un
projet.
Spring Boot : framework open source qui facilite le développement d’applications

fondées sur Spring en offrant des outils permettant d’obtenir une application totalement
autonome en Java.
Angular : framework pour applications clients, open source basée sur TypeScript qui
permet la création d’applications Web (particulièrement monopages).

Année 2023 – 2024
II – Architecture de l’application
1 – Principes fondamentaux des micro-services
Principe 1 : Autonomie
Une caractéristique clé des micro-services est leur autonomie et leur capacité à
fonctionner indépendamment les uns des autres. L’autonomie est une mesure de contrôle
que l’implémentation du service a sur son environnement d’exécution et son schéma de
base de données. Cela améliore les performances et la fiabilité du service et donne aux
clients davantage de garanties quant à la qualité du service qu’ils peuvent en attendre.
L’autonomie contribue également à la disponibilité et à l’évolutivité globales du

service. Avec une autonomie accrue, l’architecture micro-services est moins susceptible
de connaître des défaillances ou des problèmes de performances à cause d’un autre
micro-service.
Principe 2 : Couplage lâche
Les micro-services sont indépendants et faiblement couplés. Le couplage fait

référence à une mesure de dépendance entre deux composants d’un système. Lors de la
conception des micro-services, les architectes mettent constamment l’accent sur la
réduction des dépendances entre le contrat de service et sa mise en œuvre d’une part, et
entre le service et ses potentiels consommateurs d’autre part.
Cela permet une plus grande évolutivité et de nouvelles solutions en permettant

aux propriétaires de services de modifier la mise en œuvre et de changer ou modifier les
systèmes d'enregistrement ou même les compositions de services qui peuvent se trouver
derrière l'interface et les remplacer sans aucun impact en aval.
Principe 3 : Réutilisabilité
La réutilisation reste un principe de la conception de micro-services. Toutefois, la

portée de la réutilisation a été réduite à des domaines spécifiques au sein de l'entreprise.
Les équipes peuvent se mettre d'accord sur des modèles de communication pour
décider de la manière dont les micro-services doivent être adaptés pour être utilisés en
dehors des contextes dans lesquels ils ont été conçus.
Principe 4 : Tolérance aux pannes
Si un composant tombe en panne, la tolérance aux pannes est la capacité qui

permet à un système de continuer à fonctionner correctement. Chaque service est
nécessairement tolérant aux pannes afin que les défaillances des autres micro-services
aient un impact minimal sur son propre système. Dans le cas de notre application, la
tolérance vient du fait que les différents micro-services sont indépendants. Aucun micro-
service ne communique directement avec les autres, ils ont chacun leur base de données
et communiquent via un bus Kafka. Cela permet quand un micro-service tombe en panne
de ne pas impacter les autres micro-services.

Année 2023 – 2024
Principe 5 : la composabilité
Tous les principes de conception mentionnés contribuent au principe de

composabilité, qui permet au service d'apporter de la valeur à l'entreprise dans différents
contextes. On peut ainsi former de nouveaux agrégats au besoin du client.

Année 2023 – 2024
2 – Schéma de l’architecture générale
lien du lucidchart
3 – Spécification technique des composants
3.1 – MS Opinion
Ce micro-service permet la gestion des avis. En particulier, il va gérer la rédaction d’avis,

leur visualisation, leur signalement, leurs réponses, ainsi que la modération manuelle.
3.1.1 – Schéma de base de données relationnelle
Lien SQLDraw

Année 2023 – 2024
3.1.2 – Explication
La table opinion est la table principale de ce micro service, celle-ci contient les données
principales sur les avis :
- L’ID
- La note
- Le commentaire
- Le pseudonyme de l’auteur si celui-ci souhaite être anonyme (ou ses initiales).
- Le statut de modération prenant les valeurs :
- PENDING : est en cours de modération automatique
- AUTOMATIC : a été automatiquement modéré
- FINISHED : a été manuellement modéré
- L’état d’acceptation de l’avis
- Le statut de visibilité de l’avis.
- La date de création
- La date de la dernière modification
- Plusieurs références vers les ID de l’utilisateur, du commerçant, de la commande
et d’un article.
- La raison si l’avis a été refusé.

Année 2023 – 2024
Les tables event_historic (historique d’événement) et answer (réponse) sont liées à

la table opinion par une relation one-to-many, signifiant qu’un avis est lié à plusieurs
événements et a plusieurs réponses.
Ainsi, la table event_historic correspondant à l’historique d’événement d’un avis ou
d’une réponse contient différentes informations :
- l’ID
- L’évènement qui peut prendre les valeurs suivantes :
- MODIFIED : l’avis a été modifié
- DELETED : l’avis a été supprimé
- La date de cet évènement
- La référence vers un avis si référence un avis
- La référence vers une réponse si référence une réponse.
La table answer correspondant aux réponses et qui contient la réponse, l’auteur

(commerçant) de la réponse, le statut de modération, l’état d’acceptation de la réponse,
la date de la réponse, une référence vers l’ID de l’opinion et une référence vers l’ID du
commerçant.
Les tables detail_element et detail_element_answer permettent de stocker les

questionnaires personnalisés et les réponses. Tout d’abord dans la table
detail_element, nous stockons différentes informations qui sont ;
- Le label de la question
- L’ordre de la question
- Le type de la question qui peut prendre les valeurs suivantes :
- MERCHANT : question concernant un commerçant
- PRODUCT : question concernant un produit.
- Le type de produit concerné
- Le type de commerçant concerné
Et enfin dans la table concernant les réponses aux questionnaires, nous allons stocker
différentes informations qui sont :
- L’identifiant de la question
- La note attribué à la question
- L’identifiant de l’avis associé au moment de la réponse.
Les tables product et merchant sont des tables contenant des données venant d’Ollca,
celles-ci. Nous prenons ici uniquement les informations que nous avons besoin, c’est-à-
dire :
- Le nom du produit ou du commerçant
- La description
- la catégorie
De plus, dans product, nous avons une référence vers le commerçant associé.
La table order contient les commandes, une commande ne contenant juste une liste de
produits.
3.1.3 - API publique
Routes de l’API proposées par le micro-service
Méthode Chemin Entrée Réponse

Année 2023 – 2024
Code Sortie
GET /opinions N/A 200 List<OpinionDto>
201 OpinionDto
POST /opinions CreateOpinionDto
400
200 List<OpinionDto>
GET /opinions-by-merchant N/A
404 > Avis inexistant
GET /opinions-by-product N/A List<OpinionDto>
200 OpinionDto
PUT /opinions/{id} UpdateOpinionDto 400 > Entrée invalide
404 > Avis inexistant
POST /opinions/{id}/moderate ModOpinionDto 200 N/A

Année 2023 – 2024
3.2 – MS Invite
Ce micro-service a pour responsabilité de prendre en charge les commandes reçues

depuis le système Ollca. Il crée un e-mail d’invitation destiné au client afin qu’il puisse
accéder au système OllcAvis pour rédiger un ou plusieurs avis sur les produits et
commerçants de sa commande.
La première invitation est envoyée dans un délai de 48 heures après la date de retrait ou
de livraison de la commande. Si aucun avis n’a été rédigé dans un délai de 168 heures
après la date de retrait ou de livraison de la commande, une seconde invitation est
envoyée au client.
3.2.1 - Schéma de base de données
La table order stocke les informations sur les commandes reçues depuis Ollca :
a. l’identifiant de la commande auprès du système Ollca (id) ;
b. l’identifiant du client auprès du système Ollca (client_id) ;
c. si un avis a été déposé pour la commande (has_answered) - par défaut false ;
d. la date à laquelle la commande a été passée (created_at).
La table client stocke les informations liées à un client du système Ollca :

a. son identifiant auprès du système Ollca (id) ;
b. l’état civil du client composé du prénom et du nom (first_name et last_name) ;
c. l’adresse e-mail du client à laquelle envoyer les e-mails (email_address).
La table product stocke les informations liées à un produit du système Ollca :

b. le nom du produit tel que présenté au client (name) ;
c. le marchand proposant ce produit dans sa boutique (merchant_id).
La table merchant stocke les informations liées à un marchand du système Ollca :

b. le nom du marchand tel que présenté au client (name).

Année 2023 – 2024
La table order_product stocke les produits achetés pour chaque commande :

a. l’identifiant de la commande (order_id) ;
b. l’identifiant du produit acheté (product_id) ;
c. la quantité du produit acheté (quantity).
3.2.2 - Échanges entre micro-services
3.2.3.a - Envoi des liens d’invitation
Nature Production de données
Topic Kafka mail
Données fournies - Adresse e-mail du client invité à répondre (recipient) ;

- Sujet de l’e-mail d’invitation (subject) ;
- Corps de l’e-mail contenant le lien d’invitation (body).
Objectif Informer le client qu’il est éligible au dépôt d’avis sur le

système “OllcAvis” pour la commande qu’il a passé, et lui
fournir un lien direct d’accès à l’interface de rédaction d’avis. Ce
mail contiendra également le détail de la commande passée.
Dans la mesure où le micro-service Mailing serait indisponible, la demande d’envoi de l’e-

mail est mise en attente. Le client sera invité à rédiger ses avis dès lors que le micro-
service sera de nouveau opérationnel.
3.2.2.b - Écoute sur les avis nouvellement créés
Nature Consommation de données
Topic Kafka opinion
Données extraites - Identifiant de la commande à laquelle l’avis se rattache.
Objectif Empêcher l’envoi du second courrier d’invitation, si un avis a

été rédigé dans les 168 heures passé la date de retrait ou de
livraison de la commande.
Dans la mesure où le micro-service Opinion serait indisponible et que l’information de

création d’avis ne soit pas arrivée jusqu’au micro-service Invite, alors la seconde
invitation pourrait tout de même être envoyée à l’utilisateur même s’il a déjà rédigé au
moins un (1) avis dans le temps imparti.

Année 2023 – 2024
3.3 – MS Mailing
Ce micro-service prend en charge l’envoi d’e-mails auprès des utilisateurs du système

OllcAvis. Son fonctionnement est simple : il reçoit des demandes d’envoi d’e-mails depuis
le topic Kafka mail puis s’occupe de les envoyer.
Afin de rester résilient en cas d’indisponibilité du serveur SMTP, les e-mails à envoyer
sont conservés en base de données afin de pouvoir les prendre en charge ultérieurement.
Les e-mails envoyés depuis plus d’un (1) mois sont automatiquement purgés de la base
de données à rythme quotidien.
La table email est peuplée avec l’e-mail à envoyer dès lors que le micro-service reçoit un
message dans le topic Kafka mail. Le champ sent_at d’une entrée est mis à jour dès
lors que le micro-service a envoyé l’e-mail en question avec succès.
Le champ status contient une énumération composée des valeurs suivantes :

- SENDING : l’e-mail vient d’arriver et sa première tentative d’envoi est imminente ;
- SENT : l’e-mail a été envoyé avec succès (sent_at peuplé avec la date d’envoi) ;
- TO_SEND : l’envoi initial a échoué, une nouvelle tentative sera faite ultérieurement.

Année 2023 – 2024
3.3.2 - Cycle de vie d’un e-mail
Le micro-service appelant est chargé de construire les éléments suivants de l’e-mail à

envoyer : adresse e-mail du destinataire, objet de l’e-mail et contenu de l’e-mail. Le
contenu de l’e-mail peut être au format texte ou au format HTML selon la mise en page
souhaitée.
Les demandes d’envoi déposées dans le topic mail sont consommées par le micro-service
Mailing qui persiste les données en base. Par défaut, une demande d’envoi possède le
statut SENDING : il est directement pris en charge pour un envoi vers le serveur SMTP.
Dans la mesure où le serveur SMTP est opérationnel, et que l’envoi réussit, alors le statut
de la demande d’envoi passe à SENT et le champ sent_at est peuplé avec la date
effective d’envoi. Au bout d’un mois passé la date d’envoi, l’entrée est purgée de la base
de données.
Si l’envoi échoue pour une raison quelconque, le statut passe à TO_BE_SENT et sera pris
en charge périodiquement par le micro-service jusqu’à ce que l’envoi réussisse. Cette
prise en charge se fera via un CRON qui traitera l’ensemble des demandes ayant le statut
TO_BE_SENT.
3.3.3 - Serveur SMTP externe
Ce micro-service nécessite une connexion à un serveur SMTP afin de compléter sa

mission d’envoyer des e-mails. Dans le cadre du projet OllcAvis, le serveur SMTP de
l’Université de Rouen Normandie sera utilisé pour l’envoi d’e-mails depuis le système.
Nous ne pouvons pas garantir le taux de disponibilité du serveur SMTP. Par conséquent,
le micro-service a été conçu pour être résilient face aux éventuelles pannes du serveur
afin de ne pas “perdre” des demandes d’envoi si celles-ci venaient à arriver lors d’une
indisponibilité du serveur.

Année 2023 – 2024
3.4 – MS AutoMod
Ce micro-service se charge d’exécuter les algorithmes de modération automatique sur les

avis nouvellement postés. Il écoute sur son propre topic moderation dans lequel le
micro-service opinion dépose les avis et réponses fraîchement postés par les clients sur
la plateforme OllcAvi.
MS AutoMod est composé pour le moment d’une unique table contenant la liste des
algorithmes énumérant les différents algorithmes disponibles pour la configuration.
3.4.2 - Échanges entre micro-services
3.4.1.a - Auto-modération des avis
Nature Auto-modération
Topic Kafka moderation
Données fournies - Texte à modérer.
Objectif - Modération automatique des avis, renvoyant si l’avis à

modérer est accepté ou non.
3.4.3 - API publique
Le service étant destiné à une utilisation interne, il ne propose que très peu de routes.
Celles-ci correspondent à la configuration de l’auto-modération, principalement les
algorithmes utilisés.
L’auto-modération en elle-même est gérée par le topic Kafka “moderation”.
Routes de l’API proposées par le micro-service

Réponse
Méthode Chemin Entrée Code Sortie
GET /settings N/A 200 SettingsDto

Année 2023 – 2024
204 N/A
POST /settings SettingsDto 401 > Algorithme inexistant
Description du modèle de données utilisé :
SettingsDto
Champ Type Description
Liste des algorithmes à utiliser pour appliquer la
settings List<String>
modération automatique.
3.4.4 - Algorithmes
À définir.

Année 2023 – 2024
3.5 – Communication entre les Micro-Services

3.5.1 - Schéma de communication

Année 2023 – 2024
3.5.2 - Topic mail
Le principal consumer de ce topic est le micro-service de Mailing qui va nous

permettre d’envoyer des mails aux différents utilisateurs. Les principaux producer sont
le micro-service d’Invite qui va envoyer un message dans ce topic lorsqu’une
invitation à poster un avis devra être envoyé et le micro-service de Opinion qui va
envoyer un message dans ce topic lorsqu’un avis a été refusé, lorsqu’un commerçant
reçoit un avis sur sa boutique ou sur un de ses articles et lorsqu’un avis doit être modéré
par un modérateur après un signalement. Les données qui seront échangé à travers ce
topic contiendront :
- Le sujet du mail à envoyer
- Le contenu du mail à envoyer
- Adresse mail de l’utilisateur
La structure de l’objet envoyer depuis les micro-services order et opinion

ressemblera à ca:
{
“@type”: “mail”,
“body”:{
“subject”: string,
“content”: string,
“email”: string
}
}
3.5.3 - Topic moderation
Ce topic a pour objectif de modérer les différents avis. Tout d’abord, lorsque le micro-
service Opinion envoie un message sur ce topic, cela signifie que nous voulons
modérer un avis. Ensuite, le micro-service AutoMod va écouter ce message et va ensuite
le modérer. Les données échangés lors de cet échange seront :
- L’identifiant de l’avis
- L’identifiant du sujet
- Le type du sujet MERCHANT ou ARTICLE
- Le contenu de l’avis
Dans un second temps, le micro-service AutoMod pourra envoyer un message à travers

ce topic, pour objectif de donner une réponse au micro-service Opinion pour accepter
ou refuser l’avis. Les données échangés lors de cette réponse contiendront :
- L’identifiant de l’avis
- L’identifiant du sujet
- Le type du sujet MERCHANT ou ARTICLE
- Le sujet
- Les raisons du refus s’il y a un refus.
- Le status ACCEPTED ou DECLINED
La structure de l’objet envoyer sur le topic modération depuis le micro-service Opinion

destiné au micro-service AutoMod ressemblera à ca :
{
“@type”: “request”,
“body”:{
“opinionId”:integer,

Année 2023 – 2024
“sujectId”: uuid,
“sujectType”: “MERCHANT” | “ARTICLE”,
“content”: string
}
}
La structure de l’objet envoyer sur le topic modération depuis le micro-service AutoMod

destiné au micro-service Opinion ressemblera à ca :
{
“@type”: “result”,
“body”:{
“opinionId”: integer,
“sujectId”: uuid,
“sujectType”: “MERCHANT” | “ARTICLE”,
“reason”: string,
“content”: string,
“status” : “ACCEPTED” | “DECLINED”
}
}
Le type request est destiné pour demander que l’avis soit modéré. Et le type result
est destiné au résultat de la demande de modération.
3.5.4 - Topic opinion
Ce topic a pour objectif de notifier le micro-service Invite qui va traiter ce message

pour marquer qu’un avis a été déposé sur la commande. Ce message est envoyé depuis
le micro-service Opinion lorsqu’un avis est enregistré. Les données échangés
contiendront :
- L’identifiant de la commande
La structure de l’objet envoyer sur le topic opinion ressemblera à ca:

{
“@type”: “create”,
“body”:{
“id”:integer,
“orderId”: uuid
}
}
3.5.5 - Topic order
Ce topic a pour objectif de recevoir les commandes provenant du système Ollca,

ensuite notre micro-service Invite va traiter les commandes et le micro-service
Opinion va récupérer les informations qui lui sont nécessaires. Les données échangés
contiendront les informations suivantes :
- En attente du client

Année 2023 – 2024
4 - Cas d’utilisation
4.1 - Diagramme des cas d’utilisation

Année 2023 – 2024
4.2 - Résumé:
ID Cas d’utilisation
UC_01 S'authentifier
Admin
UC_02 Lister les rôles
UC_03 Gérer un rôle
UC_03_01 Créer un rôle
UC_03_02 Supprimer un rôle
UC_03_03 Modifier un rôle
UC_04 Gérer un élément de détails
UC_04_01 Ajouter un élément
UC_04_02 Supprimer un élément
UC_04_03 Modifier un élément
UC_05 Configurer l'algorithme de modération

Année 2023 – 2024
Modérateur
UC_06 Lister les avis à modérer
UC_07 Modérer un avis
UC_07_01 Consulter un avis à modérer
UC_08 Accès aux alertes
Commerçons
UC_09 Lister les avis sur ses produits/magasin
UC_10 Répondre à un avis
UC_11 Signaler un avis
UC_12 Gérer une réponse
UC_12_01 Supprimer une réponse
UC_12_02 Modifier une réponse
Client
UC_13 Lister ses avis
UC_14 Gérer un avis
UC_14_01 Modifier un avis
UC_14_02 Supprimer un avis
UC_15 Rédiger un avis
UC_16 Recevoir un email d'invitation
Visiteur
UC_17 Consulter les avis sur les magasins
UC_18 Consulter les avis sur les produits
UC_19 Signaler un avis
4.3. UC_01 : S'authentifier
Actions Description

Année 2023 – 2024
Pré-condition L’utilisateur possède un compte sur Ollca
Événements déclenchants L’utilisateur tente de se connecter
Condition d'arrêt Le serveur affiche le tableau de bord
Flots secondaires
Flots d'exceptions En cas d’échec de connection, un message d’erreur sera

renvoyé
Diagramme de séquence
Maquette

Année 2023 – 2024
4.9. UC_04 : Gérer un élément de détails

Maquette
4.10. UC_04_01 : Ajouter un élément
Actions Description
Pré-condition L’administrateur est connecté
Événements déclenchants L’administrateur clique sur “Gestion des éléments” puis

sur le bouton “+” .
Condition d'arrêt Un élément de détail à été créee avec les informations

spécifiées
Flots secondaires
Flots d'exceptions En cas d'échec lors de la création, un message d'erreur est

affiché, et l'administrateur peut corriger les informations
saisies.

Année 2023 – 2024
Maquette
4.11. UC_04_02 : Supprimer un élément
Actions Description

Année 2023 – 2024

sur le bouton “supprimer” associé à chaque élément .
Condition d'arrêt L’élément de détail à été supprimé
Flots secondaires
Flots d'exceptions En cas d'échec lors de la suppression, un message

d'erreur est affiché.
Maquette
4.12. UC_04_03 : Modifier un élément
Actions Description

sur le bouton “modifier” associé à chaque élément .
Condition d'arrêt L’élément de détail à été modifié
Flots secondaires
Flots d'exceptions En cas d'échec lors de la modification, un message

d'erreur est affiché et l’administrateur peut corriger les
informations saisies.

Année 2023 – 2024
Maquette
4.13. UC_05 : Configurer l'algorithme de modération
Actions Description
Événements déclenchants L'administrateur accède au panneau de configuration pour les

algorithmes de modération
Condition d'arrêt
Flots secondaires Les paramètres des algorithmes de modération sont configurés

par l'administrateur.
Flots d'exceptions En cas d'erreur lors de la configuration, un message d'erreur est

affiché, et l'administrateur peut réessayer ou prendre une autre
action.

Année 2023 – 2024
Maquette
4.14. UC_06 : Lister les avis à modérer
Actions Description
Pré-condition Le modérateur est connecté
Événements déclenchants Le modérateur clique sur Gestion des avis
Condition d'arrêt Le modérateur a accès à la liste des avis en attente de

Année 2023 – 2024
modération. Il peut consulter le contenu de chaque avis.
Flots secondaires
Flots d'exceptions
Maquette
4.15. UC_07 : Modérer un avis
Actions Description

Année 2023 – 2024
Pré-condition Le modérateur à accès à la liste des avis
Événements déclenchants Le modérateur clique sur un avis puis sur un bouton “✓

“ou “x” ou bien sur “...” puis sur “accepter “ ou
“supprimer”
Condition d'arrêt Le modérateur peut accepter ou refuser chaque avis dans la

liste.
Flots secondaires
Flots d'exceptions En cas d’erreur , un message est afficher et le modérateur

peut réesayer

Année 2023 – 2024
Maquette
4.16. UC_07_01 : Consulter un avis à modérer
Actions Description
Pré-condition Le modérateur accède à la liste des avis
Événements déclenchants Le modérateur clique sur un avis
Condition d'arrêt Le modérateur consulte les détails d’un avis
Flots secondaires
Flots d'exceptions

Année 2023 – 2024
Maquette
4.19. UC_08 : accéder aux alertes
Actions Description
Pré-condition Le modérateur est connecté
Événements déclenchants Le modérateur clique sur “Notifications”

Année 2023 – 2024
Condition d'arrêt Le modérateur à accès aux alertes
Flots secondaires
Flots d'exceptions
Maquette
4.20. UC_09 : Lister les avis sur ses produits/magasin

Année 2023 – 2024
Actions Description
Pré-condition Le commerçant est connecté
Événements déclenchants Le commerçant choisit “Gestion d’avis” sur le menu.
Condition d'arrêt La liste des avis sur les produits et le magasin du

commerçant s’affiche.
Flots secondaires
Flots d'exceptions

Année 2023 – 2024
Maquette
4.21. UC_10 : Répondre à un avis
Actions Description
Événements déclenchants Le commerçant clique sur le bouton “Répondre” de la liste

des actions sur la carte d’un avis.
Une fenêtre qui contient les détails de l’avis le formulaire
de réponse s’affiche.
Condition d'arrêt Le commerçant clique sur le bouton de validation.
Flots secondaires
Flots d'exceptions En cas d’échec lors de l'ajout de la réponse, un message

d’erreur doit s’afficher.

Année 2023 – 2024

Année 2023 – 2024
Maquette
4.22. UC_11 : Signaler un avis
Actions Description
Événements déclenchants Le commerçant clique sur le bouton “Signaler” de la liste

des actions sur la carte d’un avis.
Une fenêtre qui contient les détails de l’avis.
Flots secondaires
Flots d'exceptions En cas d’échec lors de signalement, un message d’erreur

doit s’afficher.

Année 2023 – 2024

Année 2023 – 2024
Maquette
4.23. UC_12 : Gérer une réponse

Maquette
4.24. UC_12_01 : Supprimer une réponse
Actions Description

Année 2023 – 2024
Événements déclenchants Le commerçant clique sur le bouton “Supprimer”.
Flots secondaires Une trace renseignant sur la suppression de la réponse

sera écrite dans un fichier de log.
Flots d'exceptions En cas d’échec lors de la suppression, un message

Maquette

Année 2023 – 2024
4.25. UC_12_02 : Modifier une réponse
Actions Description
Événements déclenchants Le commerçant clique sur le bouton “modifier”.
Flots secondaires
Flots d'exceptions En cas d’échec lors de la modification, un message


Année 2023 – 2024
Maquette
4.26. UC_13 : Lister ses avis
Actions Description
Pré-condition Le client est connecté
Événements déclenchants Le client choisit “Gestion des avis” sur le menu.
Condition d'arrêt La liste des avis que le client a laissés s’affiche.
Flots secondaires
Flots d'exceptions

Année 2023 – 2024
Maquette

Année 2023 – 2024
4.27. UC_14 : Gérer un avis

Maquette
4.28. UC_14_01 : Modifier un avis
Actions Description
Événements déclenchants Le client clique sur le bouton de modification d’avis.
Condition d'arrêt Le client clique sur le bouton de validation.
Flots secondaires
Flots d'exceptions En cas d’échec lors de la modification, un message


Année 2023 – 2024

Année 2023 – 2024
Maquette
4.29. UC_14_02 : Supprimer un avis
Actions Description
Événements déclenchants Le client clique sur le bouton de suppression d’avis.
Flots secondaires Une trace renseignant sur la suppression de l’avis sera

écrite dans un fichier de log.
Flots d'exceptions En cas d’échec lors de la suppression , un message


Année 2023 – 2024
Maquette
4.30. UC_15 : Rédiger un avis
Actions Description
Événements déclenchants Le client clique sur le lien envoyé par email, et sera dirigé
vers la page de rédaction.
Flots secondaires

Année 2023 – 2024
Flots d'exceptions En cas d’échec lors de l’ajout de l’avis, un message

Maquette
4.31. UC_16 : Recevoir un email d'invitation
Actions Description
Pré-condition Le client a fait une commande sur Ollca.
Événements déclenchants Le client a reçu sa commande d’Ollca.
Condition d'arrêt
Flots secondaires
Flots d'exceptions

Année 2023 – 2024
4.32. UC_17 : Consulter les avis sur les magasins
Actions Description
Pré-condition Le visiteur navigue sur Ollca.
Événements déclenchants Le visiteur rentre dans la page du magasin.
Condition d'arrêt
Flots secondaires
Flots d'exceptions

Année 2023 – 2024
Maquette
4.33. UC_18 : Consulter les avis sur les produits
Actions Description
Événements déclenchants Le visiteur rentre dans la page du produit.
Condition d'arrêt
Flots secondaires
Flots d'exceptions

Année 2023 – 2024
Maquette
4.34. UC_19 : Signaler un avis
Actions Description
Événements déclenchants Le visiteur rentre dans la page du produit et clique sur

signaler sur un avis.
Condition d'arrêt Le visiteur a signalé un avis
Flots secondaires
Flots d'exceptions

Année 2023 – 2024
Maquette

(DRAFT) Document D'architecture Logicielle

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

(DRAFT) Document D'architecture Logicielle

Transféré par

Droits d'auteur :

Formats disponibles

Document d’Architecture

Versio Date Modifications apportées

0.2 08/11/2023 Ajout du diagramme d’architecture

0.3 15/11/2023 Spécification technique des composants

OllcAvis - Master II GIL 2023/2024 1

Table des matières

Table des matières......................................................................................................

OllcAvis - Master II GIL 2023/2024 2

4.25. UC_12_02 : Modifier une réponse................................................................................................

OllcAvis - Master II GIL 2023/2024 3

Ce document a pour objectif de décrire l’architecture logicielle du système OllcAvis. Il

2 – Documents applicables et référence

La réalisation du présent document s’appuie sur la liste des documents et applications

⮚ Cahier des Clauses Techniques Particulières (CCTP) : ce document décrit le

⮚ Figma : outil de maquettage et prototypage utilisé pour dessiner la maquette de

⮚ Lucidchart : éditeur de diagramme d’architecture collaboratif.

⮚ DrawSQL : éditeur de diagramme permettant de concevoir des schémas de base

OllcAvis - Master II GIL 2023/2024 4

3 – Terminologie et sigles utilisés

REST (Representational State Transfer) ou RESTful : style d’architecture permettant de

Front-end : ensemble des éléments visibles par les visiteurs/utilisateurs et accessibles

MS (Micro-service) : une façon de construire des applications en découpant leur

HTTP (Hypertext Transfer Protocol) : protocole de communication client-serveur de la

IHM (Interface Homme Machine) : composant logiciel permettant aux utilisateurs

Sous-Composant : morceau d’un composant permettant de réaliser une action précise

Framework : ensemble cohérent d’outils et de composants logiciels structurels

Spring Boot : framework open source qui facilite le développement d’applications

OllcAvis - Master II GIL 2023/2024 5

1 – Principes fondamentaux des micro-services

L’autonomie contribue également à la disponibilité et à l’évolutivité globales du

Principe 2 : Couplage lâche

Les micro-services sont indépendants et faiblement couplés. Le couplage fait

Cela permet une plus grande évolutivité et de nouvelles solutions en permettant

La réutilisation reste un principe de la conception de micro-services. Toutefois, la

Principe 4 : Tolérance aux pannes

Si un composant tombe en panne, la tolérance aux pannes est la capacité qui

OllcAvis - Master II GIL 2023/2024 6

Tous les principes de conception mentionnés contribuent au principe de

OllcAvis - Master II GIL 2023/2024 7

2 – Schéma de l’architecture générale

3 – Spécification technique des composants

Ce micro-service permet la gestion des avis. En particulier, il va gérer la rédaction d’avis,

3.1.1 – Schéma de base de données relationnelle

OllcAvis - Master II GIL 2023/2024 8

OllcAvis - Master II GIL 2023/2024 9

Les tables event_historic (historique d’événement) et answer (réponse) sont liées à

La table answer correspondant aux réponses et qui contient la réponse, l’auteur

Les tables detail_element et detail_element_answer permettent de stocker les

3.1.3 - API publique

Routes de l’API proposées par le micro-service

Méthode Chemin Entrée Réponse

OllcAvis - Master II GIL 2023/2024 10

GET /opinions N/A 200 List<OpinionDto>

GET /opinions-by-product N/A List<OpinionDto>

PUT /opinions/{id} UpdateOpinionDto 400 > Entrée invalide

404 > Avis inexistant

POST /opinions/{id}/moderate ModOpinionDto 200 N/A

OllcAvis - Master II GIL 2023/2024 11

Ce micro-service a pour responsabilité de prendre en charge les commandes reçues

3.2.1 - Schéma de base de données

La table client stocke les informations liées à un client du système Ollca :

La table product stocke les informations liées à un produit du système Ollca :

La table merchant stocke les informations liées à un marchand du système Ollca :