3.01-QCM_MuscuMaths (Maths'Educ)

LogicSys Digital

Application de QCM maths pour la nouvelle matière de 1ère année Maths Muscu

Convention de nommage des commits :

build : changements qui affectent le système de build ou des dépendances externes (npm, make…)
ci : changements concernant les fichiers et scripts d'intégration ou de configuration (Travis, Ansible, BrowserStack…)
feat : ajout d'une nouvelle fonctionnalité
fix : correction d'un bug
perf : amélioration des performances
refactor : modification qui n'apporte ni nouvelle fonctionalité ni d'amélioration de performances (Lisibilité du code ou principe SOLID par exemple)
style : changement qui n'apporte aucune altération fonctionnelle ou sémantique (indentation, mise en forme, ajout d'espace, renommage d'une variable…)
docs : rédaction ou mise à jour de la documentation
test : ajout ou modification de tests

Exemple :
feat : ajout de la possibilité de se connecter
perf : optimisation de requête SQL
...Etc...

Buts et Objectifs du Projet

Le projet Maths'Educ vise à fournir une plateforme d'évaluation basée sur des questions à choix multiples pour la nouvelle matière de 1ère année intitulée "Maths Muscu". L'objectif principal est de créer un outil interactif qui permettra aux étudiants de tester leurs connaissances et de renforcer leur compréhension des concepts mathématiques.

Les principaux objectifs incluent :

• Développer une interface conviviale pour les QCM en mathématiques.
• Intégrer des fonctionnalités de suivi des progrès pour que les étudiants puissent mesurer leur compréhension au fil du temps.
• Assurer la compatibilité avec différents dispositifs et navigateurs pour une accessibilité optimale.

Le backoffice

Une partie administrateur est disponible pour gérer l'ajout/la suppression des questions, des chapitres, des administrateurs et des joueurs. Un export/import des questions au format csv est disponible. Nous avons créé un composant complexe pour afficher les détails des questions.

Le blazor, utilisant une api, un fichier de configuration API.cs est nécessaire (n'hésitez à nous le demander).

Les Parties Prenantes et leurs Rôles

1. GUITARD Maxence - Développeur polyvalent

   • Spécialisé dans la partie des utilisateurs (connexion, stockage des scores,ect..).
   • Développeur JavaScript pour la gestion du chronomètre dans les QCM.

2. VAN BRABRANDT Jade - Développeuse Front-End

   • Responsable de la partie jeux, incluant les questions, réponses, et le contrôle des données de formulaire.
   • Spécialisée dans la vérification des failles de sécurité dans les formulaires pour assurer une protection adéquate.

3. DUCOURTHIAL Jérémy - Développeur Back-End

   • En charge du développement côté serveur, particulièrement sur la gestion de la base de données.
   • Spécialisé dans l'architecture MVC (Modèle-Vue-Contrôleur) en PHP pour assurer une structure logique et organisée côté serveur.

4. CALATAYUD Yvan - Développeur Front-End

   • Concentré sur la partie Front-End avec une expertise particulière en Bootstrap et Twig.
   • Impliqué dans l'optimisation de l'interface utilisateur pour une expérience utilisateur (UX) fluide.

5. NORTIER Damien - Rédacteur de Questions en Base de Données

   • Responsable de la rédaction et de la création des questionnaires de maths pour alimenter la base de données.
   • Collaborateur actif dans l'élaboration des contenus mathématiques pertinents pour les QCM.

Chaque membre de l'équipe possède des compétences en développement Front-end et Back-end, mais chacun s'est spécialisé dans des domaines particuliers du projet pour assurer une collaboration efficace et une réalisation réussie de Maths'Educ.

Ce projet suivra les conventions de nommage des commits mentionnées précédemment pour assurer une gestion efficace du développement et de la maintenance.

Nécessite un fichier Config_DB.php pour fonctionner, n'hésitez pas à nous le demander.

API ASP.NET

Comme dit, cette partie est sur cette branche. La solution et les projets se situent dans le dossier WebApi. J'ai été trop ambitieux, je pensais aller plus rapidement en codant toute l'application d'abord puis en testant. J'ai donc codé tout le projet, cependant, je n'ai eu le temps de tester que les managers d'une answer. Ce manque de temps est notamment dû à des erreurs incomprisent et à une mauvaise injection de dépendance.

voici comment s'organise le projet :

@startuml
   hide circle
   allowmixing
   skinparam classAttributeIconSize 0
   skinparam classBackgroundColor #ffffb9
   skinparam classBorderColor #800000
   skinparam classArrowColor #800000
   skinparam classFontColor #black
   skinparam classFontName Tahoma

   title XXX est à remplacer par le nom de la classe

   file API
   package WebAPI{
      package Controllers{
         class XXXController
         class FrontController
      }
   }

   API .> FrontController
   FrontController -> XXXController
   XXXController -> Unit

   note top of Unit
      dans le package WebAPI (c'est
      juste que si je le met dedans,
      le diagramme est mal ordonné)
   end note
   
   package ManagerInterfaces{
      class IXXXManager<T>
   }

   package ServiceManagers{
      class XXXServiceManager
   }

   package DTOs{
      class XXXDto
   }

   IXXXManager <-- XXXServiceManager : T <- XXXDto
   Unit -> XXXServiceManager
   XXXServiceManager -.> XXXDto

   package DataManagers{
      class XXXDataManager
   }

   package Model{
      class XXX
   }

   IXXXManager <-- XXXDataManager : T <- XXX
   XXXServiceManager -> XXXDataManager
   XXXDataManager -.> XXX

   package EntityManagers{
      class XXXEntityManager
   }

   package Entities{
      class XXXEntity
   }

   package OrderCriterias{
      class XXXOrderCriteria
   }

   IXXXManager -> XXXOrderCriteria

   note right of XXXOrderCriteria
      bien sûr, cette classe n'est
      pas utilisée par l'interface
      mais par ces filles. Mais
      pour une raison de lisibilité,
      la flèche part volontairement
      de l'interface.
   end note

   IXXXManager <-- XXXEntityManager : T <- XXXEntity
   XXXDataManager -> XXXEntityManager
   XXXEntityManager -.> XXXEntity

   artifact DbContext

   Class MyDbContext{
   --
      + Ctr
      + Ctr(options : DbContextOptions<MyDbContext>)
      + {override} OnConfiguring(options : DbContextOptionsBuilder)
   }

   database database

   DbContext <|-- MyDbContext
   XXXEntityManager -> MyDbContext
   MyDbContext --> Entities : DbSet pour chaque entité
   MyDbContext -> database

   package ExtensionsClassLibrairie{
      class XXXExtensionMethods
   }

   XXXDto <-- XXXExtensionMethods
   XXX <-- XXXExtensionMethods
   XXXEntity <-- XXXExtensionMethods

   package StubbedDbContextLibrary{
      class StubbedDbContext
   }

   MyDbContext <|---- StubbedDbContext
   
   package FakeDatas{
      class fakeXXX{
         + {static} datas
      }
   }

   note right of fakeXXX
      Bon, là, je me suis
      trompé sur le nom
      (sachant que les
      fichiers s'appellent
      fake-XXXs)
   end note

   StubbedDbContext -> FakeDatas
@enduml

je n'est pas mis les tests car si je les mettaient, le diagramme devenait illisible mais voici le détaille de ces derniers : - Chaque test utilise les classes "MyDbContext" (pour tester l'ajout) et "StubbedDbContext" (pour le reste). - Le test "TestDataManagers" teste la bonne transcription des data managers, - Le test "TestEntityManagers" teste le bon "requêtage" des entity managers, - Le test "TestServiceManagers" teste la bonne transcription des service managers. - Chaque test est divisé en plusieurs fonctions : - une fonction TestXXX pour tester le manager de la classe XXX (appel les autres fonctions) - une fonction TestFXXX pour tester chaque méthode 'F' du manager de la classe XXX - une fonction Test appelant les fonctions TestXXX - le programme construit un StubbedDbContext puis appel la méthode 'Test'

concernant la documentation

  - toutes les classes sont documentées
  - les managers ne sont pas documentés (j'ai décidé de documenté juste les interfaces car les documentations des managers auraient été similaires).
  - les tests sont moins documentés que le reste

la classe Unit

La classe Unit n'est pas un Unit Of Work. Elle sert simplement à rassembler toutes les méthodes en une seule classe afin que les Controllers puissent accéder aux méthodes permettant la vérification des dépendances. Par exemple, à la création d'une question, le Contrôleur des questions doit pouvoir accéder à la méthode permettant d'obtenir un chapitre

les contrôleurs

J'ai décidé de créer plusieurs contrôleurs : un contrôleur pour chaque classe et un FrontController

Pourquoi un FrontController ?

Pour plus de lisibilité, j'ai pensé qu'il était préférable de séparé la déclaration d'une route de sa documentation (les [HttpGet(...)], [ProduceResponseType(...)], ...). Cependant, afin de ne pas faire trop de fichiers, je n'ai pas voulu faire un contrôleur par classe

par GUITARD Maxence, VAN BRABRANDT Jade, DUCOURTHIAL Jérémy, CALATAYUD Yvan, NORTIER Damien