Cours de GL

 Est-ce que développer un logiciel consiste

uniquement à le programmer?
 Y-a-il d’autres activités nécessaires pour
produire un logiciel?
 Qu’est ce qu’un logiciel?
 Est-ce que le développement des logiciels
est un art? ou bien obéit-il à une démarche
rigoureuse?
 Pour qui développe-t-on des logiciels?
 Quelles sont les problèmes liés aux
développement des logiciels?

1
Définition du GL
 Le Génie Logiciel est une science de l’Ingénieur qui vise à
proposer :
◦ des méthodes d’ingénierie (ensembles d’étapes logiquement
enchaînées où chacune réalise une ou plusieurs activités),
◦ des techniques (procédés ou façons de réaliser une activité)
◦ des langages (pour décrire les inputs et outputs manipulés à
chaque activité)
◦ des outils pour automatiser les tâches de chaque activité
 Et ce, pour développer (produire, construire …) des produits
logiciels :
◦ de bonne qualité,
◦ dans les meilleurs délais,
◦ et avec les moindres coûts possibles.

2
Activités de développement

3
Objectifs du cours
 Acquérir les concepts de base du génie logiciel en
termes d’objectifs de qualité, de coût et de délai.
 Comprendre les étapes d’un cycle de vie de
logiciels
 Comprendre le processus de spécification et
d’analyse des besoins en utilisant les diagrammes
de cas d’utilisation UML
 Apprendre la conception des de la vue statique
d’un logiciel à l’aide des diagrammes UML de
classes
 Apprendre la conception des de la vue dynamique
d’un logiciel à l’aide des diagrammes UML de
séquences et d’états-transitions.

4
Plan du cours de GL
 Chapitre 1 : Introduction au Génie Logiciel
◦ Crise du Logiciel, Définition du GL, Qualités des
logiciels, Modèles de cycles de vie des logiciels
 Chapitre 2 : Introduction au Langage UML
 Chapitre 3 :Vue fonctionnelle
◦ Diagramme des Cas d’Utilisation
 Chapitre 4 :Vue Statique
◦ Diagrammes des Classes et des Objets
 Chapitre 5 :Vue Dynamique
◦ Diagramme d’interaction(séquence et
collaboration), d’activités et d’Etats-Transitions

5
CHAPITRE N°1
INTRODUCTION AU
GÉNIE LOGICIEL

6
Les logiciels (1)
 Un logiciel est un ensemble de
programmes, qui permet à un ordinateur
ou à un système informatique d’assurer
une tâche ou une fonction en particulier
 Les logiciels, suivant leur taille, peuvent
être développés par:
◦ une personne seule,
◦ une petite équipe,
◦ ou un ensemble d’équipes coordonnées.

7
Les logiciels (2)
 Le développement de grands logiciels par
de grandes équipes pose d’importants
problèmes de:
◦ Conception
◦ Coordination.

8
Les logiciels (3)
 Étude du Standish Group en 1995:
reposant sur un échantillon représentatif
de 365 entreprises, totalisant 8380
applications:
◦ 16,2% seulement des projets étaient
conformes aux prévisions initiales,
◦ 52,7% avaient subi des dépassements en coût
et délai d’un facteur 2 à 3 avec diminution du
nombre des fonctions offertes,
◦ 31,1% ont été purement abandonnés durant
leur développement.
9
 Les logiciels (4)
8380 Logiciels,logiciels conformesChart Title initiales
aus prévisions 8380
logiciels ont été Logiciels,
logiciels avaient subi des dépassements en cout et délai
abandonnés, logiciels
31.1, 31% logiciels ont été abandonnés conforme
s aus
prévisions
initiales,
16.2, 16%

8380 Logiciels,
logiciels avaient
subi des
dépassements
en cout et délai,
52.7, 53%

10
Crise de l’industrie de logiciels (1)
 La crise logicielle est la situation
caractérisée par une baisse du prix du
matériel qui se heurte par:
◦ une augmentation dans les prix des
logiciels,
◦ un problème dans leur fiabilité,
◦ un délai de livraison, énormément,
dépassés
◦ et un coût difficile à estimer et à contrôler.

