Ch.

SAADI
Génie logiciel
GÉNIE LOGICIEL
2éme année DUT
EST-Salé
1
Pr.Chaimae SAADI
Email:chaimaesaadi900@gmail.com
VOLUME HORAIRE

Ch.SAADI
Volume
Nature
horaire
Elément 2 : Génie logiciel

Génie logiciel
Cours 20H
TD 0H
TP 20H
Autres (Travaux de
terrain, Projets, 0H
Stages, (préciser))
TOTAL 24H
Travail personnel
(préciser)
3H
Devoirs, exposés,
mini projet (*)
2
OBJECTIF DU COURS

Ch.SAADI
¢ L’objectif spécifique de « Génie Logiciel » est de former des
développeurs de haut niveau dans le domaine du

Génie logiciel
génie logiciel, capables de maîtriser les spécificités des
applications standard, mobiles et aussi les ERP sur les
différentes plateformes.

¢ L’objectif principale est d’assurer et d’améliorer la

qualité d’un produit logiciel et de fournir les méthodes et
techniques nécessaire à tout programmeur pour utiliser
ou réutiliser les applications existantes.

3
OBJECTIFS DÉTAILLER

Ch.SAADI
Génie logiciel
o A l’issu de ce cours l’étudiant aura la capacité d’opter
pour l’architecture logicielle la mieux adéquate et de
réussir la mise en œuvre d’une approche de
développement d’architecture à base de modèles à travers
les métadonnées et les transformations de modèles.

4
COMPÉTENCES SPÉCIFIQUES AU GÉNIE LOGICIEL

¢ Maitriser les techniques et les outils utilisés dans la production

industrielle des logiciels.

Ch.SAADI
¢ Connaitre les différents modèles de processus pour le
développement logiciel

Génie logiciel
¢ Maitriser Les outils d’aide à la prise de décision

¢ Développer une application selon une architecture distribuée

¢ Créer et déployer des services web

¢ Développer des applications sur des terminaux mobiles sur

différentes plates formes
5
¢ Gérer la migration d’une application entre les différentes plates
formes mobiles
PLAN DU COURS

Ch.SAADI
¢ Les Techniques et les Outils lies à une Phase des Cycles de Vie

Génie logiciel
— Les différents modèles de cycle de vie
— La spécification
— La conception
— Le codage

6
 Ch.SAADI
CHAPITRE1: INTRODUCTION AU GÉNIE
LOGICIEL

Génie logiciel
¢ Qu'est ce que ce génie logiciel
¢ Pour quoi la naissance de GL
¢ Processus du développement logiciel
¢ Cycle de vie des logiciels

7
QU’EST CE QU’UN LOGICIEL?
Système informatique

Logiciels classiques

Ch.SAADI
Propriétés statiques Propriétés
dynamiques

Génie logiciel
Les traitements prennent de plus en plus Systèmes d’Information d’Aide à la
d’importance Décision

Systèmes d’Information (BD)

Les données sont au centre du système :

orientation sujet (entrepôt) Les données sont
Les données sont au centre du système et persistantes Les systèmes procèdent de plus
persistantes en plus à des post-traitements : fouille de
données et aide à la décision
8
 Ch.SAADI
Quelles sont les qualités d’un bon logiciel ?

Génie logiciel
Qu’est-ce que le génie logiciel ?

Génie Logiciel= génie + Logiciel (Software engineering)

Quelles sont les activités fondamentales du génie logiciel?

9
QU’EST-CE QUE LE GÉNIE LOGICIEL?

Ch.SAADI
IEEE definition:
Le Génie Logiciel est l’application d’une approche
systématique, disciplinée et quantifiable au développement, à
l’exploitation et à la maintenance du logiciel. C’est-à-dire,

Génie logiciel
l’application de l’ingénierie au logiciel

D’après MC. Gaudel :

Le Génie Logiciel est l’art de spécifier, de concevoir, de réaliser
et de faire évoluer, avec des moyens et dans des délais
raisonnables, des programmes, des documentations et des
procédures de qualité en vue d’utiliser un système
informatique pour résoudre certains problèmes

10
LA CRISE DU LOGICIEL: NAISSANCE

Ch.SAADI
Constat du développement logiciel depuis la fin des années 60 :

Génie logiciel
● délais de livraison non respectés
● budgets non respectés
● ne répond pas aux besoins de l'utilisateur ou du client
● difficile à utiliser, maintenir, et faire évoluer
Q

D C
11
1969
LA CRISE DU LOGICIEL :
Étude du DoD 1995 Étude du Department of Defense des
États-Unis sur les logiciels produits dans le cadre de 9 gros

Ch.SAADI
projets militaires

Génie logiciel
des projets payés mais
jamais livrés 45%

des projets utilisés tels quel

2%
des projets livrés
Utilisés après mais jamais
modification 3% utilisés 30%

des projets Abandonnées

ou refaits 20%
12
Synthèse: 98% des projet ont échoué grâce aux bugs
BUGS

Ch.SAADI
Raisons principales des bugs :
oErreurs humaines

Génie logiciel
oTaille et complexité des logiciels
oManque de méthodes de conception
oNégligence de la phase d'analyse des besoins du client
oNégligence et manque de méthodes et d'outils des phases
de validation/vérification

13
BUGS
Exemple de Bugs :

Ch.SAADI
ØHealthcare.Gov en 2014:
vProgramme lancer par Obama (probléme de

Génie logiciel
saturation de serveur)
ØSonde Mariner 1, 1962…
vDétruite 5 minutes après son lancement; coût : $18,5
millions
vDéfaillance des commandes de guidage due à une
erreur de spécification
vErreur de transcription manuelle d'un symbole
14
mathématique dans la spécification
La crise du logiciel :
ØGL est surtout conçu pour maîtriser le développement des

Ch.SAADI
systèmes complexes

Génie logiciel
15
STANDISH GROUP, CHAOS MANIFESTO 2013 - THINK BIG, ACT SMALL, 2013
MYTHES DU LOGICIEL

Ch.SAADI
vIdée grossière du logiciel suffisante pour commencer à
programmer .

Génie logiciel
vTravail terminé quand programme écrit et fonctionnel

vFacile de gérer spécifications changeantes

vEn cas de retard, solution : ajouter des programmeurs

16
SYNTHÈSE

Pour répondre à cette crise, les chercheurs ont essayé d’appliquer

Ch.SAADI
les méthodes connues de l’ingénieur au domaine du logiciel, pour
établir des méthodes fiables sur lesquelles construire une

Génie logiciel
industrie du logiciel.

Il s’agit de se donner un cadre rigoureux pour :

Ø•Guider le développement du logiciel, de sa conception à sa
livraison;
Ø•Contrôler les coûts, évaluer les risques et respecter les délais;
Ø•Établir des critères d’évaluation de la qualité d’un logiciel.
17

PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL

PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL
Définition:

Ch.SAADI
•Le « processus de développement logiciel» désigne toutes les
étapes du développement d'un logiciel, de sa conception à sa
disparition.

Génie logiciel
•Ce découpage permet la validation du développement logiciel
(conformité du logiciel avec les besoins exprimés), et la
vérification du processus de développement (adéquation des
méthodes mises en oeuvre).

•L'origine de ce découpage provient du constat que les erreurs ont un coût

d'autant plus élevé qu'elles sont détectées tardivement dans le processus
de réalisation.

•Le Processus de développement logiciel permet de détecter les erreurs au

plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa
réalisation et les coûts associés.
18
PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL

