Dossier complet — Génie logiciel

L3 · S5 · Ingénierie informatique

Dossier pédagogique original Matrice MI. Contenu d’entraînement non officiel; il ne remplace pas le support ou la maquette d’un établissement.

Objectifs d’apprentissage

• Transformer un besoin métier en exigences claires, testables et traçables.

• Modéliser un système avec des cas d’utilisation, des scénarios et des diagrammes UML adaptés.

• Choisir une architecture modulaire en justifiant les responsabilités, les dépendances et les compromis.

• Concevoir une stratégie de tests et interpréter les résultats pour réduire les défauts.

• Organiser un travail d’équipe avec Git, revues, intégration continue et pratiques agiles mesurables.

Prérequis

• Savoir programmer dans un langage impératif et écrire des fonctions avec des entrées et sorties explicites.

• Connaître les structures de données élémentaires, les exceptions et les notions de débogage.

• Savoir utiliser un terminal, lire des fichiers texte et manipuler les bases de Git (commit, branche, fusion).

Cours

1. Besoins et spécification

De l’idée au contrat vérifiable

Un besoin exprime une finalité pour un acteur; une exigence le reformule en comportement observable, dans un contexte donné. Une bonne exigence est nécessaire, non ambiguë, cohérente, testable et traçable. On distingue les exigences fonctionnelles (ce que le système fait) des exigences non fonctionnelles (qualité, sécurité, performance). Une user story utile suit souvent « En tant que..., je veux..., afin de... », complétée par des critères d’acceptation. Éviter « rapide » ou « convivial » sans seuil mesurable. Exemple guidé : pour une bibliothèque, le besoin est d’éviter les retards. L’exigence devient : « Quand un emprunt arrive à échéance, le système envoie au membre un courriel au plus tard à 9 h le jour prévu. » Critères : membre valide, échéance aujourd’hui, un message enregistré; sinon aucun envoi. Le test vérifie la date et l’existence d’un envoi. Le point de contrôle est de relier chaque exigence à un scénario et à un test; une exigence sans oracle observable reste incomplète.

Points-clés

• Une exigence décrit un comportement observable et vérifiable, pas une intention vague.
• Les critères d’acceptation relient acteurs, contexte, résultat attendu et cas limites.
• La traçabilité besoin–exigence–test aide à repérer les oublis et les changements coûteux.

2. Architecture et conception

Découper sans perdre les invariants

Une architecture organise les modules, leurs interfaces et les contraintes qui les relient. Une séparation en présentation, application, domaine et infrastructure peut isoler les règles métier des détails techniques. La modularité n’est pas un empilement de couches : une dépendance doit pointer vers une abstraction stable, et chaque module doit exposer peu de connaissances. Exemple guidé : dans une billetterie, Tarification calcule le prix à partir d’une commande et d’une politique; PaiementPort décrit l’opération attendue; un adaptateur appelle Stripe ou un faux fournisseur. Le domaine reste testable sans réseau. Pour une commande de 3 billets à 20 € avec 10 % de réduction, le calcul est $3 imes20 imes(1-0{,}10)=54$ €. L’invariant « un paiement confirmé correspond à une commande existante » est contrôlé dans le service d’application, avant l’appel externe. Limites : une architecture plus abstraite coûte du temps, et une découpe trop fine augmente la coordination. Ne pas confondre microservices et qualité. Point de contrôle : peut-on remplacer la base ou le prestataire sans modifier la règle métier ?

Points-clés

• Une frontière de module doit protéger une responsabilité ou un invariant clairement nommé.
• Les ports et adaptateurs isolent les dépendances externes et rendent les tests déterministes.
• Toute décision d’architecture comporte un coût; elle doit être justifiée par un risque ou un besoin.

3. Tests et intégration

Prouver progressivement le comportement

