FICHE DE RÉVISION ULTIME - GÉNIE LOGICIEL

PARTIE 1 : CONCEPTS FONDAMENTAUX

Génie Logiciel (GL) : Discipline d'ingénierie qui applique des méthodes systématiques,
disciplinées et quantifiables pour le développement, l'exploitation et la maintenance de
logiciels de qualité. L'objectif principal est de produire des logiciels fiables, efficaces et
maintenables dans les délais et budgets impartis.

Modèle : Représentation abstraite et simplifiée d'un système ou processus qui permet de

mieux comprendre, concevoir ou prédire son comportement. Il sert de plan directeur pour la
construction du logiciel.

Base de données : Ensemble organisé et structuré de données stockées électroniquement,

accessible et gérable via un système de gestion de base de données. Elle permet la persistance,
la cohérence et le partage des informations.

Analyse : Phase du cycle de développement qui consiste à étudier et comprendre les besoins
des utilisateurs, identifier les fonctionnalités requises et définir les spécifications du système à
construire. Elle précède la conception technique.

Agrégation : Relation structurelle entre classes où une classe (le tout) contient ou est
composée d'autres classes (les parties), mais les parties peuvent exister indépendamment du
tout. Représentée par un losange vide en UML.

Composition : Relation plus forte que l'agrégation où les parties ne peuvent exister sans le
tout. La destruction du conteneur entraîne la destruction des composants. Représentée par
un losange plein en UML.

Héritage : Mécanisme de programmation orientée objet permettant à une classe fille de

récupérer automatiquement les attributs et méthodes d'une classe parent. Il favorise la
réutilisation du code et établit une relation "est-un".

Les propriétés de l'héritage incluent la spécialisation (la classe fille ajoute des caractéristiques
spécifiques), la généralisation (extraction des éléments communs dans une classe parent), le
polymorphisme (capacité d'utiliser des objets de classes différentes de manière uniforme) et
la réutilisabilité du code.

Dépendance : Relation entre classes où une classe utilise ou nécessite une autre classe pour
fonctionner correctement. Changement dans une classe peut affecter l'autre. Représentée par
une flèche pointillée en UML.

Interface : Contrat définissant un ensemble de méthodes que les classes implémentantes

doivent obligatoirement réaliser, sans spécifier comment. Elle définit le "quoi" sans le
"comment".

PARTIE 2 : PROCESSUS ET CYCLE DE VIE

Les quatre activités fondamentales du processus logiciel sont la spécification (définir ce que
le système doit faire), le développement (conception et programmation), la validation (vérifier
que le système répond aux besoins) et l'évolution (adapter le système aux changements).

Exigences fonctionnelles : Décrivent ce que le système doit faire, les services qu'il doit fournir.
Exemple : "Le système doit permettre à l'utilisateur de s'authentifier avec un identifiant et mot
de passe".

Exigences non fonctionnelles : Décrivent comment le système doit fonctionner, ses

contraintes de qualité. Exemple : "Le temps de réponse du système doit être inférieur à 2
secondes".

Architecture logicielle : Structure organisationnelle globale du système définissant les

composants principaux, leurs responsabilités et leurs interactions. Deux styles architecturaux
courants sont l'architecture en couches (séparation logique en niveaux comme présentation,
métier, données) et l'architecture client-serveur (répartition entre machines clientes et
serveurs).

Vérification et validation en GL : La vérification vérifie que le produit est construit

correctement selon les spécifications ("Est-ce qu'on construit bien le produit ?"), tandis que la
validation vérifie qu'on construit le bon produit selon les besoins réels ("Est-ce qu'on construit
le bon produit ?"). L'adage qui les résume est "Vérification = Are we building the product right?
/ Validation = Are we building the right product?"

PARTIE 3 : MODÈLES DE DÉVELOPPEMENT

