Examen de GL1 - Université de la Manouba

Questions de cours

Question 1 - Modèle

Un modèle est une représentation abstraite, simplifiée ou idéalisée d'une réalité, d'un système ou d'un processus. Il permet de comprendre, d'analyser, de concevoir ou de simuler le système réel en masquant les détails non pertinents pour se concentrer sur l'essentiel. Deux types de modèles :

1. Le modèle statique (ou structurel), qui décrit la structure du système (ex: diagramme de classes).
2. Le modèle dynamique (ou comportemental), qui décrit le fonctionnement et les interactions dans le temps (ex: diagramme d'état-transition ou de séquence).

Question 2 - Langage

Un langage (dans le contexte du génie logiciel) est un ensemble de symboles, de mots et de règles (syntaxe et sémantique) permettant de décrire, de modéliser ou de programmer un système de manière non ambiguë. Deux types de langages :

1. Les langages de modélisation (ex: UML - Unified Modeling Language, qui est graphique).
2. Les langages de programmation (ex: Java, C++, Python, qui sont textuels et exécutables).

Question 3 - Méthode

Une méthode est une démarche structurée, reproductible et outillée pour conduire un projet de développement logiciel de bout en bout. Elle est définie par trois composantes principales :

1. Une démarche (ou un processus) indiquant les étapes à suivre.
2. Un ou plusieurs modèles (les concepts sur lesquels on s'appuie).
3. Un ou plusieurs langages (les notations employées pour exprimer les modèles).

Question 4 - Méthode vs Modèle

La différence fondamentale réside dans leur portée. Un modèle n'est qu'une vue ou une représentation isolée d'un système à un instant donné. Une méthode est beaucoup plus vaste : elle englobe un ensemble de modèles, fournit la notation (le langage) pour les écrire, et dicte surtout le processus (l'ordre et la manière) pour les construire afin de réaliser un logiciel complet.

Question 5 - Choix multiples (QCM)

Note : La consigne indique que chaque réponse doit être justifiée.

5.1 Un processus de développement :

• a) Fixe un cadre rigoureux pour le développement de projet de taille importante. (Vrai : Il structure le travail en équipe et définit qui fait quoi et quand).
• d) Peut être itéré. (Vrai : Les processus modernes comme les méthodes agiles ou en spirale reposent sur des cycles itératifs).
• e) Peut s'appuyer sur plusieurs modèles de processus. (Vrai : On peut hybrider des approches, par exemple utiliser un modèle en V globalement mais des itérations agiles pour le codage).

5.2 C'est le rôle d'un chef de projet :

• b) De vérifier le bon déroulement des tâches. (Vrai : C'est le suivi de projet).
• c) D'organiser l'enchaînement des tâches. (Vrai : C'est la planification, souvent via un diagramme de Gantt).
• d) De fournir une visibilité globale sur un projet. (Vrai : Il est le garant du respect des délais, des coûts et du reporting).

5.3 Parmi les choix suivants, indiquez lesquels sont des principes de conception :

• b) Abstraction. (Vrai : Se concentrer sur les caractéristiques essentielles d'une entité en ignorant les détails d'implémentation).
• c) Raffinement. (Vrai : Approche top-down qui consiste à détailler progressivement une solution).
• e) Modularité. (Vrai : Découpage du système en composants indépendants et cohésifs).

5.4 Le couplage faible permet de :

• a) comprendre le fonctionnement d'une classe sans en analyser d'autres. (Vrai : La classe est autonome).
• b) modifier une classe sans affecter les autres. (Vrai : Les dépendances étant limitées, l'impact d'une modification est localisé).
• c) améliorer la maintenabilité. (Vrai : C'est la conséquence directe des points a et b).

5.5 La duplication de code :

• a) est un indicateur de mauvaise conception. (Vrai : Cela viole le principe DRY - Don't Repeat Yourself).
• b) rend la maintenance plus difficile. (Vrai : Une modification logique doit être reportée à plusieurs endroits).
• c) peut conduire à l'introduction d'erreurs lors de la maintenance. (Vrai : On risque d'oublier de modifier l'une des copies du code dupliqué).

5.6 Une bonne cohésion implique que :

• a) Une méthode doit être responsable d'une et une seule tâche bien définie. (Vrai : C'est le principe de responsabilité unique).
• c) Une classe doit représenter une seule entité bien définie. (Vrai : Toutes les méthodes et attributs de la classe concourent au même but fonctionnel).

Exercice 1 - Diagrammes de flots de données (DFD)