Un test unitaire cible une petite unité avec des dépendances contrôlées; un test d’intégration vérifie plusieurs composants réels; un test système observe le produit dans un contexte proche de l’usage. La pyramide des tests recommande beaucoup de tests rapides et ciblés, moins de tests coûteux. Un bon test suit Arrange–Act–Assert et nomme le comportement. Exemple guidé : pour calculer_total(100, 0.2), préparer prix 100 et taxe 20 %, appeler la fonction, puis vérifier 120. Tester aussi 0 et une taxe négative refusée, selon le contrat. La couverture de lignes ne prouve pas l’absence de défaut : elle peut ignorer une condition métier mal choisie. Un pipeline d’intégration continue installe, vérifie le formatage, exécute les tests et publie un résultat reproductible à chaque fusion. Les tests instables doivent être traités, non relancés aveuglément. Une intégration fréquente réduit la taille des conflits, mais ne remplace ni revue ni analyse des exigences. Point de contrôle : chaque échec indique-t-il clairement la cause, l’entrée et le résultat attendu ?

Points-clés

• Le niveau de test doit correspondre au risque et à la frontière vérifiée.
• Un test lisible possède un arrangement, une action et une assertion observables.
• L’intégration continue automatise des contrôles reproductibles sans garantir à elle seule la qualité.

4. UML et conception orientée responsabilités

Rendre la conception lisible

UML n’est pas un langage de programmation : c’est une notation pour communiquer une structure ou un comportement. Un diagramme de cas d’utilisation délimite le système et les acteurs; un diagramme de séquence ordonne les messages d’un scénario; un diagramme de classes expose responsabilités, associations et cardinalités. La conception doit viser une forte cohésion et un couplage maîtrisé : une classe qui possède une seule raison de changer est plus simple à tester. Exemple guidé : pour réserver une salle, l’acteur Utilisateur appelle ReservationService.reserver, qui vérifie le créneau via Calendrier, puis demande à Notification d’envoyer la confirmation. Le service porte la règle de réservation; le calendrier ne connaît pas le courriel. Si le créneau est occupé, le service renvoie un refus sans créer de réservation. La cardinalité « un utilisateur possède plusieurs réservations » ne signifie pas que l’utilisateur doit connaître la base de données. Erreurs fréquentes : mélanger interface et implémentation, multiplier les flèches, ou dessiner un diagramme sans scénario. Point de contrôle : chaque classe a-t-elle une responsabilité et chaque message un destinataire justifié ?

Points-clés

• Les diagrammes UML sélectionnés doivent répondre à une question de conception précise.
• La cohésion élevée et le couplage faible facilitent évolution, tests et remplacement des composants.
• Un scénario concret permet de vérifier les responsabilités et l’ordre des interactions.

5. Git, agilité et maintenance évolutive

Livrer, apprendre et préserver le logiciel

Git conserve des instantanés reliés par une histoire; une branche courte isole un changement, puis une revue examine code, tests et impact. Un commit atomique exprime une intention unique. En agile, le backlog ordonne une valeur et un risque; une itération produit un incrément démontrable, tandis que la définition de fini impose par exemple tests verts, revue et documentation. Exemple guidé : pour ajouter un filtre de tâches, créer feature/filtre-taches, écrire d’abord le test « statut terminé exclu », implémenter, exécuter la suite, puis ouvrir une revue. Après correction, fusionner et supprimer la branche. Une maintenance corrective répare un défaut, adaptative suit un environnement, perfective améliore le produit et préventive réduit une dette technique. Erreurs fréquentes : commits géants, branche durable, conflit résolu sans relancer les tests, ou métrique de vélocité utilisée comme objectif de productivité. Point de contrôle : peut-on expliquer le changement, le risque couvert et la preuve de fonctionnement à partir de l’historique ?

Points-clés

• Les petits commits et les branches courtes rendent la revue et le retour arrière plus sûrs.
• Une story n’est terminée que lorsque ses critères et la définition de fini sont vérifiés.
• La maintenance traite aussi l’adaptation et la prévention, pas seulement les pannes visibles.

Exercices corrigés

Exercice 1 · Fondamental

Une application de prêt doit empêcher un membre d’emprunter plus de cinq livres simultanément. Reformulez le besoin en une exigence testable, puis donnez deux cas d’acceptation, dont un cas limite.

Correction détaillée

1. Identifier l’acteur et la règle : le membre demande un prêt et le nombre de prêts actifs est limité. 2. Écrire l’exigence : « Lorsqu’un membre ayant n prêts actifs demande un nouveau livre, le système autorise si n < 5 et refuse si n >= 5, en affichant la raison du refus. » 3. Cas nominal : n = 4, livre disponible; le prêt est créé et n devient 5. 4. Cas limite : n = 5, livre disponible; aucun prêt n’est créé et le message de limite est retourné. 5. La règle est testable car l’entrée, la condition et les effets observables sont précis.

