Examen de Génie Logiciel I

Exercice 1 - Concepts de test et graphes de contrôle

Question 1 - Test statique et test dynamique

Le test statique consiste à examiner et analyser les artefacts du logiciel (code source, documents de conception, spécifications) sans exécuter le programme. L'objectif est de détecter des défauts le plus tôt possible dans le cycle de vie. Exemples de techniques : La revue de code, l'inspection formelle, l'analyse statique par outil (recherche de code mort, non-respect des conventions).

Le test dynamique implique l'exécution réelle du code avec un ensemble de données d'entrée, puis la comparaison des résultats obtenus avec les résultats attendus. Exemples de techniques : Les tests unitaires, les tests d'intégration, les tests de performance.

Question 2 - Tests boîte noire et tests boîte blanche

Les tests boîte noire (ou tests fonctionnels) se basent uniquement sur les spécifications du système. Le testeur ignore la structure interne du code et se concentre sur les entrées et les sorties. Exemples de techniques : Le partitionnement en classes d'équivalence, l'analyse des valeurs limites.

Les tests boîte blanche (ou tests structurels) utilisent la connaissance de la structure interne du code (algorithmes, conditions, boucles) pour concevoir les cas de test. Exemples de techniques : La couverture des instructions, la couverture des arcs (branches), le test des chemins de base.

Question 3 - Insuffisance de la couverture des instructions (G1 et DT1)

Le critère de couverture des instructions exige que chaque ligne de code soit exécutée au moins une fois par le jeu de test.

Considérons le code suivant :

1. lire(x)
2. si x < 0 alors
3.    x = -x
4. fin si
5. y = x - 1
6. z = 10 / y

Graphe de contrôle G1 :

• Nœuds : 1, 2, 3, 5, 6 (regroupement de 5 et 6 en un seul bloc possible, mais gardons-les séparés pour la clarté)
• Arcs : (1 vers 2), (2 vers 3) [si vrai], (2 vers 5) [si faux], (3 vers 5), (5 vers 6).

Données de test minimales DT1 : Pour couvrir toutes les instructions, il suffit de forcer le passage dans la condition si.

• DT1 : x = -2.
• Chemin parcouru : 1 → 2 → 3 → 5 → 6. (x devient 2, puis y devient 1, puis z = 10/1 = 10).

Explication : Toutes les instructions ont été exécutées avec succès, le test passe sans erreur. Pourtant, si un utilisateur saisit x = 1, le programme passe par 1 → 2 → 5 → 6 (x vaut 1, y vaut 0), ce qui provoque une division par zéro fatale à la ligne 6. Le critère de couverture des instructions est donc insuffisant, car il n'a pas détecté cette erreur latente.

Question 4 - Insuffisance de la couverture des arcs (G2 et DT2)

Le critère de couverture des arcs exige que chaque transition (vrai/faux d'une condition) soit empruntée au moins une fois.

Considérons le code suivant :

1. lire(x, y)
2. si x > 0 alors
3.    y = 10
4. sinon
5.    y = y + 5
6. fin si
7. si x < 10 alors
8.    z = 100 / y
9. fin si

Graphe de contrôle G2 :

• Nœuds : 1, 2, 3, 5, 7, 8, Fin
• Arcs : (1,2), (2,3) [Vrai], (2,5) [Faux], (3,7), (5,7), (7,8) [Vrai], (7,Fin) [Faux], (8,Fin).

Données de test minimales DT2 : Nous devons couvrir les deux branches du premier si (arcs 2-3 et 2-5) et les deux branches du second si (arcs 7-8 et 7-Fin).

• Test 1 : x = 5, y = 0. (Chemin : 1 → 2 → 3 → 7 → 8 → Fin). Couvre VRAI du 1er test et VRAI du 2e test. y devient 10, z = 100/10 = 10. Succès.
• Test 2 : x = 15, y = 5. (Chemin : 1 → 2 → 5 → 7 → Fin). Couvre FAUX du 1er test et FAUX du 2e test. y devient 10, le bloc 8 est ignoré. Succès.

Explication : Tous les arcs possibles ont été parcourus. Cependant, si nous utilisions x = -5, y = -5, le chemin emprunté serait 1 → 2 → 5 → 7 → 8. Dans ce cas, y devient 0 (-5 + 5), et l'instruction 8 provoque une division par zéro. La couverture des arcs n'a pas permis de détecter cette combinaison défectueuse.

Question 5 - Analyse du code source proposé

a) Graphe de contrôle

