Exam on Software Engineering

Questions de réflexion

Question 1 - Activités principales du processus de développement

Pour chaque activité du processus de développement, voici la description demandée basée sur le cours.

Analyse

• Entrées (Input) : Le cahier des charges du projet.
• Sorties (Output) : Le cahier des charges du logiciel (le point de vue externe du système) et le document d'analyse et de spécification (le point de vue interne du système).
• Description de l'activité :
  • Quoi (L'objectif) : Comprendre le problème, éliciter (recueillir) les besoins, et spécifier les besoins (fonctionnels, non fonctionnels incluant les métriques, et ceux liés au domaine).
  • Comment (Tâches et principes) : Il faut analyser l'existant, mener des entretiens, utiliser des techniques d'analyse des besoins, puis rédiger le cahier des charges et élaborer le document d'analyse. Les principes à respecter sont l'absence d'ambiguïté, la cohérence des besoins, et la complétude.

Conception

• Entrées (Input) : Le cahier des charges du logiciel et le document d'analyse et de spécification.
• Sorties (Output) : Le document de conception (qui décrit les architectures physique et logique) ainsi que le document de la conception détaillée.
• Description de l'activité :
  • Quoi (L'objectif) : Trouver une solution technique qui répond aux besoins spécifiés.
  • Comment (Tâches et principes) : Élaborer l'architecture logique puis physique, et détailler cette architecture jusqu'à obtenir une solution complète et prête à être codée. Les principes fondamentaux à appliquer sont la modularité, un faible couplage, une forte cohésion, l'abstraction, la réutilisation, la réutilisabilité et l'encapsulation.

Test

• Entrées (Input) : Le code source à tester et les cas de tests à effectuer.
• Sorties (Output) : Le document de tests (rapports d'exécution).
• Description de l'activité :
  • Quoi (L'objectif) : Trouver des erreurs (défauts ou anomalies) dans le logiciel.
  • Comment (Tâches et principes) : Exécuter les tests, comparer les résultats attendus avec les résultats effectivement obtenus par le système, et effectuer la mise au point (débogage). Les principes directeurs sont : tester le plus tôt possible, planifier les tests, assurer la traçabilité des tests, tout en gardant à l'esprit que des tests exhaustifs (tester toutes les combinaisons possibles) sont impossibles.

Question 2 - Pourquoi tester et quand s'arrêter ?

Note : Le corrigé source mentionne le barème (0,252) mais omet le texte de la réponse. Voici la réponse standard attendue en génie logiciel correspondant à ces concepts.*

• Pourquoi teste-t-on les logiciels ? On teste un logiciel principalement pour découvrir des erreurs et des anomalies avant son déploiement, afin de s'assurer qu'il répond aux besoins (fonctionnels et non fonctionnels) définis lors de l'analyse, et pour garantir un niveau de qualité et de fiabilité acceptable.
• Quand les tests s'arrêtent-ils ? Comme les tests exhaustifs sont impossibles (principe mentionné à la question 1), les tests s'arrêtent généralement lorsque les critères d'arrêt définis dans le plan de test sont atteints. Cela peut être lorsque le taux de couverture du code est suffisant, que les délais ou le budget sont épuisés, ou que le taux de découverte de nouveaux bugs devient acceptable pour les risques encourus.

Question 3 - MVC vs 3-tiers

• Différence : Le style MVC (Modèle-Vue-Contrôleur) est un patron d'architecture logique qui sépare les données (Modèle), l'interface utilisateur (Vue) et la logique de contrôle des interactions (Contrôleur). L'architecture 3-tiers (3 tiers ou 3 couches physiques) est un style de déploiement qui sépare physiquement le système en une couche de présentation (Client), une couche de logique métier (Serveur d'application), et une couche de données (Serveur de base de données).
• Choix :
  • On choisit MVC pour structurer le code de l'interface utilisateur (IHM) d'une application, afin de faciliter la maintenance et de permettre de multiples vues pour un même modèle de données.
  • On choisit 3-tiers lorsqu'on a besoin d'une application distribuée (comme une application Web), où la sécurité, le déploiement sur plusieurs machines, l'extensibilité (scalabilité) et la gestion centralisée des données sont nécessaires. On peut d'ailleurs utiliser MVC à l'intérieur du tiers de présentation d'une architecture 3-tiers.

Question 4 - Style architectural pour un logiciel de dessin concurrent

• Style adéquat : Le style architectural MVC (Modèle-Vue-Contrôleur).
• Justification : Dans l'architecture MVC, le "Modèle" centralise les données et la logique (ici, l'état du dessin géométrique). Lorsqu'une modification survient ou qu'une contrainte est violée lors d'une édition concurrente, le Modèle est mis à jour et peut automatiquement notifier toutes les "Vues" actives chez les différents utilisateurs. Cela permet d'alerter immédiatement tout le monde que la contrainte n'est plus vérifiée, garantissant la synchronisation de l'affichage.

Exercice 1 - Gestion d'une billetterie

Question 1 - Acteurs du système

• Acteurs primaires : Le Demandeur, Le service de réservation.
• Acteurs secondaires : Le Réseau bancaire (qui intervient pour valider et traiter le paiement en ligne).

Question 2 - Besoins fonctionnels (BF) par acteur

Le système doit permettre au Demandeur de :

• BF1 : Demander des billets. Ce besoin se décompose en :
  • BF1.1 : Saisir ses informations personnelles.
  • BF1.2 : Choisir un spectacle.
  • BF1.3 : Préciser le nombre de billets demandé.
• BF2 : Payer en ligne (en utilisant son numéro de dossier).

Le système doit permettre au Service de réservation de :

• BF3 : Valider les demandes de billets.

Question 3 - Besoins non fonctionnels (BNF)

• Rapidité (Performance) : Le temps de réponse du système pour valider ou enregistrer une demande ne doit pas dépasser 2 secondes pour l'utilisateur.
• Disponibilité : Le site Web de réservation doit être disponible et accessible 99% du temps.

Question 4 - Architecture logique

• Propositions possibles : L'architecture MVC (pour bien séparer les interfaces web, la logique de billetterie et les entités), une architecture en 3 couches (Présentation, Métier, Accès aux données), ou en 5 couches.

Question 5 - Architecture physique

• Propositions possibles : Le style 3-tiers (Tiers Client web, Tiers Serveur d'application pour gérer les demandes, Tiers Serveur de base de données), ou un style 2-Tiers basé sur un client léger (un navigateur Web) communiquant avec un serveur central regroupant métier et données.

Exercice 2 - Cohésion et couplage

Question 1 - Exemples de cohésion

a. Cohésion fonctionnelle (une méthode fait une seule tâche bien précise)

public class Calculateur {
    // Cette méthode a une cohésion fonctionnelle forte : elle ne fait que calculer une moyenne.
    public double calculerMoyenne(double[] notes) {
        double somme = 0;
        for (int i = 0; i < notes.length; i++) {
            somme += notes[i];
        }
        return somme / notes.length;
    }
}

b. Cohésion modèle (une classe regroupe des attributs fortement liés et les méthodes pour les manipuler)

public class Point {
    // Cohésion modèle : les attributs définissent l'entité, les méthodes n'agissent que sur eux.
    private double x;
    private double y;

    public Point(double x, double y) {
        this.x = x;
        this.y = y;
    }

    public void deplacer(double dx, double dy) {
        this.x += dx;
        this.y += dy;
    }
}

Question 2 - Couplage fort entre modules

Voici deux exemples d'instructions causant un couplage fort.

Exemple 1 : Utilisation de variables globales statiques (la méthode dépend de l'état global au lieu de paramètres).

public class Configuration {
    public static int TAUX_TVA = 19;
}

public class Facture {
    public double calculerTotal(double montantHT) {
        // Couplage fort avec Configuration
        return montantHT + (montantHT * Configuration.TAUX_TVA / 100); 
    }
}

Exemple 2 : Accès direct aux attributs publics d'une autre classe (brise l'encapsulation).

public class Client {
    public double solde; // Attribut public (mauvaise pratique)
}

public class Banque {
    public void debiter(Client c, double montant) {
        // Couplage fort : la Banque modifie directement l'état interne du Client
        c.solde = c.solde - montant; 
    }
}

Question 3 - Types de couplage

• public class A extends B { … } : Il s'agit d'un couplage d'héritage (A est fortement lié à l'implémentation de sa super-classe B).
• public class C { .. D d; ..} : Il s'agit d'un couplage de composant (ou couplage par dépendance/composition, la classe C possède une référence vers D et dépend donc de son type).

Question 4 - Généralisation vs Dépendance

• Laquelle est la plus forte ? L'héritage (généralisation) se traduit par le couplage le plus fort.
• Justification : Dans le cas d'une dépendance simple, une classe possède une référence sur une autre et invoque ses méthodes via une interface publique ; les changements internes de la classe référencée impactent peu la classe appelante. En revanche, dans le cas de l'héritage, la classe enfant dépend intimement de la structure, des attributs protégés et de l'implémentation de la classe parente. Toute modification de la super-classe risque de briser ou de modifier le comportement des sous-classes.

Question 5 - Métriques LCOM et CBO

• LCOM (Lack of Cohesion in Methods) : Cette métrique mesure le manque de cohésion au sein d'une classe. Elle calcule généralement le nombre de paires de méthodes qui ne partagent aucun attribut commun. Plus la valeur LCOM est élevée, moins la classe est cohésive.
• CBO (Coupling Between Object classes) : Cette métrique évalue le nombre de liens de couplage d'une classe avec d'autres classes (le nombre de classes distinctes auxquelles une classe est liée).
• Rôle dans la conception : Ces métriques guident le concepteur pour évaluer si l'architecture respecte les principes de forte cohésion et de faible couplage. Bien qu'elles fournissent des indications numériques utiles, c'est au concepteur d'interpréter ces valeurs pour décider s'il faut refactoriser le code (par exemple, scinder une classe ayant un LCOM trop élevé).

Exercice 3 - Test et Graphe de flot de contrôle

Question 1 - Classes d'équivalence

Le programme a deux comportements distincts basés sur la parité du nombre de lettres.

• Classe 1 : Les mots avec un nombre pair de lettres. Jeu de test (JT) : mot = "test" (4 lettres).
• Classe 2 : Les mots avec un nombre impair de lettres. Jeu de test (JT) : mot = "tests" (5 lettres).

Question 2 - Tests aux limites

En enrichissant le jeu de tests par les limites physiques et conceptuelles d'une longueur de chaîne de caractères :

• Limite 1 : Le mot vide (longueur 0, qui est mathématiquement pair).
• Limite 2 : Le mot avec un seul caractère (longueur 1, la plus petite valeur impaire).
• Limite 3 : Le mot avec deux caractères (longueur 2, la plus petite valeur paire non nulle).

Question 3 - Analyse du graphe de flot de contrôle

Voici une clarification importante concernant le code source avant de détailler les réponses :

• L'instruction 9 (Ecrire("de lettres")) est exécutée dans la branche Sinon après l'instruction 8, selon la structure logique du document (confirmée par les traces de l'énoncé source). L'instruction 7, elle, affiche la phrase complète en une fois et passe directement à la fin du bloc conditionnel (instruction 10).
• Attention aux erreurs du corrigé source : Le corrigé d'origine propose le chemin 1-2-3-6-8-9-10-11 pour le mot vide. Or, pour un mot vide, L=0. Puisque 0 mod 2 = 0, la condition (L mod 2) = 0 est Vraie. Le flux doit donc passer par le nœud 7 (Pair), et non par 8 (Impair). Inversement, il propose pour le mot "a" (L=1, impair) de passer par 7, ce qui est tout aussi incorrect. Les réponses ci-dessous rétablissent la vraie logique mathématique du code, tout en explicitant les nœuds à couvrir.

a. Graphe de flot de contrôle La structure des nœuds et des transitions s'établit ainsi :

• (1) M <- LireMot → (2)
• (2) L = 0 → (3)
• (3) Tant que M[L] != MarqueDeFin → (4) si Vrai, (6) si Faux
• (4) L = L + 1 → (5)
• (5) Fin tantque → (3)
• (6) Si (L mod 2) = 0 → (7) si Vrai, (8) si Faux
• (7) Alors Ecrire(pair) → (10)
• (8) Sinon Ecrire(impair) → (9)
• (9) Ecrire("de lettres") → (10)
• (10) FinSi → (11)
• (11) Fin

b. Critère de couverture des instructions Il faut trouver un ensemble de chemins permettant de passer par tous les nœuds du graphe (de 1 à 11).

• Chemin A (branche impaire, avec boucle exécutée au moins une fois) : 1-2-3-4-5-3-6-8-9-10-11. Jeu de test : mot = "a" (L=1).
• Chemin B (branche paire, boucle non exécutée ou exécutée un nombre pair de fois) : 1-2-3-6-7-10-11. Jeu de test : mot = "" (mot vide, L=0). Note : Tous les nœuds {1,2,3,4,5,6,7,8,9,10,11} sont couverts par l'union de ces deux jeux de tests.

c. Critère de couverture des i-chemins (2-chemins) Ce critère exige de tester les cas où la boucle s'exécute 0, 1 et 2 fois.

• 0-Chemin (Boucle 0 fois) : Chemin : 1-2-3-6-7-10-11. JT = mot vide (L=0).
• 1-Chemin (Boucle 1 fois) : Chemin : 1-2-3-4-5-3-6-8-9-10-11. JT = "a" (L=1).
• 2-Chemins (Boucle 2 fois) : Chemin : 1-2-3-4-5-3-4-5-3-6-7-10-11. JT = "aa" (L=2).

d. Nombre cyclomatique de McCabe Le nombre cyclomatique V(G) peut être calculé par deux méthodes mathématiques :

• Méthode 1 (Arcs et Nœuds) : V(G) = E - N + 2. Où E est le nombre d'arcs (edges) et N le nombre de nœuds (nodes). Notre graphe comporte 11 nœuds (N = 11) et 12 arcs directionnels (E = 12). Calcul : 12 - 11 + 2 = 3. (Note : Le corrigé source indique de façon confuse "11-12+1=3", ce qui est une erreur arithmétique évidente, l'équation correcte appliquée aux données est bien E - N + 2 = 3).
• Méthode 2 (Régions) : V(G) = nombre de régions fermées + 1 (pour la région extérieure). Ici, la boucle "Tant que" crée 1 région fermée, la condition "Si/Sinon" crée 1 région fermée, plus 1 région englobant le tout = 3.

Que représente ce nombre ? Il représente le nombre de chemins linéairement indépendants dans le graphe. Concrètement, c'est le nombre minimum de tests à concevoir pour garantir que chaque instruction et chaque branche (arc) soient exécutées au moins une fois.

e. Réponses Vrai / Faux sur la couverture

• a. La couverture des instructions implique la couverture des arcs. Faux. (On peut couvrir toutes les instructions d'un "Si" sans la clause "Sinon", manquant ainsi l'arc contournant l'instruction).
• b. La couverture des arcs implique la couverture des instructions. Vrai. (Si l'on parcourt tous les arcs, on entre inévitablement dans tous les nœuds qu'ils relient).
• c. La couverture des chemins implique la couverture des arcs. Vrai. (Si l'on couvre tous les chemins possibles du point de départ à la fin, tous les arcs constitutifs ont été empruntés).
• d. La couverture des chemins implique la couverture des instructions. Vrai. (Par transitivité avec la règle b et c, couvrir tous les chemins garantit le passage par toutes les instructions).

Méthode

Pour aborder ce type d'examen avec succès, gardez ces trois principes en tête :

1. Vérifiez la logique par vous-même (Test à blanc) : Face à un algorithme en pseudo-code ou un graphe de flot de contrôle, déroulez le code à la main avec un brouillon. Comme vu dans l'exercice 3, la logique mathématique (ex: 0 est un nombre pair) prévaut sur les évidences trompeuses. Suivez scrupuleusement l'état des variables étape par étape.
2. Apprenez le vocabulaire exact du cours : Le génie logiciel est une discipline de définitions formelles. Si le cours parle de Couplage de composant ou de métriques LCOM/CBO, recracher la bonne définition vous assurera les points directs de récitation.
3. Tracez de bout en bout vos tests : Quand vous proposez un jeu d'essai, n'écrivez pas juste "mot = test". Expliquez brièvement quelle classe d'équivalence cela couvre et pourquoi les limites (0, 1, et 2) sont des bascules critiques pour le programme. Cela prouve au correcteur que le choix du test n'est pas le fruit du hasard.