Exercice 2 · Fondamental

Écrivez en pseudo-code un test unitaire pour une fonction fraisLivraison(total) qui renvoie 5 € si total < 50 et 0 € sinon. Ajoutez le cas limite et expliquez l’assertion.

Correction détaillée

1. Préparer le seuil : assert fraisLivraison(49.99) == 5. Ce test couvre le côté strictement inférieur. 2. Tester la frontière : assert fraisLivraison(50) == 0. Le mot « sinon » inclut exactement 50. 3. Tester un montant plus grand : assert fraisLivraison(80) == 0. 4. Chaque appel est indépendant et ne nécessite ni base ni réseau : c’est un test unitaire. 5. Si l’implémentation utilise <= 50, le deuxième test échoue et révèle l’erreur de frontière; l’assertion compare le résultat effectif au contrat attendu.

Exercice 3 · Intermédiaire

Pour un achat en ligne, décrivez l’ordre des interactions entre Client, Panier, ServiceCommande, Stock et Paiement lorsque le stock est suffisant et que le paiement réussit. Indiquez aussi le comportement si le stock est insuffisant.

Correction détaillée

1. Client appelle Panier.confirmer. 2. Panier transmet les lignes au ServiceCommande. 3. ServiceCommande demande à Stock de réserver les quantités. 4. Si la réservation réussit, il calcule le total et appelle Paiement. 5. Si Paiement confirme, le service crée la commande et valide la réservation, puis répond au Client. 6. Si Stock refuse, le service n’appelle pas Paiement, ne crée pas de commande et renvoie une disponibilité insuffisante. 7. Le diagramme de séquence doit montrer ces messages dans cet ordre; la règle importante est d’éviter de débiter avant d’avoir établi la disponibilité. Un système réel doit en plus prévoir compensation ou transaction si l’étape finale échoue.

Exercice 4 · Intermédiaire

Proposez un pipeline CI minimal pour une API Python, avec les étapes et la règle de fusion. Le dépôt contient des tests unitaires et un linter.

Correction détaillée

1. Déclencher le pipeline sur chaque pull request et sur la branche principale. 2. Installer une version Python fixée et les dépendances depuis le fichier de verrouillage. 3. Exécuter le linter; arrêter si le style ou une erreur statique échoue. 4. Exécuter les tests unitaires avec rapport; publier le résultat. 5. Construire le paquet ou l’image seulement après les contrôles. 6. Imposer la réussite de tous les jobs et une revue approuvée avant fusion. 7. Conserver les logs et versions pour reproduire un échec. Cette séquence réduit les défauts évidents, mais n’omet pas les tests d’intégration si l’API dépend d’une base : ils doivent constituer un job séparé avec service éphémère.

Exercice 5 · Avancé

Concevez une architecture testable pour un service de remboursement. La règle est : un remboursement est autorisé seulement si la commande est payée, non déjà remboursée et datée de moins de 30 jours. Le prestataire de paiement est externe. Donnez les modules, l’interface externe et la stratégie de tests.

Correction détaillée

1. Placer la règle dans RemboursementService, côté domaine/application, et lui fournir CommandeRepository et PaiementPort par interfaces. 2. Le service charge la commande; il vérifie statut payé, indicateur non remboursé et dateCourante - dateAchat < 30 jours. 3. Il appelle PaiementPort.rembourser(idTransaction, montant) seulement après ces contrôles. 4. Si l’appel confirme, il marque la commande remboursée dans une transaction et émet un événement; sinon il ne change pas l’état. 5. L’adaptateur du prestataire traduit l’interface vers son API et gère erreurs et idempotence avec une clé de remboursement. 6. Tester unitairement chaque règle avec un faux port, notamment J+29, J+30 et une double demande. 7. Tester l’intégration de l’adaptateur avec un environnement de test, puis un scénario système incluant persistance et reprise après échec. Cette séparation conserve la logique métier indépendante du fournisseur.

Quiz d’autoévaluation

Question 1

Quelle formulation est la plus testable ?

• Le système doit être rapide. • Le système doit être moderne. ✓ Pour une recherche valide, 95 % des réponses arrivent en moins de 300 ms. • Le système doit être agréable.