Numérotons d'abord les nœuds en suivant la logique séquentielle du code :

1. lire(inf, sup)
2. i := inf
3. som := 0
4. i <= sup (condition du "tant que")
5. som := som + A[i]
6. i := i + 1
7. écrire(1/som)

(Note : On peut regrouper les nœuds séquentiels 1, 2 et 3 en un seul bloc d'initialisation, ainsi que 5 et 6 en un bloc de traitement de boucle, mais la numérotation instruction par instruction est plus rigoureuse).

Graphe :

• (1) → (2) → (3) → (4)
• De (4), deux arcs partent :
  • Arc Vrai : (4) → (5) → (6) → (4)
  • Arc Faux : (4) → (7)

b) Critère de couverture des 2-chemins

Ce critère exige de tester les chemins où la boucle est répétée 0, 1, et 2 fois.

1. Boucle répétée 0 fois (condition fausse d'emblée) :

• Suite de nœuds : 1, 2, 3, 4, 7
• Données de test : inf = 2, sup = 1 (ainsi inf > sup dès le départ). Tableau A quelconque.
• Note pédagogique : L'exécution de ce test va générer une division par zéro (som valant 0). C'est le comportement réel du code ; un bon test le mettra en évidence.

2. Boucle répétée 1 fois :

• Suite de nœuds : 1, 2, 3, 4, 5, 6, 4, 7
• Données de test : inf = 1, sup = 1. Tableau A tel que A[1] = 5.
• Résultat attendu : écriture de 1/5.

3. Boucle répétée 2 fois :

• Suite de nœuds : 1, 2, 3, 4, 5, 6, 4, 5, 6, 4, 7
• Données de test : inf = 1, sup = 2. Tableau A tel que A[1] = 2 et A[2] = 3.
• Résultat attendu : écriture de 1/5 (somme = 5).

Étude de cas : Système de gestion de réunions virtuelles

Partie 1 - Conception générale

Question 1 - Cycles de vie adaptés

1. Le cycle en spirale (ou itératif orienté risques) : Cette application implique des technologies réseau en temps réel et du multimédia sur plusieurs plateformes, ce qui comporte des risques techniques élevés. La spirale permet de prototyper et de valider ces aspects complexes (faisabilité) avant de développer tout le système.
2. Le cycle itératif et incrémental (ex: méthodes Agiles/Scrum) : Les fonctionnalités peuvent être livrées par lots. Un premier incrément pourrait gérer les réunions standards, un second les réunions privées, et un troisième les réunions démocratiques. Cela permet d'avoir très tôt une application fonctionnelle.

Question 2 - Identification des acteurs

Les acteurs sont les entités externes interagissant avec le système. D'après le texte, on identifie les rôles humains suivants :

• L'Utilisateur (générique, pour la connexion et la planification)
• L'Organisateur (qui planifie, gère les accès privés, désigne l'animateur)
• L'Animateur (qui gère le déroulement de la réunion)
• Le Participant / Intervenant (qui assiste, demande la parole et intervient)

Question 3 - Besoins fonctionnels par acteur

• Utilisateur (authentifié) : S'authentifier (login/mot de passe), Planifier une réunion (nom, sujet, date, durée, ordre du jour, type), Consulter les détails d'une réunion.
• Organisateur : Modifier les détails de la réunion, Définir le groupe de personnes autorisées (pour réunion privée), Désigner l'animateur.
• Animateur : Ouvrir la réunion, Clôturer la réunion, Accorder la parole aux participants.
• Participant : Entrer dans une réunion ouverte, Sortir d'une réunion, Demander la parole, Saisir et envoyer le texte d'une intervention.

(Note : Le serveur est mentionné comme distribuant automatiquement la parole dans les réunions démocratiques, mais c'est une règle métier interne du système, pas un besoin d'un acteur externe).

Question 4 - Besoins non fonctionnels vérifiables

