julia.spriggs/dossier
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

changes to project dossier to make it more logical

Browse source
This commit is contained in:
Julia Spriggs 2024-10-28 19:17:40 +01:00
parent 1024cf844a
commit fa5d9771d5
7 changed files with 129 additions and 123 deletions
Download patch file Download diff file Expand all files Collapse all files

7
jury blanc/jury blanc
View file

@ -40,10 +40,12 @@ ReservedMaterial peut avoir plusieurs matériaux, mais au moins 1, alors 1..*
Un matérial peut être disponible en plusieurs exemplaires, mais au moins 1, alors 1..*
Chaque matérial appartient à 1 catégorie, alors 1
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.
Portée
On peut avoir plusieurs types de portées pour nos attributs : public, private, protected, 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.
En plus de montrer les liens entre chaque Entity, on a aussi profité de notre diagramme de classe pour imaginer des services. Dans le slide, on voit bien comment on est censés créer chacun des services, en utilisant User comme exemple, et le code que nous avons créé pour create user. On a aussi créé un type InputRegister pour user afin de regrouper les infos nécessaires pour un User.
Le dernier diagramme sur lequel nous avons travaillé avant de nous mettre à coder, c'était le diagramme de cas d'utilisation. Après beaucoup de discussion, on voulait qu'un simple visiteur puisse regarder la catalogue, mais si la personne veut faire une réservation, il faut créer un compte et se logger. Alors c'est pour cela que le visiteur ainsi que le client loggué ait accès pour voir les matériaux sur le site. L'admin, cependant, a des droits qu'un client n'a pas - par exemple, il peut créer, mettre à jour, et supprimer des matériaux si nécessaire.
@ -52,10 +54,7 @@ Pour conclure aujourd'hui, je vous présente un schéma de notre application.
Le schéma commence en bas, avec le développeur, qui fait des commits avec git. Une fois commité et vérifié, le dév push sur main, ou fait un pull request. Cela déclenche les actions github, et les tests mis en place check si tout va bien. Si les tests passent, les nouvelles images sont publiées sur dockerhub, et puis on peut déclencher un webhook ou faire un fetch and deploy afin de récupérer tout ce qu'il faut pour le serveur. Côté client, notre projet utilise Next avec React, ainsi que material UI. Sur le serveur, on utilise node et express, notre BDD utilise postgreSQL, et finalement pour faire les requêtes on utilise graphQL. Notre projet est écrit en typescript, qui est transpilé en Javascript.
maximales mcd
mcd - pas de FK - il y en avait pas ?
mld - enlever des cardinalités - OK
category id dans une autre couleur - OK
diagramme de séquence
montrer un extrait de diagramme de classe