Explication : La troisième formulation donne un contexte, une mesure et un seuil observables; les autres adjectifs sont ambigus sans critère.

Question 2

Quel diagramme montre principalement l’ordre des messages d’un scénario ?

✓ Diagramme de séquence • Diagramme de déploiement • Diagramme de paquets • Diagramme de classes

Explication : Le diagramme de séquence ordonne les interactions entre participants au cours du temps.

Question 3

Quel choix caractérise une forte cohésion ?

• Une classe regroupe des responsabilités sans rapport. ✓ Une classe concentre des responsabilités liées à un même concept. • Chaque méthode appelle directement la base de données. • Tous les modules partagent leurs variables internes.

Explication : La cohésion mesure le lien entre responsabilités d’un module; des responsabilités liées rendent son rôle plus clair et ses changements plus localisés.

Question 4

Dans Arrange–Act–Assert, que représente Act ?

• La création des données et doublures. ✓ L’appel de l’opération que l’on veut vérifier. • La comparaison avec le résultat attendu. • La suppression de la branche Git.

Explication : Act déclenche le comportement testé; Arrange prépare le contexte et Assert vérifie le résultat.

Question 5

Quel énoncé sur la couverture de code est correct ?

• 100 % de lignes garantit l’absence de défaut. • Elle mesure seulement la vitesse du programme. ✓ Elle indique quelles portions ont été exécutées, sans prouver la pertinence des assertions. • Elle remplace les tests d’acceptation.

Explication : Une ligne peut être exécutée sans vérifier le bon comportement; la couverture est un indicateur, pas une preuve complète.

Question 6

Quel commit est le plus atomique ?

• Refonte complète, documentation et changement de base mélangés. ✓ Correction de la règle de remise avec son test associé. • Sauvegarde de tous les fichiers modifiés depuis un mois. • Fusion de toute la branche principale.

Explication : Le commit porte une intention cohérente et sa preuve; il est plus facile à relire, annuler et diagnostiquer.

Question 7

Pourquoi utiliser un port pour un prestataire de paiement ?

• Pour rendre obligatoire un fournisseur précis. • Pour cacher tous les tests. ✓ Pour isoler le domaine d’une API externe remplaçable. • Pour éviter toute gestion d’erreur.

Explication : L’interface définit le besoin du domaine; un adaptateur traduit ensuite vers un fournisseur réel ou un faux de test.

Question 8

Quel contrôle de fusion est le plus approprié dans une CI ?

• Fusionner même si les tests échouent. ✓ Exiger des tests verts et une revue avant fusion. • Exécuter les tests uniquement après mise en production. • Désactiver les logs pour accélérer le pipeline.

Explication : Des contrôles bloquants et une revue réduisent le risque d’intégrer un changement non vérifié; les logs facilitent le diagnostic.

Glossaire

• Exigence — Énoncé vérifiable d’un comportement ou d’une contrainte que le système doit satisfaire.
• Traçabilité — Lien maintenu entre besoin, exigence, conception, implémentation et preuve de test.
• Cas d’utilisation — Description d’un objectif d’un acteur et des interactions attendues avec le système.
• Cohésion — Degré de proximité entre les responsabilités rassemblées dans un module ou une classe.
• Couplage — Niveau de dépendance entre composants; un couplage maîtrisé limite les effets d’un changement.
• Test unitaire — Vérification automatisée d’une unité isolée avec ses dépendances contrôlées.
• Intégration continue — Pratique qui construit et vérifie fréquemment les changements partagés par un pipeline automatisé.
• Dette technique — Coût futur créé par un compromis ou un défaut de conception qui rend les évolutions plus difficiles.

TP · Mini-cas : gestion des réservations d’une salle de travail

Une association veut une petite application où un membre consulte les créneaux, réserve une salle et reçoit une confirmation. Une salle ne peut avoir deux réservations qui se chevauchent; l’administrateur peut annuler une réservation. Le groupe travaille avec un dépôt Git et une CI simple.

Objectifs

• Éliciter et prioriser des exigences fonctionnelles et non fonctionnelles.

• Modéliser un scénario de réservation et les responsabilités principales.

• Implémenter une règle de non-chevauchement avec tests automatisés.

• Livrer une branche revue et vérifiée par une intégration continue.