Ch.SAADI
Le génie logiciel est une démarche d’ingénierie qui traite
tous les aspects de la production de logiciels.

Génie logiciel
Le développement comprend un ensemble d’activités:
Ø La gestion des exigences // La spécification
Ø La conception
Ø La construction
ØLa validation
ØLe déploiement
ØLa maintenance

19
PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL
Description:

Ch.SAADI
La description du processus peut aussi inclure:
ØLes produits, qui sont les résultats des sorties d’une activité

Génie logiciel
d’un processus (les livrables)

ØLes rôles, qui reflètent les responsabilités des personnes

impliquées dans le processus (ex: Scrum-Master and
Product-Owner)

ØLes pré-et post-conditions, qui sont des conditions vraies

avant et après l’activité d’un processus (ex: durée de sprint). 20
PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL

Ch.SAADI
Phase : définition des besoins

Génie logiciel
21
PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL

Ch.SAADI
Phase : Analyse des besoins / spécification

Génie logiciel
22
PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL
Phase : Planification / Gestion de projet

Ch.SAADI
Génie logiciel
23
PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL
Phase : Conception

Ch.SAADI
Génie logiciel
24
PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL
Phase : Codage et tests unitaires

Ch.SAADI
Génie logiciel
25
PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL
Phase : Intégration

Ch.SAADI
Génie logiciel
26
PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL
Phase : Qualification

Ch.SAADI
Génie logiciel
27
PROCESSUS DE DÉVELOPPEMENT DE LOGICIEL
Phase : Maintenance

Ch.SAADI
Génie logiciel
28
QU’EST CE QU’UN CYCLE DE VIE

Ch.SAADI
Génie logiciel
Ensemble séquentiel de phases, dont le nom et le nombre
sont déterminés en fonction des besoins du projet, permettant
généralement le développement d’un service ou d’un produit.

29
MODÈLE DE CYCLE DE VIE

ØModèle linéaire :

Ch.SAADI
ü Modèle en cascade
ü Modèle en V

Génie logiciel
ØModèle itératif
ü Modèle en spirale
üModèle incrémental
ØModèle avec méthode Agile
ü XP
üScrum
üCrystal
üRAD 30
ü…
 MODÈLE LINÉAIRE :

Ch.SAADI
Historiquement, la première tentative pour mettre de la rigueur

Génie logiciel
dans le ‘développement sauvage’ (coder et corriger ou ‘code and
fix’) a consisté à distinguer la phase d’analyse avant la phase
d’implémentation (séparation des questions).

31
MODÈLE EN CASCADE

Ch.SAADI
•Il a été mis au point dès 1966, puis formalisé aux alentours de
1970.

Génie logiciel
•Le modèle de la cascade défini des étapes (ou phases) durant
lesquelles les activités de développement se déroulent.

•Une étape doit se terminer à une date donnée par la

production de certains documents ou logiciels Les résultats
de l'étapes ont soumis à une étude approfondie.

•L'étape suivante n'est abordée que si les résultats sont jugés

satisfaisants.

32
 Ch.SAADI Génie logiciel
33
MODÈLE EN CASCADE
MODÈLE EN CASCADE- CARACTÉRISTIQUES

Ch.SAADI
•Hérité des méthodes classiques d'ingénierie;

Génie logiciel
•Découverte d'une erreur entraîne retour à la phase à
l'origine de l'erreur et nouvelle cascade, avec de
nouveaux documents...

•Coût de modification d'une erreur important, donc le

choix en amont cruciaux (typique d'une production
industrielle).
34
MODÈLE EN CASCADE- INCONVÉNIENTS

Ch.SAADI
Génie logiciel
•Le modèle en cascade rend coûteux le développement
itératif puisque la rédaction des documents de validation
de chaque phase demande beaucoup de travail.

•Ce modèle est inadapté au développement de systèmes dont

la spécification est difficile à formuler a priori.

35
 Ch.SAADI Génie logiciel
36
MODÈLE EN V
MODÈLE EN V

Ch.SAADI
•Modèle de cascade amélioré dans lequel le développement des
tests et du logiciels sont effectués de manière synchrone.

Génie logiciel
•Le principe de ce modèle est qu’avec toute décomposition doit
être décrite la recomposition et que toute description d’un
composant est accompagnée de tests qui permettront de
s’assurer qu’il correspond à sa description.

•Problème de vérification trop tardive du bon

fonctionnement du système. 37
MODÈLE EN V - NIVEAU DE TEST
•Test unitaire : test de chaque unité de programme
(méthode, classe, composant), indépendamment du reste du

Ch.SAADI
système

Génie logiciel
•Test d'intégration : test des interactions entre
composants (interfaces et composants compatibles).

•Test d'acceptation et système : test du système complet par

rapport à son cahier des charges.

•Recette : faite par le client, validation par rapport aux

besoins initiaux (tests, validation des documents, conformité 38

aux normes...).
MODÈLE EN V

Ch.SAADI
Objectifs :
•Validations intermédiaires pour prévenir les erreurs tardives;

Génie logiciel
meilleure planification et gestion.

Principes
•Validation à chaque étape;
•Préparation des protocoles de validation finaux à chaque étape
descendante;
•Validation finale montante et confirmation de la validation
descendante; 39
MODÈLE EN V

Conséquences :

Ch.SAADI
•Obligation de concevoir les jeux de test et leurs résultats;
•Réflexion et retour sur la description en cours;

Génie logiciel
•Meilleure préparation de la branche droite du V.

Les activités de chaque phase peuvent être réparties en 5

catégories
•Assurance qualité;
•Production;
•Contrôle technique;
•Gestion; 40

•Contrôle de qualité.
INTÉRÊT DU MODÈLE EN V

Ch.SAADI
Validations intermédiaires

Génie logiciel
•Bon suivi du projet : avancement éclairé et limitation des risques
en cascade d’erreurs
•Favorise la décomposition fonctionnelle de l’activité
•Génération de documents et outils supports

Modèle très utilisé et éprouvé

41
MODÈLE EN V - LIMITATIONS

Ch.SAADI
Un modèle séquentiel (linéaire)

Génie logiciel
•Manque d’adaptabilité
•Maintenance non intégrée : logiciels à vocation temporaire
•Validations intermédiaires non formelles : aucune garantie sur
la non transmission d’erreurs
•Problème de vérification trop tardive du bon fonctionnement du
système

42
Ch.SAADI Génie logiciel
43
MODÈLES ITÉRATIFS:
 MODÈLE EN SPIRALE (B. BOËHM )

Ch.SAADI
- met l'accent sur l’évaluation des risques; à chaque étape:

Génie logiciel
•On n’a pas la possibilité de retourner en arrière.

•Le nombre de cycles est variable selon que le

développement est classique ou incrémental.

44
 Ch.SAADI Génie logiciel
45
MODÈLE EN SPIRALE
 Ch.SAADI Génie logiciel
46
MODÈLE EN SPIRALE
MODÈLE EN SPIRALE-LIMITATION

Ch.SAADI
-Calendrier et budget irréalistes

-Développement de fonction inapproprié

Génie logiciel
-Problème de performance a besoin de compétences dans
l'évaluation approfondie des incertitudes et des risques
associés au projet et leur réduction.
-

47
MODÈLE EN SPIRALE-LIMITATION

Ch.SAADI
Génie logiciel
48
MODÈLE INCRÉMENTAL
le modèle incrémental a été proposé dans les années 80.

