Examen Génie Logiciel

Partie 1 - Spécification des besoins

Question 1.a - Identification et classification des besoins

L'analyse des propos recueillis permet d'extraire et de classifier les besoins. Un besoin est dit Fonctionnel (BF) s'il décrit une action que le système doit accomplir, Non Fonctionnel (BNF) s'il qualifie le système (performance, sécurité, ergonomie), ou Mal Exprimé (MAL) s'il est ambigu ou invérifiable.

Certains propos (comme le 4 et une partie du 14) relèvent de la définition du domaine métier et ne sont pas des besoins informatiques stricts.

Réf	Description du besoin (et décomposition)	Type	Justification & Reformulation (si MAL)
1	Le système doit corriger automatiquement chaque QCM.	BF	Action métier principale.
2	Permettre la constitution collaborative d'une base de questions-réponses.	BF	Action métier.
3	La notation doit être sûre : demander un avis en cas de doute.	MAL	Invérifiable. Qu'est-ce qu'un "doute" ? Reformulation : Le système doit lever une alerte pour validation manuelle si une réponse est illisible ou ambiguë (ex: deux cases cochées).
4	Définition d'un questionnaire.	N/A	C'est une définition métier (hors périmètre strict des fonctionnalités logicielles).
5a	Aucune note non validée ne doit être divulguée.	BF	Règle de gestion métier.
5b	Sécuriser l'accès aux notes pour l'étudiant.	BNF	Confidentialité.
6	Associer un questionnaire à un étudiant spécifique.	BF	Action métier.
7	La triche doit être impossible.	MAL	Invérifiable (on ne peut garantir "l'impossible"). Reformulation : Le système doit pouvoir générer des questionnaires avec des questions et des choix de réponses permutés aléatoirement.
8	Ne pas reposer une question déjà posée à un même étudiant.	BF	Règle métier lors de la génération.
9	Le travail de distribution et ramassage doit être minimal.	MAL	"Minimal" n'est pas mesurable. Reformulation : Le système doit supporter la passation des QCM sur une interface Web en ligne, réduisant le support papier à 0.
10	Les règles de notation doivent être modifiables a posteriori avec recalcul.	BF	Action métier.
11	Rédiger les énoncés via divers générateurs (LATEX, Word, etc.).	MAL	Invérifiable car la liste se termine par "..." (infinie). Reformulation : Le système doit permettre l'importation de questions aux formats précis : .tex, .docx, .odt.
12	Bloquer l'accès des étudiants à la base de questions-réponses.	BNF	Sécurité et droits d'accès (Autorisation).
13	Envoyer les notes par SMS aux étudiants.	BF	Fonctionnalité de notification.
14a	Définition d'une copie.	N/A	Définition métier.
14b	Veiller à la présence du numéro étudiant sur la copie.	BF	Règle de validation des données en entrée.
15	Spécifier des critères de sélection (matière, thème, niveau) pour générer.	BF	Action de filtrage et génération.
16	Afficher des statistiques de réussite aux questions.	BF	Action de reporting.
17	Les questionnaires doivent être anonymisés lors de la correction/vue.	BNF	Confidentialité.
18	Obtenir les résultats en quelques heures, pas quelques jours.	MAL	"Quelques heures" n'est pas mesurable précisément pour un test. Reformulation : Le système doit corriger et rendre les résultats disponibles en moins de 4 heures après la fin du test.
19	Alerter si la base manque de questions pour un planning donné.	BF	Fonctionnalité d'alerte.
20	Les redoublants ne doivent pas s'ennuyer.	MAL	Complètement subjectif. Reformulation : Le système doit garantir qu'un étudiant redoublant se voit assigner un QCM avec au moins 75% de questions inédites pour lui.
21	Associer une correction détaillée avec des pointeurs de cours.	BF	Action métier (enrichissement des données).
22	Intégrer un workflow de validation croisée par les pairs pour les questions.	BF	Action métier.
23	Intégrer automatiquement les notes dans le SI de l'université.	BF	Fonctionnalité d'export.
24a	Transmettre le planning et les thèmes aux étudiants.	BF	Fonctionnalité de diffusion.
24b	Envoyer des rappels avant chaque session.	BF	Fonctionnalité de notification automatisée.
25	S'intégrer facilement au SI de l'université.	MAL	"Facilement" est subjectif. Reformulation : Le système doit fournir une API REST standardisée pour communiquer avec le SI existant.
26	Permettre des questionnaires multi-cours.	BF	Action métier (génération transversale).
27	Permettre la correction manuelle en cas de panne machine.	BNF	Résilience et haute disponibilité (processus de secours).
28	Générer des rapports sur les points incompris par groupe de TD.	BF	Fonctionnalité d'analytique avancée.

