Le Gnie logiciel et La qualit logicielle

- Introduction Dr. Youssef GAHI

youssef.gahi@gmail.com

IGA Casablanca
2015-2016
1

Objectifs du cours (24 heures)

Saisir limportance du gnie logiciel

Comprendre le cycle de vie dun logiciel et le

rle des diffrents intervenants.

Analyse, Conception, Implmentation, Support

Se familiariser avec les modles de conception.

Analyse des besoins, Contrle de lvolution

Conception dobjets rutilisables, API, MDA

Comment apporter de la qualit a un logiciel?

Design Patterns, Scrum, Tests unitaire

Plan du cours

Introduction au gnie logiciel (3h)

Logiciel vs Gnie logiciel
Pourquoi le GL ?
Les diffrents intervenants dans la production logicielle.
Cycle de vie dun logiciel.
Modles, Techniques et Processus de dveloppement (4h)
Cycle de dveloppement
Objets rutilisables, API, MDA

Etude de cas (2h)

Outils permettant de crer des logiciels de qualits (6h)

Qualit logicielle (6h)

Outils de Conception
Outils dimplmentation et de gestion
Outils danalyse
Patrons de conception (Design Patterns)

Travaux Pratiques (3h)

Introduction au gnie logiciel

Logiciel vs Gnie logiciel

Quest ce que cest logiciel?

Programmes et la documentation associe cahier de

charges, modles, manuels

Quest ce que cest gnie logiciel?

Le gnie logiciel comporte des aspects de gestion de projet

et des notions de qualit (satisfaire le client)
Ceci en utilisant des mthodes, des modles, et des outils.

Quelle est la diffrence entre gnie logiciel

et informatique?
5

Gnie logiciel

Dveloppement en quipe d'un logiciel

complexe

Un intervenant = une (petite) partie du travail

Programmation : entre 15% et 35% du

travail

Analyse, conception, vrification, gestion de

projet

Complexit croissante des logiciels

Scurit
Cot du logiciel (>> cot du matriel)

Pourquoi le GL?

Si l'on veut matriser le dveloppement de

systmes complexes, il faut :

rdiger de faon claire les spcifications du

systme (ce que le client attend du produit)

comment tre srs que ces spcifications sont compltes ?

comment tre srs que ces spcification sont cohrentes ?

valider/vrifier toutes les tapes du

dveloppements

a-t-on des moyens de validation/vrification

