Résumé coaching 3

+ Le groupe montre en démo que backend et frontend choisis sont installés et fonctionnent (au moins les bases).
+ Idéalement le groupe peut également faire le lien pour accéder à la base de données choisie.

+ Le groupe explique dans le wiki quelle est l'architecture et comment le projet est mis en place.
+ Le groupe doit maintenir à jour cette partie au fur et à mesure de l'avancement du projet et des choix effectués, en prévenant le coach.
+ Le schéma DB, ainsi que les autres schémas utiles, seront placés ici (datés!) Et mis à jour au fur et à mesure des changements.

1. Backend

1.1 Organisation du code

[Présentation La structure/hiérarchie des fichiers et dossiers du code source du backend]

1.2 Diagramme de classes UML

[Explication textuelle du diagramme de classes]

Table Utilisateurs

• Un utilisateur peut avoir des intérêts
• Un utilisateur doit faire au moins une réservation
• Un utilisateur peut posséder un ou plusieurs restaurants

Table Réservation

• Une réservation correspond à un utilisateur
• Une réservation correspond à une table

Table Restaurant

• Un restaurant appartient à au moins un utilisateur
• Un restaurant possède au moins une table

Table Intérêts

• Un intérêt correspond à au moins un utilisateur
• Un intérêt peut être le thème d'une ou plusieurs tables

Table Tables

• Une table correspond à un restaurant
• Une table peut avoir pour thème un ou plusieurs intérêts
• Une table peut correspondre à une ou plusieurs réservations
• Une table a un ou plusieurs capteurs

Table Capteurs

• Un capteur correspond à une table

2. Schémas, diagrammes et infos

2.1 Diagrammes liés à la base de données

[Schémas EA / Relationnel de la DB] [Texte expliquant les diagrammes et justifiant les choix de conception]

=> mettre le schéma entité association

2.2 Résumé du fonctionnement général de l'application (idéalement avec un schéma)

Un utilisateur peut effectuer une réservation dans un restaurant de son choix.
Une réservation comprend une date, une table, le nombre de personne présente à la table et un créneau horaire.
Un utilisateur propriétaire d'un restaurant peut accéder à un dashboard de gestion de ce restaurant. Ce dashboard contiendra les différentes réservations qu'il pourra valider ou pas.

2.3 Autres diagrammes de fonctionnement et d'architecture (ou autres informations utiles)

3. Frontend

3.1 Organisation du code

[Présentation de la structure/hiérarchie des fichiers et dossiers du code source du frontend]

3.2 Apparence

[Quelques screenshots pour montrer le résultat + discussion sur l'évolution depuis les premières maquettes]