Ch.SAADI
Génie logiciel
Ø Le produit est délivré en plusieurs fois, de manière
incrémentale, c’est-à-dire en le complétant au fur et à mesure et
en profitant de l’expérimentation opérationnelle des incréments
précédents 49
MODÈLE INCRÉMENTAL

Ch.SAADI
- Le développement est réaliser par suite d’incréments ou
composantes, qui correspondent à des parties des
spécification, et qui viennent intégrer le noyau de logiciel.

Génie logiciel
- L’objectif est d’assurer la meilleur adéquation aux
besoins possibles.

- Le choix d’incrément est un compromis entre la durée de

développement et le niveau de prise en compte des
spécification.

50
MODÈLE INCRÉMENTAL

Ch.SAADI
•Hiérarchiser les besoins du client;
•Concevoir
et livrer au client un produit implantant un sous
ensemble de fonctionnalités par ordre de priorité.

Génie logiciel
51
MODÈLE INCRÉMENTAL- AVANTAGES

Ch.SAADI
Le système peut être mis en production plus rapidement,

Génie logiciel
-
avec la diffusion ensuite sous forme de version

- Les premiers incréments permettent de renforcer

l’expression de besoin et autorisent la définition des
incrément suivant.

52
MODÈLE INCRÉMENTAL- RISQUES

Ch.SAADI
-Les noyaux, les incréments ainsi que leurs interactions
doivent être spécifiés globalement, au début du projet;

Génie logiciel
-

-Les incréments doivent être aussi indépendants que

possibles.
-

53
SYNTHÈSE

Ch.SAADI
Il n’y a pas de modèle idéal car tout dépend des circonstances.

Le modèle en cascade ou en V est risqué pour les

Génie logiciel
développements innovants car les spécifications et la
conception risquent d’être inadéquats et souvent remis en cause.

Le modèle incrémental est risqué car il ne donne pas beaucoup

de visibilité sur le processus complet.

Souvent, un même projet peut mêler différentes approches,

comme le prototypage pour les sous-systèmes à haut risque et la
cascade pour les sous systèmes bien connus et à faible risque.

54
 Ch.SAADI
Génie logiciel
MODÈLE AVEC MÉTHODE AGILE

55
MÉTHODES AGILE (NAISSANCE)

Ch.SAADI
Þ réduire le cycle de développement des projets
informatiques
Þ répondre plus rapidement aux évolutions des

Génie logiciel
demandes de l’utilisateur final.

l intégrer au cours du projet de manière continue le client final

l Gérer les projets informatiques de manière adaptative et
incrémentale.

56
VALEURS DES MÉTHODES AGILES

Ch.SAADI
¢ Des logiciels opérationnels plus qu’une documentation
exhaustive

Génie logiciel
¢ La collaboration entre les développeurs et les clients plus
que la négociation contractuelle

¢ L’adaptation au changement plus que le suivi d’un

planning

57
CARACTÉRISTIQUES DES MÉTHODES
AGILES

Ch.SAADI
¢ Le développement est centré sur le code.

Génie logiciel
¢ Il s'agit de produire rapidement des prototypes exécutables.

¢ Orientées client plutôt que processus

¢ Moins orientés documentation

¢ Méthodes adaptatives
Processus auto-adaptatif : révision du processus à chaque
itération 58
MÉTHODE AGILE

Ch.SAADI
¢ Les méthodes agiles utilisent un principe
de développement itératif => Ces itérations sont en fait

Génie logiciel
des mini-projets définis avec le client en détaillant les
différentes fonctionnalités qui seront développées en
fonction de leur priorité.

¢ Le chef de projet établi alors un macroplanning

correspondant aux tâches nécessaires pour le
développement de ces fonctionnalités.

59
MÉTHODES AGILES

Ch.SAADI
Plusieurs méthodes de type agiles existent
On peut citer :

Génie logiciel
¢ XP (Extreme programming)
¢ Scrum
¢ Crystal
¢ RAD (rapid application development)
¢ ….

60
PROCESSUS DE DÉVELOPPEMENT SCRUM

Ch.SAADI
¢ Développée en 1996, par J.Sutherland et K.Schwaber

Cette méthode de gestion, ou plutôt ce Framework de

Génie logiciel
¢
management de projet, à pour objectif d’améliorer la
productivité de son équipe.

¢ Concentrer l’équipe, de manière itérative, sur un ensemble

de fonctionnalités à réaliser

Durée des itérations

-SCRUM suggère un mois

61
RÔLE : DIRECTEUR DU PRODUIT

Ch.SAADI
Représentant des clients et des utilisateurs

Définit l’ordre de développement des fonctionnalités

Génie logiciel
¢

¢ Décide sur les orientations importantes du projet

¢ choisit la date et le contenu de la release

¢ accepte et rejette les résultats

Product owner 62
ROLE: SCRUM MASTER

Ch.SAADI
Représente le management de projet:

Veille à résoudre les problèmes non techniques

Génie logiciel
¢

¢ Veille à l’application des valeurs de Scrum

¢ Il est garant du cadre méthodologique Scrum
¢ Il est un coach, et non un supérieur
¢ Des compétences humaines indispensables
¢ L’analogie avec le maître du jeu

Scrum Master
63
ROLE : EQUIPE

Ch.SAADI
¢ Se composent de 5 à 10 personnes

Génie logiciel
¢ Auto-gérée

¢ regroupent tous les rôles: architecte, concepteur, analyste,

développeur, testeur

¢ Décisions prises ensemble

¢ se concentrent sur un sprint à la fois (sprint courant)

64
SCRUM- ITÉRATIONS (Sprint)

Ch.SAADI
Le cycle de vie Scrum est rythmé par des itérations de
quelques semaines.

Génie logiciel
¢ Une itération, appelée Sprint, dure 30 jours (2 à 4
semaines)

¢ Chaque Sprint a un but à atteindre

¢ Un Sprint aboutit sur la livraison d’un produit partiel

fonctionnel

¢ La participation du client est déterminante pour le choix

des priorités dans les fonctionnalités du logiciel 65
RÉFÉRENTIEL DES EXIGENCES : LE PRODUCT
BACKLOG

Ch.SAADI
ØLe référentiel des exigences initiales est dressé et
hiérarchisé avec le client.

Génie logiciel
ØIl constitue ce que l’on nomme le product backlog.

ØIl ne doit pas nécessairement contenir toutes les

fonctionnalités attendues dès le début du projet,

Øil va évoluer durant le projet en parallèle des besoins du client.

66
USER STORY

Ch.SAADI
Les fonctionnalités décrites portent le nom de User Stories et sont
décrites en employant la terminologie utilisée par le client.

Génie logiciel
Une User Story ou Story contient généralement les informations
suivantes :

1. ID – un identifiant unique

2. Nom – un nom court (entre 2 et 10 mots), descriptif de la

fonctionnalité attendue par le client.

3. Importance – un entier qui fixe la priorité des Stories. La

priorité d’une story peut être changée en cours de réalisation du
projet.
67
USER STORY

Ch.SAADI
4. Estimation – La quantité de travail nécessaire pour
développer, tester, et valider cette fonctionnalité. L’unité de
mesure peut être un nombre de jours idéaux (jours à 100%

Génie logiciel
dédiés à la fonctionnalité) ou un nombre de points. Les
estimations se font en relatif en comparant les estimations des
stories terminées avec la story à estimer.

5. Demo – Un test relativement simple (ex : exporter un objet en

XML puis l’effacer de la base, l’importer depuis le XML, à la fin
l’objet doit être dans la base). Ce test constitue un test de
validation.

6. Notes – toute autre information : clarifications, références