(mathmatiques) ?
de rutiliser des sous-systmes dj raliss (mais pas
n'importe comment)
a-t-on des rgles, des outils pour aider la rutilisation ?

Maitriser les cots.

Cot dun logiciel

Cot de dveloppement

Cot dinstallation

Effort jour-homme (entre 500 et 1000 euros

par jour)

Frais de dplacement, avion, htel

Cot de support/maintenance

Rsolutions des bugs, assistance

8

Les dfis devant le GL

Rles des intervenants dans

le dveloppement logiciel

10

Les commerciaux
Prsenter des solutions pour les clients.
Accompagner les clients dans la dfinition
de leur besoin (avec laide des analystes
fonctionnels)

11

Analyste fonctionnel-Concepteur
Etude de faisabilit.
Transformer le besoin fonctionnel en une
architecture logiciel.
Choix technologique

Type darchitecture
Protocoles
Estimation grosse maille

12

Chef de projets
Piloter et suivre lavancement des projets.
Dfinir les diffrentes dates en
collaboration avec les responsables de
dveloppements.
Assurer des runions avec le client final et
les responsables de dveloppements.
Calculer et estimer les couts ncessaires
ainsi que la rentabilit du projet.

13

Responsable de dveloppements
Architecture logicielle
Suivre lavancement de lquipe
Communiquer les livraisons ou Annoncer
les retards.
Assurer des runions avec les diffrentes
parties notamment les chef de projets.

14

Dveloppeur

La ralisation de toute la matire logicielle

du projet.

Codage des traitements

Tests
Prparation des binaires et des scripts
Documentation

15

Intgrateur

Vrification des prrequis

Installation et configuration du produit

Validation des recettes de tests.

Rapport de missions

16

Les partenaires

Equipes externes

Sous-traitants

Institut

Stagiaires

17

Cycle de vie dun logiciel

18

Cycle de vie dun logiciel

Analyse des besoins
Spcifications (Contrat commercial)
La conception fonctionnelle et technique
La Ralisation
Vrification et Validation
Lintgration
La recette interne et recette fonctionnelle
La formation
Documentations
Maintenance et volution

19

Analyse des besoins

Fonctionnalits attendues du systme
Point de vue mtier, de l'utilisateur
Aider formuler le besoin
Produit un document textuel, avec
schmas, intelligible par le client
Conduit la dfinition du cahier des
charges => les "spcifications"

20

Spcifications
Ce que doit faire le systme
Produit un document textuel avec
schmas, lisible par toutes les parties
Base du contrat commercial
Base des tests de vrification de la phase
d'installation

21

Conception gnrale
Comment raliser le logiciel ?
Choix techniques : explorer plusieurs
solutions Dcrire la solution retenue
Architecture gnrale

Composants

Structures de donnes
Fonctionalits

Interactions entre ces composants

Tous les lments de la spcification

doivent tre pris en compte
22

Conception dtaille
Dcompose chaque composant en souscomposants, jusqu'au niveau o le codage
devient facile
Prcise pour chaque composant :

Son interface
Les algorithmes
Le traitement des erreurs

Produits :

L'ensemble de ces descriptions

Le plan des tests unitaires (jeux de donnes)
23

Implmentation
Traduction dans un langage de
programmation des diffrents modules
Mise au point
Tests de dveloppements
Commentaires

24

Vrification et Validation

Vrification

Revues des spcifications (checklist)

Validation

Analyse du produit: Scurit, Gestion des mot de

passes
Plateformes de tests indpendante.
Beta et Alpha Test
Recette des tests interne
Tests de charge

25

Test (1)
Dans la pratique, il convient dintgrer les dveloppements unitaires
au sein de larchitecture technique cible, tout en testant la cohrence
fonctionnelle et technique globale de lapplication, avant livraison et
installation sur le site du client.

Les tests raliss seront :

Un test spcifique du Framework aprs dveloppement sur la base de la conception dfinie

au dbut de la conception fonctionnelle et technique,

Un test de rception des composants achets pour le projet (modules sous-traits),

Les tests unitaires des fonctions dveloppes,

Les tests dassemblage sur les plates-formes de dveloppement avec donnes relles
permettant entre autres le test des procdures de reprise,
Les test dintgration sur les plates-formes,
26

Les tests de charge sur chaque module.

Test (2)

Tests des composants externes

Lobjectif de cette tape est de sassurer que lensemble des

composants externes lapplication sont conformes sur les plans
fonctionnel et mtier aux spcifications prvues dans les phases de
conception.
Sur un plan technique, il sagit de sassurer que le composant
technique ne cre aucune interaction non-souhaite (ou interfrence)
de par son installation, registration, instanciation,
Les composants externes sont par exemple et suivant les technologies
employes des composants OCX, VBX, DLL
La qualification technique pourra avoir t ralise dans le cadre dun
27
projet antrieur

Test (3)

Ces tests sont raliss au fil de leau par lquipe de dveloppement.

Chaque personne de cette quipe consigne que le dveloppement de la
fonction X a t ralis par lui et aprs excution en environnement de
dveloppement ou sur simulateur. Il sagit de confirmer que cette
fonction est conforme aux spcifications fonctionnelles et techniques
dcrites.

Tests Unitaires

Tests dassemblage

Ces tests sont raliss par le chef de projet ou sous son autorit par une
personne de lquipe de dveloppement dtache sur cette mission.
Cette phase permet de sassurer que lensemble des
composants
techniques dvelopps ou acquis sinterfacent correctement :
lapplication fonctionne sans dfaillance, les rsultats attendus sont
28
conformes sur les axes rgles de calcul et rgles de gestion. Cette phase
seffectue sur le jeu dessai de dveloppement.

Test (4)

Cette phase de test seffectue sur une plate-forme dintgration dclare

conforme par le client lenvironnement de production. Cela concerne
tant les aspects techniques (OS serveur, base, client) que les interfaces
(entrantes notamment), ainsi que le jeu de donnes.

Tests dintgration

Tests de charge

Lobjectif de cette phase est deffectuer une monte en charge des

donnes entrantes et existantes dans lapplication. La base de donnes
sera charge avec une volumtrie quivalente au fonctionnement
nominal de lapplication. Les transactions devront seffectuer dans les
temps de rponses prvues lors de llaboration du cahier de charge. A
dfaut de temps de rponse dcrit, lapplication devra prouver quelle
fournit les rponses attendues avec la volumtrie nominale.
29

Installation
Dernire tape avant exploitation
Installer le logiciel dans son
environnement oprationnel
Vrifier le logiciel dans son environnement
oprationnel
Organiser la formation
Planifier la transition

30

Recettes

Prparation des procdures de

vrification/validation du logiciel

plan de validation

Version provisoire des manuels :

d'utilisation et
d'exploitation du logiciel

31

Recettes (1)

Il sagit dune validation interne, effectue par la direction projet, des

livrables avant fourniture au client du lot ralis. La recette interne
assure que le chef de projet en charge du projet suit le droulement
des actions de la contractualisation la mise en uvre du rsultat
prvu.

La recette interne

La recette fonctionnelle

La recette fonctionnelle est effectue par le client et plus

spcifiquement par le Chef de Projet Utilisateur du Client. Elle est
usuellement effectue sur la plate-forme de dveloppement ou la
plate-forme dintgration. Les complments et/ou volutions dtectes
lors de la recette fonctionnelle peuvent donner lieu ltablissement
32
davenant(s) au contrat

Formations

La formation peut prendre plusieurs formes. Elle peut viser les

utilisateurs mais aussi les quipes techniques (exemple : les quipes de
maintenance). Diffrentes dclinaisons sont envisageables en fonction
du contexte projet considr :

Les sessions de formation : elles sappuient sur lalternance dun

enseignement thorique et des mises en pratiques immdiates (TP).
Les sessions de formation doivent imprativement tre intgres
ds le dbut dans le plan projet pour quelles soient optimales.
Le transfert de comptences : il est principalement ddi aux
quipes techniques dexploitation ou de maintenance. Lobjectif est
de traiter sur la fin du projet lensemble des points critiques du
projet en parfaite transparence.
Laccompagnement en production : il se met en place lorsque la
monte en charge et/ou le dploiement reprsente(nt) un enjeu
majeur et critique du projet. Ainsi, lensemble des anomalies
33
pouvant survenir sont traites en collaboration directe avec lquipe
projet.

Documentation
Les manuels d'utilisation et d'exploitation
doivent tre prts au plus tard lors de
l'installation
Selon la complexit du logiciel :

Guide d'installation
Guide de l'utilisateur
Guide de l'oprateur
Manuel de rfrence
Documentations des composants logiciels
34

Guide dinstallation
Fonctionnalits du logiciel
Architecture
Interfaces utilisateurs
Comportements en cas d'erreurs
Performances requises
Interfaces avec autres logiciels
Interfaces avec le(s) matriel(s)
Contraintes de ralisations (matriels,
logiciels, normes)

35

Guide de lutilisateur
Le document dcrivant l'architecture
gnrale
Un plan d'intgration, avec un plan des
tests d'intgration (procdures de tests,
jeux de donnes)

36

Maintenance et volution

Corrections des erreurs

Prise en compte de nouveaux cas

d'utilisation

Ajout de nouvelles fonctionnalits

37

Cycle de dveloppement dun

logiciel

38

Rappel

Cest quoi un logiciel ?

Programmes et la documentation associe cahier de charges, modles, manuels

Cest quoi Le Gnie Logiciel ?

Le gnie logiciel comporte des aspects de gestion de projet et des notions de
qualit (satisfaire le client)
Ceci en utilisant des mthodes, des modles, et des outils.

Les intervenants dans le Gnie Logiciel?

Les Commerciaux, Analyste, Chef de Projets, Resp. de Dev, Dveloppeur,

Intgrateur, Partenaires.

Les tapes du Gnie Logiciel ?

Analyse des besoins

Spcifications (Contrat commercial)
La conception fonctionnelle et technique
La Ralisation
Vrification et Validation
Lintgration
La recette interne et recette fonctionnelle
La formation
Documentations
Maintenance et volution

39

Le Cahier des charges

Le cahier des charges est un document par lequel un

demandeur (entreprise, organisme priv ou public) exprime
le besoin devant tre satisfait par un objet concevoir.
Pour cela, il prcise les fonctions de service qu'il doit
assurer et les contraintes respecter. C'est un contrat qui
engage le concepteur.

Il servira de "consigne de recherche" pour que les ides

