Examen Génie Logiciel I

Questions de réflexion

Question 1 - Caractéristiques et schéma du cycle 2TUP

Le cycle 2TUP (Two-Track Unified Process) est un processus de développement logiciel qui se caractérise par une architecture en Y. Ses principales caractéristiques sont :

• Il sépare la conception en deux branches distinctes et parallèles dans un premier temps : une branche fonctionnelle (qui capture les besoins métier et modélise ce que le système doit faire) et une branche technique (qui capture les contraintes de l'architecture technique, matérielle et logicielle).
• Il fusionne ensuite ces deux branches lors de l'étape de conception préliminaire pour intégrer le modèle fonctionnel dans l'architecture technique.
• Il est itératif et incrémental, permettant de gérer les risques très tôt.

Schéma descriptif de l'enchaînement : Puisqu'il est impossible de dessiner graphiquement ici, voici l'organisation de l'architecture en Y attendue : Branche gauche (Fonctionnelle) : Capture des besoins fonctionnels -> Analyse Branche droite (Technique) : Capture des besoins techniques -> Conception générique Convergence (Centre) : Conception préliminaire -> Conception détaillée -> Codage -> Tests -> Déploiement.

Question 2 - Principe d'anticipation des changements

Le principe de "Anticipation des changements" stipule qu'un logiciel doit être conçu de manière à pouvoir évoluer facilement pour intégrer de futures modifications (évolutions métier, changements technologiques, correction d'erreurs) sans que cela ne nécessite une refonte majeure ou ne casse le système existant.

Trois recommandations pour l'application en pratique :

1. Favoriser un faible couplage et une forte cohésion : Chaque module doit avoir une responsabilité unique et interagir au minimum avec les fonctionnements internes des autres modules.
2. Utiliser des interfaces ou des classes abstraites : Programmer vers des interfaces permet de changer l'implémentation sous-jacente sans affecter le reste du code.
3. Encapsulation stricte : Cacher les détails d'implémentation (données et algorithmes) derrière des méthodes publiques bien définies.

Question 3 - Difficultés de la maintenance et rôle de l'équipe

Quatre difficultés liées au métier de l'ingénieur maintenance :

1. La compréhension du code écrit par d'autres (souvent peu ou mal documenté).
2. Le risque de régression (casser une fonctionnalité existante en en réparant une autre).
3. L'obsolescence des technologies ou la présence de dette technique complexe (code "spaghetti").
4. La difficulté de reproduire les bugs signalés par les utilisateurs en production.

Les membres de l'équipe (analyste, concepteur, testeur) peuvent-ils aider ? Oui, absolument.