Étapes

1. Rédiger au moins six exigences, dont la règle de chevauchement, avec critères d’acceptation et identifiants.

2. Dessiner un cas d’utilisation et un diagramme de séquence pour une réservation acceptée et une réservation refusée.

3. Définir un modèle minimal Salle, Créneau et Réservation, puis isoler le service qui porte la règle.

4. Créer une branche, coder la règle et ses tests pour créneaux adjacents, identiques et partiellement chevauchants.

5. Ouvrir une revue, exécuter la CI, corriger les remarques et produire une démonstration reproductible.

Livrables attendus

• Un fichier de spécification avec exigences identifiées, critères et matrice exigence–test.

• Un dépôt contenant code, tests, diagrammes et historique de commits compréhensible.

• Un court rapport de décision présentant architecture, résultats CI et limites connues.

Critères d’évaluation

• Exigences testables et couverture des cas limites : 25 %.

• Cohérence des modèles, responsabilités et choix d’architecture : 25 %.

• Tests automatisés, lisibilité du code et règle correctement vérifiée : 30 %.

• Qualité de l’historique, CI reproductible, rapport et démonstration : 20 %.

Piste de résolution

Créer un service de réservation dépendant d’un dépôt abstrait et d’une horloge injectée. Pour une demande, rechercher les réservations de la salle et refuser si un intervalle existant [début, fin) vérifie debutExistant < finDemandee et debutDemandee < finExistant; ainsi deux créneaux qui se touchent sont acceptés. Tester succès, égalité des bornes, chevauchement partiel, annulation et doublon. Conserver les diagrammes alignés sur le code, protéger la branche principale par la CI et signaler l’absence d’authentification réelle comme limite.

Sujets originaux d’entraînement (non officiels)

Sujet original de préparation — session normale

Sujet original d’entraînement non officiel; il ne provient pas d’une session d’examen antérieure. Ce sujet est une création pédagogique originale non officielle. Il ne s’agit jamais d’une épreuve d’années passées ni d’une annale réelle.

Exercice 1

Une mairie veut notifier les usagers quand une demande change d’état. Rédigez quatre exigences, dont une non fonctionnelle, puis donnez pour deux d’entre elles un critère d’acceptation mesurable.

Correction : Exemples : E1, un agent peut passer une demande de « reçue » à « instruite »; E2, chaque changement est historisé avec auteur et date; E3, l’usager reçoit une notification lors d’un changement visible; E4, 95 % des notifications sont préparées en moins de 2 secondes hors panne du fournisseur. Pour E1, étant donné une demande reçue et un agent autorisé, quand l’agent valide, alors l’état devient instruite; un agent non autorisé obtient un refus. Pour E4, mesurer sur un lot défini et vérifier le percentile annoncé. Chaque formulation évite les termes vagues et précise contexte, action et résultat.

Exercice 2

Proposez une architecture modulaire pour une application de location de vélos, puis expliquez comment tester la règle « un vélo ne peut être loué que s’il est disponible » sans appeler un service externe.

Correction : Séparer interface, service de location, domaine et adaptateurs de persistance/paiement. Le service dépend d’un VeloRepository et d’un PaiementPort abstraits. Il charge le vélo, vérifie disponible, réserve l’état, puis déclenche le paiement; sinon il refuse avant tout paiement. En test unitaire, fournir un faux dépôt renvoyant disponible ou indisponible et un faux port enregistrant les appels. Vérifier qu’un vélo disponible produit une location et un appel, tandis qu’un vélo indisponible produit une erreur, aucun changement et zéro appel au port. Un test d’intégration séparé couvre les adaptateurs réels.

Exercice 3

Une équipe constate des conflits fréquents sur une branche longue et des tests instables. Proposez un plan de remise en qualité sur deux itérations, avec règles Git, CI et indicateurs.

Correction : Itération 1 : découper la branche en petits changements, imposer une revue, identifier chaque test instable et enregistrer sa cause; rendre le formatage et les tests déterministes bloquants. Itération 2 : intégrer quotidiennement, ajouter les scénarios manquants, isoler les tests d’intégration lents et publier leurs rapports. Indicateurs : âge moyen des branches, durée jusqu’à revue, taux de réussite au premier passage, nombre de tests instables et délai de correction. Ne pas viser seulement un pourcentage de couverture : vérifier aussi les règles critiques et les défauts détectés. Une rétrospective décide quels garde-fous conserver.

