Atelier de Génie Logiciel

Chapitre1 Introduction
et rappels
1.1Introduction et concepts de base
 Introduction
 Un AGL (Atelier de Génie Logiciel) ou outils
CASE (Computer Aided Software Engineering)

 environnement de développement logiciel qui

permet d’assister la réalisation de logiciels.

 Un AGL intègre des outils adaptés aux différentes

phases de la production d'un logiciel

 facilite la communication et la coordination entre

ces différentes phases
5
Paradigmes de programmation
 Paradigmes de programmation
6
 Un paradigme est :
 Un style de programmation
 Une manière de programmer
 Basé sur un ensemble de principes ou de concepts de
programmation

 Les paradigmes de programmation permettent de

"classer" les langages entre eux selon des critères
 1.Paradigme impératif
7

 Décrit les opérations en termes de séquences

d'instructions exécutées par l'ordinateur pour modifier
l'état d'un programme

 Le programme se déroule en écrasant les valeurs d'une

zone mémoire par une nouvelle valeur

 Fonctionnement : recette de cuisine

 ingrédients, préparation , résultat
Paradigme impératif :Exemple
PROGRAM calc_age;
8
{ Déclarations des constantes et des variables }
CONST
cet_annee=2015;
VAR
naissance, age : integer;
{corps du programme }
BEGIN
readln(naissance);
age:=cet_annee-naissance;
writeln('Tu as ',age,' ans.');
END.
2.Paradigme procédural
9
 Une succession d'appel de procédures ou de
fonctions

 Intérêt des porocedures :

 Eviter les répétitions de code
 Diminuer la taille du programme
 Programme plus lisible

 Exemple ; Pascal et C ...

 Paradigme procédural Exemple

10 PROGRAM calc_age;
PROCEDURE age ();
CONST
cet_annee=2015;
VAR
naissance, age : integer;
BEGIN
readln(naissance);
age:=cet_annee-naissance;
writeln('Tu as ',age,' ans.');
END;
BEGIN
age();
END.
 Programmation modulaire
11

 Un programme de taille importante ou destiné à

être utilisé et maintenu par d'autres personnes

 Il est nécessaire de fractionner le programme en

plusieurs fichiers sources

 Regroupement de plusieurs fonctions et

procédures dans un fichier
Exemple: Langage C
12
Crise du logiciel
 Crise logicielle
14
 1970 : Crise logicielle
 Provoquée par :
 L'inflation des délais et cout de développement
 L'impossibilité de maitriser la sureté des
logiciels (pannes nombreuses)
 Difficulté de maintenance
Problématique
15
 La taille des programmes augmente

 Les années 1970:

 10 000 lignes de code

 Les années 1980:

 50000 lignes de code dans les années 1980

 Actuellement : des millions de lignes de code

 Génie logiciel (software engineering)
16

 De manière analogue au génie civil, au génie

électrique et au génie chimique

 Il faut promouvoir (développer ) un génie

logiciel.
 Génie logiciel
 1968 : naissance GL à la conférence de l'OTAN à
Garmisch-Partenkirchen (Allemagne)

 1973 : première conférence sur le GL

 1975 : première revue sur le GL (IEEE

Transaction of Software Engineering)

 1980 : début des AGL

 Le génie logiciel
 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
 des procédures
 de qualité
 Les Moyens
 Les modèles

 Les langages

 La démarche

 Les outils

 Les Méthodes

 Les techniques
 Modèles
 représentation simplifiée d’une réalité.

 Conçus avec un ensemble de concepts, dotés de

règles d’utilisation et de représentation (souvent
graphiques).

 Ils guident le raisonnement dans l’identification

des aspects pertinents du domaine qu’on étudie.
Langages :

 Ils permettent de décrire les aspects

pertinents du système.

 Ils peuvent être textuels ou graphiques,

naturels ou formels.
Démarche

 étapes successives à enchaîner.

 Outils

 Permettent d’automatiser partiellement ou

totalement certaines phases du processus
de
conception.

 Exemples :
 outils d’aide à la conception,
 des outils de simulation,
 des outils d’aide à la vérification, etc
Méthode

 Les modèles et les langages sont en

général indissociables.

 Les modèles associés aux Langages

constituent une méthode.
Technique

 permettent un développement Cohérent

 comment utiliser les méthodes et les

outils.
 Les difficultés du génie logiciel
 Le logiciel est un objet immatériel (abstrait) Et
très flexible
 caractéristiques attendues sont difficiles à figer au
départ
 L’évolution rapide des technologies

 Le GL est un domaine très vaste , et jeune

 La réutilisation tarde à être effective :

 le développement par assemblage de composant
 Logiciel
 Un logiciel est un ensemble de
 programmes documentations
 informations de configuration
 Nécessaire à:
 Installation et utilisation
 développement et maintenance

 Exemple:
 spécifications, schémas conceptuels,