11
Crise de l’industrie de logiciels (2)
 1962: Destruction en
vol de la sonde spatiale
Mariner 1 peu de
temps après son envol
◦ Coût : 18,5 millions de
dollars
◦ Mission: survol de la
planète Vénus
◦ Cause: Erreur de
transcription manuelle
d'un symbole
mathématique dans la
spécification

12
Crise de l’industrie de logiciels (3)
 1991: L’echec du Missile
Patriot Américain
◦ Cout: 28 soldats morts et
100 blessés (destruction
d’une caserne d’arme
américaine)
◦ Cause: un calcul inexact du
temps depuis le démarrage
en raison d’erreur
arithmétique.
◦ L’erreur est que le registre
utilisé est de 24 bits, alors
que la valeur stockée
dépasse ce nombre de bits.

13
Crise de l’industrie de logiciels (4)
 1985/1987: Problème
du Therac-25,
surdosage en
radiothérapie «
appareil d’irradiation
thérapeutique »
◦ Au moins 5 morts par
dose massive de
radiations
◦ Cause: des fautes de
conception dans le
matériel et le logiciel

14
Crise de l’industrie de logiciels (5)
 1994: le bug de la division du Pentium, une erreur
était introduite en raison d’une faute de
conception de l'algorithme de division flottante
 1996: Ariane 5, explosion du premier vol d’Arian
5 due à une erreur de débordement lors de la
conversion d’un nombre flottant 64 bits vers un
entier 16 bits. Coût 500 millions de dollars .(Le
bug informatique le plus couteux de l’histoire)
 2000 : Le bug de l’an 2000, dysfonctionnements
lorsque les dates sont postérieures au 31
décembre 1999

15
Crise de l’industrie de logiciels (6)
 L’importance d’une approche
méthodologique s’est imposée à la suite
de cette crise.
 Ainsi, une nouvelle discipline est née: le
génie logiciel

16
Objectifs du GL
 Le GL se préoccupe des procédés de
fabrication des logiciels de façon à s’assurer
que les 4 critères (coût, qualité,
fonctionnalité et délais) soient satisfaits:
◦ Le système qui est fabriqué répond aux besoins
des utilisateurs (correction fonctionnelle).
◦ La qualité correspond au contrat de service
initial.
◦ Les coûts restent dans les limites prévues au
départ.
◦ Les délais restent dans les limites prévues au
départ.

17
Définition du génie logiciel (1)
 Le génie logiciel est un domaine de
recherche qui a été défini en 1968
 D’après la Norme IEEE 610.12 : «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,
l’application de l’ingénierie au logiciel»

18
Définition du génie logiciel (2)
 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 »

19
Notion de qualité pour un logiciel
(1)
 Qualités externes: intéressent le client en
premier lieu
◦ Validité & fiabilité, ergonomie, efficacité &
performances, maintenabilité
 Qualités internes: intéressent le
développeur (techniques)
◦ Réutilisation, adaptabilité, maintenabilité, …

20
Notion de qualité pour un logiciel
(2)
 Validité : aptitude d’un produit logiciel à remplir
exactement ses fonctions, définies par le cahier
des charges et les spécifications.
 Fiabilité :désigne la capacité d’un produit logiciel à
maintenir son niveau de service dans des
conditions précises pendant une certaine durée.
 Extensibilité (maintenance) : facilité avec laquelle
un logiciel se prête à sa maintenance, c’est-à-dire
à une modification ou à une extension des
fonctions qui lui sont demandées.

21
Notion de qualité pour un logiciel
(3)
 Réutilisabilité : aptitude d’un logiciel à être
réutilisé, en tout ou en partie, dans de nouvelles
applications.
 Compatibilité : facilité avec laquelle un logiciel
peut être combiné avec d’autres logiciels.
 Efficacité : Utilisation optimales des ressources
matérielles. c'est-à-dire avoir le bon rapport entre
la quantité de ressources utilisées (moyens
matériels, temps, personnel), et la quantité de
résultats délivrés.
 Portabilité : facilité avec laquelle un logiciel peut
