Documentation de Conception - Cas d’utilisation "Créer un questionnaire"

Table of Contents

1. Introduction

1.1. Objectif du document

Ce document présente la conception détaillée du cas d’utilisation "Créer un questionnaire" du système QuizMaker. Il constitue une spécification complète des aspects comportementaux et structurels de cette fonctionnalité centrale.

1.2. Public visé

Ce document s’adresse aux différentes parties prenantes du projet :

  • Architectes logiciels : pour comprendre la structure globale du système

  • Développeurs : pour implémenter les composants conformément à la conception

  • Testeurs : pour élaborer les scénarios de test

  • Chefs de projet : pour suivre l’avancement et la conformité

  • Mainteneurs : pour assurer l’évolution du système

1.3. Portée

Ce document couvre exclusivement la fonctionnalité FR-1 "Créer un questionnaire" incluant :

  • L’analyse comportementale complète

  • Le modèle du domaine et les contraintes métier

  • L’architecture logicielle et technique

  • Les interactions entre composants

1.4. Références

Document Description

SRS-QuizMaker-v1.0

Spécification des exigences système

UC-1

Cas d’utilisation "Préparation d’un questionnaire"

NF-Req-3

Exigence non fonctionnelle sur le format Asciidoc

NF-Req-4

Exigence non fonctionnelle sur l’utilisation de PlantUML

2. Vue d’ensemble du cas d’utilisation

2.1. Description fonctionnelle

Élément Description

Identifiant

FR-1 / UC-1

Nom

Créer un questionnaire

Priorité

Haute

Acteur principal

Enseignant

Objectif

Permettre à un enseignant de créer un questionnaire composé de questions à choix multiple pour évaluer ses étudiants

Fréquence

Hebdomadaire

Version

1.0.0

2.2. Conditions

2.2.1. Pré-conditions

  • L’enseignant est connecté au système QuizMaker

  • L’enseignant dispose d’un compte valide sur le serveur

  • L’enseignant a une connexion Internet active

  • L’enseignant connaît le thème de son questionnaire et les questions à inclure

2.2.2. Post-conditions en cas de succès

  • Un nouveau questionnaire existe dans le système

  • Le questionnaire contient au moins une question validée

  • Chaque question possède au moins une réponse correcte

  • Le questionnaire est associé à un module d’enseignement

  • Le questionnaire est prêt à être utilisé dans une épreuve

2.2.3. Post-conditions en cas d’échec

  • Aucun questionnaire n’est créé

  • Les données partielles ne sont pas persistées

  • L’enseignant est informé de la raison de l’échec

  • Le système reste dans un état cohérent

2.3. Scénarios

2.3.1. Scénario nominal

Étape Action

1

L’enseignant se connecte au système QuizMaker

2

L’enseignant crée un nouveau module d’enseignement

3

L’enseignant ajoute des étudiants au module

4

L’enseignant crée un questionnaire et lui attribue un nom

5

L’enseignant ajoute des questions à choix multiple au questionnaire

6

L’enseignant ferme et valide le questionnaire

2.3.2. Scénario alternatif

Étape Action

1

L’enseignant se connecte au système QuizMaker

2

L’enseignant ouvre un module d’enseignement existant

3

L’enseignant crée un questionnaire dans ce module

4

L’enseignant ajoute des questions au questionnaire

5

L’enseignant ferme et valide le questionnaire

2.3.3. Scénarios d’exception

Exception 1 : Question sans réponse correcte

  • Le système détecte qu’une question n’a aucune réponse correcte

  • Le système affiche un message d’erreur explicite

  • La question est rejetée et n’est pas ajoutée au questionnaire

  • L’enseignant corrige la question

Exception 2 : Questionnaire vide

  • L’enseignant tente de fermer un questionnaire sans question

  • Le système affiche un message d’erreur

  • Le questionnaire n’est pas validé

  • L’enseignant doit ajouter au moins une question

Exception 3 : Perte de connexion

  • La connexion réseau est interrompue pendant la création

  • Le système sauvegarde automatiquement l’état actuel (si possible)

  • Un message informe l’enseignant de la perte de connexion

  • À la reconnexion, l’enseignant peut reprendre son travail

3. Modélisation comportementale

Cette section présente les différents diagrammes comportementaux qui décrivent les interactions, les flux d’activités et les états du système lors de la création d’un questionnaire.

3.1. Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation présente une vue d’ensemble des fonctionnalités du système QuizMaker et de leurs relations avec les acteurs.

cas-utilisation
Diagramme de cas d’utilisation - Vue d’ensemble

Ce diagramme illustre :

  • Les deux acteurs principaux : Enseignant et Étudiant

  • Le cas d’utilisation central "Créer un questionnaire" (UC-1)

  • Les dépendances avec les cas d’utilisation subordonnés

  • Les relations d’inclusion (include) et d’extension (extend)

3.1.1. Analyse des relations

Relations d’inclusion ([include])

Le cas "Créer un questionnaire" inclut obligatoirement :

  • Créer un module d’enseignement

  • Ajouter des étudiants à un module

  • Ajouter des questions au questionnaire

  • Valider le questionnaire

Relations d’extension ([extend])

Le cas "Créer une question" peut étendre vers :

  • Gérer la banque de questions (optionnel)

Relations de précédence ([precedes])

  • Se connecter au serveur doit précéder toute autre action

  • Créer un module doit précéder l’ajout d’étudiants

3.2. Diagramme de séquence - Scénario nominal

Le diagramme de séquence illustre les interactions temporelles entre l’enseignant et le système lors du scénario nominal de création d’un questionnaire.

sequence-nominal
Diagramme de séquence - Scénario nominal

Points clés du scénario :

  • La connexion initiale authentifie l’enseignant

  • La création du module précède l’ajout des étudiants

  • Chaque question ajoutée est validée individuellement

  • La validation vérifie la présence d’au moins une réponse correcte

  • La fermeture du questionnaire déclenche une validation globale

