diff --git a/dossier de projet/images/class diagram.jpg b/dossier de projet/images/class diagram.jpg index f132cff..7de033a 100644 Binary files a/dossier de projet/images/class diagram.jpg and b/dossier de projet/images/class diagram.jpg differ diff --git a/dossier de projet/images/material sorted by category.png b/dossier de projet/images/material sorted by category.png deleted file mode 100644 index f309dc7..0000000 Binary files a/dossier de projet/images/material sorted by category.png and /dev/null differ diff --git a/dossier de projet/images/welcome page.png b/dossier de projet/images/welcome page.png deleted file mode 100644 index 73eb687..0000000 Binary files a/dossier de projet/images/welcome page.png and /dev/null differ diff --git a/dossier de projet/main.md b/dossier de projet/main.md index d99e822..7aa30bb 100644 --- a/dossier de projet/main.md +++ b/dossier de projet/main.md @@ -292,6 +292,8 @@ On a aussi fait les maximalités (chiffres en bleu dans notre diagramme). Cela n ---- +\newpage + ### Modèle Logique de Données Nous progressons vers le Modèle Logique de Données, une étape plus concrète dans la définition de la base de données. Comme mentionné ci-dessus, on peut voir qu'il est nécessaire de créer un tableau intermédiaire entre Réservation et Material, qu’on a décidé d’appeler reserved_material, afin d’éviter une relation Many to Many. À cause de cela, on voit qu’on a deux attributs qui sont des foreign keys dans ce tableau, alors que dans d’autres comme Reservation, on a une clé étrangère pour lier les deux entités. @@ -327,16 +329,12 @@ Pour le diagramme de classe, nous nous reposons sur ces idées : * Pour louer un matérial, un utilisateur doit créer un compte sur le site, avec son prénom, nom de famille, son email et un mot de passe. * Chaque fois qu'un utilisateur se connecte à notre site, cela crée une session, où nous pouvons garder les information de leur panier dans un fichier JSON. - \newpage - #### Multiplicités Dans le diagramme de classe, il faut travailler les multiplicités, alors si on prend l’exemple de l’entity User, dans les deux directions, vers Reservation ainsi que Session, on voit qu’il y a une Multiplicité de 1. Pourquoi ? Car un User est relié à une session. Il ne peut en avoir plusieurs. Une Reservation est également relié à seulement un User, alors c’est également 1. ![Multiplicités entre Session et User, et Reservation et User](images/Reservation User Session.jpg){height=50%} -\newpage - #### Portée On peut avoir plusieurs types de portées pour les attributs : public, privé, ou protégé par exemple. On a décidé de garder tout public à part les mots de passe pour un utilisateur, qui sont privés, pour les raisons de sécurité. De cette façon, les autres classes ne pourront pas y accéder, et cela protège ces données. @@ -1210,11 +1208,11 @@ useEffect(() => { *Accueil* -![Capture d'écran de la page d'accueil](images/welcome page.png) +(image de l'accueil) *Catégorie "Sports d'hiver"* -![Capture d'écran du matérial trié par la catégorie sports d'hiver](images/material sorted by category.png) +(image des matérials trié par une catégorie) Lorsque l'utilisateur se trouve sur la page d'accueil, ces boutons de catégorie sont visibles, offrant un accès direct aux différentes catégories de matériels. Ces boutons sont créés dynamiquement en parcourant les catégories obtenues grâce à la requête GraphQL. Chaque bouton permet de rediriger l'utilisateur vers une page de liste de matériels correspondant à la catégorie choisie. @@ -2071,9 +2069,3 @@ La securité d’une application est extrêmement importante. On ne peut pas pen * CORS management : Middleware peut gérer les settings de Cross-Origin Resource Sharing (CORS) pour contrôler quels domaines peuvent accéder les ressources, ce qui empêche des accès non-authorisés. * Security Headers : Middleware peut ajouter des security headers HTTP aux réponse, ce qui donne une couche additionnelle de sécurité contre les attaques. * Gestion des Sessions : Middleware peut gérer les cookies de session secures et implemente les mesures comme expiration des cookies et secure flags pour protéder les données de session. - -\newpage - -# Annexe (diagramme de classe) - -![](images/class diagram.jpg){height=99%} diff --git a/dossier professionnel/downloaded from microsoft 365/DP_CDA_Pré-rempli 3 v2.odt b/dossier professionnel/downloaded from microsoft 365/DP_CDA_Pré-rempli 3 v2.odt deleted file mode 100644 index 0ddbde4..0000000 Binary files a/dossier professionnel/downloaded from microsoft 365/DP_CDA_Pré-rempli 3 v2.odt and /dev/null differ diff --git a/dossier professionnel/downloaded from microsoft 365/DP_CDA_Pré-rempli 3 v2.pdf b/dossier professionnel/downloaded from microsoft 365/DP_CDA_Pré-rempli 3 v2.pdf deleted file mode 100644 index cc29d10..0000000 Binary files a/dossier professionnel/downloaded from microsoft 365/DP_CDA_Pré-rempli 3 v2.pdf and /dev/null differ diff --git a/dossier professionnel/signé/DP_CDA_Pré-rempli.pdf b/dossier professionnel/signé/DP_CDA_Pré-rempli.pdf deleted file mode 100644 index 2e47549..0000000 Binary files a/dossier professionnel/signé/DP_CDA_Pré-rempli.pdf and /dev/null differ diff --git a/dossier professionnel/with text in text boxes/DP_CDA_Pré-rempli.docx b/dossier professionnel/with text in text boxes/DP_CDA_Pré-rempli.docx deleted file mode 100644 index 1e0d688..0000000 Binary files a/dossier professionnel/with text in text boxes/DP_CDA_Pré-rempli.docx and /dev/null differ diff --git a/dossier professionnel/with text in text boxes/DP_CDA_Pré-rempli.pdf b/dossier professionnel/with text in text boxes/DP_CDA_Pré-rempli.pdf deleted file mode 100644 index 50f34f5..0000000 Binary files a/dossier professionnel/with text in text boxes/DP_CDA_Pré-rempli.pdf and /dev/null differ diff --git a/jury blanc/jury blanc b/jury blanc/jury blanc index 9202155..6de6b21 100644 --- a/jury blanc/jury blanc +++ b/jury blanc/jury blanc @@ -15,7 +15,7 @@ Chaque catégorie peut contenir 0 matériaux et au maximum plusieurs matériaux. Avec ceci, on a pu créer une phrase qui résume nos idées, et on peut créer le modèle conceptuel de données selon cette phrases. -La phrase qui résume : Un utilisateur se connecte à une session, et envoie une réservation qui contient du matériel, et qui appartient à une catégorie, et elle contient la date du début, la date de la fin, et si la réservation a été complété. +La phrase qui résume : Un ou plusieurs utilisateurs envoient une réservation qui contient du matériel, qui appartient à 1 catégorie, et elle contient la date du début, la date de la fin, et le user id. Après avoir créer le modèle conceptuel des données, nous avons procédé à créer le modèle logique des données. On a enlévé le cardinal le plus petit chaque fois, et en faisant ça, on s'est rendu compte qu'on allait avoir un tableau Many to Many, alors afin d'éviter ce problème, nous avons créé un tableau intermédiaire, reserved_material, qui contient les ids de matérial et de la réservation, ainsi que la quantité réservée, et le prix de la réservation. Non seulement ce tableau aide à faire intermédiaire, mais c'est un récap qui peut être partagé avec l'utilisateur une fois leur réservation est finalisée. @@ -30,7 +30,7 @@ Ce magasin contient des matériaux. Un matérial est caracterisé par son nom, sa description, son image, son stock initial, son prix. Un matérial est attribué à au moins une catégorie, qui a son nom. Pour louer un matérial, un utilisateur doit créer un compte sur le site, avec son prénom, nom de famille, son email et un mot de passe. -Chaque fois qu'un utilisateur se connecte à notre site, cela crée une session, où nous pouvons garder les information de leur panier dans un fichier JSON. +Chaque fois qu'un utilisateur se connecte à notre site, cela crée une session, où nous pouvons garder les information de leur caddy dans un fichier JSON. Multiplicités Une réservation est relié à au minimum et au maximum 1 utilisateur, alors 1