être transféré sous différents environnements
matériels et logiciels.

22
Notion de qualité pour un logiciel
(4)
 Vérifiabilité : facilité de préparation des
procédures de test (s'assurer que les
descriptions successives du logiciel et le
logiciel lui-même satisfont la spécification
globale).
 Intégrité : aptitude d’un logiciel à protéger
son code et ses données contre des accès
non autorisés.
 Ergonomie (Facilité d’emploi): facilité
d’apprentissage, d’utilisation, de préparation
des données, d’interprétation des erreurs et
de rattrapage en cas d’erreur d’utilisation.
23
Vie d’un logiciel

24
Le cycle de vie d’un logiciel (1)
 Désigne toutes les étapes du
développement d’un logiciel, de sa
conception à sa disparition
 Le cycle de vie permet de:
◦ Détecter les erreurs au plus tôt,
◦ Maîtriser la qualité du logiciel,
◦ Respecter les délais de sa réalisation et les
coûts associés.

25
Le cycle de vie d’un logiciel (2)
 Le cycle de vie du logiciel comprend:
◦ Analyse des besoins et faisabilité: l’expression,
le recueil et la formalisation des besoins du
demandeur et de l’ensemble des contraintes
puis l’estimation de la faisabilité de ces
besoins.
◦ Spécification ou conception générale :
l’élaboration des spécifications de
l’architecture générale du logiciel.

26
Le cycle de vie d’un logiciel (3)
◦ Conception détaillée : définir précisément
chaque sous-ensemble du logiciel.
◦ Codage (Implémentation ou programmation):
la traduction dans un langage de
programmation.
◦ Tests unitaires: vérifier individuellement que
chaque sous-ensemble du logiciel est
implémenté conformément aux spécifications.

27
Le cycle de vie d’un logiciel (4)
◦ Intégration: L’objectif est de s’assurer de l’interfaçage
des différents éléments (modules) du logiciel. Elle fait
l’objet de tests d’intégration consignés dans un
document.
◦ Qualification (ou recette): C’est-à-dire la vérification
de la conformité du logiciel aux spécifications initiales.
◦ Documentation: Elle vise à produire les informations
nécessaires pour l’utilisation du logiciel et pour des
développements ultérieurs.
◦ Mise en production
◦ Maintenance : Elle comprend toutes les actions
correctives (maintenance corrective) et évolutives
(maintenance évolutive) sur le logiciel.

28
Modèles de cycles de vie d’un
logiciel
 Plusieurs modèles de cycle de vie ont été
élaborés:
◦ Modèle en cascade
◦ Modèle en V
◦ Modèle par prototypage
◦ Modèle par incrément
◦ Modèle en spirale

29
Modèle en cascade (1)
 Principe est très simple :
◦ Projet découpé en phases successives.
◦ A chaque phase correspond une activité
◦ Chaque activité peut produire plusieurs
livrables
◦ Chaque phase ne remet en cause que la phase
précédente
◦ Pas d’évaluation entre le début du projet et sa
validation

30
Modèle en cascade (2)

31
Modèle en cascade (3)
 Avantages
◦ Simple à mettre en œuvre
◦ Production de documents à chaque étape
 Inconvénients
◦ Les vrais projets ne suivent pas un développement
séquentiel
◦ Les erreurs de définitions des besoins sont détectés
par le client tardivement pendant le test
d’acceptation, c.-à-d. à la fin du cycle de
développement (pas de validation intermédiaire )
 Ce modèle est mieux adapté aux petits projets
ou à ceux dont les spécifications sont bien
connues et fixes.

32
Modèle en V (1)
 Dérivé du modèle de la cascade.
 Le principe est:
◦ Avec toute décomposition doit être décrite
la recomposition,
◦ Toute description d’un composant est
accompagnée de tests qui permettront de
s’assurer qu’il correspond à sa description.

33
Modèle en V (2)

34
Modèle en V (3)
 Avantages
◦ Les plans de test sont meilleurs,
◦ Les éventuelles erreurs peuvent être détectées plus tôt.
 Inconvénients