Note : Les réponses à cet exercice impliquent des diagrammes graphiques. Ce support étant textuel, nous fournissons la description formelle et complète des composants et des flux qui doivent apparaître sur vos dessins.

1.a) Diagramme de contexte

Ce diagramme de niveau 0 montre le système comme une boîte noire unique interagissant avec son environnement.

• Processus principal : [0] Système de gestion de location de cassettes.
• Entités externes :
  • Client : Fournit le flot "Demande d'emprunt/retour", reçoit le flot "Cassette" et "Facture/Reçu".
  • Gérant : Fournit les flots "Mise à jour catalogue" (ajout/suppression) et "Mise à jour tarifs", reçoit le flot "États de caisse".

1.b) Raffinement de niveau 1

On éclate le processus principal en sous-processus et on fait apparaître les stockages (fichiers/bases de données).

• Processus :
  • [1.1] Gestion des locations de cassettes (interagit avec le Client).
  • [1.2] Gestion du catalogue et des tarifs (interagit avec le Gérant).
  • [1.3] Gestion de la caisse (génère les états pour le Gérant).
• Stockages :
  • (D1) Fichier Clients
  • (D2) Fichier Cassettes / Catalogue
  • (D3) Fichier Tarifs
  • (D4) Journal des locations / Caisse
• Flots autour de [1.1] (Gestion des locations) :
  • Reçoit la demande du Client.
  • Lit et écrit dans (D1) Clients (pour enregistrer le client).
  • Lit dans (D2) Cassettes (pour vérifier la disponibilité).
  • Lit dans (D3) Tarifs (pour calculer le prix).
  • Écrit dans (D4) Journal des locations.

1.c) Raffinement de niveau 2 (Fonction Gestion des locations)

On détaille ici uniquement le processus [1.1].

• Sous-processus :
  • [1.1.1] Enregistrer le client (crée ou met à jour le client dans D1).
  • [1.1.2] Traiter l'emprunt (met à jour le statut de la cassette dans D2, enregistre la date dans D4).
  • [1.1.3] Traiter le retour et calculer le prix (lit la durée dans D4, le prix dans D3, calcule le total, génère la facture pour le client).

2. Architecture fonctionnelle

L'architecture fonctionnelle montre la circulation de la donnée. Le système s'articule autour de trois pôles qui s'échangent des données via des bases communes :

1. Module Catalogue : Reçoit les saisies du gérant, maintient les données de référence (Cassettes et Tarifs).
2. Module Transactions (Locations) : Cœur du système, il consomme les données du Catalogue, identifie le Client, calcule les coûts dynamiquement en fonction du temps, et génère des enregistrements de transaction (emprunts en cours, historiques de paiement).
3. Module Comptabilité : Fonctionnant de manière asynchrone (en fin de journée), il agrège les données transactionnelles pour produire un rapport synthétique (état de caisse) à destination du gérant.

Exercice 2 - Couplage et Cohésion

Question 1 - Problèmes de cohésion du code C1

Analyse du problème : Le code C1 (circonferenceCercle) souffre d'une cohésion très faible, souvent appelée cohésion logique ou séquentielle, car la méthode effectue trois tâches complètement distinctes qui n'ont pas le même niveau de responsabilité :

1. L'interaction avec l'utilisateur (saisie clavier avec validation).
2. Le traitement mathématique (le calcul de la circonférence).
3. L'affichage du résultat à l'écran.

Ces multiples responsabilités rendent le code impossible à réutiliser (par exemple, on ne peut pas utiliser ce calcul dans une interface graphique car il est lié à la console) et difficile à maintenir.

Solution proposée : Il faut appliquer le principe de responsabilité unique (une méthode = une tâche). Le code source de l'examen propose le découpage correct suivant :

// 1. Lit le rayon (positif) d’un cercle au clavier.
public static double lireRayon() {
    System.out.print("Entrer le rayon du cercle: ");
    double rayon = Keyboard.readDouble();
    while(Keyboard.error() || rayon < 0) {
        System.err.println("Mauvaise valeur de rayon.");
        System.out.print("Entrer le rayon du cercle: ");
        rayon = Keyboard.readDouble();
    }
    return rayon;
}

// 2. Calcule la circonference d’un cercle de rayon donne.
public static double circonferenceCercle(double rayon) {
    return 2 * Math.PI * rayon;
}

// 3. Affiche la circonference d’un cercle
public static void afficheCirconference(double circonference) {
    System.out.println("La circonference est " + circonference);
}

Question 2 - Problèmes de couplage du code C2

Analyse du problème : Le code C2 présente un cas typique de couplage fort (ou couplage global). Les méthodes afficheTriangle, afficheEspaces et afficheLettres dépendent toutes de variables globales définies au niveau de la classe (colonne, ligne, total). Conséquences :

