SAÉ S3 - dev. appli avec BdD

1°/ Constitution des groupes et choix du sujet

• Les groupes doivent être constitués de 5 étudiants (sauf exception à 4 à cause du nombre d'étudiants), peu importe les groupes de TD/TP/parcours
• En cas de litige ou problèmes pour former les groupes, l'équipe pédagogique se donne le droit de constituer arbitrairement certains groupes.
• Chaque groupe constitué doit choisir un des 2 types de sujet et en préciser le contexte (cf. ci-dessous) 
• Les 2 types de sujet sont décrits dans les articles :
  • sujet type 1, orienté développement "full stack"
  • sujet type 2, orienté manipulation de données

2°/ Organisation du travail

2.1°/ sujet type 1 - orienté full stack

• L'organisation des cours de S3 permettent d'apprendre en parallèle comment créer le front et le back d'une application web.
• Il est donc possible de commencer le développement de ces 2 parties quasi en même temps, une fois que le cahier des charges est pleinement défini.
• En revanche, l'accès d'un serveur node à une BdD SQL est abordé en seconde partie du semestre 3. Il n'est donc pas possible d'implémenter ces accès dès le début de la SAÉ. En revanche, il est parfaitement possible de modéliser dès le début la BdD en définissant quelles tables sont utiles, avec quels champs.
• Compte tenu de ces contraintes, voici un suggestion de découpage du travail : 
  1. création d'un cahier des charges détaillé, c.a.d. qui fixe le cadre du projet (type manifestation, prestataire, ...) aussi bien du point de vue fonctionnel (quels services, quelles statistiques, ...) que les données manipulées (informations liées aux prestataires, services, ...)
  2. création du modèle de données pour la BdD, puis une fois stabilisé des scripts de création de la BdD. L'idéal est de commencer par les données communes à tout projet : informations utilisateur, données de gestion de la carte interactive puis de s’intéresser aux données liées aux services.
  3. définition des requêtes possibles donc des routes de l'API en fonction des fonctionnalités de l'application. Cela signifie qu'il faut définir le type de requête HTTP, ainsi que le format de la route. Les premières routes à définir concernent la gestion des utilisateurs puis celles de la carte, pour terminer avec les services et les statistiques.
  4. création du modèle de données pour la communication entre le front-end et l'API. Lors d'une requête vers une route, ces deux parties vont s'échanger des objets JSON. Il faut donc définir leur contenu. Par exemple, lorsque que l'utilisateur veut s'authentifier, le front-end doit envoyer une requête au serveur API. Cette requête est forcément accompagnée d'un objet JSON contenant au minimum un champ pour le login, et un pour le mot de passe. Il faut donc définir précisément la structure de cet objet : nom des champs, type des champs, optionnels ou non, etc. Ensuite, le serveur procède à l'authentification et va retourner un objet résultat au front-end. Il faut également définir la structure de cet objet. Ces définitions sont à écrire pour chacune des requêtes/routes possibles.
  5. création d'un fichier contenant des objets JSON faisant office de source de données pour l'API et le front-end (comme vu dans les cours de dev. Web). Ce fichier contient tout simplement des objets dont le format correspond à celui qui est défini en 4 pour les réponses de l'API au front-end. Par exemple, ce fichier va contenir des objets représentant les données renvoyées lors d'une authentification, une liste représentant des prestataires bidons, etc.
  6. implémentation de l'API en écrivant des fonctions de traitement des requêtes qui vont récupérer des données dans le fichier mentionné en 5, plutôt que dans la BdD pas encore stabilisée. Les premières fonctions à écrire concernent la gestion des utilisateurs, puis celles de la carte, pour terminer avec les services et les statistiques.
  7. Implémentation du front-end. Là encore, la source de données est le fichier mentionné en 5.
  8. modification des fonctions de l'API traitant les requêtes pour aller chercher les données en BdD.

2.2°/ sujet type 2 - orienté manipulation de données

• L'organisation du travail pour ce type de sujet est globalement le même qu'avec le type 1, excepté qu'il y a des tâches supplémentaires, notamment liées à la récupération des données manipulées par l'application :
  1. création d'un cahier des charges détaillé, c.a.d. qui fixe le cadre du projet (objectif du site, type d'informations, ...) aussi bien du point de vue fonctionnel (quelles statistiques affichables, tris/filtres, ...) que les données manipulées (source initiale, pré-traitements, ...)
  2. récupération des données auprès des sources (par ex au format csv), puis écriture de scripts permettant des traiter ces données : nettoyage, agrégation, production d'images statiques, etc.
  3. création du modèle pour la BdD, puis une fois stabilisé des scripts de création de la BdD. Ce modèle doit inclure les tables nécessaire pour stocker les données mentionnées en 2, mais aussi celles qui contiennent des données de gestion de l'application, comme par exemple les informations utilisateur.
  4. importation des données du 2 dans la BdD, sous la forme de script (python, shell, ...)
  5. définition des requêtes possibles donc des routes de l'API en fonction des fonctionnalités de l'application. Cela signifie qu'il faut définir le type de requête HTTP, ainsi que le format de la route. Les premières routes à définir concernent la gestion des utilisateurs (inscription, login, modification profil, etc.), puis celles qui permettent de récupérer des données de façon paramétrée depuis la BdD.
  6. création du modèle de données pour la communication entre le front-end et l'API. Lors d'une requête vers une route, ces deux parties vont s'échanger des objets JSON. Il faut donc définir leur contenu. Par exemple, lorsque que l'utilisateur veut s'authentifier, le front-end doit envoyer une requête au serveur API. Cette requête est forcément accompagnée d'un objet JSON contenant au minimum un champ pour le login, et un pour le mot de passe. Il faut donc définir précisément la structure de cet objet : nom des champs, type des champs, optionnels ou non, etc. Ensuite, le serveur procède à l'authentification et va retourner un objet résultat au front-end. Il faut également définir la structure de cet objet. Ces définitions sont à écrire pour chacune des requêtes/routes possibles.
  7. création d'un fichier contenant des objets JSON faisant office de source de données pour l'API et le front-end (comme vu dans les cours de dev. Web). Ce fichier contient tout simplement des objets dont le format correspond à celui qui est défini en 6 pour les réponses de l'API au front-end. Par exemple, ce fichier va contenir des objets représentant les données renvoyées lors d'une authentification, des données comme celles récupérées en 2, etc.
  8. implémentation de l'API en écrivant des fonctions de traitement des requêtes qui vont récupérer des données dans le fichier mentionné en 7, plutôt que dans la BdD pas encore stabilisée. Les premières fonctions à écrire concernent la gestion des utilisateurs, puis celles de récupération paramétrée des données.
  9. Implémentation du front-end. Là encore, la source de données est le fichier mentionné en 7.
  10. modification des fonctions de l'API traitant les requêtes pour aller chercher les données en BdD.