3.2.1. Description des phases

Phase 1 : Connexion

L’enseignant s’authentifie auprès du système avec ses identifiants. Le système vérifie les credentials et retourne une confirmation.

Phase 2 : Préparation du contexte

L’enseignant crée un module d’enseignement qui servira de conteneur pour le questionnaire, puis y ajoute les étudiants concernés.

Phase 3 : Création du questionnaire

L’enseignant initialise un nouveau questionnaire en lui donnant un nom descriptif.

Phase 4 : Ajout des questions

Cette phase itérative permet d’ajouter plusieurs questions. Chaque question subit une validation pour s’assurer qu’elle contient au moins une réponse correcte.

Phase 5 : Finalisation

L’enseignant ferme le questionnaire. Le système effectue une validation finale vérifiant qu’au moins une question a été ajoutée.

3.3. Diagramme de séquence - Scénario alternatif

Ce diagramme présente le flux alternatif où l’enseignant utilise un module d’enseignement déjà existant.

sequence-alternatif
Diagramme de séquence - Scénario alternatif

Avantage de ce scénario :

Ce scénario est plus rapide car il évite la création d’un module et l’ajout manuel des étudiants. Il est particulièrement utile pour :

  • Créer plusieurs questionnaires pour un même module

  • Évaluer le même groupe d’étudiants sur différents sujets

  • Réutiliser la structure organisationnelle existante

3.3.1. Différences avec le scénario nominal

Aspect Scénario nominal Scénario alternatif

Création du module

Nouveau module créé

Module existant sélectionné

Ajout d’étudiants

Ajout manuel obligatoire

Étudiants déjà présents

Temps d’exécution

Plus long

Plus rapide

Cas d’usage

Premier questionnaire du module

Questionnaires suivants

3.4. Diagramme d’activité

Le diagramme d’activité détaille la logique complète du processus de création d’un questionnaire, incluant toutes les décisions et boucles.

activite
Diagramme d’activité - Logique détaillée avec conditions

Éléments notables :

  • Points de décision : Module existe ? / Ajouter une autre réponse ? / Au moins une réponse correcte ? / Ajouter une autre question ? / Le questionnaire contient au moins une question ?

  • Boucles : Ajout de réponses et ajout de questions

  • Gestion d’erreurs : Validation des réponses correctes et du nombre de questions

  • Partitionnement : Séparation claire entre actions de l’Enseignant et du Système

3.4.1. Flux de décision

Décision 1 : Existence du module

SI module existe ALORS
    Ouvrir le module existant
SINON
    Créer un nouveau module
    Ajouter des étudiants au module
FIN SI

Décision 2 : Validation de la question

SI au moins une réponse correcte ALORS
    Ajouter la question au questionnaire
SINON
    Afficher erreur
    Rejeter la question
FIN SI

Décision 3 : Validation du questionnaire

SI le questionnaire contient au moins une question ALORS
    Valider et enregistrer le questionnaire
    Afficher confirmation
SINON
    Afficher erreur
    Retour à l'ajout de questions
FIN SI

3.4.2. Points de contrôle qualité

Le diagramme met en évidence trois points de contrôle essentiels :

  1. Contrôle au niveau des choix : Vérification qu’au moins deux choix sont proposés

  2. Contrôle au niveau de la question : Vérification qu’au moins un choix est correct

  3. Contrôle au niveau du questionnaire : Vérification qu’au moins une question est présente

3.5. Diagramme d’états - Question

Ce diagramme modélise le cycle de vie complet d’une question, de sa création à son archivage ou suppression.

etats-question
Diagramme d’états - Cycle de vie d’une Question

États critiques :

  • Invalide : Une question sans réponse correcte ne peut pas être utilisée

  • Utilisée : Une question en cours d’utilisation dans une épreuve ne peut plus être modifiée

  • Historique : Conservation pour traçabilité et statistiques

3.5.1. Description des états

État EnCréation

État composite où la question est en cours d’élaboration :

  • SaisieTexte : L’enseignant saisit l’énoncé

  • AjoutChoix : L’enseignant ajoute les options de réponse

  • Validation : Vérification des contraintes métier

État Invalide

État temporaire lorsqu’une question ne respecte pas les contraintes :

  • Aucune réponse correcte définie

  • Moins de deux choix proposés

  • Transition vers EnCréation pour correction

État Validée

État composite pour une question prête à l’emploi :

  • Disponible : Question validée disponible pour utilisation

  • EnModification : Modification d’une question existante

État AjoutéeAuQuestionnaire

État composite une fois la question intégrée :

  • DansQuestionnaire : Question liée à un questionnaire

  • Archivée : Le questionnaire parent est archivé

  • Utilisée : La question est utilisée dans une épreuve active

États finaux

  • Historique : Conservation après utilisation

  • Supprimée : Retrait définitif du système

3.5.2. Transitions et événements

Transition Événement déclencheur Condition de garde

EnCréation → Invalide

valider()

[aucune réponse correcte]

Invalide → EnCréation

corriger()

-

EnCréation → Validée

valider()

[au moins une réponse correcte ET au moins 2 choix]

Validée → AjoutéeAuQuestionnaire

ajouterAuQuestionnaire()

-

DansQuestionnaire → Utilisée

questionnaireUtiliséDansÉpreuve()

-

Utilisée → Historique

épreuveTerminée()

-

3.5.3. Invariants d’état

context Question
inv ValideImpliqueBonneStructure:
    self.etat = 'Validée' implies
        (self.choix->size() >= 2 and
         self.choix->exists(c | c.estCorrect = true))

inv UtiliséeImpliquePasDeModification:
    self.etat = 'Utilisée' implies
        self.estModifiable = false

3.6. Diagramme d’états - Questionnaire