abstraites de dpart dbouchent sur un projet concret. Pour
chaque fonction, il dfinira galement les critres rentrant
en compte, le niveau de performance attendu et la
flexibilit tolre.

Pour ne rien oublier lors de la rdaction du CdCF on se

doit d'tre rigoureux et mthodique.

40

Le processus de dfinir les besoins

Etude de
faisabilit

Trouver les besoins

et analyse
Spcification
des besoins
Validation
des besoins

Rapport de
faisabilit
Modles du
systme
Besoins dusager
et du systme

Document des
besoins (Cahier
de charge)
41

Cahier des charges d'un robot aspirateur

L'expression du besoin

Le besoin
Rduire le temps consacr au mnage en
ralisant de manire automatique le
passage de l'aspirateur.
La rponse actuelle au besoin
De nombreuses entreprises fabriquant
des aspirateurs traditionnels ont le projet
de concevoir ce type d'aspirateur.
Actuellement, trs peu de produits fiables
sont disponibles sur le march.
Les objectifs
Raliser un aspirateur robot fiable
pouvant remplacer un aspirateur
traditionnel, un prix acceptable pour les
mnages. Les interventions humaines
42
sont limiter au maximum.

Cahier des charges d'un robot aspirateur

2
2
3

Fonctions de service et contraintes

Aspirer la poussire au sol sans intervention de
l'utilisateur
Aspirer la poussire sous les meubles
Aspirer le long des murs et des obstacles
viter les obstacles en douceur

Passer sur des obstacles (tapis, seuils de porte...)

5
6

Ne pas tomber dans les escaliers

Stocker la poussire aspire

Assurer la scurit des personnes et des animaux

8
9
10

Doit tre esthtique

tre transportable
Pouvoir tre rang dans un placard

43

Cahier des charges fonctionnel

Exemple : Support de tlphone portable
Fonctions
Doit permettre de maintenir un tlphone mobile.
Doit tre visible la nuit

Doit assurer la scurit de l'utilisateur.

Doit plaire, Doit tre beau, esthtique

Doit tre rsistant
Sera pos (support de tlphone mobile) sur un plan horizontal pour une lisibilit aise de
44
l'cran.

Cahier des charges fonctionnel

Application : Support de tlphone portable
Fonctions
tre ralisable au collge
tre comptitif (cot matire maxi 5 euros)
Doit tre peu onreux

Assurer une bonne autonomie

45

Le processus de logiciel

Activits

Spcification quest ce que le logiciel doit

faire et les contraintes poses au
dveloppement
Dveloppement - production logiciel
Validation vrification si le logiciel est celui
qui est attendu du client.
Evolution modification du logiciel en
accordance avec les besoins.

46

Modles gnriques
Effet Tunnel
Cascade
Modle en V
Modle en W
Modle en Spirales
Dveloppement volutif et itratif
Dveloppement itratif incrmental
Bas lassemblage de composants

47

Leffet tunnel
Un jour,
peut-tre ...

Le dpart est
connu

Le modle de dveloppement en tunnel

noffre aucune visibilit sur ltat
davancement du logiciel.
48

Le modle en cascade

Cycle de vie linaire sans aucune valuation entre le dbut

du projet et la validation

Le projet est dcoup en phases successives dans le temps

Chaque phase ne peut remettre en cause que la phase

prcdente.

Le dveloppement en cascade est en gnral rythm par la

gnration de documents qui servent de validation pour le
passage dune phase lautre

Chaque phase est donc acheve avant que ne dbute la

suivante.
49

Cascade

50

Cascade

Problmes

Avantages

Il est difficile de sparer les tapes

On peut lutiliser quand les besoins sont bien dfinis et ils sont stables.
Bien document chaque phase

Dsavantages

Rigide (on ne peut pas de rpondre au besoins nouveaux ou modifis

des clients)
Les vrais projets suivent rarement un dveloppement squentiel.
Etablir tous les besoins au dbut dun projet est difficile.
Aucune validation intermdiaire (aucune
prparation des phases de vrification)

Sensibilit larrive de nouvelles exigences refaire toutes les tapes

51

Le modle en V

A ce jour, le cycle en V reste le cycle de vie le

plus utilis. Cest un cycle de vie orient test

A chaque activit crative (spcification,

conception et codage) correspond une activit de
vrification (validation, intgration, tests unitaire)

Chaque phase en amont prpare la phase

correspondante de vrification (la vrification est
prise en compte au moment mme de la
cration).
52

Le modle en V

53

Les limites des cycles de vie en V

Les cycles de vie sont trop longs.
Les relations entre les clients et les
fournisseurs ne sont pas suffisamment
formalises.
Ils ne grent pas les risques.
Lintgration est trop tardive dans le cycle
de vie.
La documentation est ralise dabord et
le logiciel aprs

54

Cycle en V

Avantage:

La prparation des dernires phases (validationvrification) par les premires (construction du logiciel),
permet de dviter dnoncer une proprit quil est
impossible de vrifier objectivement aprs la ralisation.

Inconvnients:

Construit-on le bon logiciel? le logiciel est utilis trs

(trop) tard
Il faut attendre longtemps pour savoir si on a construit
le bon logiciel
Difficile dimpliquer les utilisateurs lorsque quun logiciel
utilisable nest disponible qu la dernire phase.
Idal quand les besoins sont bien connus, quand
55
lanalyse et la conception sont claires.

Le modle en W
Ce modle est une variante du modle en
V .
Le cycle de dveloppement ne commence
que quand les problmes ou les besoins
sont parfaitement connus (cf. module de
communication selon la mthode Merise).
Un cycle en W peut tre coupl un
cycle en V , quand il est ncessaire de
dcomposer le systme en sous-systmes.

56

Le modle en W
Exigences
brutes

Spcification des
IHM du systme

Vrification des
flux logiques

Validation ou tests
dacceptation

Conception des
sous-systmes

Intgration et tests
des sous-systmes

Conception des
modules

Intgration et tests
des modules

2me cycle de Goldberg

Codage et
tests unitaires

57

Le modle en spirale

Ce modle complexe est d Boehm.

Il apporte une vue volutive au modle en
cascade au travers dune approche fonde sur
lanalyse et la gestion des risques, puis la
conception et la ralisation de prototypes
volutifs en fonction de lavancement du projet.
Le dveloppement prsente quatre grandes
phases qui se succdent au fur et mesure de la
construction de la spirale,
Au dernier tour de la spirale, le produit est
totalement dfini, les risques rsolus et le produit
dvelopp.
58