2.3°/ Remarques

• Il n'est pas demandé au S3 que le front-end fasse réellement des requêtes à l'API. Ce sera plutôt abordé en S4. Cela dit, rien n'interdit d'en faire pour ceux qui auront investigué eux-mêmes le sujet et qui seront "en avance".
• C'est identique pour l'authentification des utilisateurs : un authentification bidon peut être mise en palce pour le S3 et une authentification à base de sessions et/ou jwt être ajoutée en S4.
• D'un point de vue temporel, il va de soi que certaines tâches vont évoluer en parallèle afin que tous les membres soient occupés.
• Par exemple, pendant que certains s'occupent de modéliser et créer les tables concernant les utilisateurs, d'autres peuvent commencer la modélisation des échanges entre API et front
• Quand ces tâches ont suffisamment avancé, il est possible de commencer en parallèle les tâches de développement du front et du back.
• Pour l'accès réel à l'API, la prévision est de la commencer après la toussaint et le cours qui présente comment interroger un API dans une application vuejs.

3°/ Référents

Pour simplifier la gestion des questions concernant la SAÉ, des référents enseignants ont été désignés pour chaque domaine technique abordé dans le projet.

• API : Joseph Azar,
• front-end : Stephane Domas,
• BdD : David Laiymani,
• extraction, analyse et visualisation des données : Hassan Noura
• gestion/suivi de projet : Fabrice Ambert,
• méthodes/algorithmes pour la création automatisée des emplacements prestataire, planning, trajet, ... : Karine Deschinkel,

Pour des questions relatives à l'organisation générale du projet (planning, délivrables, ...), posez vos questions de préférence par mail, en écrivant aux 5 premiers enseignants de la liste ci-dessus. On se chargera d'élaborer une réponse collective à votre demande.

5°/ Planning (en cours de rédaction donc susceptible de changer)

• jeudi 7 septembre 2022 : Réunion de présentation générale,
• jusqu'au vendredi 15 septembre : constitution des groupes, choix des contextes des sujets. 
• semaine du 18 ou du 25 septembre : chaque groupe présente (devant l'équipe d'enseignants chargés du suivi) son projet en décrivant le type de sujet choisi et son contexte. Par exemple, pour le sujet de type 1, cela implique de présenter le type de manifestation, les informations liées aux prestataires, les services, les statistiques, ... et pour le sujet de type 2, de présenter les types de données sources, le type de graphique qui peut être visualisé, ... c.a.d. tout ce qui est laissé libre de choix dans le cahier des charges. Les enseignants valideront le projet tel quel ou bien feront des ajustements pour augmenter/réduire la difficulté.
• toutes les semaines : suivi (en méthode agile) d'un certains nombre de projets (avec F. Ambert), sachant qu'un projet donné est évalué toutes les 2 semaines.
• fin du semestre 3, deuxième évaluation : délivrables décrits en partie 6.2 + soutenance.