Question 1.b - Identification des acteurs

Un acteur est une entité (humaine ou système externe) qui interagit directement avec le système. Pour UmaQCM, les acteurs sont :

• Enseignant (incluant Magistral et TD) : Crée les questions, génère les QCM, consulte les statistiques, valide les questions des pairs, corrige manuellement si besoin.
• Étudiant : Passe les QCM (en ligne), reçoit ses notes (par SMS et SI).
• Responsable de la scolarité : Assure le suivi administratif (gestion des copies papier, vérification).
• Responsable pédagogique : Consulte les résultats anonymisés, gère les plannings et les envois de rappels.
• Administrateur système : Maintient le système technique.
• Système d'Information (SI) de l'université (Acteur externe) : Reçoit les notes, fournit les listes d'étudiants.
• Service SMS / Passerelle de télécommunication (Acteur externe) : Permet l'envoi des notes aux étudiants.

Question 1.c - Diagramme de contexte

Le diagramme de contexte place le système au centre et le relie à ses acteurs externes via des flux d'informations.

• Système central : UmaQCM
• Flux avec les Enseignants : Soumission de questions/réponses, Paramétrage de QCM, Récupération de statistiques, Validation de questions.
• Flux avec les Étudiants : Réponses aux QCM en ligne, Réception de notifications (planning).
• Flux avec le Responsable pédagogique : Définition des plannings, Consultation de tableaux de bord globaux.
• Flux avec le Responsable scolarité : Soumission de lots de copies scannées, Signalement d'anomalies.
• Flux avec l'Administrateur Système : Configuration technique, Maintenance.
• Flux avec le SI de l'université : Synchronisation des données (Envoi des notes, Récupération de la base étudiante).
• Flux avec le Service SMS : Envoi des requêtes de messages textes (notes).

Partie 2 - Conception

Question 2.a - Structuration des services

Les services de UmaQCM peuvent être hiérarchisés en modules fonctionnels selon les problèmes qu'ils adressent :

1. Module de Gestion des Connaissances (Banque de questions)
   • Création et import de questions.
   • Workflow de validation croisée.
   • Indexation (thèmes, niveaux, cours).
2. Module de Génération et Planification
   • Sélection multicritères et prévention des doublons (anti-triche, gestion des redoublants).
   • Création des plannings de passage et assignation des étudiants.
3. Module de Passation et d'Évaluation
   • Interface de passage en ligne.
   • Module de correction automatique et paramétrage des barèmes.
   • Gestion des "doutes" (exceptions pour validation manuelle).
4. Module d'Analytique et de Restitution
   • Calcul des statistiques (réussite, points incompris).
   • Génération de rapports anonymisés.

Module de Communication et Intégration

• Notifications (Rappels, SMS de notes).
• Interfaçage bidirectionnel avec le SI de l'université.

Question 2.b - Architecture générale

L'architecture proposée repose sur un découpage en trois grandes couches pour assurer la séparation des préoccupations :

1. Couche Présentation (Interfaces Utilisateurs) : Sous-modules dédiés par profil (Portail Étudiant, Portail Enseignant, Portail Administration). Elle gère les affichages Web.
2. Couche Logique Métier (Services) : Contient les modules identifiés en 2.a (Générateur de QCM, Moteur de correction automatique, Gestionnaire de workflows de validation).
3. Couche Accès aux Données et Intégration :
   • Sous-module DAO (Data Access Object) communiquant avec la base de données relationnelle (stockage des questions, copies, logs).
   • Sous-module Passerelles (API Gateway) pour communiquer avec les systèmes externes (SI Université, API SMS).

Justification : Cette architecture modulaire en couches favorise la maintenabilité. Si l'API d'envoi de SMS change, seule la couche d'intégration est impactée, sans toucher la logique de calcul des notes.

Question 2.c - Styles d'architecture

• Pipe and Filter (Tuyaux et Filtres) : Très pertinent pour le flux de traitement spécifique des copies papier (Scan -> Reconnaissance des marques -> Vérification de la cohérence -> Calcul de la note). Cependant, il est inadapté pour gérer des interfaces interactives (comme la saisie de questions ou la consultation de statistiques).
• MVC (Modèle - Vue - Contrôleur) : Idéal pour concevoir l'interface utilisateur web du système, permettant de bien séparer les données (Modèle), les interfaces (Vue) et la logique de navigation (Contrôleur).
• Architecture en couches : Parfait pour structurer globalement l'application entière, garantissant une forte cohésion et un couplage faible entre la base de données, la logique métier et l'interface.