• Les méthodes ne peuvent pas être réutilisées dans un autre contexte sans emporter ces variables.
• Une modification de la variable par l'une des méthodes altère le comportement de toutes les autres de manière imprévisible.
• Le flot de contrôle est caché : afficheEspaces dépend du fait que afficheTriangle ait correctement initialisé ligne et colonne au préalable.

Solution proposée : Il faut supprimer l'état global et utiliser le passage de paramètres (couplage de données, qui est le couplage le plus faible et le plus souhaitable). Note sur la réparation du code : Le code source original comportait des guillemets typographiques altérés (ex: ’a’). Nous les avons corrigés en caractères d'échappement valides en Java ('a').

public class Triangle {
    
    // Réécriture d'afficheEspaces avec paramètre
    public static void afficheEspaces(int combien) {
        int i;
        for(i = 0; i < combien; ++i) {
            System.out.print(' ');
        }
    }

    // Généralisation (factorisation) d'afficheLettres et afficheEspaces
    public static void repeteCaracteres(char c, int combien) {
        int i;
        for(i = 0; i < combien; ++i) {
            System.out.print(c);
        }
    }

    // Réécriture de la méthode principale sans état global
    public static void afficheTriangle(int nbLignes) {
        int ligne;
        for(ligne = 0; ligne < nbLignes; ++ligne) {
            repeteCaracteres(' ', ligne);
            // La logique (nbLignes - ligne) contrôle le nombre de caractères
            repeteCaracteres((char)('a' + ligne), nbLignes - ligne);
            System.out.println();
        }
    }
}

Exercice 3 - Couplage

Question 1 - Principe des différents niveaux de couplage

L'objectif en génie logiciel est de minimiser le couplage. Du pire (le plus fort) au meilleur (le plus faible) :

1. Couplage de contenu (ou pathologique) : Un module modifie ou s'appuie directement sur l'implémentation interne d'un autre module (ex: modifier une variable locale cachée ou faire un branchement direct dans le code de l'autre).
2. Couplage global (ou commun) : Plusieurs modules partagent et modifient des variables globales communes (espace mémoire partagé).
3. Couplage de contrôle : Un module passe une information (comme un drapeau booléen) à un autre module dans le but explicite de contrôler sa logique d'exécution interne (ex: un paramètre bool modeAffichage).
4. Couplage par structure de données (ou externe/par signature) : Un module passe une structure de données complexe (un objet ou un enregistrement) à un autre module, alors que ce dernier n'a besoin que d'une petite partie de ses champs.
5. Couplage de données : Le couplage idéal. Les modules ne communiquent qu'en se passant des données simples et élémentaires (types primitifs) via des paramètres de fonction, strictement nécessaires au calcul.

Question 2 - Analyse des scénarios A, B et C

Scénarios A et B : Couplage global

• Justification : Dans ces deux scénarios, les modules Menu et Imprime communiquent via les variables gEntete et gPiedDePage. Celles-ci sont déclarées globalement avec le mot-clé extern string pour être accessibles à travers tous les fichiers du projet. Ce partage d'état global sans restriction caractérise un couplage global.

Scénario C : Couplage de données

• Justification : Le concepteur a retiré les variables partagées globalement. Désormais, la fonction Imprime exige de recevoir entete et piedDePage explicitement en tant que paramètres lors de son appel. Les modules ne sont liés que par les données échangées dans la signature de la méthode, ce qui est l'approche recommandée.

Exercice 4 - Tests

Question 1 - Graphe de contrôle

Pour établir le graphe de contrôle, nous devons découper le programme en blocs d'instructions séquentiels (nœuds) et tracer les branchements conditionnels (arcs). Voici la numérotation adoptée pour la suite de l'exercice :

• Nœud 1 : lire(x); lire(y); z = 0; signe = 1; puis le test conditionnel (x < 0)
• Nœud 2 : signe = -1; x = - x
• Nœud 3 : le test conditionnel (y < 0)
• Nœud 4 : signe = - signe; y = - y
• Nœud 5 : le test de boucle (x >= y)
• Nœud 6 : x = x - y; z = z + 1 (corps de la boucle)
• Nœud 7 : z = signe * z

Les arcs (transitions) du graphe :