Modèle en Cascade (Cycle en V) : Approche séquentielle où chaque phase doit être complétée
avant de passer à la suivante. Les phases descendent (analyse, conception, codage) puis
remontent avec les tests correspondants (tests unitaires, d'intégration, de validation).

Avantages : structure claire, documentation complète, adapté aux projets stables avec
exigences bien définies. Inconvénients : rigidité face aux changements, feedback tardif, risques
découverts tard, ne convient pas aux projets évolutifs.

Modèle itératif et incrémental : Développement par cycles successifs où chaque itération

produit une version fonctionnelle avec des fonctionnalités supplémentaires. Il est plus adapté
aux changements que le modèle en cascade car il permet d'ajuster les exigences entre les
itérations, d'obtenir des retours utilisateurs fréquents et de réduire les risques
progressivement.

Méthode Agile : Approche de développement centrée sur la flexibilité, la collaboration et la

livraison continue de valeur. Les quatre valeurs clés du Manifeste Agile sont : les individus et
interactions plus que les processus et outils, des logiciels opérationnels plus qu'une
documentation exhaustive, la collaboration avec les clients plus que la négociation
contractuelle, l'adaptation au changement plus que le suivi d'un plan.
User Stories dans les méthodes Agiles : Descriptions courtes et simples d'une fonctionnalité
du point de vue de l'utilisateur final. Elles capturent le "qui", le "quoi" et le "pourquoi". Format
courant : "En tant que [type d'utilisateur], je veux [action] afin de [bénéfice]". Exemple : "En
tant que client, je veux pouvoir réinitialiser mon mot de passe afin de retrouver l'accès à mon
compte".

Gestion de Configuration Logicielle (GCL) : Discipline gérant l'évolution et l'intégrité des

produits logiciels tout au long du cycle de vie. Elle est indispensable à la maintenance car elle
permet de suivre les versions, gérer les changements, assurer la traçabilité et garantir la
cohérence entre les différentes composantes du système.

PARTIE 4 : UML ET MODÉLISATION

UML (Unified Modeling Language) : Langage de modélisation graphique standardisé pour

visualiser, spécifier, construire et documenter les artefacts d'un système logiciel.

Deux types de diagrammes structurels : Diagramme de Classes (structure statique du système),

Diagramme d'Objets (instances à un moment donné).

Deux types de diagrammes comportementaux : Diagramme de Cas d'Utilisation (interactions

système-acteurs), Diagramme de Séquence (interactions temporelles entre objets).

DIAGRAMME DE CAS D'UTILISATION (DCU)

Rôle : Représenter les fonctionnalités du système du point de vue des utilisateurs externes. Il
montre qui utilise le système et pour quoi faire, sans entrer dans les détails techniques.

Composants principaux :

• Acteurs : Entités externes interagissant avec le système (utilisateurs, systèmes

externes, temps)

• Cas d'utilisation : Fonctionnalités ou services offerts par le système

• Relations : Include (inclusion obligatoire), Extend (extension conditionnelle)

Différence entre relations :

• "Include" : Le cas d'utilisation de base inclut systématiquement le comportement d'un

autre cas. Utilisé pour factoriser un comportement commun.

• "Extend" : Le cas d'utilisation de base peut être étendu conditionnellement par un

autre cas. Utilisé pour les variations optionnelles.

Démarche pratique avec exemple de la station-service :

1. Identifier les acteurs : Client (primaire), Ahmed le pompiste (primaire), Camion-citerne

(secondaire)
 2. Identifier les cas d'utilisation principaux : Se servir de l'essence, Servir l'essence (pour
Ahmed), Remplir les réservoirs (camion-citerne)

3. Définir les relations include si nécessaire : "Se servir de l'essence" include

"S'authentifier" (obligatoire avant de servir)

4. Définir les relations extend si applicable : Certains pompistes peuvent avoir un cas
extend "Effectuer maintenance" en plus de leurs opérations habituelles

DIAGRAMME DE CLASSES

Objectif : Représenter la structure statique du système en montrant les classes, leurs attributs,
méthodes et les relations entre elles. C'est le diagramme central de la conception orientée
objet.

Représentation de la Multiplicité (Cardinalité) : Indique combien d'instances d'une classe

peuvent être associées à une instance d'une autre classe.

• 1 : exactement un

• 0..1 : zéro ou un

o ou 0..* : zéro ou plusieurs

• 1..* : un ou plusieurs

• n..m : entre n et m

Héritage dans le diagramme : Représenté par une flèche avec un triangle vide pointant vers la
classe parent. La classe fille hérite de tous les attributs et méthodes de la classe parent et peut
en ajouter de nouveaux ou redéfinir ceux existants.

Démarche pratique avec exemple de la réservation scolaire :

Structure identifiée :

• Classe Salle avec attributs (numéro, capacité, type)

• Classe Matériel avec attributs (numéro, type, état)

• Classe Enseignant avec attributs (matricule, nom)

• Classe Étudiant avec attributs (matricule, nom, formation)

• Classe Réservation avec attributs (date, heure_début, heure_fin)

• Classe Formation avec attributs (code, nom)