• L'analyste : En rédigeant des spécifications claires, non ambiguës et traçables, ce qui permet à l'ingénieur de comprendre "pourquoi" le système fait cela.
• Le concepteur : En créant une architecture modulaire et bien documentée, facilitant la localisation des erreurs et l'ajout de fonctionnalités.
• Le testeur : En construisant une suite de tests automatisés (tests unitaires, d'intégration) qui pourra être réutilisée par l'ingénieur maintenance pour s'assurer qu'aucune régression n'est introduite (tests de non-régression).

Exercice 1 - Gestion de projet et Analyse

Question 1 - Cycles de vie pour la version de démonstration

Pour une première version de démonstration dont le but est d'acquérir rapidement des clients, les cycles de vie candidats sont :

• Le modèle de prototypage (jetable ou évolutif) : Permet de sortir rapidement une maquette visuelle et fonctionnelle pour convaincre les clients et valider les besoins du marché sans s'alourdir de développements complexes inutiles à ce stade.
• Le cycle agile (ex: Scrum) : Permet de livrer rapidement un incrément fonctionnel (MVP - Minimum Viable Product) pour recueillir les retours des premiers prospects, avec un temps de mise sur le marché très court.

Question 2 - Cycles de vie pour les versions sur mesure

Pour réutiliser les parties communes et profiter de la démo, le chef de projet a intérêt à adopter :

• Le développement à base de composants (CBSE) : Permet d'isoler les fonctionnalités de base (la démo) sous forme de composants réutilisables, et de développer uniquement les composants "sur mesure" pour chaque client.
• Le modèle incrémental / itératif : Le noyau de base constitue le premier incrément. Pour chaque client, on ajoute des incréments successifs correspondant aux extensions demandées.

Question 3 - Diagramme de contexte du système

Le diagramme de contexte définit les frontières du système et ses interactions avec les acteurs externes.

• Système central : Système de contrôle de la consommation (Le processus de niveau 0).
• Entités externes (Acteurs) et flux de données :
  • Compteurs automatisés : Fournissent les "Données de consommation en temps réel".
  • Agent responsable (manuel) : Fournit les "Données de consommation manuelles".
  • Serveur central de la chaîne : Reçoit les "Informations d'analyse et de suivi".
  • Propriétaire / Utilisateur local : Reçoit les "Rapports de consommation locale" et fournit la "Configuration (période de non-utilisation)".
  • Équipements contrôlés : Reçoivent les "Commandes d'extinction".

Question 4 - DFD 1 (Diagramme de Flux de Données de niveau 1)

Le DFD 1 détaille l'intérieur du système en processus principaux. Il comprendrait :

• Processus 1 : Collecter les mesures. Reçoit les données des compteurs automatiques et les enregistre.
• Processus 2 : Gérer les saisies manuelles. Interface pour l'agent responsable afin d'insérer les données manquantes.
• Processus 3 : Analyser et synchroniser. Lit toutes les données, génère des statistiques locales et envoie les données formatées au Serveur central.
• Processus 4 : Contrôler les équipements. Surveille la durée de non-utilisation en fonction de la configuration et envoie les commandes d'extinction aux équipements.
• Stockage de données (Data Store) : Une base de données locale "Consommations et Configurations" interfacée avec tous ces processus.

Question 5 - Besoins non fonctionnels

1. Fiabilité / Disponibilité : Le système doit pouvoir continuer à collecter des données même si la connexion au serveur central est temporairement coupée (fonctionnement en local essentiel pour le contrôle des équipements).
2. Interopérabilité : Le système doit pouvoir communiquer avec différentes marques et modèles de compteurs et d'équipements électriques, ainsi qu'avec le serveur central distant.

Question 6 - Architecture de l'application

Une architecture Client-Serveur distribuée (ou architecture n-tiers) est le style le plus approprié ici. Justification : Il y a un traitement et un stockage de données à réaliser localement dans chaque hôtel (nœud local / client riche ou serveur local), qui assure le contrôle des équipements en temps réel. Ces nœuds locaux communiquent ensuite avec un composant distant (le serveur central de la chaîne) pour consolider les analyses, ce qui correspond exactement au modèle distribué de type client (hôtels) - serveur (siège).

Exercice 2 - Tests Logiciels

Note importante : Le texte source de l'examen mentionne "Soit le programme C suivant :" mais le code a été omis dans l'extraction. Il est donc impossible de fournir les réponses spécifiques au code manquant (valeurs exactes, graphe précis). Les réponses ci-dessous détaillent la méthode exacte exigée pour ce type d'exercice.

Question 1 - Tests Boîte Noire : Classes d'équivalence

La méthode consiste à diviser le domaine d'entrée de la fonction maxsum en classes pour lesquelles le comportement est supposé identique.

• Méthode : Si le programme prend un tableau d'entiers en entrée, on définit des classes valides (ex: un tableau avec des nombres positifs, un tableau avec un mélange de positifs et négatifs) et des classes invalides (ex: un tableau vide, des valeurs non numériques si la saisie l'autorise). On choisit ensuite une valeur représentative pour chaque classe pour constituer les jeux de tests.

Question 2 - Tests aux limites

Les erreurs de programmation se trouvent souvent aux frontières des classes d'équivalence.

• Méthode : Il faut tester les bornes. Par exemple, si la taille maximale du tableau est N, il faut tester pour des tableaux de taille 0, 1, N-1, N, et N+1. Il faut également tester avec des valeurs extrêmes d'entiers (INT_MAX, INT_MIN) pour vérifier les éventuels débordements de la somme.

Question 3 - Graphe de contrôle

• Méthode : Chaque instruction séquentielle ou bloc d'instructions forme un nœud. Les structures de contrôle (if, while, for) créent des embranchements (arcs). Le graphe commence par un nœud de début et finit par un nœud de fin. Les nœuds doivent être numérotés séquentiellement pour tracer les chemins.

Question 4 - Couverture des instructions

Ce critère exige qu'au moins un jeu de test permette à chaque ligne de code d'être exécutée.