1. Portabilité : Le système client doit s'exécuter sans erreur de compilation ni d'affichage sur les systèmes d'exploitation Mac, Windows et Unix.
2. Performance / Temps de réponse : Les interventions textuelles doivent être transmises et affichées chez tous les participants en "temps-réel", ce qui se traduit de façon vérifiable par une latence maximale (par exemple, ≤ 500 ms après validation de l'envoi).

Question 5 - Diagramme de contexte

(Représentation textuelle des éléments à dessiner)

• Au centre : Une bulle représentant le système global "Système de Gestion de Réunions Virtuelles".
• Autour, les acteurs externes liés par des flux d'informations :
  • Utilisateur → (Fournit identifiants, Reçoit confirmation)
  • Organisateur → (Fournit paramètres de réunion, Reçoit détails mis à jour)
  • Animateur → (Envoie ordres d'ouverture/clôture/parole, Reçoit demandes de parole)
  • Participant → (Envoie demandes de parole, Envoie interventions textuelles, Reçoit flux des interventions)

Question 6 - Architecture logique

Architecture en couches (3-tiers) ou architecture MVC (Modèle-Vue-Contrôleur).

• Justification : L'application nécessite de séparer clairement l'interface utilisateur (qui variera potentiellement selon les plateformes Mac/Windows/Unix), la logique métier (gestion des tours de parole, planification) et l'accès aux données (persistance des utilisateurs et des réunions). Cette séparation garantit une bonne maintenabilité.

Question 7 - Architecture physique

Architecture Client-Serveur.

• Justification : Les utilisateurs sont distants par nature et doivent partager une session en temps réel. Un serveur centralisé traitera les connexions, maintiendra l'état des réunions et se chargera du broadcast (diffusion) des messages vers les divers postes clients (Mac, Windows, Unix) de façon asynchrone.

Partie 2 - Analyse orientée objet

Question 8 - Problèmes de couplage et de cohésion

La classe MeetingManager proposée souffre de deux graves défauts de conception :

1. Une très faible cohésion : Cette classe fait tout (c'est une "God Class" ou "classe à tout faire"). Elle mélange la gestion des règles métier (logique de réunion), l'accès direct à la base de données (connexion SQL), et la gestion de l'interface graphique (créer et afficher des écrans, messages d'erreur).
2. Un couplage très fort : La classe est fortement couplée aux technologies de l'interface graphique, à l'implémentation spécifique de la base de données (SQL) et à d'autres modules. Si on change de base de données ou si l'on modifie l'interface graphique d'une plateforme, on sera obligé de modifier cette classe métier.

Question 9 - Solution proposée

Il faut appliquer le principe de séparation des préoccupations (par exemple via le pattern MVC et des motifs DAO).

1. Créer une couche d'accès aux données (DAO) : Déplacer toute la logique de connexion SQL et de requêtes dans des classes dédiées (ex: UserDAO, MeetingDAO).
2. Créer une couche de présentation (Vues) : Confier la création et l'affichage des écrans ("écran d'accès", "message d'erreur") à des classes de l'interface utilisateur (ex: DashboardView, ErrorView).
3. Alléger le Contrôleur / Métier : Le MeetingManager ne doit conserver que la logique pure de gestion des réunions (maintenir les listes, vérifier si une réunion peut démarrer). Il fera appel aux DAO pour chercher les données et renverra l'état aux vues, sans jamais manipuler du SQL ou des fenêtres graphiques directement.

Méthode

Face à une épreuve de Génie Logiciel combinant théorie des tests et architecture système :

1. Maîtrisez les définitions fondamentales : La distinction boîte blanche / boîte noire est incontournable. Apprenez à illustrer chaque concept avec un exemple très court, comme fait aux questions 3 et 4, en prouvant par A+B qu'un jeu de test laisse passer une anomalie.
2. Dessinez mentalement l'exécution : Pour les questions de graphe de contrôle (Q5), ne fusionnez pas trop les nœuds si vous craignez de vous tromper sur les boucles. Suivre ligne par ligne (ou bloc conditionnel par bloc conditionnel) assure de ne rater aucun chemin.
3. Séparez les responsabilités (SOLID) : En conception orientée objet (Partie 2), dès que vous voyez des appels à la base de données (SQL) ou à l'interface (afficher l’écran) au sein d'une boucle métier, vous êtes en présence d'une classe "fourre-tout" à faible cohésion. La réponse attendue consistera toujours à extraire ces responsabilités dans des couches distinctes (DAO, Vues, Métier).