Examen – Session de Rattrapage en Génie Logiciel I

Exercice 1 - Concepts fondamentaux en Génie Logiciel

Question 1 - Notion de cycle de vie d'un logiciel

CORRIGÉ : On parle de "cycle de vie" car un logiciel, à l'image d'un produit complexe ou d'un organisme, traverse plusieurs étapes chronologiques incompressibles depuis sa conception initiale jusqu'à son retrait définitif.

EXPLICATION : Un logiciel n'est pas simplement "codé". Il naît d'une expression de besoin (analyse), il est modélisé (conception), construit (développement), vérifié (tests), exploité par les utilisateurs (déploiement), maintenu pour corriger des erreurs ou ajouter des fonctionnalités (maintenance), et finit par mourir lorsqu'il devient obsolète (retrait). Formaliser ce cycle permet de structurer les équipes, d'estimer les coûts et de garantir la qualité à chaque étape.

Question 2 - Principes fondamentaux de l'architecture logicielle

CORRIGÉ : Voici trois principes fondamentaux à respecter lors de la conception architecturale :

1. La séparation des préoccupations (Separation of Concerns).
2. Le couplage faible (Low Coupling).
3. La cohésion forte (High Cohesion).

(Note : L'encapsulation, l'abstraction ou l'ouverture/fermeture sont également des réponses valides).

a) L'intérêt de chacun de ces principes

• Séparation des préoccupations : Ce principe permet de diviser un système complexe en sous-systèmes plus petits, où chaque partie a une responsabilité unique et bien délimitée. L'intérêt principal est de faciliter la compréhension, le travail en équipe et la maintenance du système.
• Couplage faible : Ce principe vise à réduire les interdépendances et les liens directs entre les différents modules. L'intérêt est de garantir qu'une modification dans un composant aura peu ou pas d'effet boule de neige sur les autres, réduisant ainsi le risque de régression.
• Cohésion forte : Ce principe s'assure que les éléments regroupés au sein d'un même module concourent tous au même but logique. L'intérêt est de rendre le composant robuste, autonome et facilement réutilisable.

b) Exemples concrets illustrant ces principes

• Séparation des préoccupations : Dans une application web, l'utilisation du patron architectural MVC sépare strictement l'interface graphique (la Vue), la logique métier (le Modèle) et le traitement des requêtes (le Contrôleur).
• Couplage faible : Deux classes communiquent entre elles via une interface abstraite plutôt que par une instanciation directe. Si l'implémentation de la base de données change (passage de MySQL à PostgreSQL), la classe qui appelle l'interface n'a pas besoin d'être modifiée.
• Cohésion forte : Une classe nommée TraitementImage contient uniquement des fonctions liées à l'image (redimensionner, appliquer_filtre, recadrer). Elle ne contiendra pas de fonction envoyer_email_rapport(), car cela violerait sa cohésion en mélangeant deux métiers différents.

Exercice 2 - Graphe de contrôle et tests structuraux

Questions 1, 2, 3 et 4 - Analyse du programme

FICHE DE COURS : SIGNALEMENT D'ERREUR D'ÉNONCÉ Le code source du programme sur lequel porte cet exercice est manquant dans l'énoncé (le document indique "Soit le programme suivant : 1/4" puis saute directement à la question 1 sur la page suivante).

Par conséquent, il est impossible de tracer le graphe de contrôle, de définir les séquences de nœuds, ni d'inventer des données de test pour la boucle while. En situation réelle, il faut explicitement écrire sur sa copie que la question est intraitables en raison d'une annexe manquante, plutôt que d'inventer un programme.

Étude de cas : Le système « CollabRecommender »

Partie 1 : Analyse et Spécification

Question 1 - Choix du cycle de vie

CORRIGÉ : Le cycle de vie itératif et incrémental (ou une méthode agile comme Scrum) est le plus adapté pour ce système.

EXPLICATION : Le cahier des charges implique l'intégration d'API externes complexes (WordNet) et des interfaces graphiques très interactives (Gephi). Ce type de projet comporte des risques ergonomiques et techniques élevés. Une approche itérative permet de construire rapidement un prototype (incrément) pour valider l'affichage du graphe et la pertinence de la recommandation sémantique auprès des chercheurs, puis d'ajuster les fonctionnalités au fil des retours utilisateurs. Le cycle en cascade serait trop rigide ici.

Question 2 - Identification des acteurs

CORRIGÉ :