• Classe Responsable héritant d'Enseignant

Relations clés :
 • Enseignant effectue Réservation (1 enseignant, 0..* réservations)

• Réservation concerne Salle (1 salle, 0..* réservations)

• Réservation peut inclure Matériel (0..* matériel, 0..* réservations)

• Formation a un Responsable (1 responsable qui est un Enseignant)

• Étudiant consulte le planning via Réservation

• Seuls les Enseignants peuvent réserver

• Le Responsable peut éditer le récapitulatif horaire pour sa Formation

MODÈLE CONCEPTUEL DE DONNÉES (MCD)

Objectif : Représenter les données du système et leurs relations de manière abstraite,

indépendamment de toute considération technique. Il sert de base pour créer la base de
données.

Composants :

• Entités : Objets du monde réel ayant une existence propre (représentées par des
rectangles)

• Propriétés : Caractéristiques des entités

• Associations : Relations entre entités (représentées par des ovales ou losanges)

• Cardinalités : Nombre minimum et maximum de participations (notation x,y où x =

minimum, y = maximum)

Démarche de construction d'un MCD :

1. Identifier les entités principales du domaine

2. Déterminer les propriétés de chaque entité (avec identifiants uniques soulignés)

3. Identifier les associations entre entités

4. Définir les cardinalités de chaque association

5. Vérifier la cohérence et éliminer les redondances

Exemple concret avec le système de gestion de stages :

Entités identifiées :

• ÉTUDIANT (matricule, nom, prénom, formation)

• ENTREPRISE (siret, nom, adresse, secteur)

• STAGE (id_stage, durée, date_début, date_fin)

 • ENSEIGNANT (matricule, nom, prénom)

• SUJET_STAGE (id_sujet, intitulé, description, rémunération)

• PROPOSITION (id_proposition, date_proposition)

• CONVENTION (id_convention, date_signature)

Associations principales :

• ÉTUDIANT contacte ENTREPRISE (cardinalités 0,N - 0,N)

• ENTREPRISE propose SUJET_STAGE (1,1 - 0,N car un sujet est proposé par une seule
entreprise)