6°/ Attendus (en cours de rédaction donc susceptible de changer)

6.1°/ Présentation du projet : vendredi 29 septembre.

Selon le type de sujet choisi, le contenu des transparents de la présentation vont différer un peu, mais la forme est identique : un oral de 5 minutes environ avec un seul orateur.

Pour le sujet de type 1, les points à aborder sont (au minimum) :

• 1 transparent sur le thème et les motivations pour choisir ce thème.
• 1 transparent sur le "cadre géographique" avec éventuellement une première ébauche visuelle de la carte.
• 1 transparent présentant les type de prestataire/activités, avec pour chacun quelque types de catégorie de contraintes logistiques.
• 1 transparent présentant les service fournis, avec pour chacun quelques exemple des données manipulées et/ou collectées.
• 1 transparent présentant les types de statistiques qui seront faites à partir des données collectées de quel(s) service(s), et éventuellement, une idée du visuel

Pour le sujet de type 2, les points à aborder sont (au minimum) :

• 1 transparent sur le thème et les motivations pour choisir ce thème.
• 1 transparent sur les sources de données envisagées, avec quel type de champ vont être récupérés, et quel volume de données
• 1 transparent pour décrire la page d'accueil, avec quel type de graphique dans le carrousel, et éventuellement, une maquette du visuel
• 1 ou 2 transparents pour décrire chacun des types de graphique qui peut être créé dynamiquement et affiché dans le navigateur. Ces transparents doivent décrire :
  • les objectifs/intérêt de ces graphiques,
  • quelles données doivent être extraites de la BdD pour les produire,
  • quels filtres permettent à l'utilisateur de paramétrer cette extraction,
  • quels traitement sont faits (sur le serveur ou la navigateur) après l'extraction pour analyser/modifier ces données avant affichage,
  • quelle est la forme visuelle du ou des graphiques crées à partir de ces données.

Ensuite, soit le jury validera directement votre projet, soit il fera (à priori plus tard lors des créneaux horaires dédiés aux SAÉ) des remarques sur ce qu'il faudrait ajouter/supprimer. Par exemple, si vous présentez un festival de musique avec une seule scène, cela ne cadre pas avec les fonctionnalités pour la carte interactive. On vous demandera donc de prévoir d'autres emplacements. A l'inverse, si vous prévoyez de faire des services ou produire des graphiques qui sont trop complexes à implémenter, on vous demandera de revoir vos ambitions à la baisse.

6.2°/ Attendus de fin de S3 : vendredi 12 janvier

6.2.1°/ Rendu numérique

Ci-dessous est listé le minimum demandé. Si vous êtes allé plus loin, c'est bien entendu une plus-value pour le résultat et l'évaluation.

ATTENTION ! La plupart des attendus sont communs aux deux types de sujets, mais d'autres sont spécifiques. Dans ce cas, cela est indiqué par un commentaire du type  [ seulement pour sujet X ].

 Base de données :

• Scripts SQL de création de la base, si vous avez créé la base ainsi. Sinon, rien est à fournir si vous utilisez sequelize pour créer les tables "quand il y a besoin"
• Jeux de données pour remplir les tables, soit sous la forme d'un script SQL, soit sous la forme de code JS appelé lorsque l'API est lancée. NB : au moins un utilisateur administrateur/organisateur doit exister, ainsi que 2-3 utilisateurs de type prestataire/enregistré.
• [ seulement pour sujet 2 ] :
  • un document texte décrivant :
    • les sources de données "brutes" récupérées,
    • les liens vers ces sources,
    • la façon de récupérer ces données (scripts ? manipulations utilisateur ? ...),
    • leur format,
    • les problèmes principaux de ces données (redondance ? formatage ? ...),
    • les types de traitement qui ont été appliqués pour les nettoyer.
  • si applicable, les scripts pour récupérer les données brutes,
  • les scripts permettant de nettoyer et évaluer la qualité des données.

API :

• Accès à la BdD fonctionnel,
• Pour toutes les routes triviales nécessaires au fonctionnement de votre application web, le code de traitement de ces routes doit être fonctionnel et interagir avec la BdD. Par triviale, on entend un traitement qui nécessite L'accès en lecture/création/modification de un ou plusieurs éléments dans une unique table (c.a.d. façon CRUD)
• 3-4 routes non triviales doivent également être fonctionnelles. Par non triviale, on entend un traitement qui nécessite de récupérer/mettre à jour des informations en BdD qui sont réparties dans plusieurs tables.

