-
Notifications
You must be signed in to change notification settings - Fork 0
Explication du diagramme
La classe « Connection » (1) prend en paramètre un username et un password. Cette classe possède une méthode « checkUserData » qui permet de savoir si l’username existe. Si oui, toutes les informations de ce username sont récupérées depuis la base de donnée et un objet UserData est créé pour être utilisé par d’autres classes :
La classe « PasswordForget » (2) utilise l’objet UserData pour chercher la question secrète, et vérifie si la réponse correspond. Si la réponse est bonne, le user sait changer son mot de passe. La classe « User » (3) utilise l'objet UserData pour récupérer les données que l'on pourra afficher en profil utilisateur sur l'application.
La classe « register » (4) permet de créer un nouveau user. On crée un dictionnaire qui contient les données de tous les utilisateurs, on vérifie le mot de passe et si l'adresse mail existe. Un fois ces informations vérifiées, on enregistre l'utilisateur dans la base de donnée avec " insertUserData " et on utilise la méthode " getUserDataFromDB " pou créer l'objet UserData.
Nous avons besoin d’un fichier de fonction « Utilities.Lib » (5) afin d’y stocker toutes les méthodes statiques utilisées par plusieurs classes.
La classe "User" utilise l'objet UserData pour récupérer les données utilisateur après connexion. Elle nous permet d'afficher le profil une fois sur l'application.
Chaque rôle hérite de la classe « User », en fonction des rôles présents dans cette classe. "Modérator" (6) hérite de user : un modérateur peut faire tout ce que user peut faire. La classe "Admin" (7) hérite de modérateur pour les mêmes raisons.
Présentation du projet
Cahier des charges
- Présentation du client
- Présentation du projet
- Objectif du client
- Intervenants
- Cibles utilisateurs
- Demandes fonctionnelles
- Contraintes
- Charte graphique ergonomique
- Enveloppe budgétaire
- Planification
Diagramme de classes
Diagramme d'architecture
Tests Unitaires