◦ Les plans de test et leurs résultats obligent à une réflexion
et à des retours sur la description
en cours,
◦ La partie droite peut être mieux préparée et planifiée.
 Ce modèle est idéal quand les besoins sont bien
connus, quand l’analyse et la conception sont
claires,
 ce modèle est adapté aux projets de taille et de
complexité moyenne.

35
Modèle par prototypage (1)
 Le prototypage est également considéré
comme un modèle de développement de
logiciels.
 Il s’agit d’écrire une première spécification
et de réaliser un sous-ensemble du
produit logiciel final.
 Ce sous ensemble est alors de plus en
plus raffiné et évalué jusqu’à obtenir le
produit final.
36
Modèle par prototypage (2)
 Deux types de prototypage:
◦ Jetable(maquette) : squelette du logiciel qui
n’est créé que dans le but de corriger le
cahier de charge(une nouvelle version du
système sera développée à partir du cahier de
charge corrigé).
◦ Non jetable(Evolutif) : conservé tout au long
du cycle de développement. Il est amélioré et
complété pour obtenir le logiciel final.

37
Modèle par prototypage (3)
 Avantages
◦ Validation très tôt dans le processus,
◦ Visibilité (donc compréhension) du produit final,
◦ Anticipation des changements : maintenance
incluse tout le long du projet.
 Inconvénients
◦ Risque de déstructuration du code,
◦ Difficulté de planifier et de gérer le
développement.
 Ce modèle est bien adapté pour les projets
innovants.
38
Modèle par incrément (1)
 Dans ce modèle, un seul sous ensemble
des composants d’un système est
développé à la fois :
◦ un logiciel noyau est tout d’abord développé,
◦ puis, des incréments sont successivement
développés et intégrés.
 Le processus de développement de
chaque incrément est un des processus
classiques (cascade ou V).

39
Modèle par incrément (2)

40
Modèle par incrément (3)
 Avantages
◦ Chaque développement est moins complexe,
◦ Les intégrations sont progressives,
◦ Il peut y avoir des livraisons et des mises en
services après chaque intégration d’incrément.
 Inconvénients
◦ Mettre en cause le noyau ou les incréments
précédents,
◦ Ne pas pouvoir intégrer de nouveaux incréments.
 Ce modèle est utilisé dans de grands
projets nécessitant des livraisons
rapides.
41
Modèle en spirale (1)
 Il met l’accent sur l’activité d’analyse des risques
 chaque cycle de la spirale se déroule en quatre
phases :
1. détermination, à partir des résultats des cycles
précédents, ou de l’analyse préliminaire des besoins,
des objectifs du cycle, des alternatives pour les
atteindre et des contraintes ;
2. analyse des risques, évaluation des alternatives et,
éventuellement maquettage;
3. développement et vérification de la solution
retenue, un modèle classique (cascade ou en V) peut
être utilisé ici ;
4. revue des résultats et vérification du cycle suivant.

42
Modèle en spirale (2)

43
Modèle en spirale (3)
 Avantages
◦ Validité des besoins,
◦ Inclut l’analyse de risque et le prototypage.
 Inconvénients
◦ Calendrier et budget souvent irréalistes,
◦ Difficulté d’anticiper les composants nécessaires dans
les cycles ultérieurs,
◦ Sa mise en œuvre demande de grandes compétences
et devrait être limitée aux projets innovants à cause
de l'importance qu'il accorde à l'analyse des risques.
 Ce modèle est utilisé pour des projets
innovants, à risques, et dont les enjeux sont
importants.

44
Méthodes d’analyse et de
conception de logiciels (1)
 Qu’est ce qu’une méthode ?
◦ Les méthodes d’analyse et de conception
fournissent une méthodologie et des
notations standards qui aident à concevoir
des logiciels de qualité.
◦ Toute méthode met en œuvre 4 composants
indissociables : des modèles, un langage, une
approche et des outils

45
Méthodes d’analyse et de
conception de logiciels (2)
 Une méthode pourquoi ?