Sujet original de préparation — session de rattrapage

Sujet original d’entraînement non officiel; il ne provient pas d’une session d’examen antérieure. Ce sujet est une création pédagogique originale non officielle. Il ne s’agit jamais d’une épreuve d’années passées ni d’une annale réelle.

Exercice 1

Pour une plateforme de cours, décrivez un cas d’utilisation « remettre un devoir », ses exceptions principales et les tests d’acceptation associés.

Correction : Acteur : étudiant. Précondition : devoir ouvert et étudiant inscrit. Scénario : sélectionner un fichier, le téléverser, vérifier le format, enregistrer la remise et afficher la date. Exceptions : fichier trop volumineux, format interdit, délai dépassé; dans chaque cas aucune remise valide n’est créée et un message précis est affiché. Tests : fichier PDF valide avant échéance produit une remise; fichier invalide est refusé; remise à la borne de fermeture suit la règle documentée; fichier trop gros n’est pas conservé comme remise. Ajouter un test de reprise si le transfert échoue. Les critères relient chaque variante à un résultat observable.

Exercice 2

Un module calcule une note finale : 40 % contrôle continu et 60 % examen, avec arrondi au dixième. Donnez l’algorithme, quatre tests pertinents et un défaut de frontière possible.

Correction : Calculer note = 0,4 * continu + 0,6 * examen, puis arrondir au dixième selon la règle choisie et documentée. Tests : 10 et 10 donnent 10,0; 0 et 10 donnent 6,0; 10 et 0 donnent 4,0; 12,34 et 15,66 donnent 14,3 avant vérification du calcul exact et de l’arrondi. Tester aussi une valeur exactement à mi-chemin, par exemple 12,25, car les conventions diffèrent. Valider les bornes 0 et 20 et refuser une note hors intervalle. Un défaut fréquent consiste à arrondir chaque composante avant la moyenne, ce qui peut changer le résultat; n’arrondir qu’à la fin.

Exercice 3

Vous devez intégrer une API météo externe dans une application de randonnée. Décrivez l’interface interne, les erreurs à traiter et la stratégie de test et de déploiement.

Correction : Définir PrevisionPort.prevoir(position, instant) et faire dépendre le service métier de cette interface. L’adaptateur traduit la réponse externe vers un modèle interne. Traiter délai dépassé, réponse invalide, quota, erreur HTTP et absence de données; prévoir une valeur de repli explicitement signalée, sans inventer une prévision. Utiliser un faux port en tests unitaires pour succès, absence et erreur, puis un serveur simulé en intégration pour vérifier le mapping. En CI, ne pas dépendre du réseau réel; vérifier contrat et format. En déploiement, configurer secret et délai, journaliser sans données sensibles, surveiller taux d’erreur et latence, et documenter la possibilité de dégradation.

Parcours de révision sur quatre semaines

Semaine 1 · Besoins, exigences et UML

Réécrire cinq besoins vagues en exigences testables, puis dessiner un cas d’utilisation et un scénario de séquence; corriger avec la checklist de traçabilité. Avant de terminer, reformule les notions sans tes notes, vérifie les résultats dans le cours et note une difficulté précise à reprendre la semaine suivante.

Semaine 2 · Conception et architecture

Découper un mini-système en modules, justifier deux décisions et résoudre les exercices sur responsabilités, frontières et dépendances. Avant de terminer, reformule les notions sans tes notes, vérifie les résultats dans le cours et note une difficulté précise à reprendre la semaine suivante.

Semaine 3 · Tests et intégration continue

Écrire des tests Arrange–Act–Assert pour les cas nominaux et limites, simuler une CI locale et analyser un échec volontaire. Avant de terminer, reformule les notions sans tes notes, vérifie les résultats dans le cours et note une difficulté précise à reprendre la semaine suivante.

Semaine 4 · Git, agile, maintenance et synthèse

Réaliser le mini-cas, faire une revue de commits, répondre au quiz sans notes puis reprendre chaque erreur et traiter un sujet original en temps limité. Avant de terminer, reformule les notions sans tes notes, vérifie les résultats dans le cours et note une difficulté précise à reprendre la semaine suivante.