Dveloppement spirale

59

Le modle en spirale

Premier cycle : Analyse du risque Prototype 1 Simulations

et/ou modlisations et/ou bancs d'essais Dfinition de la
mission (par la MO) Planification de l'analyse (c'est--dire du
cycle suivant, portant principalement sur un travail d'analyse)
Second cycle : Analyse du risque Prototype 2 Simulations
et/ou modlisations et/ou bancs d'essais Dfinition (par la ME)
et validation (par la MO) des besoins Dfinition du plan de
dveloppement (c'est--dire des deux cycles suivants, consacrs
la conception, au codage, aux tests et la mise en oeuvre du
logiciel)
Troisime cycle : Analyse du risque Prototype 3
Simulations et/ou modlisations et/ou bancs d'essais Dfinition
(par la ME), vrification (par la ME) et validation (par la MO) de la
conception gnrale Rajustement, le cas chant, du plan de
dveloppement (ne concerne que la conception dtaille, le
codage, les tests et la mise en oeuvre du logiciel)
Quatrime cycle : Analyse du risque Prototype 4
Simulations et/ou modlisations et/ou bancs d'essais
Conception dtaille, codage, tests divers et mise en oeuvre du
logiciel
60

Dveloppement spirale

Secteurs

Prciser les objectifs

Dfinir et minimiser le risque
Dveloppement et validation
Planifier litration suivante

61

Processus volutif

Aperu de
description

Spcification

Version initiale

Dveloppement

Versions
intermdiaires

Validation

Versions
finale

62

Le cycle itratif incrmental

Risques initiaux,
porte du projet

Planification
de litration
Dveloppement de
litration
Itration N

valuation

Rvision du
plan du projet
Risques limins
Rvision des risques
63

Itration

Phase

Objectif

Itration
prliminaire

Etude dopportunit

Comprendre le
problme

Dcision
Ressources pour
llaboration

Itration
darchitecture

Elaboration

Comprendre la
solution

xN

Ressources pour la
construction

Itration de
dveloppement

Construction

Raliser la solution

xN

Livrer le produit
(version bta)

Itration de
transition
xN

Transition

Transmettre la
solution

Recette client
64

Les avantages des cycles de vie

itratifs et incrmentaux

Ces processus sont bass sur lvolution de

prototypes excutables :
Lutilisateur est plac devant des situations
dutilisation concrtes. Il est partenaire du projet.
Lintgration est progressive et permet dviter
leffet big bang lapproche de la date de
livraison.
Les progrs se mesurent par des programmes
dmontrables et non par des documents ou
estimations.
Le dcoupage par incrments permet de rduire la
complexit du systme en la ventilant dans les
incrments.
65

Dveloppement par composants

Spcification
des besoins

Analyse des
composants

Conception avec
rutilisation

Modification
des besoins

Dveloppement
et intgration

Validation

66

Origine et dfinitions

Problmes

Fiabilit comment lutilisateur va croire que le

composants ne va pas chouer
Certification qui va certifi le composant
Les proprits intgrales comment les prvoir
Compromis des besoins comment faire le compromis
entre les besoins assurs des diffrents composants

Caractristiques

Standardis
Indpendant
Composable
Dployable
Document
67

Interface de composants

Requires interface
Defines the services
from the components
environment that it
uses

Provides interface
Component

Defines the services

that are provided
by the component
to other components

68

Composants et objets
Les composants sont dployables
Les composants ne dfinirent pas des
types
Limplmentation des composants est
opaque
Les composants sont indpendant de
langage
Les composants sont standardiss

69

Modles

Dfinition

Le modle de composants cest la dfinition

des standard pour implmentation,
documentation et dploiement du composant

Exemples

EJB
.NET (COM+)
Corba Component Model

70

Elments du modle
Customisation

Naming
convention
Composition
Interface
definition

Specific
interfaces

Interfaces

Documentation
Meta-data
access
Usage
information

Packaging

Evolution
support

Deployment
and use

Component model

71

Gestion des risques

Quest ce que cest risque?

La probabilit que quelque circonstances
dfavorables vont arriver

Types de risque

De projet affecte lemploi de temps ou les

ressources
De produit affecte la qualit et le
comportement du logiciel
Dorganisation affecte le lorganisation

72

Gestion des risques

Identification de risque
Analyse de risque

Planifier le risque

Estimer la probabilit et consquences;

Plans dviter et minimiser les effet du risque;

Suivi du risque

73

Gestion des risques

Identification des
risques

Analyse

Planifier

Suivi

Liste de risques
potentiels

Liste prioritaire
des risques

Plans pour
viter les risques et
durgence

Estimer le risk

74

Gestion des risques

Identification du risque

Technologiques
Personnel.
Organisation.
Besoins.
Estimation.

Analyse La probabilit et les effets du

sinistre

Probabilit trs basse, basse, modre,

haute, trs haute.
Effets catastrophique, srieux, tolrable,
insignifiant.

75

Gestion des risques

Planifier pour chaque risque

Stratgie dviter le risque diminuer la

probabilit
Stratgie de minimisation minimiser leffet
du sinistre
Plan durgence quand lvnement arrive
quest ce quon doit faire.

Suivi

Estimer chaque risque par priodes rguliers

pour voir si la probabilit a chang.
Estimer les effets de chaque risque
Ne pas voir peur de discuter les problmes

76

Annexe

Cahier de Charge:

est le recueil des exigences fonctionnelles

demandes par la matrise d'ouvrage, il dcrit des
rgles de gestion et de traitement dans le langage
du mtier (vue externe du systme, c'est la vision
utilisateur).

Cahier de Spcifications:

est la traduction du cahier des charges en termes

plus techniques (donnes en entre, donnes en
sortie, description des crans de l'IHM, rgles de
calcul, de transformation des donnes, ...) dont le
but est de dcrire de faon dtaille comment les
exigences fonctionnelles vont tre implmentes 77

Annexe (1)

Spcifications:

Des scenarii plus dtaills

Base de la conception du systme
Ils peuvent tre inclus dans le cahier de charge
et dans le contrat
On peut utiliser et des modles du systme
(les UML diagrammes)
Ils sont interdpendants avec larchitecture du
systme

78

Annexe (2)

Dsavantages de la langue naturelle

Ambigut
Sur-flexibilit
Manque de structure

Alternatives

Langues structures formulaires, modles,

tableaux
Langages spcifiques rarement utiliss
Notations graphiques UML
Spcifications mathmatiques
79