documentaires… 68
PLANNIFICATON

Ch.SAADI
Planification à trois niveaux :

Génie logiciel
¢ Sprint : itération de 30 jours

¢ Release/projet : regroupement d’itérations

¢ Quotidien : réunion (srcum) de mise au point

69
 Ch.SAADI Génie logiciel
70
SCRUM BOARD
AN EXAMPLE OF A SPRINT BACKLOG

Ch.SAADI
Génie logiciel
71
 Ch.SAADI Génie logiciel
72
SCRUM PROCESS
OUTILS POUR SCRUM

Ch.SAADI
Outils libres :
¢ IceScrum (open source)

Génie logiciel
Outils propriétaires :
¢ ScrumWorks

73
METHODE XP

Ch.SAADI
eXtreme Programming (XP) Apparaît en 1999 par
Ken Beck de Chrysler .

Génie logiciel
Nouvelle approche de développement incrémental basée
sur la réalisation rapide, en équipe, d’incréments fonctionnels.

Caractéristiques :

•Emphase sur la satisfaction du client

Øle produit dont il a besoin

Ødes livraisons aux moments où il en a besoin
Øun processus robuste si les exigences sont modifiées

•Emphase sur le travail d'équipe 74

Ømanagers, clients, développeurs : ensemble
VALEURS DE L’EXTREME PROGRAMMING (XP)

Ch.SAADI
Communication: Au sein de l’équipe de développeurs et avec le

Génie logiciel
client

Feedback : Itérations rapides permettant la réactivité, test du

code dès le début

Simplicité : Code simple livrable ne contenant que les

exigences du client avec un design propre et simple

75
PRATIQUE DE L’EXTREME PROGRAMMING (EQUIPE)

Ch.SAADI
Responsabilité collective du code : polyvalence des
développeurs, contribution collective aux nouvelles
fonctionnalités, à la correction de bugs et à la restructurations

Génie logiciel
(pas de droits exclusifs);

Programmation en binôme : partage des compétence,

prévention des erreurs, motivation mutuelle;

Langage commun \ Métaphore : Les mots utilisés pour

désigner les entités techniques doivent être choisis parmi les
métaphores du domaine de projet;

Rythme durable : maintenir un niveau optimal de travail entre

énergie nécessaire pour le développement et le repos réparateur.
76
PRATIQUE DE L’EXTREME PROGRAMMING
(CODE)

Ch.SAADI
Refactoring : Investissement pour le futur, réduction de la
dette technique;

Génie logiciel
Conception simple : facilité des reprises du code, facilité de
l’ajout de fonctionnalité;

Tests unitaires: Test en premier pour une programmation

ultérieure plus facile et plus rapide, fixe la spécification
(ambiguïtés) avant le codage, feedback immédiat lors du
développement, itération du processus pour tout tester;

Intégration continue : Ajout de valeurs chaque jour, évite la

divergences, efforts fragmentés et permet la diffusion rapide
pour la réutilisation;
77
Règles de codage : cohérence globale, code lisible / modifiable
par toute l'équipe.
PRATIQUE DE L’EXTREME PROGRAMMING
(PROJET)

Ch.SAADI
Client sur site : orienter le développement en fonction des
réactions des usagers et des points critiques du domaine

Génie logiciel
d’utilisation

Tests d’acceptation : conformité par rapport aux attentes du

client

Planification itérative et livraison fréquente : Les fiches

sont rédigés tout au long du projet, chaque fiche correspond à une
fonctionnalité (scénario) où figure la description du scénario,
l’ordre de priorité, la durée de réalisation, les noms des
développeurs…

78
LE CYCLE STANDARD XP

Ch.SAADI
v1. Le client écrit ses besoins sous forme de scénario

v2. Les développeurs évaluent le coût de chaque scénario, si le

Génie logiciel
coût est trop élevé pour un scénario ou difficile à estimer, le
client le découpe en plusieurs scénario et les soumet aux
développeurs

v3. Le client choisi, en accord avec les développeur, les

scénario à intégrer à la prochaine livraison

v4. Chaque binôme des développeurs prend la responsabilité

d’une tâche

79
LE CYCLE STANDARD XP

Ch.SAADI
v5. Le binôme écrit les tests unitaires correspondant au
scénario à implémenter

Génie logiciel
v6. Le binôme procède à l’implémentation du programme

v7. Le binôme réorganise le code (refactoring)

v8. Le binôme intègre ses développement à la version

d’intégration, en s’assurant que tous les tests de non
régression passent

80
CRYSTAL

Ch.SAADI
Génie logiciel
Cette méthode a été mise au point par Alistair
Cockburn(signataire du Manifeste) en 1997.

ØPlusieurs principes doivent être partagés par l’ensemble de

l’équipe

81
PRINCIPE DE CRYSTAL

Ch.SAADI
v La communication et la collaboration entre les membres de
l’équipe est omniprésente

Génie logiciel
v Le nombre de membres de l’équipe ne peut pas dépasser 6
personnes

v Toute l’équipe doit travailler dans la même pièce

v Les diagrammes de modélisation doivent être élaborés en

groupe et sur tableau blanc

v Livrer fréquemment des parties exécutables

82
CARACTÉRISTIQUES DE CRYTSAL

Ch.SAADI
Ses caractéristiques principales sont :

Ø Une collaboration étroite entre toutes les parties

prenantes, y compris en dehors de l’équipe (stakeholders)

Génie logiciel
Ø Une bonne communication interpersonnelle

Ø Focus sur l’objectif et disponibilité

Ø Un contact permanent avec les utilisateurs

Ø Une réflexion constante sur ces propriétés

83
CARACTÉRISTIQUES DE CRYTSAL

Ch.SAADI
Ø La spécialisation consiste à observer les utilisateurs dans leur
travail pour mieux connaître leurs besoins

Génie logiciel
Ø Classer par priorité les différents cas d'utilisation.

Ø Elaboration d’une ébauche de conception impliquant les outils

à utiliser.