Swagger [ seulement pour sujet 1 ] :

• Une dizaine de routes triviales, ainsi que les 3-4 routes non triviales doivent être documentées et testables via swagger

Front-end vuejs :

• Le visuel peut utiliser du HTML basique du moment que l'application est fonctionnelle. Il n'y a donc aucune contrainte sur le fait d'utiliser vuetify, ou du CSS pour améliorer le visuel (NB : cela sera cependant demandé en S4)
• La source de données peut être locale (comme vu en TP). Il n'y a donc aucune obligation d'interroger réellement l'API.
• Les principes de navigation générale dans l'application doivent être fonctionnel, notamment la possibilité de changer de rôle, ainsi que l'affichage de menus pour accéder aux fonctionnalités en fonction du rôle de l'utilisateur.
• L'authentification doit donc être fonctionnelle quand bien même ce n'est pas sécurisé et purement local. Par fonctionnelle, on entend le fait que l'application peut changer de "mode" selon le rôle de l'utilisateur authentifié.
• [ seulement pour sujet 1 ] : par rapport au cahier des charges complet, voici ce qui est demandé au minimum selon les rôles.
  • La partie accessible par le public doit afficher la carte interactive avec des informations qui apparaissent (localisation et mode laissé libre : encart, infobulle, dialogue, ...) quand on survole une zone associée à un prestataire. 
  • Au moins un prestataire doit exister et la carte interactive permet d'accéder à l'espace de ce prestataire (NB : en restant mode public).
  • Cet espace prestataire doit permettre d'accéder à 2 services publics "faciles" à implémenter (par ex, livre d'or, contact, ...) et un moyennement facile (par ex, réservation de séance). Ces services doivent être fonctionnels quand bien même les données saisies ne vont pas en BdD. Il faut donc prévoir des fonctions permettant d'ajouter des données à la source locale.
  • Quand un prestataire est logué, aucune fonctionnalité de gestion de ses informations ou de ses services (création/suppression) n'est demandé. En revanche, la partie prestataire des 2 services faciles et du service moyen doivent être fonctionnels. Par exemple, si le public peut signer un livre d'or, le prestataire doit pouvoir visualiser les commentaires. Si le public peut réserver une séance, le prestataire peut voir la liste des réservations. etc.
  • Quand un administrateur est logué, aucune fonctionnalité de gestion des informations de l'événement ou bien des prestataires n'est demandé. Seul les menus doivent changer pour permettre d'accéder à ces fonctionnalités.
• [ seulement pour sujet 2 ] : 
  • La partie accessible par le public doit afficher au minimum le carrousel.
  • Les fonctionnalités attendues pour les rôles "utilisateur authentifié" et "administrateur" sont décrites directement dans le sujet.
  • Fournir les scripts permettant de créer les images pour le carrousel de la page d'accueil.

6.2.2°/ Rendu oral

La forme est une soutenance entre 20 et 25 minutes, démonstration comprise, avec comme points à aborder :

• présentation de l'application avec le cadre, les fonctionnalités générales, ... c.a.d. un résumé mis à jour de la soutenance de présentation initiale.
• [ seulement pour sujet 2 ] : un résumé rapide des sources de données qui ont été utilisées, les éventuels problèmes dans ces données et les traitements qui ont été appliqués pour les nettoyer, préparer avant mise en BdD.
• 3 scénarios d'utilisation de l'application, avec comme acteur une personne du public, un prestataire/utilisateur enregistré et un administrateur. Ces scénarios doivent être illustrés par différents documents graphiques tels que des storyboards, des diagrammes de séquence, des maquettes d'interface etc. 
• démonstration
  • [ seulement pour sujet 1 ] : doit présenter les fonctionnalités liées à un utilisateur public et prestataire, en s'appuyant sur les scénarios.
  • [ seulement pour sujet 2 ] : doit présenter les fonctionnalités liées à un utilisateur enregistré ainsi que la partie gestion utilisateur de l'administrateur, en s'appuyant sur les scénarios.
• bilan d'avancement du projet avec comme support un burn-up chart, et bilan fonctionnel que ce qui est implémenté (avec %) et ce qui reste à faire.
• commentaire sur des faits marquants lors de la conception de la BdD, illustrant par exemple la difficulté de modéliser sans avoir défini précisément et/ou correctement les scénarios d'utilisations.
• un plan pour la prochaine version, avec pour chaque "sprint" les fonctionnalités principales à intégrer.