Annexe (3)
Modifier un
item

Ajouter un
item

Supprimer
un item
Consultation de
linventaire

Commande
fournisseur

Saisir livraison

Responsable
des
oprations
Produire des
rapports

80

Annexe (4)

Spcifications fonctionnelles

Le guichet doit vrifier la validit de la carte

insre
Le guichet doit valider le code PIN.
Le guichet doit allouer une somme maximum
de 5000 DH

Spcifications non fonctionnelles:

Le systme de Guichet doit tre ralis en

C++
Le systme doit utiliser un cryptage de 256
bits
Le systme doit vrifier le PIN en moins de 3
sec.

81

Mthodes danalyse et de
Conception

82

Analyse et Conception

Analyse du systme

modlisation du domaine, modlisation de lexistant

(ventuellement),
dfinition dun modle conceptuel (ou spcification
conceptuelle),
plan de validation.

On labore un dossier danalyse plus un plan de validation.

Conception

proposition de solution au problme spcifi dans lanalyse

organisation de lapplication en modules et interface des
modules (architecture du logiciel),
description dtaille des modules avec les algorithmes
essentiels (modle logique)
structuration des donnes

On labore un dossier de conception plus un plan de test

global et par module

83

Mthodes dAnalyse et de Conception

Proposition d une dmarche distinguant les

tapes du dveloppement dans le cycle de vie du
logiciel (modularit, rduction de la complexit,
rutilisabilit ventuelle, abstraction)

Utilisation d un formalisme de reprsentation qui

facilite la communication, lorganisation et la
vrification

Production de documents (modles) qui facilitent

les retours sur conception et lvolution des
applications

84

Techniques de Conception

Mthodes fonctionnelles hirarchiques

Mthodes donnes

Data-Flow/SADT/SA-SD, Structure-Chart, ...

Entit-Relation, MERISE, UML

Mthodes comportements

Rseaux de Ptri, ...

85

Mthodes fonctionnelles: SADT

SADT : technique structure d'analyse et

de modlisation

86

Mthodes fonctionnelles: SADT (2)

87

Mthodes fonctionnelles: SADT (3)

88

Mthodes fonctionnelles: Data Flow

sang

Paramtres du sang
Capteur de
glucose sanguin

Analyse de
glucose sanguin

Niveau du glucose

Calcul du besoin
dinsuline
insuline

Instructions vers la pompe

Pompe dinsuline

Gestion de dlivrance
dinsuline

Besoin dinsuline

89

Mthodes fonctionnelles: Data Flow (2)

Visio 2000

Visio 5.x
From Flow Chart /
Data Flow Diagram

From Software Diagram /

Gane-Sarson DFD

From Flow Chart /

Data Flow Diagram

ID #

Process
Process

Process

Data Store
Data Store

Data Store

ID
#

External Entity

External
Entity

External
Entity

90

Mthodes fonctionnelles: Data Flow (3)

91

Mthodes fonctionnelles: Data Flow (4)

92

Mthodes donnes: Entit-Relation

Entit [dfinition de Chen] :

chose qui peut tre identifie distinctement
Proprit (ou Attribut) :
les entits (et les associations) sont dcrites par des
proprits caractrises par un nom et un type
Association [dfinition de Chen] :
Lien entre entits
elle peut tre binaire, ternaire, n-aire

93

Mthodes donnes: Entit-Relation (2)

94

Mthodes donnes: Merise

Merise

Une approche systmique

Approche fonctionnelle
A une vision duale des donnes-traitements
A trois niveaux dabstraction

Niveau conceptuel
Niveau logique
Niveau physique

95

Mthodes donnes: Merise - MCT

96

Mthodes donnes: UML

Systme rel

Analyse
Modle
dAnalyse

Conception
Modle
de
Conception

Ralisation
Modle
de
Ralisation

Dploiement
Modle
de
Dploiement

BOOCH, OMT, OOSE,

UML (Unified Modeling Language)

97

Mthodes donnes: UML (2)

Rsum
UML est une notation, pas une mthode
UML est un langage de modlisation objet
UML convient pour toutes les mthodes objet

Programmation Oriente Objet

modliser informatiquement des lments d'une partie du monde rel en
un ensemble d'entits informatiques (objets)
Intrt d'une mthode objet
dfinir le problme haut niveau sans rentrer dans les spcificits du
langage
dfinir un problme de faon graphique
utiliser les services offertes par lobjet sans rentrer dans le dtail de
programmation (Encapsulation)
Rutilisation du code
98

Mthodes donnes: UML (3)

Voiture
Numro de srie : Int
Poids : double
Immatriculation : String
Kilomtrage : double

FIAT-UNO-17
233434 : Numro de srie
1500 kg : Poids
8864 YF 17 : Immatriculation
33 000 : kilomtrage

Dmarrer ()
Arrter()
Rouler()

Renault-Clio-17
5323454 : Numro de srie
1500 kg : Poids
64 YFT 17 : Immatriculation
23 000 : kilomtrage

Peugeot-206-75
3434 : Numro de srie
1700 kg : Poids
8634 YGG 75 : Immatriculation
15 000 : kilomtrage

99

Mthodes donnes: UML (4)

Vues statiques
Les diagrammes
Les diagrammes
Les diagrammes
Les diagrammes
Les diagrammes

de classes
dobjets
de cas dutilisation
de composants
de dploiement

Vues dynamiques
Les diagrammes
Les diagrammes
Les diagrammes
Les diagrammes

de squence
de collaboration
dtats-transition
dactivits

100

Mthodes donnes: UML (5)

Cas dutilisation

Acteur

Objectif du systme, motiv par un besoin

d'un (ou plusieurs) acteur(s)
Personne ou composant dorigine dune
interaction avec le systme
Documente un lment du modle

Note

Relation dutilisation

Le cas source contient aussi le comportement

dcrit dans la cas destination

101

Mthodes donnes: UML (6)

102

Mthodes comportements
Rseaux de Ptri

C'est un ensemble d'automates tats finis communicants

Pour pouvoir analyser :
on reprsente les tats internes des automates et les
communications entre les automates avec les mmes
primitives
Graphe avec deux types de nuds
les tats (partiels = des automates) sont des ronds ce
sont les places
les transitions (arcs dans la reprsentation des
automates) sont des rectangles (barres)
Les communications
asynchrones : ajout (ou fusion) de places
synchrones : fusion (ou ajout) de transitions
103

Mthodes comportements
Rseaux de Ptri (2)