ØDéveloppement des itérations (d'une longueur de 2 à 3 mois)

84
MÉTHODES CLASSIQUES VS AGILES

Ch.SAADI
Les méthodes classique (prédictives) tentent de
réduire l'incertitude dès le début du projet par une
planification très précise et très détaillée. Cette levée de

Génie logiciel
risque implique que les exigences de l'application soient figées.

Les méthodes Agiles (adaptables) préfèrent, partant

d'une planification initiale, réévaluée régulièrement,
s'adapter aux évolutions du contexte.

=> La réévaluation servira de base à une prise de décision de

type GO ou NO GO à chaque grand changement appliqué au
projet initial.

85
RÉCAPITULATIF MÉTHODE AGILES

Ch.SAADI
Les méthodes agiles seront plus utilisées pour les gros

Génie logiciel
¢
projets car elles offrent une meilleure adaptabilité,
visibilité et gestion des risques.

¢ Elles pourraient tout aussi bien être utilisées pour les

projets où il n’y pas de documentations détaillées

86
RÉCAPITULATIF MÉTHODES CLASSIQUES

Ch.SAADI
¢ Les méthodes classiques seront plus utilisées si vous avez
une idée très précise de votre projet avec un cahier des

Génie logiciel
charges et planning très détaillé où vous avez anticipé
tous les risques possibles.

¢ Le chef de projet se retrouve souvent seul face à lui-même

lors de la prise de décision, de gérer les retours client, devant
l’incertitude afin de satisfaire le client tout en respectant les
3C.

87
Ch.SAADI Génie logiciel
88
 Ch.SAADI
Génie logiciel
CHAPITRE 2: LA SPÉCIFICATION

89
 SPÉCIFIER….?

Ch.SAADI
Préciser
Exprimer

Génie logiciel
Objectif : comprendre les besoins du clients
Définir
Déterminer
Établir une description claire de ce que doit faire le
Indiquer logiciel (fonctionnalités détaillées, exigences de qualité,
interface...)

90
EXIGENCE VS BESOIN

Ch.SAADI
¢ Besoin èobjectif a atteindre

Génie logiciel
¢ Exigenceè comment satisfaire le besoin de ce
client!!!

¢ Exemple:
— Besoin d’application :sécurité
— Se mettre d’accord sue le type de sécurité : Exigence
(doit apparaitre dans le CDC)

91
SPÉCIFICATION

Ch.SAADI
Déterminer ce que doit faire le système (côté client)

= > Document précis spécifiant les fonctionnalités attendues;

Génie logiciel
Exemple : définition de la frontière du système, description des
fonctionnalités du système, interactions…

À noter : Les spécifications ne sont jamais complètes ni

définitives.

92
L’INGÉNIERIE DES EXIGENCES

Ch.SAADI
Définition :

Génie logiciel
« L’ingénierie de exigences est la branche du génie logiciel qui
concerne les buts réels, les fonctions et les contraintes d’un
système logiciel. Elle concerne aussi la relation que ces facteurs
entretiennent avec les spécifications précises du comportement
logiciel, et avec leur évolution dans le temps et à travers les
familles de logiciels. » Zave 1997

93
L’INGÉNIERIE DES EXIGENCES

Ch.SAADI
La gestion des exigences est une activité méthodique
pluridisciplinaire qui permet:
§ Recueillir, spécifier, affiner et qualifier les exigences d'un

Génie logiciel
système dans son environnement,
§ Définir l'engagement "à faire",
§ Maîtriser les changements de ces exigences dans le temps.

èC’est un ensemble de techniques, consistant à recueillir les

besoins, à les transformer en exigences, et à les spécifier dans
un cahier des charges.

Ø Objectif: la rédaction du CDC selon des étapes précises.

94
LOGICIEL : CARACTÉRISTIQUES

Ch.SAADI
Spécification fonctionnelle :

•Fonctionnalités du logiciel, réponse aux besoins des utilisateurs.

Génie logiciel
Spécification non fonctionnelle :

•Facilité d'utilisation : prise en main et robustesse

•Performance : temps de réponse, débit, fluidité...
•Fiabilité : tolérance aux pannes
•Sécurité : intégrité des données et protection des accès
•Maintenabilité : facilité à corriger et à faire évoluer le logiciel
•Portabilité : adaptabilité à d'autres environnements matériels
ou logiciels
95
SPÉCIFICATION : TYPES DES EXIGENCES

Ch.SAADI
Exigences fonctionnelles
Exemple: ajouter/modifier/supprimer

Génie logiciel
Exigences non-fonctionnelles
Des cas opérationnels exprimer d’une manière
fonctionnelle (norme ISO 9126 / norme ISO 25019 ’version 2011’)

Contraintes
Obligation du client en relation avec: budget, délai,
technologie, modèle,…
96
TYPES DES EXIGENCES : EXERCICE

Ch.SAADI
Identifier le type des exigences suivantes :
- le système doit utiliser des mots de passe

Génie logiciel
- le système doit se déconnecter automatiquement après
2 mn sans utilisation
-Le projet permet d’aider ceux qui souffrent d’Alzheimer.
- système ne peut fonctionner que sur une plate-forme
mobile smartphone avec un système d'exploitation
Android.
- Le système doit permettre un accès direct et précis aux
contacts en cas d’urgence.

97
TYPES DES EXIGENCES : EXERCICE

Ch.SAADI
-Le système doit fournir une interface pour la recherche.

Génie logiciel
-la recherche doit être effectuée dans un délai de 3s.

- Le système doit présenter des objets fréquemment

utilisés.

-La plate-forme mobile doit disposer des ressources

environnementales nécessaires pour faire fonctionner le
système.
98
ELICITATION : RECUEIL DES BESOINS

Ch.SAADI
Les méthodologies de collection de besoins et exigences (non
formelles) :

Génie logiciel
- effectuées en individuel (analyse documentaire,
observation, etc.)

- en groupe (questionnaire, mind-mapping, méthode des

post-it, interviews, storyboards, sondage/questionnaire etc.)

- brainstorming, étude de la documentation existante

(recherche interne), groupes de discussion.
99
ELICITATION : RECUEIL DES BESOINS

Ch.SAADI
Par le biais des méthodes formelles :

Génie logiciel
Ø Utilisation du bachmarking: étude des projets similaires

Ø Utilisation des ontologies des graphes, KAOS, SIG

Ø Utilisation des freamwork : NFR Framework

100
ELICITATION : RECUEIL DES BESOINS

Ch.SAADI
- NFR Framework
Types de Relation : AND OR

Génie logiciel
101
QUELS SONT LES PROBLÈMES LIÉS À CES EXIGENCES?
Exemple de fausse rédaction d’exigence?

Ch.SAADI
§ La régulation sera efficace dans tous les cas.
§ Toutes les informations inutiles ne sont pas affichées.
§ L’interface est simple d’utilisation.

Génie logiciel
§ Les données sont sauvegardées autant que possible.
§ L’application n’a pas de bugs.
§ « Le logiciel calcule la vitesse du missile et sa trajectoire,
en 5 secondes maximum » ….a un sens différent de:
« Le logiciel calcule la vitesse du missile, et sa trajectoire en
5 secondes maximum »

èL’exigence doit être :compréhensible claire et interpréter

102
d’une seul manière par plusieurs lecteur
COMMENT RÉDIGER UN CAHIER DES CHARGES ?
Exemple de Volere

Ch.SAADI
Génie logiciel
103
COMMENT RÉDIGER UN CAHIER DES CHARGES ?

La norme IEEE 830

Ch.SAADI
Génie logiciel
104
 Ch.SAADI
CHAPITRE 3:CONCEPTION

Génie logiciel
RAPPEL MERISE
RAPPEL MODÉLISATION OBJET
RAPPEL UML
LES PRINCIPES FONDAMENTAUX EN GL

105
MERISE (RAPPEL)

Ch.SAADI
¢ Les modèles de la méthode Merise :

Génie logiciel
¢ Le modèle de flux
¢ Le modèle conceptuel de données

¢ Le modèle conceptuel de traitements

¢ Le modèle organisationnel de traitements

¢ Le modèle logique de données

¢ Le modèle opérationnel des traitements

¢ Le modèle physique des données

106
POURQUOI L’ORIENTÉ OBJET?

Ch.SAADI
une liste de ‘concepts ’(water, salt water ...) a été donné aux élèves
de primaires.
Résultat => (Harry) a construit un schéma conceptuel

Génie logiciel
Etude [Martin & Odell] [Novak, 1984, Cambridge University Press]
107
MODELISATION OBJET (RAPPEL)
Principaux concepts objet :

Ch.SAADI
¢ Classe
— Type d’objet caractérisé par sa structure de données
(attributs) et son comportement (méthodes)

Génie logiciel
¢ Objet
— Un objet représente un individu, une entité identifiable
réelle ou conceptuelle avec un rôle bien défini dans le
domaine du problème ou dans un système (instance de
classe)

¢ Attribut
— Un attribut est une propriété, une caractéristique, une
qualité inhérente ou distinctive d’un objet (exemples : la 108
couleur ou l’immatriculation d’une voiture)
¢ Méthode

Ch.SAADI
— Une méthode est une action qu’un objet effectue de sa
propre initiative ou à la demande (réaction à un
événement ou à un envoi de message). Ces méthodes

Génie logiciel
décrivent les propriétés dynamiques d’un objet.

¢ Quelques méthodes "classiques" :

— Un constructeur est une méthode qui permet de
construire et d’initialiser un objet (instanciation d’un
objet)

— Par opposition, un destructeur est une méthode qui

permet de détruire un objet instancié

109
— Un accesseur est une méthode qui permet de récupérer la
valeur d’un attribut d’un objet (get… et is…)

Ch.SAADI
— Un modificateur est une méthode qui permet de modifier
la valeur d’un attribut d’un objet (set…)

Génie logiciel
— Un observateur est une méthode qui permet de retrouver
des informations sur l’histoire (l’état) d’un objet

— Un itérateur est une méthode qui permet d’appliquer à

chaque partie d’un objet (par exemple dans le cas d’un objet
de type collection) une action déterminée

110
¢ Association
— Une association permet de préciser une relation entre
différents objets. Une association possède généralement un

Ch.SAADI
nom qui sert à décrire la nature de la relation
— Une association est également caractérisée par le nombre
d’objets pouvant être reliés par l’intermédiaire d’une instance

Génie logiciel
d’association : 0..1, 0..n, 1..n, n..n
¢ Agrégation
— Une agrégation est une relation binaire entre deux objets
qui spécifie une inclusion entre une partie et un tout. Une
partie peut appartenir à d’autres agrégations et exister
indépendamment
¢ Composition
— Une composition est un type particulier d’agrégation qui
spécifie une inclusion entre une partie et un tout plus forte
que l’agrégation : quand on supprime l’élément composite, il
y a obligatoirement suppression des composants 111
¢ Héritage
— Mécanisme permettant à une classe d’objets de

Ch.SAADI
bénéficier de la structure de données et du
comportement d’une classe "mère", tout en lui
permettant de les affiner et ce, afin de prendre en compte les
spécificités de la classe "fille", sans avoir cependant à

Génie logiciel
redéfinir ce que les deux classes ont de commun

¢ Généralisation
— Dans le cas d’un héritage, on dit qu’une classe "mère" est
une généralisation des propriétés de ses classes "fille"

¢ Spécialisation
— Dans le cas d’un héritage, on dit qu’une classe "fille" est
une spécialisation des propriétés de sa classe "mère"
112
¢ Encapsulation (interface)
— Mécanisme permettant de dissimuler les détails du

Ch.SAADI
fonctionnement interne d’une classe aux autres classes

¢ Abstraction (classe abstraite)

Génie logiciel
— Mécanisme permettant la dissociation entre la
déclaration d’une classe et son implémentation (interface)

¢ Polymorphisme
— Mécanisme permettant d’associer à un comportement, une
implémentation différente en fonction de l’objet auquel on
se réfère (par exemple : dessiner à l’écran un carré ou un
cercle). L’émetteur n’a pas besoin de connaître la classe
du receveur, seulement que la sémantique du message
sera la même pour toutes les classes similaires (par
exemple : la méthode toString en JAVA, les injecteurs en 113

C++)
¢ Message
— Mécanisme caractéristique des langages objet. Le message
est l’unique support de communication entre objets.

Ch.SAADI
L’arrivée d’un message provoque l’exécution d’une méthode
de l’objet

Génie logiciel
¢ Type d’accès, portée, visibilité
— Public
— Private
— Protected

¢ Surcharge de méthode
— Mécanisme permettant de déclarer plusieurs
constructeurs ou plusieurs fois une même méthode
(même nom) dans une classe, à condition que tous aient
une signature différente (valeur de retour et/ou 114
paramètres différents).
UML (UNIFIED MODELING LANGUAGE) :
¢ Auteurs
— James Rumbaugh, Grady Booch et Yvar Jacobson

Ch.SAADI
¢ Objectifs
— Faciliter la communication entre les différents acteurs

Génie logiciel
d’un projet
— Faciliter la communication avec la machine
— Documenter un projet de bout en bout
— Spécifier et donc limiter les ambiguïtés
— Construire (interpréter les diagrammes pour code)

¢ Définition
— Langage de description des objets permettant une
modélisation rigoureuse des systèmes complexes
115
— Langage Unifié pour la Modélisation objet
UML

Ch.SAADI
¢ Avantages d’UML :
— Formel et normalisé (garantit stabilité et performance
d’un projet, réduit les risques)

Génie logiciel
— Support de communication performant et éprouvé
(permet de cadrer l’analyse et de faciliter la
compréhension de représentations abstraites : c’est
« l’esperanto » de l’analyse)

¢ Inconvénients d’UML :
— Période d’apprentissage
— Processus de production non couvert

116
 Ch.SAADI Génie logiciel
117
DIAGRAMMES UML
ORDONNANCEMENT DES DIAGRAMMES UML

Ch.SAADI
¢ 1. Découverte des besoins

Génie logiciel
— Diagramme de cas d’utilisation : décrit les fonctions du
système (point de vue de ses futurs utilisateurs -
Jacobson)

— Diagramme de séquence : représentation des

interactions temporelles entre objets dans la
réalisation d’une IHS

118
ORDONNANCEMENT DES DIAGRAMMES UML
2. Analyse

Ch.SAADI
¢

— Diagramme de classes : structure des données

Génie logiciel
— Diagramme d’objets : illustration

— Diagramme collaboratif : représentation des interactions

entre objets

— Diagramme d’états : représentation du comportement

des objets d’une classe en terme d’états et de
transitions d’états

119
— Diagramme d’activités : structure d’une opération en
actions
ORDONNANCEMENT DES DIAGRAMMES UML

Ch.SAADI
¢ 3. Conception

Génie logiciel
— Diagramme de séquence : représentation des interactions
temporelles entre objets dans la réalisation d’une
opération

— Diagramme de déploiement : description du

déploiement des composants sur les dispositifs
matériels

— Diagramme de composants : architecture des

composants physiques d’une application
120
POINT DE DÉPART: DÉCOUVERTE DES BESOINS
(SPÉCIFICATION)

Ch.SAADI
¢ Cette activité met donc en œuvre un mode de représentation
fonctionnel s’appuyant sur :

Génie logiciel
— Les diagrammes de cas d’utilisation qui permettent
d’identifier et de formaliser les différents acteurs ainsi
que les services attendus de la future application.

— La maquette pour sa part, permet de présenter de

manière concrète ces services via les IHM (Interface
Homme Machine) de l’application.

121
POINT DE DÉPART: SPÉCIFICATION

Ch.SAADI
Génie logiciel
122
EXEMPLE DE USE-CASE

Ch.SAADI
Génie logiciel
123
¢ Exemple de description pour le cas d’utilisation
s’authentifier

Ch.SAADI
Génie logiciel
124
¢ Exemple de maquette

Ch.SAADI
Génie logiciel
125
ANALYSE
¢ Étape intermédiaire entre la spécification des besoins et
la conception du système
èidentifier les classes de conception intervenant dans les

Ch.SAADI
diagrammes d’interaction du modèle conceptuel, deux sous étapes
sont nécessaires :

Génie logiciel
126
L’ANALYSE STATIQUE

Ch.SAADI
Modèle du domaine

¢ Construire le modèle du domaine. Sorte de glossaire

Génie logiciel
formalisé des concepts fondamentaux de l’espace du
problème, ce modèle fournit une partie des classes de
conception : celles correspondant directement aux
concepts métier manipulés par les experts du domaine
et les utilisateurs. Ces concepts, leurs attributs et leurs
relations vont être décrits en UML par des diagrammes de
classes simplifiées.

èC’est une représentation formelle d’un domaine de

connaissance avec plus de précision sur les comportements 127
L’ANALYSE STATIQUE
Exemple :Modèle du domaine

Ch.SAADI
Génie logiciel
128
L’ANALYSE STATIQUE

Ch.SAADI
Diagrammes de classes participants

¢ Construire les diagrammes de classes participants. Afin de

Génie logiciel
prendre en compte également l’IHM et la cinématique
de l’application, les diagrammes de classes participantes font
la jonction entre les cas d’utilisation, le modèle du
domaine, la maquette… et les diagrammes de conception
logicielle. Il s’agit de diagrammes de classes qui décrivent,
par cas d’utilisation, les trois principales classes d’analyse et
leurs relations.

129
L’ANALYSE STATIQUE
¢ Les diagrammes de classes participantes :

— Les classes de type dialogue : elles permettent les

Ch.SAADI
interconnections entre l’IHM et ses utilisateurs. Ce sont
typiquement les écrans proposés à l’utilisateur : les
formulaires de saisie, les résultats de recherche… Elles
proviennent directement de l’analyse de la maquette.

Génie logiciel
— Les classes de type métier : elles représentent les règles
métier et proviennent directement du modèle du domaine
mais sont confirmées et complétées pour chaque cas
d’utilisation.

— Les classes de type contrôle : elles contiennent la

cinématique de l’application et font la transition entre les
dialogues et les classes métier, en permettant aux
écrans de manipuler des informations détenues par un ou
130
plusieurs objets métier.
L’ANALYSE STATIQUE

Ch.SAADI
¢ Exemple de diagramme de classes participantes:

Génie logiciel
131
L’ANALYSE DYNAMIQUE

¢ Le modèle dynamique permet de décrire :

Ch.SAADI
Pour chaque cas d’utilisation, la séquence des

Génie logiciel
—
interactions entre les acteurs et le système vue
comme une boîte noire, représentée par les diagrammes
de séquence système.

¢ è Ces diagrammes qui feront le lien entre les cas d’utilisation et

les diagrammes d’interaction du niveau conceptuel.

132
L’ANALYSE DYNAMIQUE

¢ Le modèle dynamique permet de décrire :

Ch.SAADI
— Une manière formelle l’ensemble des chemins possibles
entre les principaux écrans proposés à l’utilisateur, et à

Génie logiciel
partir des informations fournies par la maquette, il reste à
détailler les diagrammes d’activités de navigation.

— Si nécessaire, le cycle de vie commun aux objets d’une

même classe, peut être explicité par les diagrammes
d’états.

133
L’ANALYSE DYNAMIQUE
¢ Exemple de diagramme de séquence système pour le
CU s’authentifier

Ch.SAADI
Génie logiciel
134
L’ANALYSE DYNAMIQUE
¢ Exemple de diagramme d’activités de navigation
pour le CU s’authentifier :

Ch.SAADI
Génie logiciel
135
CONCEPTION DU SYSTÈME

Ch.SAADI
¢ La conception du système Cible Dans les activités de
conception, le modèle correspond aux concepts

Génie logiciel
informatiques utilisés par les outils, les langages ou les
plates-formes de réalisation.

¢ Le modèle sert ici à étudier, documenter,

communiquer et anticiper la solution logicielle.

136
 Ch.SAADI Génie logiciel
137
CONCEPTION SYSTÈME
LA CONCEPTION DU SYSTÈME

Ch.SAADI
¢ Dans le cadre de systèmes orientés objet, la structure du code

Génie logiciel
est définie par des classes logicielles et leurs regroupements en
ensemble (appelés packages).

¢ La conception représente deux points de vue : la structure

statique et le comportement dynamique, deux
perspectives qui complètent la compréhension du système à
développer.

138
LA CONCEPTION DU SYSTÈME

Ch.SAADI
¢ Le modèle statique, qui permet de décrire les différents

Génie logiciel
composants logiciels structurant le système, est représenté à
l’aide de diagrammes de classes de conception.

¢ Le modèle dynamique, permet quant à lui de décrire

l’attribution des bonnes responsabilités (services) aux bonnes
classes. Tout le comportement du système est ainsi réparti
entre les classes de conception. C’est le rôle des diagrammes
d’interaction (diagrammes de séquence ou de
collaboration) de représenter graphiquement ces décisions
d’allocation de responsabilités ainsi que les collaborations
induites.
139
LA CONCEPTION DU SYSTÈME

¢ Exemple de diagramme de classes de conception de Struts :

Ch.SAADI
Génie logiciel
140
PRINCIPES FONDAMENTAUX EN GL

Ch.SAADI
• Séparation des problèmes

• Modularité

Génie logiciel
• Abstraction

• Anticipation du changement

• Généricité

• Construction incrémentale

141
SÉPARATION DES PROBLÈMES

Ch.SAADI
En pratique, plusieurs façons de faire :

Génie logiciel
¢ Séparation dans le temps (= ordonnancement)

¢ Séparation dans l’espace (= on se répartit les taches)

¢ Séparation des qualités (= priorités)

142
MODULARITÉ

Ch.SAADI
Génie logiciel
Ø Caractéristique d’un système, matériel ou logiciel, conçu en
séparant les fonctions élémentaires pour qu’elles
puissent être étudiées et réalisées séparément.

Ø Les modules sont des entités cohérentes qui peuvent

éventuellement être sorties du contexte et réutilisées.

143
ABSTRACTION

Ch.SAADI
¢ Opération qui consiste à isoler l’un des caractères de
quelque chose et à le considérer indépendamment des

Génie logiciel
autres caractères de l’objet.

¢ C’est un exemple de séparation des problèmes. On ne

considère à un instant donné que certains aspects du
système que l’on juge importants. On peut souvent
considérer plusieurs niveaux d’abstraction pour un même
système

144
ANTICIPATION DES CHANGEMENT

Ch.SAADI
La caractéristique essentielle du logiciel, par
rapport à d’autres produits, qu’il est presque toujours
soumis à des changements continuels, dus à des

Génie logiciel
corrections d’imperfections et/ou des évolutions en fonction
des besoins. Ceci requiert des efforts pour prévoir, faciliter
et gérer ces évolutions inévitables.

èIl faut :
q Faire attention à la modularité (localisation
des changements)

q Faire attention à la compatibilité entre

différentes versions d’un même module
145
GÉNÉRACITÉ

Ch.SAADI
Caractéristique générale qui permet d’englober une
classe d’objets dont chacun, pris séparément, reçoit une

Génie logiciel
dénomination spécifique.

Exemple: Siège est un terme générique d’une classe

comprenant la chaise, le fauteuil, le tabouret, etc..

Il peut être parfois utile de remplacer la résolution

d’un problème spécifique par la résolution d’un problème
plus général.
Des solutions génériques (paramétrables, adaptables)
sont plus facilement réutilisables. cf classes, héritage, 146
spécialisation
CONSTRUCTION INCRÉMENTALE

Ch.SAADI
Un procédé incrémental atteint son but par étapes,
en s’en approchant progressivement. Chaque résultat

Génie logiciel
intermédiaire est construit en étendant le précédent.

En pratique, on implémente d’abord un noyau

fonctionnel pour chaque module, qui inclut les fonctions de
base. Ce noyau est ensuite incrémenté petit à petit par de
nouvelles fonctionnalités.

147
Ch.SAADI Génie logiciel
148
4: CODAGE
CHAPITRE
CODAGE

Ch.SAADI
èL'objectif: transformer la conception d'un système en

Génie logiciel
¢
code avec un langage de haut niveau.

¢ Les programmeurs adhèrent a un style bien défini de codage

qui s’appel « standard de codage ».

149
CODAGE

Ch.SAADI
¢ Pour la mise en œuvre de notre conception en un code, nous
avons besoin d'un bon langage de haut niveau.

Génie logiciel
— Une norme de codage assure une uniformité du code écrit
par différents ingénieurs

— Il facilite la compréhension du code.

— Favorise de bonnes pratiques de programmation

150
CODAGE : STANDARS ET GUIDLINES

Ch.SAADI
¢ 1.Contenu des en-têtes pour différents modules.

Voici quelques-unes (des données d'en-tête) standard :

Génie logiciel
— Nom du module.
— La date à laquelle le module a été créé.
— Le nom de l'auteur.
— Historique des modifications.
— Différentes fonctions prises en charge, ainsi que leurs
paramètres d'entrée / sortie.
— Les variables globales accessibles / modifiées par le module.

151
CODAGE : STANDARS ET GUIDLINES

Ch.SAADI
¢ 2. Conventions de dénomination des variables globales,
variables locales et les identificateurs constants :

Génie logiciel
— Une convention de nommage possible peut être que les noms
des variables commencent toujours par une lettre
majuscule, les noms de variables locales sont en
minuscule et noms constants sont toujours des lettres
majuscules.

¢ 3. Conventions de retour d’erreur et les mécanismes de gestion

des exceptions :
— La façon dont les erreur sont signalées, par des fonctions
différentes dans un programme, devrait respecter la
norme au sein d'une organisation.
152
CODAGE : STANDARS ET GUIDLINES

Ch.SAADI
¢ Autres directives de codage recommandées par de nombreuses
organisations de développement de logiciels.

Génie logiciel
— 1.Ne pas utiliser un style de codage trop difficile à
comprendre;

— 2.Ne pas utiliser un identifiant à des fins multiples (Chaque

variable doit avoir un nom descriptif indiquant son but).

èUtilisation de variables à des fins multiples rend

généralement les futures améliorations (les modifications)
plus difficile.

153
CODAGE : STANDARS ET GUIDLINES

Ch.SAADI
¢ 3. Le code devrait être bien documenté : (usage des
commentaires)

Génie logiciel
¢ 4. La longueur de toute fonction ne doit pas dépasser 10
lignes de source : Une fonction qui est très long est
généralement très difficile à comprendre.

¢ 5. Ne pas utiliser les instructions goto : Utilisation des

instructions goto fait un programme non structuré et très
difficile à comprendre.

154
LA RÉVISION DU CODE

Ch.SAADI
¢ La Révision du Code à pour but d’avoir un module
développé, compilé avec succès on se débarrassant

Génie logiciel
de toutes les erreurs (de syntaxe).

¢ Les examens du code sont des stratégies très rentables

pour la réduction des erreurs de codage et pour produire un
code de haute qualité.

155
 Auto-correction

Ch.SAADI
Inspection de code (desk-checking)

Génie logiciel
Technique d’examen du
code

Lecture croisée (author-

reader cycle)
Revue structurée

Code walk-through
156
RÉVISION DU CODE : CODAGE DESK-CHECKING

Ch.SAADI
Génie logiciel
¢ Auto-correction (desk-checking) :

c'est une relecture personnelle avec une efficacité

quasi nulle pour les documents amont, faible pour le code.

157
RÉVISION DU CODE : CODAGE AUTHOR-READER

Ch.SAADI
¢ Lecture croisée (author-reader cycle) :

Génie logiciel
un collègue qui cherche les ambiguïtés, les lacunes, les
incertitudes du code. L'efficacité de cette méthode est faible
pour les documents amont mais plus adapté pour la relecture
du code.

158
RÉVISION DU CODE : REVUE STRUCTURÉE

Ch.SAADI
¢ Revue structurée :

Génie logiciel
c'est la constitution d'une liste de défauts, pendant
un débat dirigé par un responsable, en utilisant une liste de
défauts typiques (checklist) cela a une bonne contribution à
l'assurance qualité

159
RÉVISION DU CODE : INSPECTION

Ch.SAADI
¢ Inspection :

C'est un cadre de relecture plus formel avec

Génie logiciel
recherche des défauts avant les débats et un bon suivi des
décisions et corrections cela a une excellente contribution à
l'assurance qualité

160
RÉVISION DU CODE : CODE WALK-THROUGH

Ch.SAADI
¢ On donne le code à des membres de l'équipe de
développement, quelques jours avant la réunion de
‘walkthrough’. Chaque membre sélectionne certains cas de

Génie logiciel
test et simule l'exécution du code à la main.

¢ Les membres notent leurs remarques à en discuter dans la

réunion où le ‘développeur’ du module est présent.

¢ Les principaux objectifs sont : découvrir les erreurs

algorithmiques et logiques dans le code.

161
RÉVISION DU CODE : CODAGE WALK THROUGH

Ch.SAADI
¢ Même s’elle est une technique d'analyse informelle,
plusieurs directives ont évolué au fil des ans pour faire de
cette technique d'analyse utile et plus efficace:

Génie logiciel
¢ L'équipe effectuant le walkthrough devrait par être ni
trop grand ni trop petit. Idéalement, il devrait être
composé de trois à sept membres.

¢ La discussion devrait se concentrer sur la découverte

d'erreurs et non pas sur la façon de corriger les erreurs
découvertes.

¢ Les Managers ne devraient pas participer à la réunion 162

walkthrough.
DÉFAUTS TYPIQUES
¢ 1. Référence aux données :

Ch.SAADI
— Variables non initialisées

— Indices de tableaux hors bornes

Génie logiciel
— Accès à des structures/records à champs variables ou à des
unions

— Confusion entre donnée et pointeur vers la donnée

— Déréférence de pointeurs nuls

— Pointeurs sur des données désallouées ou pas encore

allouées

— Pointeurs sur des données devenues inutiles mais non 163

libérées
DÉFAUTS TYPIQUES

Ch.SAADI
¢ 2. Calculs :

Génie logiciel
— Conversions de type (implicites et explicites)

— Underflow/overflow (dépassement de capacité du type)

— Division par zéro

— Précédence des opérateurs

164
DÉFAUTS TYPIQUES

¢ 3. Comparaison :

Ch.SAADI
— incohérence des types : mélanges d'entiers et de booléens

Génie logiciel
— · inclusion ou non des bornes incorrecte :
< au lieu de <=, >= au lieu de >, …

— · inversion du test : == au lieu de !=, > au lieu de <, ...

— · confusion en égalité (==) et affectation (=) :

if (x = y) {...} au lieu de if (x == y) {...}:

165
DÉFAUTS TYPIQUES
¢ 4. Contrôle :
— Switch : ensemble de case incomplet, cas default

Ch.SAADI
manquant, break oublié

— Rattachement du else au if

Génie logiciel
— Terminaison du programme : boucles et récusions sans
fin

— Boucles : conditions initiales (indices, ...) incorrectes,

itérations en plus ou en moins,

— incohérences après une sortie de boucle anticipée,

incohérences après une sortie de boucles emboîtées

— Procédures et fonctions : incohérences après une sortie

166
anticipée

— Exceptions non rattrapées