Choix le plus adéquat : Le système nécessitera une combinaison. L'architecture en couches est le choix global le plus adéquat pour isoler la logique complexe (génération, correction) des interfaces. Au sein de la couche de présentation, le style MVC sera utilisé.

Question 2.d - Couplage et Cohésion

Définitions :

• Couplage : Mesure le degré de dépendance entre deux ou plusieurs modules/classes. Un bon design cherche un couplage faible pour qu'un changement dans une classe n'impacte pas les autres.
• Cohésion : Mesure le degré avec lequel les responsabilités au sein d'une même classe sont liées. Un bon design cherche une cohésion forte (une classe ne fait qu'une seule chose précise).

Exemple de problème dans UmaQCM : Imaginons 3 classes : Questionnaire, Etudiant, ConnexionBaseDeDonnees. Si la classe Questionnaire possède une méthode calculerNotesEtEnvoyerSms(Etudiant e) qui instancie directement ConnexionBaseDeDonnees, effectue des requêtes SQL pour trouver le numéro de téléphone, calcule la note mathématique, et appelle directement une librairie SMS réseau. Problème : Cohésion très faible (la classe fait des maths, du réseau et de la BDD). Couplage très fort (liée directement à la base et à l'API réseau).

Correction (Conception améliorée) :

1. Classe Questionnaire : Contient uniquement les données des questions et la méthode métier abstraite corriger(Copie c).
2. Classe CalculateurNote : Reçoit une copie, applique les barèmes, renvoie un entier. (Forte cohésion mathématique).
3. Classe ServiceNotification : Écoute les événements "CorrectionTerminée" et se charge d'envoyer les résultats à l'étudiant via l'interface appropriée. (Découplage).

Partie 3 - Tests

Question 3.1 - Tests à partir de la spécification (Boîte noire)

Question 3.1.a - Jeux de test

La spécification indique une signature Int CalculNote(ReponseSeq quest, int n, BoolSeq rep) avec pour pré-conditions : n > 0 et size(quest) = size(rep). Si les conditions sont respectées et le calcul possible, on renvoie la note, sinon on renvoie NaN.

1. Jeu de test 1 (Nominal / Cas normal) :

   • Entrées : n = 10, quest = [0.2, 0.8], rep = [true, false]
   • Résultat attendu : 2 (car 0.2 × 10 = 2, le second choix n'étant pas coché).
   • Intérêt : Vérifier que le calcul s'effectue correctement quand toutes les pré-conditions sont validées (chemin normal).

2. Jeu de test 2 (Invalidation de pré-condition sur n) :

   • Entrées : n = 0, quest = [1.0], rep = [true]
   • Résultat attendu : NaN (car n n'est pas strictement supérieur à 0).
   • Intérêt : Tester la robustesse et le comportement du système (post-condition "sinon on renvoie NaN") en dehors des limites autorisées pour le barème.

3. Jeu de test 3 (Invalidation de pré-condition sur les tailles) :

   • Entrées : n = 10, quest = [0.5, 0.5], rep = [true]
   • Résultat attendu : NaN
   • Intérêt : S'assurer que le système rejette une désynchronisation entre les propositions du sujet et les réponses de l'étudiant.

4. Jeu de test 4 (Valeur limite / Tout faux) :

   • Entrées : n = 10, quest = [1.0], rep = [false]
   • Résultat attendu : 0
   • Intérêt : Vérifier le calcul dans un cas limite où aucune réponse n'est cochée (initialisation des variables).

Question 3.1.b - Type de test

Il s'agit de tests fonctionnels (ou tests de type boîte noire). Pourquoi ? Parce que ces tests ont été construits uniquement à partir de la spécification métier (entrées, sorties, pré-conditions, post-conditions) sans jamais regarder ni analyser le code source interne de la fonction.

Question 3.2 - Tests d'implémentation (Boîte blanche)

Note technique sur le code fourni dans l'énoncé : Le code contient quelques coquilles (un I majuscule ligne 5 suivi d'un i minuscule, et la comparaison note != NaN sachant que note est typée int). Nous réparons l'erreur de casse (i=0) pour le suivi des variables. Pour l'analyse du graphe, nous considérons NaN comme une valeur d'erreur constante vérifiable.

Question 3.2.a - Graphe de contrôle

Voici la liste des nœuds correspondant aux lignes du code réparé et l'enchaînement de leur contrôle d'exécution :

• N1 (Ligne 2) : if (n<=0 || (quest.length() != rep.length()))
• N2 (Ligne 3) : return NaN;
• N3 (Lignes 4-5) : int note=0; int i=0;
• N4 (Ligne 6) : while(i<quest.length() && note != NaN) (Évaluation de la condition de boucle)
• N5 (Ligne 7) : if (rep.getAt(i))
• N6 (Ligne 8) : note += quest.getAt(i).getPourcentage()*n;
• N7 (Ligne 9) : i++;
• N8 (Ligne 11) : return note;

Arcs (Chemins possibles) :

• N1 → N2 (Si condition L2 Vraie)
• N1 → N3 (Si condition L2 Fausse)
• N3 → N4
• N4 → N5 (Si entrée/maintien dans la boucle Vrai)
• N4 → N8 (Si fin de boucle Faux)
• N5 → N6 (Si condition L7 Vraie)
• N5 → N7 (Si condition L7 Fausse)
• N6 → N7
• N7 → N4 (Retour boucle)

Question 3.2.b - Suites de tests (Critères de couverture)

i. Couverture de toutes les instructions Il faut passer par chaque nœud (lignes de code) au moins une fois.

• Test 1 (Couvre N1, N2) : n = 0, quest = [], rep = []. (Passe par le return NaN).
• Test 2 (Couvre N1, N3, N4, N5, N6, N7, N8) : n = 10, quest = [1.0], rep = [true]. (La condition L7 est vraie, ce qui exécute l'instruction d'addition N6).

ii. Couverture de tous les arcs (branches) Il faut exécuter chaque flèche de notre graphe au moins une fois, notamment les deux sorties de chaque if et du while.

• Test 1 (Couvre N1→N2) : n = 0 (condition initiale vraie).
• Test 2 (Couvre N1→N3, N3→N4, N4→N5, N5→N6, N6→N7, N7→N4, N4→N8) : n = 10, quest = [1.0], rep = [true]. (Arc VRAI du if).
• Test 3 (Couvre l'arc N5→N7) : n = 10, quest = [1.0], rep = [false]. (L'arc FAUX du if à l'intérieur de la boucle, sautant N6).

iii. Couverture des 1-chemins (0 à 1 boucle) Il faut garantir un test sans jamais entrer dans la boucle (0 itération) et des tests y entrant exactement 1 fois.

• 0 fois dans la boucle :
  • Test 1 (Sortie anticipée via erreur) : n = 0. Chemin : N1 → N2.
  • Test 2 (Listes vides) : n = 10, quest = [], rep = []. Chemin : N1 → N3 → N4 (Faux) → N8. (La boucle L6 s'évalue à faux immédiatement car 0 < 0 est faux).
• 1 fois dans la boucle (On ajoute des listes de taille 1) :
  • Test 3 (Avec le if vrai) : n = 10, quest = [1.0], rep = [true]. Chemin complet sur 1 itération passant par N6.
  • Test 4 (Avec le if faux) : n = 10, quest = [1.0], rep = [false]. Chemin complet sur 1 itération esquivant N6.

Question 3.2.c - Type de test

Il s'agit de tests structurels (ou tests de type boîte blanche). Pourquoi ? Parce que la conception de ces jeux de test s'appuie directement sur la lecture et l'analyse de l'implémentation (le code source de la fonction). L'objectif explicite est de traverser les graphes de contrôle, les conditions logiques internes et les boucles de l'algorithme écrit.

Méthode

Pour aborder efficacement ce type d'examen de Génie Logiciel :

1. Spécification des besoins : Distinguez toujours "ce que fait le système" (fonctionnel) de "comment il le fait / sous quelles contraintes" (non fonctionnel). Si une affirmation est subjective ou ne contient pas de métriques chiffrées testables (comme "facilement", "minimal", "rapide"), classez-la immédiatement en "Mal exprimée" et proposez une reformulation technique quantifiable.
2. Conception et Architecture : Ne récitez pas de cours à l'aveugle. Si vous choisissez un pattern comme le Modèle-Vue-Contrôleur (MVC), justifiez-le toujours en vous appuyant sur les acteurs définis dans la Partie 1 (ici, l'interface étudiant/enseignant en ligne exige une stricte séparation interface/logique).
3. Tests (Boîte noire vs Boîte blanche) : C'est le piège classique. La boîte noire s'écrit avant (ou indépendamment) du code, en se basant sur le contrat/spécification (bornes, limites, valeurs absurdes). La boîte blanche nécessite de tracer le graphe de la fonction au brouillon. Assurez-vous de numéroter les lignes de code pour dresser vos chemins d'exécution (nœuds et arcs) rigoureusement, sans en oublier (notamment les sorties de boucles).