104

Outils dAnalyse et dimplmentation

105

Les outils de gnie logiciel

Outils
Outils
Outils
Outils
Outils
Outils
Outils
Outils

dAnalyse
de design
de modlisation (diagrammes)
de programmation
de gestion de projet
de prototype
de qualit
de maintenance
106

Outils dAnalyse
Ces outils permettent de rassembler les
besoin et les obligations.
Vrifier les redondance et traduite
automatiquement les spcifications textes
vers des schmas basique.
Exemples:

Accept 360.
Visual Paradigm.
CaseComplete.
Visible Analyst.
107

108

Outils de Design
Ces outils aident les concepteurs de
logiciels pour concevoir la structure du
bloc du logiciel qui peut en outre tre
dcompos en modules plus petits en
utilisant des techniques de raffinement.
Ces outils montrent linteraction entre les
diffrents gros modules.
Exemples: Animated Software Design

109

110

111

Outils de modlisation
Ces outils sont utiliss pour reprsenter
les composants du systme, les donnes
et les flux de contrle.
Ces composants sont reprsents en
frome graphique tout en montrant
linteraction entre les diffrents objets.
Exemples: Flow Chart Maker, jMerise,
Rational Roze, ArgoUML.

112

113

114

115

Outils de prototypage
Prototype de logiciel est une version
simule du logiciel prvu. Le Prototype
fournit une premire impression du
produit et simule quelques aspect du
produit rel.
Un outil de prototypage est compose de
plusieurs briques graphiques pour crer
une version rapide.
Exemples: Windev, Dreamweaver, Mockup
Builder, Visual Sudio, NetBeans.

116

Outils de prototypage (2)

117

Outils de programmation

Ces outils consistent a construire les

modules et les diffrents composants.

Ces outils permettent aussi de gnrer des

livrables, simuler et tester les
fonctionnalits.

Exemples: Eclipse, NetBeans, Visual

Studio
118

Outils de programmation: Eclipse

119

Outils de programmation: NetBeans

120

Outils de programmation: V. Studio

121

Outils de Gestion de Projet

Ces outils sont utiliss pour la planification
du projet, le cot, l'effort, planification de
projet et planification des ressources.
Les gestionnaires doivent respecter
strictement l'excution du projet chaque
tape mentionne dans la gestion de projet
logiciel.
Outils de gestion de projet aident stocker
et partager des informations sur le projet en
temps rel dans toute l'organisation.
For example: SCRUM.

122

Les mthodes agiles

Une mthode agile est une approche itrative et

incrmentale, qui est mene dans un esprit collaboratif
avec juste ce quil faut de formalisme

Elle gnre un produit de haute qualit tout en prenant

en compte lvolution des besoins des clients

Concepts formaliss en 2001 par le Manifeste Agile.

123

Les mthodes agiles (2)

Les 4 principes essentiels du Manifeste Agile:
L'quipe : Personnes et interactions plutt que processus et
outils

L'application :Logiciel fonctionnel plutt que documentation

complte
La collaboration :Collaboration avec le client plutt que
ngociation de contrat
L'acceptation du changement :Ragir au changement plutt
que suivre un plan.

124

Scrum Principes cls

Scrum est une mthode agile qui permet de produire la plus

grande valeur mtier dans la dure la plus courte.
Mthode itrative et incrmentale:

Ralisation dun ensemble de fonctionnalits par itration

Itration dune dure fixe (d2 4 semaines)// sprint

Livraison dun produit partiel fonctionnel par itration

Participation du client:

Dfinition des fonctionnalits prioritaires

Ajout de fonctionnalits en cours de projet (pas pendant un sprint !)

125

Scrum Les rles

Les rles:

Le product owner
Le scrummaster
Lquipe

12
6

Scrum Planifier un projet

LCL GUR Remaining
300

250

Number

200

150

100

50

0
0

10

11

12

Jour

Constitution du backlog produit par le product owner.

Rpartition en sprints et en releases.

127

Scrum Organisation 1/5

Source : www.scrumalliance.org

1. Backlog produit (ou catalogue des besoins)

Besoins prioriss par le product owner

Besoins valus par lquipe

128

Scrum Organisation 2/5

Source : www.scrumalliance.org

2. Backlog de sprint
Extrait du backlog produit
Besoins clats en tches
129

Scrum Organisation 3/5

3. Sprint
Dveloppement des fonctionnalits du backlog de sprint
Aucune modification du backlog de sprint possible
130

Scrum Organisation 4/5

Source : www.scrumalliance.org

4. Mle quotidienne
Point de contrle quotidien de lquipe
Interventions rgules 2 min. par personne
131

Scrum Organisation 5/5

Source : www.scrumalliance.org

5. Incrment logiciel : livr au product owner la

fin du sprint.
132

Scrum Indicateurs de projet 1/2

Le tableau des tches

133

Scrum Indicateurs de projet 2/2

Le burndown chart

134

Scrum Ingnierie logicielle

Scrum est une mthode de gestion de

projet

Doit tre complte par des techniques

dingnierie logicielle

Complmentaire avec Extreme

Programming :

Test Driven Development

Intgration continue
135

Outil de qualit

Assurance de la qualit dans un

dveloppement logiciel consiste a mettre
en place un processus d'ingnierie et des
mthodes adoptes pour dvelopper le
produit conforme selon les normes du
standard.

Qualit logicielle.

136

Qualit Logiciel

Les outils de versionning

Les tests unitaires

Junit

Lintgration continue

SCM, SVN, SubVersion

Hudson, Jenkins

Les outils de compilation

Inspection de code

Sonar,
137

Qualit Logiciel: Versioning

Grer les sources dans le temps

Conserver un historique de toutes les

modifications - plusieurs versions de
chaque fichier

Coordonner les travaux de plusieurs

auteurs

Montrer les diffrences entre les versions

d'un fichier

Modifications du document - la raison du

changement

138

Qualit Logiciel: Versioning (2)

client

checkout (first
time)

(do some work, test)

check status
update
(resolve conflicts)
commit
(do more work, test)

server

Envoyer la version ( n )
Vrifier sil y a des changements
Mettre a jour la version locale
par celle du serveur
Mettre a jour le serveur par le
contenu local

Qualit Logiciel: Versioning (3)

Repository parent dir

Root
Project 1

Project 1

trunk

trunk

tags

tags

branches

Project 2

branches

Project 2

trunk

trunk

tags

tags

branches

branches

Qualit Logiciel: Versioning (4)