• Le chercheur : Utilisateur principal du système, qu'il soit co-localisé ou distant.
• Le(la) secrétaire du laboratoire : Acteur administratif.
• Le directeur du laboratoire : Acteur mentionné explicitement pour les droits d'authentification.
• (Note : L'API WordNet peut être considérée comme un acteur secondaire non-humain dans certains formalismes UML).

Question 3 - Besoins fonctionnels par acteur

CORRIGÉ :

• Pour le chercheur :
  • Déposer une demande d'inscription (nom, sujet, mots clés, etc.).
  • S'authentifier.
  • Saisir les mots clés d'un problème et lancer une recherche de collaborateurs.
  • Visualiser le réseau social sous forme de graphe (effectuer un zoom in/out, une rotation, un déplacement).
  • Utiliser la messagerie instantanée (envoyer, répondre, ignorer ou supprimer un message textuel).
• Pour la secrétaire :
  • S'authentifier.
  • Saisir les données des demandeurs à la fin de chaque semaine.
  • Créer de nouveaux comptes.
  • Envoyer par email les coordonnées (login, mot de passe) aux chercheurs.
• Pour le directeur du laboratoire :
  • S'authentifier (avec des droits particuliers).

Question 4 - Besoins non fonctionnels et vérifiabilité

CORRIGÉ :

Besoin non fonctionnel	Description tirée du texte	Unité de mesure (Vérifiabilité)
Ergonomie / Utilisabilité	Manipulation fluide du graphe complexe généré par Gephi et affichage scindé (liste à gauche, graphe à droite).	Nombre de clics pour trouver un collaborateur (ex: ≤ 3 clics) ou temps d'apprentissage.
Performance	Le système doit calculer des distances sémantiques réelles et supporter l'échange instantané de messages.	Temps de réponse du système (ex: affichage des recommandations en ≤ 2 secondes).
Portabilité	Utilisation de Gephi qui est portable sur Linux, Windows et Mac OS. Le système final doit conserver cet avantage.	Nombre de systèmes d'exploitation supportés de manière native (minimum 3 OS).

Question 5 - Spécification fonctionnelle (Axe fonctionnel)

CORRIGÉ : L'approche fonctionnelle couplée à l'axe fonctionnel fait appel aux Diagrammes de Flux de Données (DFD) ou au formalisme SADT (Actigramme). Ne pouvant dessiner le diagramme graphique, voici sa modélisation au niveau 0 (Diagramme de contexte) :

• Processus principal : "Gérer les recommandations CollabRecommender".
• Entités externes : Chercheur, Secrétaire.
• Flux entrants : Informations d'inscription, requêtes de mots-clés, actions de navigation sur le graphe, textes des messages (venant du Chercheur) ; données saisies pour validation (venant de la Secrétaire).
• Flux sortants : Identifiants par email, liste des 10 chercheurs pertinents, affichage du graphe actualisé avec coloration des nœuds, messages instantanés reçus.

Question 6 - Spécification orientée objet (Axe fonctionnel)

CORRIGÉ : L'approche orientée objet couplée à l'axe fonctionnel fait appel au Diagramme des Cas d'Utilisation (UML). Voici sa description textuelle :

• Système : CollabRecommender.
• Acteur Secrétaire relié au cas :
  • Gérer les comptes (qui inclut Saisir les données et Envoyer les identifiants).

Acteur Chercheur relié aux cas :

• S'inscrire au système.
• Rechercher des collaborateurs (qui inclut Consulter la liste et Visualiser le graphe).
• Gérer la messagerie (qui inclut Envoyer, Répondre, Ignorer, Supprimer).

Relation d'inclusion globale (<<include>>) : Les cas d'utilisation majeurs (Gérer les comptes, Rechercher des collaborateurs, Gérer la messagerie) pointent vers un cas d'utilisation indispensable : S'authentifier. (Le Directeur y est également relié).

Partie 2 : Conception

Question 1 - Vue logique et style architectural

CORRIGÉ : En adoptant une vue logique, le meilleur style est l'architecture Modèle-Vue-Contrôleur (MVC) ou l'Architecture en Couches (N-Tiers).

EXPLICATION : L'énoncé décrit une interface utilisateur très riche nécessitant l'intégration d'une bibliothèque graphique spécifique (Gephi / Swing) et des affichages scindés (graphe à droite, liste à gauche). Séparer la logique de visualisation (la Vue) de la logique de calcul de distance sémantique via WordNet (le Modèle) est impératif pour la maintenabilité du code. MVC permet précisément d'isoler ces préoccupations logiques.

Question 2 - Vue physique et style architectural

CORRIGÉ : En adoptant une vue physique, le meilleur style est l'architecture Client-Serveur.

EXPLICATION : Le cahier des charges précise que les chercheurs sont "co-localisés ou distants" et mentionne explicitement des mécanismes de "messagerie instantanée" entre utilisateurs connectés. Cela exige physiquement un serveur centralisé pour router les messages, héberger la base de données des profils et centraliser les appels à l'API WordNet. Les machines des chercheurs joueront le rôle de clients distants se connectant à ce serveur via le réseau.

Méthode

Pour exceller dans une épreuve d'analyse et de conception en Génie Logiciel :

1. Lisez le cahier des charges de manière active : Lors de l'étude de cas, soulignez les verbes d'action (ils trahissent souvent les cas d'utilisation fonctionnels) et encadrez les noms propres ou les groupes nominaux (ils révèlent les acteurs, les entités ou les contraintes d'infrastructure).
2. Repérez les contraintes techniques imposées : Les outils exigés par le client (ici Gephi en Java/Swing et l'API WordNet) dictent vos choix architecturaux. Un bon concepteur justifie toujours son architecture physique ou logique en s'appuyant sur ces contraintes textuelles.
3. Différenciez les approches : Retenez bien le vocabulaire académique. "Axe fonctionnel + Approche fonctionnelle" appelle généralement un Modèle de Flux de Données (DFD / SADT), tandis que "Axe fonctionnel + Approche Objet" appelle invariablement un Diagramme de Cas d'Utilisation UML.
4. Soyez pragmatique face aux erreurs de l'énoncé : Si des données sont manquantes (comme le code source de l'exercice 2), ne perdez pas votre temps à tenter de les deviner. Documentez clairement l'anomalie sur votre copie et passez à la suite. La rigueur intellectuelle prime sur le remplissage.