jeux de tests,
mode d'emploi, ..
Types de logiciels
 Systèmes pour la gestion : Logiciels
spécifiques ou Progiciels

 Systèmes de recherche d’information

 Moteurs de recherche…

 Systèmes d’aide à la décision

 SIAD
 Systèmes Experts…
Types de logiciels

 Systèmes de contrôle de machines

numériques (Systèmes embarqués)

 Systèmes de calcul scientifique

 Systèmes de simulation (Simulateur de

vols ; Simulateurs de guerre ; Jeux de
simulation…);
Types de logiciels
 Systèmes de support d’activités
 La conception assistée
par ordinateur  CAO 
 Le dessin assisté par ordinateur (DAO) 
 ….

 Systèmes techniques
 (Systèmes d’exploitation,
Compilateurs, SGBD, Antivirus …)
 Les qualités d'un logiciel Externe

 Fiabilité les résultats sont ceux attendus

 Adéquation et validité conformité et validité

 Efficacité espace mémoire, et temps d’exécution

 Les qualités d'un logiciel

 Documentable
 documents de conception ou architecture..

 Lisibilité et Clarté
 respect des conventions de programmation

 Portabilité
 fonctionner sur plusieurs types de machines et
indépendant de son environnement d'exécution
Les qualités d'un logiciel

 Robustesse et Sureté pas de

dysfonctionnements

 Sécurité absence du risque lors de

l’exploitation du logiciel.

 Intégrité Aptitude à protéger son code et ses

données contre des accès non autorisé.
Les qualités d'un logiciel

 Convivialité et Utilisabilité facile et

agréable à utiliser

 Ergonomique adaptée aux conditions de

travail de l’utilisateur

 Documentable accompagné d’un manuel

utilisateur
Les qualités d'un logiciel

 Réutilisabilité des parties peuvent être

réutilisées

 Interopérabilité interagir avec d'autres

logiciels
Les qualités d'un logiciel

 Traçabilité suivie du produit aux

différents stades ( production,
transformation commercialisation. ..)

 Testabilité c’est la possibilité de

soumettre un logiciel à des épreuves de
confirmation
 Les compromis
 Il est nécessaire de trouver des compromis

 les objectifs de qualité doivent être définis

pour chaque logiciel

 et la qualité du logiciel doit être contrôlée

par rapport au délai et au budget
Principes

 39
Comment assurer
la bonne qualité d’un logiciel ?

 Généralisation : regrouper tous se qui est commun

(instructions et données) pour éviter la répétition du
code

 Abstraction : décrire des entités à différents niveaux

d'abstraction, ne donner que les éléments pertinents et
omettre ceux qui ne le sont pas.
 Principes
40

 Modularité : décomposer les logiciels en

composants aussi petits et indépendants que
possible et réutilisable.

 Documentation : documenter le code et produire

des notices permettant la réutilisation.

 Vérification : permettre des tests...

.Quel paradigme ?
41

 Paradigme objet

 La programmation objet est inventée dans les années

1970 comme une extension de la programmation
procédurale .

 des objets (programmes) qui dialoguent au lieu de

lignes de codes séquentielles et des appels de
procédures et fonctions
Paradigme orienté objet
42

 Introduction des nouvelles notions dans les

langages de programmation

 objet
 classe
 instanciation
 encapsulation
 héritage
 polymorphisme
 Technologie objet
43
 Les technologies objets englobent désormais :
 La modélisation logicielle
 (UML, …)
 Les règles de conception
 (Design Pattern, ...).
 La programmation
 (langages objets)
 La communication entre programmes
 (CORBA, …)
 Les ateliers logiciels
 (Eclipse, NetBeans, …)
les autres domaines de
l’informatique
 Le GL est en forte relation avec presque
tous les autres domaines de l’informatique
:
 programmation
 réseaux
 bases de données
 informatique théorique (automates,
réseaux de Petri, ...)
 …
métiers du génie logiciel

 Analystes
 Concepteurs
 Programmeurs
 Ergonomes
 Experts en sécurité,
 Testeur
 Formateur …
 Domaines intervenant
 Informatique
 Droit
 Gestion
 Ressources humaines
 Finances
 Organisation
 Sciences Sociales et Humaines
 communication
 formation
 accompagnement, …
les rôles

 Utilisateurs

 Clients

 Développeurs analystes ,Concepteurs ..

 Chefs de projets
 1.2 cycle de vie

Processus de développement
Cycle de vie
Le processus de développement
de logiciel
 Le processus de développement

 Le processus technique modélise la

procédure à suivre pour réaliser le
produit.

 Le processus de gestion il modélise