Ce diagramme représente les différents états par lesquels passe un questionnaire durant son existence.

etats-questionnaire
Diagramme d’états - Cycle de vie d’un Questionnaire

Règles de modification :

Un questionnaire ne peut être modifié que dans les états suivants :

  • EnCréation (état Vide ou AvecQuestions)

  • Complet (état Prêt ou EnModification)

Un questionnaire en cours d’utilisation (état EnCours) est verrouillé et toute modification est interdite pour garantir l’intégrité des épreuves en cours.

3.6.1. Description des états

État EnCréation

État composite initial :

  • Vide : Questionnaire créé sans aucune question

  • AvecQuestions : Au moins une question ajoutée

  • Transitions internes pour l’ajout/retrait de questions

État Incomplet

État d’erreur lorsqu’on tente de fermer un questionnaire vide :

  • Aucune question présente

  • Retour obligatoire à EnCréation pour correction

État Complet

État composite pour un questionnaire finalisé :

  • Prêt : Questionnaire finalisé, prêt à être utilisé

  • EnModification : Modifications apportées avant utilisation

État AffectéÀÉpreuve

État composite lorsque le questionnaire est associé à une épreuve :

  • EnAttente : Épreuve programmée mais non démarrée

  • EnCours : Épreuve active avec étudiants en train de répondre

  • Terminé : Épreuve terminée

État EnCours - Détails

État imbriqué critique :

  • Entry action : Blocage des modifications

  • Do activity : Les étudiants répondent aux questions

  • Exit action : Déblocage pour archivage

États finaux

  • Archivé : Conservation pour historique et statistiques

  • Supprimé : Retrait définitif (uniquement si jamais utilisé)

3.6.2. Machine à états détaillée

État source Événement État cible Garde/Action

Vide

ajouterQuestion()

AvecQuestions

[première question] / compteur++

AvecQuestions

ajouterQuestion()

AvecQuestions

/ compteur++

AvecQuestions

retirerQuestion()

AvecQuestions

[compteur > 1] / compteur--

AvecQuestions

retirerQuestion()

Vide

[compteur == 1] / compteur--

EnCréation

fermer()

Incomplet

[compteur == 0]

EnCréation

fermer()

Complet

[compteur >= 1] / valider()

Prêt

modifier()

EnModification

/ déverrouiller()

EnModification

enregistrer()

Prêt

/ verrouiller()

Complet

créerÉpreuve()

AffectéÀÉpreuve

/ associerÉpreuve()

EnAttente

démarrerÉpreuve()

EnCours

/ bloquerModifications()

EnCours

terminerÉpreuve()

Terminé

/ calculerNotes()

3.6.3. Contraintes sur les transitions

context Questionnaire
inv ComplètementImpliquePasVide:
    self.etat = 'Complet' implies
        self.questions->size() >= 1

inv EnCoursImpliqueBlocage:
    self.etat = 'EnCours' implies
        self.estModifiable = false and
        self.epreuve.estActive = true

inv SuppressionConditionnelle:
    self.etat = 'Supprimé' implies
        self.epreuves->isEmpty()

3.7. Diagramme de communication

Le diagramme de communication illustre l’organisation structurelle des objets et leurs interactions lors de la création d’un questionnaire.

communication
Diagramme de communication - Interactions entre objets

Numérotation des messages :

La notation utilisée (1, 1.1, 1.2, 2, 2.1, etc.) représente :

  • Premier niveau (1, 2, 3…​) : Ordre chronologique des actions principales

  • Deuxième niveau (1.1, 1.2…​) : Appels imbriqués déclenchés par l’action principale

  • Troisième niveau (1.1.1, 1.1.2…​) : Appels encore plus profonds

3.7.1. Analyse des interactions

Séquence 1 : Initialisation du questionnaire