/var/svn/kuclock
revision 4
revision 3
revision 2
revision 1
(initial repo
structure)

revision 3:
content diffs
author
date

reason for change (comment)

revision 2:
initial project check-in
...etc...

Qualit Logiciel: Versioning (5)

0

Numro de la
rvision est
augmente pour
chaque
transaction qui
modifie le
repository.

Proprits dun Repository

Histoire de toutes les modifications apportes aux

fichiers et rpertoires.
Il est possible de rcuprer une version
prcdente d'un fichier.
Contrle daccs

Autorisation de lecture / criture pour les utilisateurs et

les groupes
Les autorisations peuvent appliquer repo, rpertoire ou
un fichier

Logging

Auteur du changement
La date du changement
La raison du changement

SVN cycle de vie

Soumettre les changements

Crer une copie locale

svn checkout
svn update

Subversion
Repository

svn commit
106

100

Fixer les conflits

Faire des changements

svn add
svn move
svn delete

svn diff
svn resolved
105

Vrifier ce qui a t chang

svn status -u

Mettre a jour la copie locale

svn update

Qualit Logiciel: Les tests unitaires

Junit

145

Qualit Logiciel: Les tests de charge

jMeter

146

Qualit Logiciel: Les tests de non rgression

Cahier de Tests

MyIcIphone Client

Tel : +33 (0)2 98 14 30 40

Doc Reference

Author
Audited by
Approved by

Fax : +33 (0)2 98 14 39 06

Mail : professional.services@alcatel-lucent.fr

Title
Test document

File Name
MyIcIphone MyIcTestGuide.doc

Fonction

Name

Ingnieur dveloppeur
Team Leader / Contact Administrative
Manager

Y. Gahi

Alcatel-Lucent Services for Enterprise

All Rights Reserved Alcatel-Lucent 2007

147

Qualit Logiciel: Lintgration continue

Spcifications

Spcifications

Dveloppeme
nt

Intgration

Dveloppement
Intgration

148

Qualit Logiciel: Lintgration continue

149

Qualit Logiciel: Lintgration continue

Hudson

150

Qualit Logicielle: Outil de compilation

Debuggage

151

Qualit Logicielle: Inspection du code

Cobertura et Sonar

152

Qualit Logicielle
4 Build + Tests
5 Dploiement

$ Gcc c *.c o test

Compiling
Compilation Sucessfull
Testing
Junit tests OK
Integration tests OK
Performance tests OK
Code Inspection 86%
Deploying in test environnement OK

Serveur de test

6 Notification

Serveur dintgration
3 Update

Serveur de recette

2 Vrification des

modifs

Postes de dev

Serveur de production

1 Commit

SCM

Outils de maintenance

La maintenance du logiciel comprend des

modifications dans le produit logiciel aprs
sa livraison.

Des logs automatiques, des prise decrans,

rapports techniques

Exemples: Bugzilla, JIRA.

154

Outils de maintenance (2): Bugzilla

Bugzilla

155

Design Patterns

156

Les patrons de conception

Patron de conception = design pattern

Un design pattern traite un problme de

conception recurrent.
Ne pas rinventer la roue.
Facilite la communication entre dveloppeurs

Il apporte une solution gnrale,

indpendante du contexte
Description de l'organisation de classes et d'instances en
157
interaction pour rsoudre un problme de conception

les patrons de conception (2)

Quatre lments principaux dfinissent un patron

Objectif

Problme / Motivation

Quand appliquer le patron de conception

Relations problmatiques entre les classes

Solution propose

Description de son utilit

Elments impliqus
Relations entre les lments
Schmas conceptuels (e.g., diagrammes UML)

Consquences

Compromis ventuels
Qualit de la solution
158

Catgories de Design Patterns

Cration

Structure

Description de la manire dont un objet ou un ensemble

dobjets peuvent tre crs, initialiss, et configurs
Isolation du code relatif la cration, linitialisation
afin de rendre lapplication indpendante de ces aspects
Description de la manire dont doivent tre connects
des objets de lapplication afin de rendre ces connections
indpendantes des volutions futures de lapplication
Dcouplage de linterface et de limplmentation de
classes et dobjets

Comportement

Description de comportements dinteraction entre objets

Gestion des interactions dynamiques entre des classes
et des objets

159

Design Patterns du GoF

160

Cration

Abstraction du processus de cration.

Encapsulation de la logique de cration.

On ne sait pas a l'avance ce qui sera

cre ou comment cela sera cr.

161

Cration: Singleton

Problmes:

Certaines applications possdent des classes

qui doivent tre instancies une seule et
unique fois
Assurer qu'il n'existe qu'une seule instance de
la classe
Fournir un moyen d'obtenir cette instance
unique

Solution:

Une seule instance est renvoye a chaque fois

162

Cas dutilisation

le cas dune classe qui implmenterait un

pilote pour un priphrique, ou encore un
systme de journalisation. En effet,
instancier deux fois une classe servant de
pilote une imprimante provoquerait une
surcharge inutile du systme et des
comportements incohrents.

163

Meilleur Solution
La premire tape consiste
empcher les dveloppeurs
dutiliser le constructeur
de la classe pour linstancier
dclarer priv tous
les constructeurs de la
classe.

Nous allons construire

un pseudo constructeur.

il faut dclarer une

mthode statique qui
retournera un objet
correspondant au type de
la classe

164

Exercice

On veut crer un
Aeroport ainsi que des
objets de type Avion.
Voici le code des classes
Aeroport et Avion, ainsi
que de la classe test de
l'ensemble.

On souhaite que les

clients, les objets de type
Avion, ne puisse pas crer
plus d'un Aeroport,afin qu'ils
se situent tous dans un
mme Aeroport. Comment
empcher la possibilit un
Avion de crer un Aeroport
s'il en existe dj un ?

165

Cration: Factory

Problmes:

Le client ne peut dterminer le type d'objet

crer qu' l'excution
Il y a une volont de centraliser la cration des
objets

Solutions:

Concevoir une classe qui va instancier

diffrents types d'objets suivant un paramtre
fourni
Des applications individuelles de dfinir elles166
mmes leurs propres objets crer

Cas dutilisation

une usine va fabriquer des produits en fonction du modle

qu'on lui indique.
L'ide la plus simple pour rpondre ce besoin est d'crire
une succession de conditions qui suivant le modle
demand, instancie et retourne l'objet correspondant.
Le problme avec cette implmentation, c'est que la classe
correspondant l'usine va tre fortement couple tous les
produits qu'elle peut instancier car elle fait appel leur type
concret. Or ce code va tre amen voluer rgulirement
lors de l'ajout de nouveaux produits fabriquer ou de la
suppression de certains produits obsoltes.