la procédure à suivre pour contrôler
les délais et les coûts.
 Le processus qualité

 modélise la procédure à suivre pour

garantir la qualité du produit,
 et des différents processus participant
au développement du produit (gestion
et qualité).
Cycle de vie d’un logiciel

 C'est la description du processus de

développement couvrant les phases de:
 Création
 Exploitation
 Suppression
Objectif

 Maîtriser
 les risques
 les délais
 les coûts
 la qualité
 Cycle de vie d’un logiciel
1. Définition des besoins (cahier des charges)
2. Analyse des besoins (Spécification)
3. Planification et gestion du projet
4. La conception du logiciel
5. Le codage, les tests , intégration et installation
6. Exploitation et La maintenance
Modèles de cycle de vie
Chapitre1
1.3 Modèles de cycle de vie
Modèle de cycle de vie

 permet de caractériser les étapes

successives que peut prendre un logiciel
depuis sa demande jusqu’à sa disparition
LE MODELE DU CODE-AND-
FIX
 détermination facile des besoins

1. phase d’analyse des besoins

2. phase de Programmation
3. puis une phase de Mise au point
LE MODELE DE TRANSFORMATION AUTOMATIQUE

 Spécifications  programmes

1. description exhaustive des spécifications

2. Validation
3. génération du code

 Une succession de cycles Phase de

Spécifications – Phase de Validation
LE MODELE EN CASCADE
LE MODELE EN CASCADE
(WATERFALL MODEL)
 date de 1970
 Le projet est découpé en phases
successives
 chaque phase correspond une activité
produisant des livrables
 On ne passe à l’étape suivante que si les
résultats de l’étape précédente sont
validés
 Inconvénients :
 chaque étape sert de contrôle du livrable de l’étape
précédente

 Chaque phase ne peut remettre en cause que la phase

précédente

 les erreurs de spécifications souvent détectées au moment

des tests
 la correction nécessite de reprendre le cycle
 Adapté pour des projets de petite taille, et dont le domaine
est bien maîtrisé.
LE MODELE EN V

 Dérivé du modèle en cascade

 la notion de décomposition et d’intégration

fondamentaux dans les applications de
grande taille.

 Adapté pour des projets dont le domaine est

bien maîtrisé
LE MODELE EN V
Caractéristiques
 relation entre les phases du et celles de
fin.

 avec toute décomposition doit être décrite

la recomposition

 Avec toute description d’un composant un

ensemble de tests qui permettront de
s’assurer qu’il correspond à sa
description.
cycle de vie en spiral

 C’est modèle itératif ou à chaque itération

on reproduit les mêmes étapes du cycle de
vie.
 Etapes
1. Détermination des objectifs du cycle des alternatives
pour les atteindre et des contraintes,(solutions)
2. Identification et résolution des risques
3. Développement de la solution retenue, un modèle «
classique » (cascade ou en V) peut être utilisé
4. Simulation et essais;
5. Détermination et Validation des besoins
6. Planification du cycle suivant.
 Exemple de risques
 surestimation des compétences
 validité des besoins
 développement de fonctions
inappropriées
 développement d'interfaces utilisateurs
inappropriées
 exigences démesurées par rapport à la
technologie
MODELE DE CYCLE DE VIE ORIENTE
REUTILISATION DE
COMPOSANTS
Caractéristiques

 les clients et les fournisseurs font partie de la même

entreprise

 si l'analyse de risque démontre que le projet peut être

continué, une équipe peut être réaffectée au projet

 devrait être limitée aux projets innovants à

cause de l'importance que ce modèle accorde
à l'analyse des risques.
Modèle incrémental

 ensemble de composants est développé à la

fois

 des incréments viennent s'intégrer à un

noyau de logiciel développé au préalable.

 Chaque incrément est développé selon l'un

des modèles précédents.
 Caractéristiques
 chaque développement est moins complexe

 les intégrations sont progressives

 il y a la possibilité de livraison et de mise en

service après chaque incrément

 meilleure évaluation du temps et de l’effort de

programmation.
 .
les risques :

 la mise en cause du noyau et des

incréments précédents,

 l’éventuelle difficulté d’intégrer les

nouveaux incréments
Prototypage

 Maquette ou prototype rapide

 Prototype expérimental
 Prototype évolutif
Maquette ou prototype rapide

 Un Prototype est une version d'essai du logiciel.

 pour montrer aux clients les fonctions que l'on

veut mettre en œuvre.

 permet de contourner la difficulté de la

validation liée à l’imprécision des besoins du
système à développer.
Maquette ou prototype rapide
Prototype expérimental

 Utilisé au niveau de la conception pour

 S'assurer de la faisabilité de parties

critiques

 Valider des options de conception

Prototype évolutif

 La première version du prototype est

l'embryon du produit final

 On itère jusqu'au produit final