1: créerQuestionnaire(nom)
  1.1: new(nom) [création de l'instance Questionnaire]
  1.2: associerQuestionnaire(questionnaire) [liaison au module]

Séquence 2-4 : Construction d’une question

2: créerQuestion(texte, points)
  2.1: new(texte, points) [création de l'instance Question]

3: ajouterChoix(question, texte, estCorrect)
  3.1: ajouterChoix(texte, estCorrect)
    3.1.1: new(texte, estCorrect) [création du premier Choix]

4: ajouterChoix(question, texte, estCorrect)
  4.1: ajouterChoix(texte, estCorrect)
    4.1.1: new(texte, estCorrect) [création du second Choix]

Séquence 5-6 : Validation et intégration

5: validerQuestion(question)
  5.1: valider()
    5.1.1: vérifierRéponsesCorrectes() [auto-vérification]

6: ajouterQuestionAuQuestionnaire(questionnaire, question)
  6.1: ajouterQuestion(question)
  6.2: sauvegarderQuestion(question) [dans la banque]

Séquence 8 : Finalisation

8: fermerQuestionnaire(questionnaire)
  8.1: valider()
    8.1.1: vérifierNombreQuestions()
  8.2: fermer()

3.7.2. Responsabilités des objets

Objet Responsabilités

:ControleurQuestionnaire

Coordination des opérations, orchestration du flux, gestion des appels

:Questionnaire

Gestion de la collection de questions, validation de sa complétude

:Question

Auto-validation, gestion de ses choix

:Choix

Stockage du texte et de l’état (correct/incorrect)

:BanqueQuestions

Persistance et indexation des questions

:ModuleEnseignement

Association du questionnaire au contexte pédagogique

3.7.3. Patterns de conception identifiés

Pattern Contrôleur (Controller)

Le :ControleurQuestionnaire agit comme façade pour toutes les opérations, centralisant la logique de coordination.

Pattern Composite

Questionnaire contient des Question qui contiennent des Choix, formant une hiérarchie d’agrégation.

Pattern Repository

BanqueQuestions encapsule la logique de persistance et de récupération des questions.

4. Modélisation structurelle

Cette section présente les diagrammes structurels qui décrivent l’organisation statique du système, son architecture et son infrastructure.

4.1. Diagramme de classes - Modèle du domaine

Le diagramme de classes présente le modèle conceptuel du domaine avec toutes les entités, leurs attributs, leurs opérations et leurs relations.

classes
Diagramme de classes - Modèle du domaine avec contraintes OCL

Éléments clés du modèle :

  • Classes métier : 10 classes représentant les concepts fondamentaux

  • Relations : Associations, compositions et agrégations

  • Cardinalités : Contraintes sur les multiplicités

  • Contraintes OCL : 4 contraintes d’intégrité formelles

4.1.1. Description des classes principales

Classe Enseignant

Élément Description

Responsabilité

Créer et gérer les questionnaires et modules

Attributs

nom, prenom, email, identifiant

Opérations

créerQuestionnaire(), créerModule(), ajouterÉtudiants()

Relations

Crée des ModuleEnseignement (1..), Élabore des Questionnaire (1..)

Classe Étudiant

Élément Description

Responsabilité

Participer aux épreuves et répondre aux questions

Attributs

nom, prenom, email, matricule

Opérations

participerÀÉpreuve(), répondreQuestion()

Relations

Inscrit dans ModuleEnseignement (0..), Possède des Copie (0..)

Classe ModuleEnseignement

Élément Description

Responsabilité

Organiser l’enseignement et regrouper étudiants et épreuves

Attributs

id, nom, description, dateCreation

Opérations

ajouterÉtudiant(), retirerÉtudiant()

Relations

Organise des Épreuve (1..), Inscrit des Étudiant (0..)

Classe Questionnaire

Élément Description

Responsabilité

Contenir et organiser les questions, assurer la validité

Attributs

id, nom, description, dateCreation, estFermé

Opérations

ajouterQuestion(), retirerQuestion(), valider(), fermer()

Relations

Contient des Question (1..), Utilisé dans des Épreuve (0..)

La cardinalité 1..* pour la relation Questionnaire-Question garantit qu’un questionnaire doit toujours contenir au moins une question (contrainte métier).

Classe Question

Élément Description

Responsabilité

Représenter une question avec ses choix possibles

Attributs

id, texte, points, ordre

Opérations

ajouterChoix(), validerRéponses()

Relations

Propose des Choix (2..*), Appartient à un Questionnaire (1)

Classe Choix

Élément Description

Responsabilité

Représenter une option de réponse

Attributs

id, texte, estCorrect, ordre

Opérations

aucune (classe de données)

Relations

Appartient à une Question (1), Sélectionné dans des Réponse (0..*)

Classe BanqueQuestions

Élément Description

Responsabilité

Stocker et indexer les questions réutilisables

Attributs

id, nom

Opérations

ajouterQuestion(), rechercherQuestion(), supprimerQuestion()

Relations

Utilisée par des Questionnaire (0..*), Gérée par Enseignant (1)

Classe Épreuve

Élément Description

Responsabilité

Organiser une session d’évaluation

Attributs

id, dateDebut, dateFin, duree, estActive

Opérations

démarrer(), terminer()

Relations

Utilise un Questionnaire (1), Génère des Copie (0..*)

Classe Copie

Élément Description

Responsabilité

Représenter les réponses d’un étudiant

Attributs

id, dateRemise, note, estCorrigée

Opérations

calculerNote()

Relations

Contient des Réponse (1..*), Correspond à un Questionnaire (1)

Classe Réponse

Élément Description

Responsabilité

Représenter la sélection de choix par l’étudiant

Attributs

dateSelection

Opérations

estCorrecte()

Relations

Sélectionne des Choix (1..*), Répond à une Question (1)

4.1.2. Relations et cardinalités

Relations de composition (losange noir plein)

Ces relations indiquent que les objets composés n’ont pas de sens sans leur conteneur :

Questionnaire ◆---> Question
    "Un questionnaire est détruit, ses questions le sont aussi"

Question ◆---> Choix
    "Une question est détruite, ses choix le sont aussi"

Copie ◆---> Réponse
    "Une copie est détruite, ses réponses le sont aussi"

Relations d’association

Association Cardinalité Signification

Enseignant - ModuleEnseignement

1 - 0..*

Un enseignant crée plusieurs modules

Enseignant - Questionnaire

1 - 0..*

Un enseignant élabore plusieurs questionnaires

ModuleEnseignement - Étudiant

0..* - 0..*

Relation plusieurs-à-plusieurs

Questionnaire - Épreuve

1 - 0..*

Un questionnaire peut être réutilisé

Épreuve - Copie

1 - 0..*

Une épreuve génère une copie par étudiant

Copie - Étudiant

0..* - 1

Chaque copie appartient à un étudiant

4.1.3. Contraintes OCL

Contrainte 1 : Question doit avoir au moins une réponse correcte

context Question
inv AuMoinsUneRéponseCorrecte:
    self.choix->exists(c | c.estCorrect = true)

Justification métier : Une question sans réponse correcte ne peut pas être évaluée. Cette contrainte garantit que chaque question peut être notée correctement.

Contrainte 2 : Question doit avoir au moins deux choix

context Question
inv AuMoinsDeuxChoix:
    self.choix->size() >= 2

Justification métier : Un QCM nécessite plusieurs options pour être significatif. Un seul choix transformerait la question en vrai/faux, ce qui n’est pas l’objectif du système.

Contrainte 3 : Questionnaire doit contenir au moins une question

context Questionnaire
inv AuMoinsUneQuestion:
    self.questions->size() >= 1

Justification métier : Un questionnaire vide n’a aucune utilité pédagogique. Cette contrainte est vérifiée lors de la fermeture du questionnaire.

Contrainte 4 : Cohérence entre Copie et Questionnaire

context Copie
inv CohérenceRéponsesQuestionnaire:
    self.reponses.choix->forAll(c |
        self.questionnaire.questions.choix->includes(c))

Justification métier : Cette contrainte fondamentale assure que tous les choix sélectionnés dans une copie correspondent effectivement aux choix proposés dans le questionnaire. Elle évite toute incohérence de données.

4.1.4. Règles métier supplémentaires

Au-delà des contraintes OCL, d’autres règles métier importantes s’appliquent :

Règle 1 : Immuabilité pendant une épreuve

Un questionnaire utilisé dans une épreuve active ne peut être modifié pour garantir l’équité entre tous les participants.

Règle 2 : Unicité des identifiants

Tous les identifiants (id) doivent être uniques au sein de leur classe respective pour assurer l’intégrité référentielle.

Règle 3 : Calcul de la note

La note d’une copie est calculée automatiquement en fonction du nombre de bonnes réponses et du barème défini pour chaque question.

Règle 4 : Ordre des questions et choix

L’attribut ordre permet de définir la séquence de présentation, garantissant une expérience cohérente pour tous les étudiants.

4.2. Diagramme de composants

Le diagramme de composants illustre l’architecture logicielle du système QuizMaker en montrant les différents composants et leurs dépendances.

composants
Diagramme de composants - Architecture logicielle

Architecture en couches :

Le système adopte une architecture en trois couches :

  1. Couche Présentation : Interface avec les clients et gestion des requêtes

  2. Couche Métier : Logique applicative et règles de gestion

  3. Couche Données : Persistance et accès aux données

4.2.1. Description des composants

Couche Client

Composant Description

Interface Utilisateur Enseignant

Interface graphique pour les enseignants permettant la création et la gestion des questionnaires

Gestionnaire de Questionnaire

Composant client gérant l’état local et les interactions avec le questionnaire

Éditeur de Question

Composant spécialisé pour la création et l’édition de questions

Couche Présentation (Serveur)

Composant Description

API REST

Point d’entrée unique exposant les endpoints HTTP/REST, gère le routage des requêtes

Contrôleur Authentification

Gère l’authentification et l’autorisation des utilisateurs

Contrôleur Questionnaire

Orchestre les opérations liées aux questionnaires

Couche Métier

Composant Description

Service Gestion Questionnaire

Logique métier pour la création, modification et suppression de questionnaires

Service Gestion Question

Logique métier pour la gestion des questions

Service Gestion Module

Logique métier pour la gestion des modules d’enseignement

Service Validation

Composant central de validation des contraintes métier (OCL)

Service Banque Questions

Gestion du référentiel de questions réutilisables

Couche Données

Composant Description

Repository Questionnaire

Abstraction de la persistance des questionnaires

Repository Question

Abstraction de la persistance des questions

Repository Module

Abstraction de la persistance des modules

Repository Utilisateur

Abstraction de la persistance des utilisateurs

BD QuizMaker

Base de données relationnelle (PostgreSQL/MySQL)

4.2.2. Dépendances entre composants

Dépendances Client → Serveur

Gestionnaire de Questionnaire ..> API REST : HTTP/REST
Éditeur de Question ..> API REST : HTTP/REST

Les composants clients communiquent avec le serveur via des appels REST utilisant le protocole HTTPS sur le port 443.

Dépendances Présentation → Métier

Contrôleur Questionnaire --> Service Gestion Questionnaire
Contrôleur Questionnaire --> Service Gestion Question
Contrôleur Questionnaire --> Service Gestion Module
Contrôleur Questionnaire --> Service Validation

Les contrôleurs délèguent la logique métier aux services appropriés.

Dépendances Métier → Métier

Service Gestion Questionnaire --> Service Banque Questions
Service Gestion Question --> Service Validation

Certains services métier dépendent d’autres services pour des fonctionnalités transverses.

Dépendances Métier → Données

Service Gestion Questionnaire --> Repository Questionnaire
Service Gestion Question --> Repository Question
Service Gestion Module --> Repository Module

Les services métier accèdent aux données via les repositories, respectant le pattern Repository.

Dépendances Données → Base

Repository Questionnaire --> BD QuizMaker : CRUD
Repository Question --> BD QuizMaker : CRUD
Repository Module --> BD QuizMaker : CRUD
Repository Utilisateur --> BD QuizMaker : CRUD

Tous les repositories effectuent des opérations CRUD sur la base de données.

4.2.3. Interfaces exposées

API REST - Endpoints pour les questionnaires

POST   /api/questionnaires              # Créer un questionnaire
GET    /api/questionnaires/{id}         # Récupérer un questionnaire
PUT    /api/questionnaires/{id}         # Modifier un questionnaire
DELETE /api/questionnaires/{id}         # Supprimer un questionnaire
POST   /api/questionnaires/{id}/questions # Ajouter une question
PUT    /api/questionnaires/{id}/close   # Fermer un questionnaire

API REST - Endpoints pour les questions

POST   /api/questions                   # Créer une question
GET    /api/questions/{id}              # Récupérer une question
PUT    /api/questions/{id}              # Modifier une question
DELETE /api/questions/{id}              # Supprimer une question
POST   /api/questions/{id}/choix        # Ajouter un choix
POST   /api/questions/{id}/validate     # Valider une question

API REST - Endpoints pour les modules

POST   /api/modules                     # Créer un module
GET    /api/modules/{id}                # Récupérer un module
PUT    /api/modules/{id}                # Modifier un module
POST   /api/modules/{id}/etudiants      # Ajouter des étudiants

4.2.4. Patterns architecturaux

Pattern 1 : Layered Architecture

L’architecture en couches sépare clairement les responsabilités :

  • Présentation : Interaction utilisateur

  • Métier : Logique applicative

  • Données : Persistance

Pattern 2 : Repository Pattern

Les repositories encapsulent la logique d’accès aux données, permettant de changer de SGBD sans impact sur les couches supérieures.

Pattern 3 : Service Layer

Les services métier centralisent la logique applicative et les règles de gestion, facilitant leur réutilisation.

Pattern 4 : API Gateway

L’API REST agit comme point d’entrée unique, gérant le routage, l’authentification et la transformation des requêtes.

4.2.5. Principes de conception

Principe de responsabilité unique (SRP)

Chaque composant a une responsabilité bien définie et limitée.

Principe ouvert/fermé (OCP)

Les composants sont ouverts à l’extension mais fermés à la modification grâce aux interfaces.

Principe d’inversion de dépendance (DIP)

Les couches hautes ne dépendent pas des couches basses ; toutes dépendent d’abstractions (interfaces).

Séparation des préoccupations

Chaque couche gère ses propres préoccupations sans empiéter sur les autres.

4.3. Diagramme de déploiement

Le diagramme de déploiement illustre l’infrastructure physique et la distribution des composants logiciels sur les nœuds matériels.

deploiement
Diagramme de déploiement - Infrastructure technique

Architecture distribuée :

Le système QuizMaker utilise une architecture client-serveur distribuée avec :

  • Clients légers : Navigateurs web sur postes enseignants et étudiants

  • Serveurs dédiés : Serveur web, serveur d’application, serveur de base de données

  • Séparation des responsabilités : Chaque serveur a un rôle spécifique

4.3.1. Description des nœuds

Nœud : Poste Enseignant

Caractéristique Description

Type

Poste client (PC/Mac/Linux)

Artefacts

Application Web Client, Navigateur Web (Chrome, Firefox, Safari, Edge)

Connexion

Internet via HTTPS (port 443)

Configuration minimale

Processeur moderne, 4GB RAM, connexion haut débit

Logiciels requis

Navigateur web moderne avec JavaScript activé

Nœud : Poste Étudiant

Caractéristique Description

Type

Poste client (PC/Mac/Linux/Tablette)

Artefacts

Application Web Client, Navigateur Web

Connexion

Internet via HTTPS (port 443)

Configuration minimale

Processeur moderne, 2GB RAM, connexion stable

Logiciels requis

Navigateur web moderne avec JavaScript activé

Nœud : Serveur Web

Caractéristique Description

Type

Serveur physique ou virtuel

Artefacts

Apache/Nginx (serveur HTTP), Application QuizMaker (front-end)

Protocole

HTTPS sur port 443

Rôle

Servir les pages web, gérer les certificats SSL/TLS, reverse proxy

Configuration

2 CPU, 8GB RAM, 100GB stockage SSD

Haute disponibilité

Load balancer en option

Nœud : Serveur Application

Caractéristique Description

Type

Serveur physique ou virtuel

Artefacts

API REST QuizMaker, Services Métier, Gestionnaires (Questionnaire, Validation)

Technologies

Java/Python/Node.js (selon implémentation)

Rôle

Exécuter la logique métier, valider les contraintes, orchestrer les opérations

Configuration

4 CPU, 16GB RAM, 200GB stockage

Scalabilité

Horizontal scaling possible

Nœud : Serveur Base de Données

Caractéristique Description

Type

Serveur dédié haute performance

Artefacts

PostgreSQL 14+ ou MySQL 8+, Base de données QuizMaker

Rôle

Stocker et gérer toutes les données persistantes

Configuration

8 CPU, 32GB RAM, 1TB stockage SSD, RAID 10

Haute disponibilité

Réplication Master-Slave, sauvegardes automatiques quotidiennes

Sécurité

Chiffrement des données au repos et en transit

Nœud : Serveur Fichiers

Caractéristique Description

Type

Serveur de stockage en réseau (NAS/SAN)

Artefacts

Stockage Banque Questions, Stockage Documents

Protocoles

NFS, SFTP, SMB

Rôle

Stocker les fichiers volumineux et documents annexes

Configuration

2TB+ stockage redondant

Sauvegarde

Snapshots quotidiens, réplication géographique

Nœud : Internet (Cloud)

Caractéristique Description

Type

Infrastructure réseau publique

Protocoles

HTTPS (TLS 1.3)

Port

443

Sécurité

Certificat SSL/TLS valide, firewall, WAF (Web Application Firewall)

Performance

CDN optionnel pour distribution géographique

4.3.2. Protocoles de communication

Communication Client-Serveur

Navigateur Web → Internet : HTTPS/TLS 1.3
Internet → Serveur Web : HTTPS (Port 443)
Serveur Web → Application QuizMaker : HTTP (déploiement local)

Caractéristiques :

  • Chiffrement end-to-end avec TLS 1.3

  • Authentification par certificat SSL

  • Session management via tokens JWT

Communication Serveur Web - Serveur Application

Application QuizMaker → API REST : HTTP/REST
API REST → Services Métier : Appels de méthodes locaux

Caractéristiques :

  • Communication interne non chiffrée (réseau privé)

  • Format d’échange : JSON

  • Authentification par API keys

Communication Serveur Application - Base de Données

Services Métier → SGBD : JDBC/SQL (PostgreSQL)
                       : MySQL Connector (MySQL)

Caractéristiques :

  • Connexion persistante (connection pooling)

  • Transactions ACID

  • Requêtes préparées (prepared statements) pour prévenir les injections SQL

Communication Serveur Application - Serveur Fichiers

API REST → Stockage Banque Questions : NFS/SFTP
API REST → Stockage Documents : NFS/SFTP

Caractéristiques :

  • Montage réseau pour NFS

  • Transfert sécurisé pour SFTP

  • Contrôle d’accès par permissions Unix

4.3.3. Configuration réseau

Topologie réseau recommandée

Internet (Zone Publique)
    |
[Firewall / DMZ]
    |
Serveur Web (Zone DMZ)
    |
[Firewall Interne]
    |
Serveur Application (Zone Privée)
    |
[Firewall Base de Données]
    |
Serveur Base de Données (Zone Sécurisée)
Serveur Fichiers (Zone Sécurisée)

Règles de firewall

Source Destination Port Description

Internet

Serveur Web

443

HTTPS entrant

Serveur Web

Serveur App

8080

API REST

Serveur App

Serveur BDD

5432/3306

PostgreSQL/MySQL

Serveur App

Serveur Fichiers

2049/22

NFS/SFTP

4.3.4. Exigences non fonctionnelles

Performance

  • Temps de réponse < 2 secondes pour 95% des requêtes

  • Support de 500 utilisateurs concurrents

  • Débit minimum : 100 requêtes/seconde

Disponibilité

  • Uptime cible : 99.5% (43.8 heures d’arrêt/an)

  • Maintenance planifiée : fenêtres nocturnes

  • Redémarrage automatique en cas de défaillance

Scalabilité

  • Scaling horizontal du serveur application

  • Load balancing pour distribution de charge

  • Mise en cache (Redis/Memcached) optionnelle

Sécurité

  • Chiffrement TLS 1.3 obligatoire

  • Authentification multi-facteurs recommandée

  • Logs d’audit complets

  • Conformité RGPD pour données personnelles

Sauvegarde et récupération

  • Sauvegardes complètes quotidiennes

  • Sauvegardes incrémentales toutes les 4 heures

  • RPO (Recovery Point Objective) : 4 heures

  • RTO (Recovery Time Objective) : 2 heures

  • Rétention : 30 jours

4.3.5. Environnements de déploiement

Environnement de Développement

Configuration minimale :
- Serveur unique avec tous les composants
- Docker Compose pour orchestration
- Base de données locale SQLite/PostgreSQL

Environnement de Test/Staging

Configuration intermédiaire :
- 2 serveurs (Application + Base de données)
- Données anonymisées
- Mirroir de la production à échelle réduite

Environnement de Production

Configuration complète :
- 4+ serveurs (Web, App×2, BDD, Fichiers)
- Haute disponibilité
- Monitoring complet
- Sauvegardes automatisées

5. Contraintes et considérations

5.1. Contraintes techniques

5.1.1. Contraintes logicielles

Langage de conception : Asciidoc (NF-Req-3)

Toute la documentation de développement doit être rédigée en format Asciidoc pour garantir :

  • La génération automatique de documentation

  • La portabilité multi-format (HTML, PDF, DocBook)

  • L’intégration dans les pipelines CI/CD

  • La lisibilité en format texte brut

Diagrammes UML : PlantUML (NF-Req-4)

Tous les diagrammes doivent être créés avec PlantUML en respectant strictement la norme UML 2.x :

  • Diagrammes versionnables (format texte)

  • Génération automatique d’images (SVG, PNG)

  • Intégration native dans Asciidoc

  • Conformité à la notation UML standard

Contraintes OCL

Les contraintes d’intégrité doivent être exprimées en Object Constraint Language (OCL) pour :

  • Formaliser les règles métier

  • Permettre la validation automatique

  • Servir de spécification pour les tests

  • Documenter précisément les invariants

5.1.2. Contraintes matérielles

Serveurs

  • Architecture x86-64 ou ARM64

  • Virtualisation supportée (VMware, KVM, Docker)

  • Connexion réseau gigabit minimum

  • Alimentation redondante recommandée

Stockage

  • SSD obligatoire pour la base de données

  • RAID 10 ou équivalent pour la redondance

  • Capacité évolutive pour croissance des données

Réseau

  • Bande passante minimale : 100 Mbps

  • Latence < 50ms entre serveurs internes

  • Connexion Internet redondante recommandée

5.2. Contraintes de sécurité

5.2.1. Authentification et autorisation

Authentification forte

  • Mots de passe conformes à la politique de sécurité (12+ caractères, complexité)

  • Authentification multi-facteurs recommandée pour enseignants

  • Expiration de session après 30 minutes d’inactivité

  • Limitation des tentatives de connexion (5 maximum)

Autorisation basée sur les rôles (RBAC)

Rôle Permissions Restrictions

Enseignant

Créer/modifier/supprimer questionnaires, Gérer modules, Consulter résultats

Ne peut voir que ses propres questionnaires

Étudiant

Participer aux épreuves, Consulter ses notes

Ne peut voir que ses propres copies

Administrateur

Toutes permissions

Accès complet au système

5.2.2. Protection des données

Chiffrement

  • TLS 1.3 obligatoire pour toutes les communications externes

  • Chiffrement des mots de passe avec bcrypt (cost factor 12+)

  • Chiffrement des données sensibles au repos (AES-256)

Conformité RGPD

  • Consentement explicite pour traitement des données personnelles

  • Droit à l’oubli : suppression complète sur demande

  • Portabilité des données : export en format standard

  • Journalisation des accès aux données personnelles

Anonymisation

  • Données de test anonymisées dans environnements non-production

  • Logs ne contenant pas d’informations personnelles identifiables

  • Agrégation des statistiques sans données individuelles

5.2.3. Audit et traçabilité

Journalisation

  • Toutes les actions critiques loguées (création, modification, suppression)

  • Format de log standardisé (JSON avec timestamp, utilisateur, action)

  • Rétention des logs : 12 mois minimum

  • Logs stockés de manière immuable

Actions tracées

Catégorie Actions loguées

Authentification

Connexion, déconnexion, échecs

Questionnaires

Création, modification, suppression, validation

Questions

Ajout, modification, suppression

Épreuves

Création, démarrage, arrêt

Copies

Soumission, correction, consultation

5.3. Contraintes de performance

5.3.1. Temps de réponse

Opération Temps max Justification

Chargement interface

2 sec

Expérience utilisateur fluide

Création questionnaire

1 sec

Action fréquente, doit être réactive

Ajout question

500 ms

Action très fréquente

Validation questionnaire

1 sec

Traitement des contraintes OCL

Sauvegarde automatique

200 ms

Transparente pour l’utilisateur

5.3.2. Charge supportée

  • Utilisateurs simultanés : 500 minimum

  • Questionnaires actifs : 100 simultanément

  • Questions par questionnaire : 1000 maximum

  • Étudiants par épreuve : 500 maximum

5.3.3. Optimisations

  • Mise en cache des questionnaires fréquemment utilisés

  • Pagination des listes de résultats (50 éléments/page)

  • Compression des réponses HTTP (gzip)

  • Lazy loading des éléments lourds

5.4. Contraintes d’utilisabilité

5.4.1. Accessibilité

  • Conformité WCAG 2.1 niveau AA minimum

  • Support des lecteurs d’écran

  • Navigation clavier complète

  • Contraste de couleurs respectant les normes

  • Taille de police ajustable

5.4.2. Compatibilité navigateurs

Navigateur Version minimale Support

Chrome

90+

Complet

Firefox

88+

Complet

Safari

14+

Complet

Edge

90+

Complet

Internet Explorer

-

Non supporté

5.4.3. Internationalisation

  • Interface en français (version 1.0)

  • Architecture prête pour multi-langues

  • Format de dates localisé

  • Encodage UTF-8 pour tous les contenus

5.5. Contraintes de maintenabilité

5.5.1. Documentation du code

  • Commentaires pour toutes les classes et méthodes publiques

  • Documentation API générée automatiquement (Javadoc, JSDoc)

  • README à jour dans chaque module

  • Changelog maintenu (format Keep a Changelog)

5.5.2. Standards de codage

  • Respect des conventions du langage utilisé

  • Linting automatique (ESLint, Pylint, etc.)

  • Couverture de tests > 80%

  • Revue de code obligatoire avant merge

5.5.3. Versioning

  • Git pour le contrôle de version

  • Stratégie de branching : GitFlow

  • Tags sémantiques (Semantic Versioning 2.0)

  • Releases documentées avec notes de version

6. Annexes

6.1. Annexe A : Glossaire

Terme Définition

Acteur

Entité externe (personne ou système) qui interagit avec le système

Artefact

Élément tangible produit ou utilisé lors du développement

Asciidoc

Format de documentation textuelle légère

Banque de questions

Référentiel centralisé de questions réutilisables

Cardinalité

Nombre d’instances participant à une relation

Choix

Option de réponse proposée pour une question à choix multiple

Composition

Relation d’agrégation forte où le composé n’existe pas sans le conteneur

Contrainte OCL

Règle formelle exprimée en Object Constraint Language

Copie

Ensemble des réponses d’un étudiant à un questionnaire lors d’une épreuve

Déploiement

Installation et configuration d’un système dans son environnement d’exécution

Diagramme d’activité

Représentation UML des flux de contrôle et des processus

Diagramme de cas d’utilisation

Vue d’ensemble des fonctionnalités et acteurs

Diagramme de classes

Représentation statique des classes et de leurs relations

Diagramme de communication

Interactions entre objets avec emphase sur la structure

Diagramme de composants

Architecture logicielle montrant les composants et dépendances

Diagramme de déploiement

Infrastructure physique et distribution des composants

Diagramme de séquence

Interactions temporelles entre objets

Diagramme d’états

Cycle de vie d’un objet à travers ses états

Enseignant

Utilisateur créant et gérant les questionnaires

Épreuve

Session d’évaluation pendant laquelle les étudiants répondent à un questionnaire

Étudiant

Utilisateur participant aux épreuves et répondant aux questionnaires

Invariant

Condition qui doit toujours être vraie pour un objet

Module d’enseignement

Unité organisationnelle regroupant étudiants, questionnaires et épreuves

OCL

Object Constraint Language - langage formel pour exprimer des contraintes

PlantUML

Outil de génération de diagrammes UML à partir de texte

QCM

Question à Choix Multiple

Question

Énoncé avec plusieurs choix de réponses possibles

Questionnaire

Collection organisée de questions formant un outil d’évaluation

Réponse

Sélection de choix effectuée par un étudiant pour une question

UML

Unified Modeling Language - langage de modélisation standard

6.2. Annexe B : Acronymes

Acronyme Signification

API

Application Programming Interface

CRUD

Create, Read, Update, Delete

DMZ

DeMilitarized Zone

HTTP

HyperText Transfer Protocol

HTTPS

HTTP Secure

JDBC

Java Database Connectivity

JSON

JavaScript Object Notation

MVC

Model-View-Controller

NAS

Network Attached Storage

NFS

Network File System

OCL

Object Constraint Language

OCP

Open-Closed Principle

PDF

Portable Document Format

QCM

Question à Choix Multiple

RAID

Redundant Array of Independent Disks

RBAC

Role-Based Access Control

REST

Representational State Transfer

RGPD

Règlement Général sur la Protection des Données

RPO

Recovery Point Objective

RTO

Recovery Time Objective

SAN

Storage Area Network

SFTP

SSH File Transfer Protocol

SGBD

Système de Gestion de Base de Données

SMB

Server Message Block

SQL

Structured Query Language

SRP

Single Responsibility Principle

SRS

Software Requirements Specification

SSL

Secure Sockets Layer

SVG

Scalable Vector Graphics

TLS

Transport Layer Security

UC

Use Case (Cas d’utilisation)

UML

Unified Modeling Language

UTF

Unicode Transformation Format

7. Contact et Support

Pour toute question concernant cette fonctionnalité :

Auteur : Cheikh Tidiane DIOP
Institution : Université de Nantes - Master Informatique
Date : Janvier 2026