update readme
continuous-integration/drone/push Build is failing
Details
continuous-integration/drone/push Build is failing
Details
parent
29f226ebbb
commit
29e611487e
@ -0,0 +1,91 @@
|
||||
[retour au README.md](../../../README.md)
|
||||
[Retour aux Documents](../../README_DOCUMENTS.md)
|
||||
[Retour au diagramme de classes](../README_DIAGRAMMES.md)
|
||||
|
||||
# Introduction au Diagramme de Classes : Gestion des Utilisateurs et Notifications
|
||||
|
||||
Bienvenue dans le cœur de notre système, où la gestion des utilisateurs et des notifications prend vie à travers ce diagramme de classes. Explorez les relations et les fonctionnalités essentielles qui orchestrent l'interaction entre les utilisateurs, les demandes d'amis, et les notifications.
|
||||
|
||||
**Entités Principales :**
|
||||
|
||||
- **Utilisateur (User) :** Représente les individus inscrits sur notre plateforme, caractérisés par leur nom et établissant des liens d'amitié avec d'autres utilisateurs.
|
||||
|
||||
- **Notification (Notification) :** Contient le texte informatif des notifications qui peuvent être émises par le système.
|
||||
|
||||
- **Demande d'Ami (Ask) :** Modélise une demande d'amitié émise par un utilisateur en direction d'un autre.
|
||||
|
||||
**Interfaces et Classes Abstraites :**
|
||||
|
||||
- **INotifier :** Interface définissant la méthode `notify()`, implémentée par des classes concrètes pour gérer la notification aux observateurs.
|
||||
|
||||
- **Observer :** Interface définissant la méthode `update()`, implémentée par les classes qui souhaitent être informées des changements dans un sujet observé.
|
||||
|
||||
- **UserManager :** Classe abstraite gérant la logique métier liée aux utilisateurs, tels que l'ajout ou la suppression d'amis, la réponse aux demandes d'amis, et la récupération de la liste d'amis.
|
||||
|
||||
- **IUserRepository :** Interface définissant les méthodes pour la recherche d'utilisateurs et l'ajout d'un nouvel utilisateur.
|
||||
|
||||
**Relations Clés :**
|
||||
|
||||
- Les utilisateurs peuvent avoir plusieurs amis et plusieurs notifications.
|
||||
|
||||
- La classe UserManager est connectée à IUserRepository pour gérer les opérations liées aux utilisateurs.
|
||||
|
||||
- Observer et Subject sont des composants du modèle de conception "Observer", permettant la notification efficace des changements dans le système.
|
||||
|
||||
Plongez-vous dans ce diagramme pour découvrir comment notre application crée un écosystème social dynamique, permettant aux utilisateurs d'interagir, de rester informés et de développer des liens significatifs au sein de la communauté.
|
||||
|
||||
```plantuml
|
||||
class User {
|
||||
+ name : string
|
||||
}
|
||||
|
||||
User "1" --> "*" User: friends
|
||||
User "1" --> "*" Notification: notifications
|
||||
User "1" --> "*" Ask: friendRequests
|
||||
class Notification {
|
||||
- text : string
|
||||
}
|
||||
|
||||
interface INotifier {
|
||||
+ notify() : void
|
||||
}
|
||||
|
||||
INotifier --|> Observer
|
||||
|
||||
abstract class UserManager {
|
||||
- currentUser : User
|
||||
+ deleteFriend(userId : int) : void
|
||||
+ addFriend(userId : int) : void
|
||||
+ respondToFriendRequest(requestId : int, choice : bool) : void
|
||||
+ getFriends(userId : int) : User[]
|
||||
}
|
||||
|
||||
class Ask {
|
||||
- fromUser : int
|
||||
- toUser : int
|
||||
}
|
||||
|
||||
Ask --|> Subject
|
||||
|
||||
abstract class Subject {
|
||||
+ attach(o : Observer) : void
|
||||
+ detach(o : Observer) : void
|
||||
+ notify() : void
|
||||
}
|
||||
|
||||
Subject "1" --> "*" Observer
|
||||
interface Observer {
|
||||
+ update() : void
|
||||
}
|
||||
|
||||
UserManager ..> User
|
||||
UserManager o-- IUserRepository
|
||||
UserManager o-- INotifier
|
||||
|
||||
interface IUserRepository {
|
||||
+ findByUsername(username : string) : User
|
||||
+ addUser(user : User) : bool
|
||||
}
|
||||
|
||||
IUserRepository ..> User
|
||||
```
|
@ -0,0 +1,41 @@
|
||||
[retour au README.md](../../../README.md)
|
||||
[Retour aux Documents](../../README_DOCUMENTS.md)
|
||||
[Retour au diagramme de classes](../README_DIAGRAMMES.md)
|
||||
|
||||
# Introduction au Diagramme de Séquence : Gestion des Demandes d'Amis
|
||||
|
||||
Bienvenue dans le processus dynamique de gestion des demandes d'amis au sein de notre application ! Ce diagramme de séquence met en évidence les étapes clés impliquées dans la gestion des demandes d'amis entre utilisateurs.
|
||||
|
||||
**Acteurs Principaux :**
|
||||
|
||||
- **Utilisateur (u) :** L'individu interagissant avec l'application, recevant et répondant aux demandes d'amis.
|
||||
|
||||
**Flux d'Interaction :**
|
||||
|
||||
1. **Réception d'une Demande d'Ami :** Lorsqu'un utilisateur reçoit une demande d'ami, le modèle (Model) notifie le contrôleur (Controller) de la nouvelle demande, spécifiant l'identifiant de l'utilisateur émetteur.
|
||||
|
||||
2. **Affichage de la Demande d'Ami :** Le contrôleur transmet l'information à la vue (View), qui affiche la demande d'ami à l'utilisateur.
|
||||
|
||||
3. **Affichage de la Page des Demandes d'Amis :** L'utilisateur visualise la page des demandes d'amis dans l'interface utilisateur.
|
||||
|
||||
4. **Réponse à la Demande d'Ami :** L'utilisateur prend une décision quant à la demande d'ami, en répondant par un choix binaire (accepter ou refuser).
|
||||
|
||||
5. **Enregistrement de la Réponse :** La vue (View) transmet la réponse de l'utilisateur au contrôleur, qui enregistre cette réponse.
|
||||
|
||||
6. **Envoi de la Réponse :** Le contrôleur communique avec le modèle pour envoyer la réponse, indiquant si la demande a été acceptée (true) ou refusée (false).
|
||||
|
||||
À travers ce diagramme de séquence, découvrez comment notre application gère efficacement le processus de gestion des demandes d'amis, offrant aux utilisateurs une expérience transparente et réactive lors de l'établissement de connexions sociales au sein de la plateforme.
|
||||
|
||||
```plantuml
|
||||
actor User as u
|
||||
boundary View as v
|
||||
control Controller as c
|
||||
entity Model as m
|
||||
|
||||
m->c:RecevoirDemandeAmi(idUser)
|
||||
c->v:AfficherDemandeAmi(idUser)
|
||||
v->u:PageDemandeAmi(idUser)
|
||||
u-->v:RepondreDemandeAmi(bool)
|
||||
v-->c:EnregistrerReponse(bool)
|
||||
c-->m:EnvoyerReponse(bool)
|
||||
```
|
@ -0,0 +1,50 @@
|
||||
[retour au README.md](../../../README.md)
|
||||
[Retour aux Documents](../../README_DOCUMENTS.md)
|
||||
[Retour au diagramme de classes](../README_DIAGRAMMES.md)
|
||||
|
||||
# Introduction au Diagramme de Séquence : Recherche d'Amis
|
||||
|
||||
Bienvenue dans le processus dynamique de recherche d'amis au sein de notre application ! Ce diagramme de séquence met en lumière les étapes clés impliquées lorsque les utilisateurs recherchent des amis en utilisant un pseudo spécifique.
|
||||
|
||||
**Acteurs Principaux :**
|
||||
|
||||
- **Utilisateur (u) :** L'individu interagissant avec l'application, initié à la recherche d'amis.
|
||||
|
||||
**Flux d'Interaction :**
|
||||
|
||||
1. **Accès à la Fonctionnalité de Recherche :** L'utilisateur déclenche la fonctionnalité de recherche d'amis depuis son interface utilisateur.
|
||||
|
||||
2. **Saisie du Pseudo :** L'utilisateur entre le pseudo de l'ami qu'il souhaite rechercher.
|
||||
|
||||
3. **Requête de Recherche :** La vue (View) transmet la demande de recherche au contrôleur (Controller), qui déclenche une requête GET au serveur pour récupérer la liste des amis correspondant au pseudo saisi.
|
||||
|
||||
4. **Traitement de la Requête :** Le modèle (Model) récupère la liste d'amis correspondante en utilisant l'identifiant de l'utilisateur et notifie le contrôleur du résultat.
|
||||
|
||||
5. **Notification des Utilisateurs :** Le modèle informe également les utilisateurs concernés (émetteur et destinataire) de l'action de recherche effectuée.
|
||||
|
||||
6. **Rendu de la Vue :** Le contrôleur reçoit la liste d'amis du modèle et rend cette liste à la vue.
|
||||
|
||||
7. **Affichage des Résultats :** La vue affiche les résultats de la recherche à l'utilisateur, montrant les amis qui correspondent au pseudo saisi.
|
||||
|
||||
À travers ce diagramme de séquence, découvrez comment notre application facilite le processus de recherche d'amis, fournissant aux utilisateurs une interface conviviale et réactive pour élargir leur réseau social au sein de la plateforme.
|
||||
|
||||
```plantuml
|
||||
actor User as u
|
||||
boundary View as v
|
||||
control Controller as c
|
||||
entity Model as m
|
||||
|
||||
u->v:/Friend
|
||||
v->c:Get : /Friends
|
||||
c->m:getFriends(userId)
|
||||
m-->c::friends : User[]
|
||||
c-->v:renderView(Friends)
|
||||
v-->u:
|
||||
u->v:input : name
|
||||
v->c:Get : searchFriends? pseudo=name
|
||||
c->m:searchUser(name:string)
|
||||
m->m:notify(from : user, to : user, action : action)
|
||||
m-->c:OK
|
||||
c-->v:OK
|
||||
v-->u:OK
|
||||
```
|
@ -0,0 +1,64 @@
|
||||
[retour au README.md](../../../README.md)
|
||||
[Retour aux Documents](../../README_DOCUMENTS.md)
|
||||
[Retour au diagramme de classes](../README_DIAGRAMMES.md)
|
||||
|
||||
# Introduction au Diagramme de Séquence : Gestion des Amis
|
||||
|
||||
Bienvenue dans le processus dynamique de gestion des amis au sein de notre application ! Ce diagramme de séquence met en lumière les interactions entre l'utilisateur et l'application, ainsi que le flux d'informations entre les différentes composantes du système.
|
||||
|
||||
**Acteurs Principaux :**
|
||||
|
||||
- **Utilisateur (u) :** L'individu interagissant avec l'application, souhaitant consulter et gérer sa liste d'amis.
|
||||
|
||||
**Flux d'Interaction :**
|
||||
|
||||
1. **Demande de la Page d'Amis :** L'utilisateur déclenche la demande de la page d'amis, amorçant le processus d'affichage de sa liste d'amis.
|
||||
|
||||
2. **Récupération des Amis :** Le contrôleur (Controller) reçoit la demande et interagit avec le modèle (Model) pour récupérer la liste d'amis associée à l'identifiant de l'utilisateur.
|
||||
|
||||
- *Cas de Récupération Réussi :* Si la récupération est réussie, le modèle transmet la liste d'amis au contrôleur.
|
||||
|
||||
- *Cas d'Échec de Récupération :* En cas d'échec, une notification d'erreur est renvoyée.
|
||||
|
||||
3. **Affichage de la Liste d'Amis :** Le contrôleur rend la vue (View) en utilisant la liste d'amis récupérée, qui est ensuite affichée à l'utilisateur.
|
||||
|
||||
4. **Suppression d'un Ami :** L'utilisateur décide de supprimer un ami spécifique en cliquant sur l'option correspondante.
|
||||
|
||||
5. **Traitement de la Suppression :** Le contrôleur, en réponse à la demande de suppression, envoie une requête au modèle pour effectuer la suppression de l'ami identifié par son identifiant utilisateur (idUser).
|
||||
|
||||
- *Cas de Suppression Réussie :* Si la suppression est réussie, le modèle renvoie la liste d'amis mise à jour.
|
||||
|
||||
- *Cas d'Échec de Suppression :* En cas d'échec, une notification d'erreur est renvoyée.
|
||||
|
||||
6. **Affichage de la Liste d'Amis Mise à Jour :** La vue est mise à jour avec la nouvelle liste d'amis, qui est ensuite affichée à l'utilisateur.
|
||||
|
||||
À travers ce diagramme de séquence, découvrez comment notre application gère de manière fluide et réactive les interactions de l'utilisateur avec sa liste d'amis, garantissant une expérience utilisateur cohérente et sans heurts.
|
||||
|
||||
```plantuml
|
||||
actor User as u
|
||||
boundary View as v
|
||||
control Controller as c
|
||||
entity Model as m
|
||||
|
||||
u->v: Request Friends Page
|
||||
v->c: Get /Friends
|
||||
c->m: getFriends(userId)
|
||||
alt successful retrieval
|
||||
m-->c: friendsList: User[]
|
||||
else retrieval failed
|
||||
m-->c: error
|
||||
end
|
||||
c-->v: renderView(friendsList)
|
||||
v-->u: Display Friends
|
||||
|
||||
u->v: clickDeleteFriend(idUser)
|
||||
v->c: Post: deleteFriend(idUser)
|
||||
c->m: deleteFriend(idUser)
|
||||
alt successful deletion
|
||||
m-->c: updatedFriendsList: User[]
|
||||
else deletion failed
|
||||
m-->c: error
|
||||
end
|
||||
c-->v: renderView(updatedFriendsList)
|
||||
v-->u: Display Updated Friends
|
||||
```
|
Loading…
Reference in new issue