• ÉTUDIANT effectue STAGE (1,1 - 1,1 car un étudiant fait un seul stage dans l'année)

• STAGE correspond_à SUJET_STAGE (1,1 - 0,1)

• ENSEIGNANT encadre STAGE (1,1 - 0,N)

• STAGE génère CONVENTION (1,1 - 1,1)

DICTIONNAIRE DE DONNÉES

À quoi sert un dictionnaire de données : Il recense et décrit toutes les données manipulées
par le système de manière exhaustive et précise. Il sert de référentiel commun pour toute
l'équipe de développement.

Comment identifier une donnée ou propriété : Examiner tous les documents, processus et
besoins fonctionnels pour extraire chaque information élémentaire manipulée, en éliminant
les redondances et en normalisant les noms.

Structure type d'un dictionnaire de données :

Code Désignation Type Taille Contraintes Entité

ETU_MATRIC Matricule étudiant AN 10 Unique, obligatoire ÉTUDIANT

ETU_NOM Nom étudiant A 50 Obligatoire ÉTUDIANT

STG_DUREE Durée du stage N 3 >0, ≤365 STAGE

Types courants : A (alphabétique), N (numérique), AN (alphanumérique), Date, Booléen

Démarche pour construire le MCD correspondant : Une fois le dictionnaire établi, regrouper
les données par entités cohérentes, identifier les identifiants, établir les associations logiques
entre entités et déterminer les cardinalités selon les règles métier.

PARTIE 5 : DIAGRAMMES COMPORTEMENTAUX

DIAGRAMME ÉTAT-TRANSITION

Rôle : Modéliser le comportement dynamique d'un objet en montrant ses différents états
possibles et les événements qui provoquent les transitions entre ces états.

Composants :

• États : Situations dans lesquelles l'objet peut se trouver

• Transitions : Passages d'un état à un autre déclenchés par des événements

• Événements : Actions ou conditions qui déclenchent les transitions

• Actions : Traitements exécutés lors des transitions

Distinction importante : Contrairement aux événements qui durent un instant (déclencher un

bouton), un état a une durée et représente une information instantanée qui doit être traitée
sans attente (comme le niveau d'essence dans un réservoir). Tout message dans un système
orienté objet est un événement qui implique une interaction entre deux objets.

Exemple avec le MCD Merise : Lors du passage du Modèle Conceptuel de Données au

diagramme de classes UML, l'entité est transformée en classe, l'association devient soit une
classe d'association soit un attribut de référence, et les objets sont transformés en
composition ou agrégation selon le degré de dépendance.

DIAGRAMME DE SÉQUENCE

Objectif : Représenter les interactions entre objets dans un ordre chronologique précis,
montrant comment les messages s'échangent au fil du temps.

Démarche avec exemple de l'appareil égaré :

Acteurs : Usager, Système de gestion, Base de données des appareils

Scénario principal :

1. Usager déclare appareil volé (avec IMEI)

2. Système s'authentifie auprès de l'Usager

3. Système enregistre la déclaration dans la BD

4. Usager peut vérifier en recherchant par IMEI

5. Système consulte la BD et retourne le statut

Messages représentés par des flèches horizontales entre les lignes de vie des objets, avec le
temps s'écoulant de haut en bas.

PARTIE 6 : GESTION DE STOCK ET CAS PRATIQUES

SYSTÈME DE GESTION DE STOCK MAGASIN

DCU pour le système :

Acteurs : Commerçant (acteur principal)

Cas d'utilisation :

• Éditer fiche fournisseur

• Ajouter article (include "Éditer fiche fournisseur" si nouveau fournisseur)

• Éditer inventaire

• Imprimer inventaire

• Effacer article

Relations : "Ajouter article" include "Créer fiche fournisseur" si le fournisseur n'existe pas
encore dans le système.

Diagramme de classes :

Classe FOURNISSEUR (code_fournisseur, nom, adresse, téléphone) Classe ARTICLE

(code_article, désignation, prix_unitaire, quantité_stock) Association : FOURNISSEUR fournit
ARTICLE (1,1 - 0,*)

Méthodes dans ARTICLE : ajouterStock(), retirerStock(), calculerValeur() Méthodes dans

FOURNISSEUR : ajouterArticle(), consulterArticles()

SYSTÈME DE GESTION DE ZONES INDUSTRIELLES

Analyse du domaine :

Entités principales : CLIENT, PARCELLE, FACTURE, SOCIÉTÉ, TARIF

Règles métier complexes :

• Une parcelle est identifiée par référence unique et caractérisée par superficie et valeur
locative

• Un tarif préférentiel s'applique par client et par parcelle pour une période donnée

• Tarif normal : superficie × valeur_locative × période

• Tarif préférentiel : tarif_normal × (1 - pourcentage_réduction)

• Facture établie sur une parcelle pour un client avec période donnée

• Facture caractérisée par état (payé ou non payé) et montant

• Client peut se connecter pour visualiser ses factures

• Employé chargé d'appliquer tarif préférentiel et d'éditer factures

• Amortissement préfinancé est applicable par parcelle avec période de dépréciation

DCU pour cette situation :

Acteurs : Client, Employé, Administrateur

Cas d'utilisation Client : S'authentifier, Consulter mes factures, Visualiser parcelles louées

Cas d'utilisation Employé : Appliquer tarif préférentiel, Générer facture, Éditer facture

Cas d'utilisation Administrateur : Gérer clients, Gérer parcelles, Gérer tarifs

Diagramme de classes :

Classe CLIENT (id_client, nom, entreprise, adresse, email, téléphone, login, password)

Classe PARCELLE (ref_parcelle, superficie, valeur_locative, statut)

Classe FACTURE (num_facture, montant, date_émission, état_paiement, période_début,

période_fin)

Classe SOCIÉTÉ (siret, raison_sociale, secteur)

Classe TARIF_PRÉFÉRENTIEL (id_tarif, pourcentage_réduction, date_début, date_fin)

Associations :

• CLIENT loue PARCELLE (0,* - 0,*) via association ternaire avec période

• FACTURE concerne CLIENT (1,1 - 0,*)

• FACTURE porte_sur PARCELLE (1,1 - 0,*)

• TARIF_PRÉFÉRENTIEL appliqué_à association CLIENT-PARCELLE

SYSTÈME DE BIBLIOTHÈQUE

Analyse fonctionnelle :

Acteurs : Lecteur (peut consulter, emprunter, retourner), Administrateur (gère catalogue)

Règles de gestion :

• Lecteur consulte catalogue des livres disponibles

• Lecteur emprunte livre si limite non dépassée après authentification

• Lecteur retourne livre emprunté

• Administrateur ajoute/supprime livre du catalogue

• Système peut suggérer livre à l'administrateur si introuvable lors consultation

DCU :

Cas d'utilisation Lecteur :

 • S'authentifier (include pour Emprunter)

• Consulter catalogue

• Emprunter livre

• Retourner livre

Cas d'utilisation Administrateur :

• Ajouter livre

• Supprimer livre

Extension optionnelle : Suggérer livre extend Consulter catalogue (si livre introuvable)

Diagramme de classes :

Classe LECTEUR (id_lecteur, nom, prenom, email, limite_emprunt)

Classe LIVRE (isbn, titre, auteur, éditeur, année, statut)

Classe EMPRUNT (id_emprunt, date_emprunt, date_retour_prévue, date_retour_réelle)

Classe ADMINISTRATEUR (id_admin, nom, login)

Associations :

• LECTEUR effectue EMPRUNT (1,1 - 0,*)

• EMPRUNT concerne LIVRE (1,1 - 0,1) car un livre ne peut être emprunté qu'une fois à
la fois

Méthodes :

• LECTEUR : vérifierLimite(), emprunter(), retourner()

• LIVRE : marquerEmprunté(), marquerDisponible()

• EMPRUNT : calculerRetard()

PARTIE 7 : QUALITÉ ET TESTS

Design Pattern (Patron de Conception) : Solution éprouvée et réutilisable à un problème

récurrent de conception logicielle. Il fournit un modèle de conception testé et validé. Exemple
: le pattern Singleton garantit qu'une classe n'a qu'une seule instance dans toute l'application
(utile pour les gestionnaires de configuration).

Les trois niveaux de test principaux :

Test Unitaire : Vérifie le bon fonctionnement d'une unité de code isolée (méthode, fonction,
classe). Objectif : détecter les bugs au niveau le plus fin.
Test d'Intégration : Vérifie que les différents modules fonctionnent correctement ensemble.
Objectif : détecter les problèmes d'interfaces et d'interactions.

Test Système/Validation : Vérifie que le système complet répond aux exigences spécifiées.
Objectif : valider que le produit final correspond aux attentes.

Différence entre Tests Boîte Blanche et Boîte Noire :

Tests Boîte Blanche : Testent en connaissant le code source interne, vérifient la logique et les
chemins d'exécution. Nécessitent l'accès au code.

Tests Boîte Noire : Testent sans connaître l'implémentation interne, se basent uniquement sur
les spécifications fonctionnelles. Vérifient les entrées/sorties.

Plan de Test : Document structuré décrivant la stratégie et l'organisation des tests. Il doit
contenir les objectifs des tests, le périmètre (ce qui est testé), les ressources nécessaires, le
calendrier, les cas de test détaillés, les critères d'acceptation et les responsabilités.

Qualité Logicielle : Ensemble des caractéristiques qui déterminent l'aptitude du logiciel à

satisfaire les besoins exprimés et implicites. Deux métriques clés : la fiabilité (capacité à
fonctionner sans défaillance) et la maintenabilité (facilité à modifier et corriger).

Refactoring de code : Processus d'amélioration de la structure interne du code sans modifier

son comportement externe. Objectif principal : améliorer la lisibilité, réduire la complexité,
faciliter la maintenance et éliminer la dette technique tout en préservant les fonctionnalités.

CONSEILS POUR L'EXAMEN

Pour les questions de cours : Soyez précis dans les définitions, utilisez le vocabulaire technique
approprié et illustrez avec des exemples concrets quand demandé.

Pour les DCU : Commencez toujours par identifier clairement les acteurs (qui interagit avec le
système), puis listez les fonctionnalités principales (les cas d'utilisation), et enfin établissez les
relations include/extend si nécessaire.

Pour les diagrammes de classes : Identifiez d'abord les entités/objets métier, puis leurs
attributs essentiels, ensuite les associations avec cardinalités précises, et enfin vérifiez la
cohérence de l'héritage si applicable.

Pour les MCD : Pensez toujours en termes de règles métier pour déterminer les cardinalités.
Une cardinalité 1,1 signifie participation obligatoire et unique, 0,N signifie participation
optionnelle et multiple.

Vérification systématique : Pour chaque diagramme, posez-vous la question "Est-ce que ce

modèle reflète fidèlement toutes les règles de gestion énoncées ?" et "Ai-je oublié des entités,
acteurs ou relations importantes ?"
Cette fiche couvre l'ensemble des concepts essentiels de votre cours de Génie Logiciel avec
une approche pratique orientée vers la réussite à votre examen. Bon courage pour votre
préparation.