• 1 -> 2 (Si x < 0 est Vrai)
• 1 -> 3 (Si x < 0 est Faux)
• 2 -> 3 (Jonction inconditionnelle)
• 3 -> 4 (Si y < 0 est Vrai)
• 3 -> 5 (Si y < 0 est Faux)
• 4 -> 5 (Jonction inconditionnelle)
• 5 -> 6 (Si x >= y est Vrai - Entrée/Maintien dans la boucle)
• 6 -> 5 (Retour de boucle inconditionnel)
• 5 -> 7 (Si x >= y est Faux - Sortie de boucle)

Question 2 - Couverture des instructions

Ce critère exige que chaque ligne de code (chaque nœud du graphe) soit exécutée au moins une fois.

• Suite de nœuds : Pour passer par tous les nœuds en un seul chemin, il faut forcer l'entrée dans les deux conditions "si" et exécuter la boucle au moins une fois. Le chemin est : 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 5 -> 7.
• Jeu d'essai minimum : Il faut un x initial négatif (pour N2), un y initial négatif (pour N4), et après changement de signe, il faut que x >= y soit vrai au moins une fois pour entrer dans la boucle (N6).
  • Exemple de jeu d'essai : x = -2, y = -2
  • Trace: x devient 2, y devient 2. Le test de boucle (2 >= 2) est Vrai (passage par N6). Puis x devient 0. Le test de boucle (0 >= 2) est Faux (sortie vers N7).

Question 3 - Couverture des arcs

Ce critère (aussi appelé couverture des branches) exige que tous les arcs possibles du graphe de contrôle (les issues Vrai et Faux de chaque test) soient traversés au moins une fois. Le chemin précédent couvre les arcs Vrai des conditions, et la sortie de la boucle (qui est l'arc Faux de la boucle). Il nous manque les arcs Faux des deux conditions si.

• Suite de nœuds : Nous proposons deux chemins pour couvrir l'ensemble des arcs.
  • Chemin 1 : 1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 5 -> 7 (couvre Vrai/Vrai pour les conditions, et Vrai/Faux pour la boucle).
  • Chemin 2 : 1 -> 3 -> 5 -> 7 (couvre Faux/Faux pour les conditions, et Faux direct pour la boucle).
• Jeu d'essai minimum :
  • Test 1 : x = -2, y = -2 (pour le Chemin 1)
  • Test 2 : x = 1, y = 2 (pour le Chemin 2 : x non négatif, y non négatif, et 1 n'est pas >= 2, donc on ne rentre pas dans la boucle).

Question 4 - Couverture des 1-chemins

L'énoncé définit ce critère comme garantissant de passer sur tous les chemins possibles en répétant de 0 à i fois chaque boucle (ici i = 1). Il faut donc démontrer l'exécution de la boucle exactement 0 fois, et exactement 1 fois.

• Suite de nœuds :
  • Chemin A (boucle répétée 0 fois) : 1 -> 3 -> 5 -> 7
  • Chemin B (boucle répétée 1 fois) : 1 -> 3 -> 5 -> 6 -> 5 -> 7
• Jeu d'essai minimum :
  • Pour 0 itération : x = 1, y = 2 (x et y positifs, et x < y initialement).
  • Pour 1 itération : x = 2, y = 2 (x et y positifs. Au test initial 2 >= 2 est Vrai. La boucle s'exécute 1 fois, x devient 0. Le test suivant 0 >= 2 est Faux).

Méthode

Voici comment aborder un examen théorique et pratique de ce type en génie logiciel :

1. Sur les questions de cours : La terminologie est extrêmement précise. Une "méthode" au sens métier n'est pas juste un synonyme de "processus" ou de "modèle". Apprenez à restituer les définitions officielles en distinguant la démarche (les étapes) des modèles (les vues abstraites) et des langages (la syntaxe utilisée).
2. Sur le couplage et la cohésion : Il ne suffit pas de retenir qu'un "couplage faible et une cohésion forte" sont désirables. Vous devez être capable de diagnostiquer le problème dans un code (l'utilisation du mot clé extern, static pour des variables d'état global, ou une méthode qui fait des entrées/sorties tout en faisant du calcul). La solution consiste presque systématiquement à déléguer les responsabilités dans des méthodes distinctes et à faire circuler les informations via des paramètres formels de fonction.
3. Sur les tests en boîte blanche :
   • Commencez toujours par dessiner sur un brouillon (ou lister minutieusement) les nœuds du graphe.
   • Chaque instruction conditionnelle (si, tant que, pour) constitue un point de branchement avec au moins deux arcs sortants (Vrai et Faux).
   • Lors du choix du jeu d'essai (vos variables d'entrée), tracez manuellement votre code étape par étape en notant les valeurs successives pour être certain que la condition ciblée bascule bien comme vous le prévoyez (comme l'impact de x = - x avant l'entrée de la boucle).