On se retrouve alors avec du code fortement coupl, qui

risque d'tre dupliqu plusieurs endroits de l'application.
167

Meilleur Solution
La premire solution
est de regrouper
l'instanciation de tous
les produits dans une
seule classe charge
uniquement de ce rle.
On vite alors la duplication
de code et on facilite l'volution
au niveau de la gamme des produits.
L'utilisateur du produit fait appel la Fabrique Simple pour
obtenir un Produit.
L'utilisateur du produit est donc fortement coupl
uniquement la Fabrique Simple et non tous les produits
168
qu'il prend en charge.

Meilleur Solution (2)

Etape 1: Crer un interface

Etape2: Crer les

Classes

Etape3: Crer le Factory

169

Meilleur Solution (3)

Etape4: utiliser le Factory

170

Exercice
Modifier la structure pour
Eviter les duplications et optimiser
larchitecture a laide du concept
Factory.
Rgles:
1) On dfinit un interface qui
contient la mthode commune.
2) Toutes les classes implmente
linterface.
3) On dfinit une nouvelle classe
qui se charge de la cration
des diffrents objets.
4) La nouvelle nutilise pas le type
Programme1, mais plutt
linterface gnrique.
5) Le client ne communique
quavec cette classe.

171

Structure

Ces modles de conception tentent de

composer des classes pour btir de
nouvelles structures.

Comment sont assembls les objets.

Dcoupler l'interface de l'implmentation.

On obtient donc une structure plus large

mais toujours facilement manipulable.

172

Structure: Adaptateur

Problme:

Lutilisation dune classe existante dont linterface ne nous

convient pas.
Utilisation de plusieurs sous-classes dont ladaptation des
classes est impossible par drivation

Solutions:

L'Adapteur ou Adapter est un moyen commode de faire

fonctionner un objet avec une interface qu'il ne possde
pas.
L'ide est de concevoir une classe supplmentaire qui se
charge d'implmenter la bonne interface (L'Adapteur) et
d'appeler les mthodes correspondantes dans l'objet
utiliser (L'adapt).
173

Cas dutilisation

Le systme doit intgrer un soussystme existant. Ce sous-systme a une

interface non standard par rapport au
systme.

Cela peut tre le cas d'un driver bas

niveau pour de l'informatique embarque.
Le driver fournit par le fabricant ne
correspond pas l'interface utilise par le
systme pour d'autres drivers.
174

Meilleur Solution
La solution est de masquer
cette interface non stantard
au systme et de lui
prsenter
une interface standard. La
partie cliente utilise les
mthodes de l'Adaptateur qui
utilise les mthodes du soussystme pour raliser les
oprations correspondantes.

175

Structure: Composite

Problme:

Etablir des structures arborescentes entre des

objets et les traiter uniformment.

Solutions:

Le modle Composite cherche liminer toute

diffrence entre un groupe d'objets et un objet.
Il s'agit d'une dmarche rcurrente valable pour
tous les problmes qui font merger de
nouvelles structure par association.

176

Cas dutilisation

Vous avez l'impression d'utiliser de

multiples objets de la mme faon,
souvent avec des lignes de code
identiques ou presque. Par exemple,
lorsque la seule et unique diffrence entre
deux mthodes est que l'une manipule un
objet de type Carr, et l'autre un objet
Cercle. Lorsque, pour le traitement
considr, la diffrenciation n'a pas besoin
d'exister, il serait plus simple de
considrer l'ensemble de ces objets
comme homogne.

177

Meilleur Solution

Un exemple simple consiste considrer l'affichage des noms de fichiers contenus

dans des dossiers :
Pour un fichier, on affiche ses informations.
Pour un dossier, on affiche les informations des fichiers qu'il contient.
Dans ce cas, le patron composite est tout fait adapt :
L'Objet est de faon gnrale ce qui peut tre contenu dans un dossier : un
fichier ou un dossier,
L'ObjetSimple est un fichier, sa mthode affiche() affiche simplement le nom du
fichier,
L'ObjetComposite est un dossier, il contient des objets (c'est dire des fichiers
et des dossiers). Sa mthode affiche() parcourt l'ensemble des objets qu'il
contient (fichier ou dossier) en appelant leur mthode affiche().

178

Comportement

Description de structures dobjets ou de

classes avec leurs interactions.

Le modle de comportement simplifie

l'organisation d'excution des objets.

ils dfinissent comment organiser les

objets pour que ceux-ci collaborent
(distribution des responsabilits)
179

Comportement: Observateur

On trouve des classes possdant des

attributs dont les valeurs changent
rgulirement.

Un certain nombre de classes doit tre

tenu inform de lvolution de ces valeurs.

180

Cas dutilisation

On considre une classe HeurePerso possdant dans

le mme attribut lheure et la minute courante.
Cette classe est utilis par une autre classe
AfficheHeure pour laffichage de lheure courante
dans un cran.
Quelle dmarche adopter pour que la classe charge
de laffichage soit tenue informe en temps rel de
lheure courante stocke dans la classe HeurePerso
?
Deux solutions possibles:

Soit la classe daffichage se charge de demander la

classe HeurePerso la valeur de son attribut
soit cest la classe HeurePerso qui informe la classe
AfficheHeure lors de changements.

181

Meilleur solution: Obesrvateur

Linterface Observateur
sera implment par toutes
classes qui souhaitent avoir
le rle dobservateur.
la classe ObservateurConcret
qui implmente la mthode
actualiser(Observable). Cette
mthode sera appele
automatiquement lors dun changement dtat de la classe
observe.
On trouve galement une interface Observable qui devra tre
implmente par les classes dsireuses de possder des
observateurs.

182

Comportement: Iterateur

Problme:

Une collection contient un ensemble d'objets

stock par diffrentes mthodes (un tableau,
un vecteur...).
L'exploitant qui accde a contenu de la
collection ne souhaite pas tre concern par
cette manire de grer les objets.

Solution:

Un seule interface qui gre tout type dobjets

183

Meilleur Solution

Un itrateur ressemble un
pointeur disposant
essentiellement de deux
primitives:
Accder l'lment point
en cours (dans le
conteneur)
Se dplacer pour pointer
vers l'lment suivant

184

Merci pour votre attention

Questions / Rponses

185