• Méthode : On identifie sur le graphe de contrôle le ou les chemins qui traversent tous les nœuds (sans forcément passer par toutes les combinaisons d'arcs). On détermine ensuite les valeurs des variables d'entrée qui forcent le programme à emprunter ce chemin.

Question 5 - Couverture des arcs

Ce critère (plus fort que le précédent) exige que chaque transition (arc) du graphe de contrôle soit empruntée au moins une fois.

• Méthode : On vérifie si les tests de la Question 4 ont forcé l'évaluation de chaque condition à VRAI et à FAUX. Si un "if" n'a jamais été évalué à FAUX (donc l'arc de contournement n'est pas couvert), on ajoute un jeu de données spécifique pour déclencher ce cas.

Question 6 - Couverture des i-chemins (2-chemins)

Ce critère vise à tester le comportement des boucles. "2-chemins" signifie qu'il faut tester le passage dans la boucle 0 fois, 1 fois, et 2 fois.

• Méthode : Identifier la boucle. Construire un jeu d'essai où la condition de boucle est d'emblée fausse (0 itération). Un autre où elle est vraie 1 seule fois, puis fausse. Et un dernier où elle est vraie 2 fois consécutives.

Question 7 - Comparaison Boîte Noire vs Boîte Blanche

• Interprétation : Les tests de la partie 1 (Boîte noire) se concentrent sur les spécifications fonctionnelles et les données, sans se soucier de l'implémentation. Ils sont bons pour vérifier ce que le système doit faire. Les tests de la partie 2 (Boîte blanche) se concentrent sur la structure interne du code. Ils garantissent que toute la logique développée est parcourue et qu'il n'y a pas de code mort ou d'effets de bord non anticipés par le développeur. Les deux approches sont complémentaires.

Exercice 3 - Conception Orientée Objet

Question 1 - Type de cohésion de la classe Carrée

La classe Carrée regroupe des fonctions mathématiques/géométriques (lireCôté, SurfaceCarrée) et des fonctions utilitaires liées à la saisie et l'affichage de l'utilisateur (lectureReel, afficheSurface). Il s'agit d'une cohésion logique ou d'une cohésion par coïncidence. Les méthodes sont vaguement liées par la logique d'un programme d'exercice géométrique en console, mais elles n'opèrent pas sur une même abstraction de données.

Question 2 - Problèmes liés à la cohésion et solution

Problèmes : La classe viole le principe de responsabilité unique (Single Responsibility Principle). Elle mélange l'interface utilisateur (saisies au clavier, affichage de messages) avec la logique métier (calcul de la surface d'un carré). Cela rend la classe difficile à réutiliser dans un autre contexte (par exemple, une interface graphique fenêtrée ne pourrait pas réutiliser la logique métier sans embarquer les méthodes de lecture console).

Solution : Il faut séparer ces responsabilités en scindant la classe en deux. Correction du code source défectueux (Mots-clés Java en majuscules corrigés, syntaxe standardisée) :

// Classe utilitaire dédiée aux interactions utilisateur
public class UtilitaireSaisie {
    public double lectureReel(String msg) { /* ... */ return 0.0; }
    public double lectureReelValidee(String msg, double borneInf, double borneSup) { /* ... */ return 0.0; }
    public double lectureReelPositif(String msg) { /* ... */ return 0.0; }
    public void afficheSurface(double surface) { /* ... */ }
}

// Classe métier dédiée uniquement à l'entité géométrique
public class Carre {
    private double cote;

    public Carre(double cote) {
        this.cote = cote;
    }

    public double calculerSurface() {
        return cote * cote;
    }
}

Question 3 - Type de couplage entre Voiture et Roue

Dans la méthode montage() de la classe Voiture, l'objet instancie directement Roue et modifie directement ses attributs publics (roue.diametre = 12.5;). Il s'agit d'un couplage de contenu (ou couplage pathologique), car la classe Voiture agit directement sur l'implémentation interne (les données) de la classe Roue.

Question 4 - Problèmes liés au couplage et solution

Problèmes : Il y a une rupture totale de l'encapsulation. Si les règles métier concernant une Roue changent (par exemple, si le poids ne peut pas être négatif, ou si les attributs doivent être renommés), il faudra obligatoirement modifier la classe Voiture. Le maintien de ce code sera difficile et source de bugs.

Solution : Utiliser l'encapsulation. La classe Roue doit cacher ses attributs (en les passant en private) et proposer un constructeur ou des méthodes d'accès (getters/setters) pour les manipuler de façon sécurisée.

class Roue {
    private double poids;
    private double diametre;

    // Le constructeur garantit que l'objet est initialisé correctement
    public Roue(double diametre, double poids) {
        this.diametre = diametre;
        this.poids = poids;
    }
}

class Voiture {
    private Roue roue;

    public void montage(){
        // Voiture utilise l'interface publique (constructeur) sans toucher à l'interne
        roue = new Roue(12.5, 19.0);
    }
}

Méthode

Pour réussir ce type d'épreuve en Génie Logiciel :

1. Identifier les concepts clés : L'examen teste la théorie classique de l'ingénierie (Cycle de vie, Architecture, Tests, Qualité objet). Chaque question cible un mot-clé précis du cours (ex: "anticipation", "cohésion", "couplage").
2. Justifier ses choix : Dans l'exercice 1, donner un nom de cycle de vie ou d'architecture ne rapporte que la moitié des points. L'essentiel réside dans le "Pourquoi ?" en s'appuyant sur les spécificités du texte (démonstration rapide, acquisition de clients, traitements décentralisés).
3. Appliquer les principes SOLID en code : En analyse orientée objet (Exercice 3), la majorité des défauts soumis aux étudiants impliquent des violations de la responsabilité unique et de l'encapsulation. Pensez toujours : "Cette classe en fait-elle trop ?" et "Les variables sont-elles protégées ?".
4. Gestion des imprévus : Comme vu dans l'Exercice 2, si un élément technique précis vous échappe ou est manquant, ne restez pas bloqué. Exposez la démarche algorithmique, expliquez la méthode de test de couverture point par point. L'examinateur évalue avant tout votre rigueur et votre raisonnement.