◦ Maîtriser le développement des systèmes
 Contrôler les coûts, et les délais
 Répondre aux besoins nés de l’évolution de l’entreprise
 Intégrer les innovations techniques
 Augmenter le service rendu par la structure.
◦ Faciliter la communication
 Normaliser le vocabulaire
 Homogénéiser la présentation de solutions
 Améliorer l’expression des besoins
◦ Assurer la pérennité des systèmes
 Apporter des aides à la maintenance
 Améliorer les performances des systèmes.

46
Méthodes d’analyse et de
conception de logiciels (3)
 Trois grandes catégories de méthodes de
conception de logiciels:
◦ Méthodes cartésiennes
SADT(Structured Analysis Design
Technique)
◦ Méthodes systémiques
MERISE
◦ Méthodes orientées Objet
OMT, UML
47
Méthodes orientées objet
 Considère le logiciel comme une
collection d’objets dissociés, et identifiés,
définis par des propriétés.
 La fonctionnalité du logiciel émerge de
l’interaction entre les différents objets qui
le constituent.
 L’approche OO permet de:
◦ rapprocher les données et leurs traitements
associés au sein d’un unique objet.

48
Concepts de méthodes orientées
objet
 Classe
 Objet
 Identité
 Encapsulation
 Héritage
 Polymorphisme
 Agrégation
…

49
Classe
 Une classe regroupe des propriétés et
des comportements.
 En OO, les comportements sont appelés
méthodes et les propriétés variables
d'instance.
 les propriétés des classes peuvent elles-
mêmes être des objets.

50
objet
 Un objet est:
◦ une instance de classe,
◦ c'est-à-dire, un exemplaire utilisable crée à
partir de cette classe et en valorisant
certaines propriétés.
 Tout objet possède un type.
 L'instance d'une classe est du type de sa
classe. C'est le type initial de l'objet.

51
Identité (référence) d’objet
 Chaque objet créé possède un identifiant
unique indépendant de son état (ses
valeurs de champs).
 Deux ou plusieurs objets ayant les mêmes
propriétés soient égaux en valeur mais
chacun possède sa propre identité.

52
Encapsulation
 L’encapsulation:
◦ masquer les détails d’implémentation d’un objet, en
définissant une interface.
 L’interface est la vue externe d’un objet, elle définit
les services accessibles (offerts) aux utilisateurs de
l’objet.
 L’encapsulation facilite l’évolution d’une application
car elle stabilise l’utilisation des objets :
◦ on peut modifier l’implémentation des attributs d’un objet
sans modifier son interface, et donc la façon dont l’objet
est utilisé.
 L’encapsulation garantit l’intégrité des données:
◦ elle permet d’interdire, ou de restreindre, l’accès direct
aux attributs des objets.

53
héritage
 L'héritage permet de spécialiser une classe qui
possédera non seulement les propriétés et méthodes
de sa mère mais également d'autres méthodes
spécifiques ou redéfinies.
 Le terme est faire dériver la classe en une classe fille.
 Dans l'objet fille, on trouve:
◦ De nouvelles méthodes ou propriétés
◦ Des méthodes ou propriétés qui surchargent, c'est-à -dire
redéfinissent celles de la classe mère.
◦ Les propriétés et méthodes de la classe mère qui n'ont pas
été surchargées
 L’héritage peut être simple ou multiple.
 L’héritage évite la duplication et encourage la
réutilisation.

54
Polymorphisme
 Les objets sont dits polymorphes car ils
possèdent plusieurs types:
◦ type de leurs classes
◦ et types des classes ascendantes.
 Le polymorphisme paramétrique:
◦ la faculté d’une méthode à pouvoir s’appliquer
à des objets de classes différentes.
 Le polymorphisme augmente la généricité,
et donc la qualité, du code.
55
Agrégation
 Une relation entre deux classes, spécifiant
que les objets d’une classe sont des
composants de l’autre classe.
 Une relation d’agrégation permet donc de
définir des objets composés d’autres
objets.
 L’agrégation permet d’assembler des
objets de base, afin de construire des
objets plus complexes.
56