Routage Et Protocoles de Routage

1
Dveloppement de Systmes
Informatiques Orients objets en UML
lments du gnie logiciel, du paradigme objet et de la notation
unifie
Djamel-Abdelhak SERIAI
seriai@ensm-douai.fr
http://csl.ensm-douai.fr/seriai
Objectifs du cours
Le Logiciel et le Gnie logiciel
Les concepts objet travers UML
Le paradigme objet
Notation UML des concepts objet
La notation UML pas pas
Cest quoi le problme ?

Cycle de vie dun logiciel
Les mthodes de dveloppement (SADT, Merise, ,UML...?)
Les diffrents diagrammes

Des exemples
Le langage OCL (?)
Des travaux pratiques pour matriser UML

Les outils CASE
Dveloppement dun exemple complet
Organisation du cours
Organisation du cours
Le logiciel
et
Le Gnie logiciel
20/01
Cours
TP
Approche objet
et UML
Notation
UML
Notation
UML
22/01
27/01
03/02
TP UML
un exemple de A Z
Un outil CASE (AGL)
24/02
26/02
Partie I : Le Logiciel et
le Gnie logiciel
Logiciel et Gnie logiciel
Introduction en image : Informatique et logiciels

Logiciel et processus de
dveloppement
Fonctions ralises dans un environnement

suivant certaines exigences
(performance, sret, etc.)
Service
Produit
Processus
Caractristiques
Du systme :
Structure, adaptabilit,
Complexit, etc.
Organisation des moyens,

procdures, mthodes et
Outils pour dvelopper et
valider le produit
Caractristiques dun produit logiciel
Un logiciel est un produit (manufactur) comme une voiture ou une

machine outils
Procd de fabrication : processus de dveloppement
Un logiciel est un produit avec des caractristiques particulires
Pas de problme de fabrication en srie

La reproduction dun logiciel se fait par simple copie
Processus de dveloppement itratif : certaines tapes peuvent

dclencher la rvision des tapes prcdentes :
La dtection dune erreur lors dun test va dclencher un retour sur la
programmation, peut-tre la conception voir mme la spcification
Le procd de fabrication dun logiciel est invisible

pour pallier au problme de l'invisibilit, il donne lieu la production de documents
intermdiaires permettant de contrler un logiciel en cours de dveloppement
Caractristiques dun produit logiciel
Un logiciel est un produit avec des caractristiques particulires

Le processus de dveloppement se poursuivi aprs la livraison
du logiciel, pour la maintenance
Aprs son dveloppement un produit logiciel est mis en exploitation et
entre dans une phase de maintenance qui peut remettre en cause les
fonctions du systme et impliquer des modifications et/ou un redveloppement
La correction des dfauts : maintenance corrective
Adaptation du logiciel un nouvel environnement : maintenance
adaptative
Amlioration des caractristiques et suivi de lvolution des
besoins : maintenance perfective
La crise du logiciel
Quelques constats de l'ampleur de l'impact des dfaillances :
la sonde Mariner vers Vnus s'est perdue dans l'espace cause

d'une erreur de programme FORTRAN ;
en 1972, lors d'une exprience mtorologique en France 72

ballons contenant des instruments de mesure furent dtruits
cause d'un dfaut dans le logiciel ;
en 1981, le premier lancement de la navette spatiale a t

retard de deux jours cause d'un problme logiciel. La navette
a d'ailleurs t lanc sans que l'on ait localis exactement le
problme (mais les symptmes taient bien dlimits) ;
le dveloppement du compilateur PL1 de Control Data n'a

jamais abouti ;
10
Quelques constats de l'ampleur de l'impact des dfaillances :
EDF a rcemment renonc la mise en service de nouveaux

systmes de contrle-commande de ses centrales 1400 mgawatts
la SNCF a rencontr des difficults importantes pour la mise en

service du systme Socrate
l'explosion d'Ariane 5, le 4 juin 1996, qui a cot un demi

milliard de dollars (non assur !), est de une faute logicielle
d'une composante dont le fonctionnement n'tait pas
indispensable durant le vol
Pourquoi : manque de mthodologie de dveloppement des

produits logiciels
11
Prise de conscience :
La premire reconnaissance publique de la crise du logiciel a t faite

lors dune confrence Garmisch
Les symptmes les plus caractristiques de cette crise sont :
Les logiciels raliss ne correspondent souvent pas aux besoins des utilisateurs
Les logiciels contiennent trop derreurs (qualit du logiciel insuffisante)
Les cots de dveloppement sont rarement prvisibles et sont gnralement
prohibitifs
La maintenance des logiciels est une tche complexe et coteuse
Les dlais de ralisation sont gnralement dpasss
Les logiciels sont rarement portables
12
Prise de conscience :
Comparer lvolution du cot du logiciel et du matriel :

Le cot du matriel baisse rgulirement;
Le matriel devient de plus en plus puissant, conduisant la
ralisation de logiciels de plus en plus complexes et donc coteux
Le cot des logiciels reprsenterait actuellement 85 % des
dpenses totales des systmes informatiques
13
Quelques sources de la crise
Une ide grossire du logiciel raliser est suffisante pour

commencer dcrire un programme (il est assez tt de se
proccuper des dtails plus tard).
Faux : une ide imprcise du logiciel raliser est la cause
principale dchecs
Une fois que le programme est crit et fonctionne, le travail est

termin.
Faux : la maintenance du logiciel reprsente un travail important :
le cot de la maintenance reprsente plus du 50 % du cot total dun
logiciel
14
Quelques sources de la crise
Si les spcifications du logiciel raliser changent

continuellement, cela ne pose pas de problme, puisque le
logiciel est un produit souple
Faux : des changements de spcifications peuvent se rvler coteux et
prolonger les dlais
Si la ralisation du logiciel prend du retard par rapport aux dlais

prvus, il suffit dajouter plus de programmeurs afin de finir dans
les dlais.
Faux : si lon ajoute de gens un projet, il faut compter une priode de
familiarisation. Le temps pass communiquer lintrieur du groupe
augmente galement, lorsque la taille du groupe augmente
15
Le gnie logiciel
Est un domaine de recherche qui a t dfini (fait rare) du 7 au 11

octobre 1968, Garmisch-Partenkirchen, sous le parrainage de
l'OTAN.
Le gnie logiciel est la discipline ne en rponse la crise du logiciel.
Le gnie logiciel se caractrise par une approche rigoureuse et

systmatique la construction de logiciels ne pouvant tre matriss
par une seule personne.
Le gnie logiciel est donc l'art :

De spcifier, de concevoir, de raliser, et de faire voluer des
programmes, des documentations et des procdures de qualit
Avec des moyens et dans des dlais raisonnables, en vu d'utiliser un
systme informatique pour rsoudre certains problmes.
16
Le gnie logiciel
Objectif du gnie logiciel
Optimiser le cot de dveloppement du logiciel.

L'importance d'une approche mthodologique s'est montre par la crise de
l'industrie du logiciel la fin des annes 60 :
augmentation des cots ;

difficults d'volution ;
non fiabilit ;
non respect des spcifications ;
non respect des dlais.
17
Cycle de vie de logiciel
Dans la ralisation d'un programme simple, fait par une personne, il

est possible de distinguer 3 phases:
la phase d'analyse du problme;
la phase de codage et de mise au point;
la phase d'opration (le programme est oprationnel).
Cette approche n'est pas approprie pour un projet important

impliquant plusieurs personnes.
Dans un tel cas il est ncessaire de distinguer plus de phases
18

Projet abondonn
non
Pourquoi ?
L'approche traditionnelle distingue 6 phases dans la vie

du logiciel
Pr-analye
La phase de pr-analyse : tude d'opportunit;
Oui
La phase de spcification (software requirements)

:l'analyse des besoins ;
La phase de conception (software design): la

spcification globale, la conception architecturale et
dtaille.
La phase d'implmentation : la programmation
La phase de test : la validation et vrification
La phase de maintenance, la gestion de

configuration et intgration.
Spcification
Quoi ?
Cahier des charges

Comment ?
Conception
Dcopage du logiciel en modules
Impmentation
Code
Test
Logiciel oprationnel
Maintenance
19
La phase de pr-analyse
Prcde le dveloppement proprement dit et rpond la question

pourquoi:
Pourquoi faut-il raliser un certain logiciel, quels sont les besoins?
Quelques autres questions typiques se poser durant cette phase :
Pourquoi a-t-on besoin du logiciel?

Y a-t-il de meilleures alternatives?
Le logiciel sera-t-il satisfaisant pour les utilisateurs?
Y a-t-il un march pour le logiciel?
Quelles sont les ressources ncessaires pour raliser le logiciel (budget,
personnel, matriel).
La rponse de la phase de pr-analyse est oui ou non:

Oui, la dcision est prise de raliser le logiciel;
Non, le projet est abandonn.
20
Analyse des besoins
But :
La phase de spcification rpond la question quoi ?
Eviter de dvelopper un logiciel non adquat
Permettre de dfinir prcisment quelles sont les fonctions raliser par le logiciel.
Exemple : Si l'on considre un logiciel effectuant le paiement des salaires dans une
entreprise, la phase de spcification permettra de rpondre notamment aux questions
suivantes :
Les employs sont-ils enregistrs sur bande ou sur disque?
Quel est le format de chaque enregistrement du fichier?
Quel est le format des sorties?
Etc.
21
Analyse des besoins
Entre:
donnes fournies par des experts du domaine d'application et les futurs
utilisateurs
Mthodes:
Il faut surtout tablir un dialogue avec les experts du domaine, qui ne sont
pas forcment des informaticiens,
Utiliser des mthodes plutt cognitives : entretiens, questionnaires,
observations de l'existant, tudes de situations similaires
Dmarche : pour tablir les besoins (le cahier des charges), il faut
tudier le domaine d'application ;
l'tat actuel de l'environnement du futur systme ;
le rle du systme ;
les ressources disponibles et requises ;
les contraintes d'utilisation ;
les performances attendues ;
22
Analyse des besoins
Lien : Cette activit doit tre mene en liaison avec les tudes
de faisabilit et la planification, et doit se poursuivre durant tout
le processus de dveloppement.
Rsultat: Le cahier des charges du logiciel (spcification des

besoins, software requirement specification)
Documents dcrivant
l'environnement du futur systme

son rle
son utilisation (manuel d'utilisation prliminaire)
si ncessaire, partage entre matriel et logiciel
Dure : Peut se poursuivre durant tout le cycle de vie

(maintenance volutive).
23
Conception architecturale, dtaille : Spcification globale
Remarque : la spcification globale est souvent regroupe dans

la mme tape que la spcification des besoins.
But :
tablir une premire description du futur systme
rpondre la question comment: comment raliser le logiciel dfini par le
cahier des charges
Entre:
analyse des besoins + considrations techniques et faisabilit informatique
Mthodes:
SADT, SART, MERISE, UML, ...
24
Rsultat:
modle conceptuel pour produire une description de ce que doit
faire le systme mais sans prciser comment il le fait (on prcise le
quoi mais pas le comment).
complment au manuel d'utilisation
manuel de rfrence prliminaire
Remarque
Cette activit ne fait pas apparatre de choix d'implmentation.
25
Techniques de spcification
nonces informels
description en langage naturel pouvant respecter des plans types (standardiss ou
propres une entreprise ou un projet)
Risque de non-cohrence, d'ambigut, de non compltudes, de difficult
d'organisation et de redondance d'informations
Prsentations formates
Dictionnaire de donnes ou glossaire :
- spcification de l'ensemble des donnes utilises en analyse et en
conception
- dfinition des termes, sigles, codes, symboles, synonymes et alias

- peut utiliser des notations syntaxique strictes de forme Backus-Naur
26
Table de dcision :
correspondance entre les valeurs d'entre et les valeurs de sortie d'un
processus (adapte la dfinition des systmes finis).
Table tats-transitions :
table des tats et, pour chaque tat les vnements qui provoquent la
transition un autre tat, les actions effectuer et l'tat suivant pour
chaque transition. Peut tre reprsente par une matrice.
Techniques graphiques ou semi-formelles : Reprsentation graphique
formelle accompagne de textes informels
Modle entit-association
27
Techniques graphiques ou semi-formelles :
Diagrammes de flots de donnes DFD : montrent comment chaque
processus transforme les donnes qu'il reoit entre pour gnrer
celle qu'il produit en sortie.
Diagrammes de structures : description du systme sous forme de
hirarchie de fonctions. La notation permet d'exprimer les appels de
fonctions, les paramtres (entres, sorties, contrle), les structures
itratives et alternatives.
Diagrammes tats-transitions : semblables (et complmentaires) aux
tables tats-transitions.
28
Techniques graphiques ou semi-formelles :
Rseaux de Petri et : un rseau de Petri est un outil mathmatique trs
gnral permettant de modliser le comportement d'un systme
dynamique des vnements discrets.
Grafcet: le Graphset, inspir des rseaux de Petri, est un outil de
spcification des automates logiques frquemment utilis en
automatique.
Techniques formelles
Langage B
Langage Z
Etc.
29
Conception architecturale, dtaille :
But
Dfinir larchitecture logicielle par ltablissement dune description trs proche
du systme raliser.
Rpartition des entits (ou des fonctions) identifies dans la spcification sur une
architecture matrielle et logicielle
Dcomposer le logiciel en composants plus simples, dfinis par leurs interfaces
et leurs fonctions (les services qu'ils rendent)
Choix dalgorithmes
Dmontrer que la spcification est correctement dcrite
Cohrence entre description, spcification et conception
Comportement
Proprits
30
Documents dentre
Document de spcification : les spcifications globales + contraintes
d'implmentation
Entits
Description des comportements locaux
Description des comportement globaux
Documents de sortie
Documents de conception gnrale (ou prliminaire)
Description des modules
Description des interfaces entre modules
Traabilit avec la spcification
Plans de test dintgration
Document de conception dtaille
Plan de test unitaire
31
Mthodes:
Enrichir la description du systme de dtails d'implmentation. Deux tapes:
1. conception architecturale :dcomposer le logiciel en composants plus simples
en terme de fonctions et interfaces
2. conception dtaille : description de chaque composant: algorithmes, structure
des donnes, ...
Rsultat : Modle d'implmentation:

Architecture du systme et spcification des composants
Algorithmes et modle des donnes (entit-association)
Selon la nature de la conception:
Fonctionnelle: modles par flux de donnes: DFD, Contexte, AFD, structure,
Petri, ...
Objets: diagrammes UML
...
32
Conception architecturale, dtaille
Dmarche de conception
Conception de l'architecture : identifier les sous-systmes et leurs
relations
Spcification abstraite : pour chaque sous-systme produire une
spcification abstraite des services qu'il offre et des contraintes
auxquelles il est soumis
Conception de l'interface : pour chaque sous-systme, concevoir et
documenter (de manire claire) l'interface avec les autres sous-systmes
Conception des composants de chaque sous-systme
Conception dtaille des structures de donnes
Conception dtaille des algorithmes
33
Quelques critres mesurant la qualit de la conception

Cohsion
Une composante (module) doit implanter une seule entit logique.
Toutes les parties de cette composante doivent contribuer cette
implantation.
Ainsi dans un systme (logiciel) chaque composante rsout une partie du
problme.
Couplage
Est relatif la cohsion :
Il exprime le degr d'interconnexion des diffrents composants d'un
systme.
Un couplage fort (partage de donnes, change d'informations de
contrle, etc.) implique des difficults d'entretien.
34
Quelques critres mesurant la qualit de la conception

Comprhensibilit : La comprhensibilit d'un module dpend de :
sa cohsion ;
l'appellation : utilisation de noms significatifs ;
la documentation : tablir un lien entre le monde rel et le composant
Complexit
une composante complexe ncessite un effort de documentation supplmentaire
Adaptabilit
L'adaptabilit dpend du couplage et de la documentation.
Une conception ou un logiciel adaptable doit avoir un haut degr de lisibilit :
fournir plusieurs reprsentations, cohrentes avec l'implantation, diffrents
niveaux d'abstraction.
Les modifications doivent tre faciles incorporer sur tous les niveaux pour ne
pas avoir des problmes d'incohrence.
35

Programmation
But :
Ralisation, partir de la conception dtaille, d'un ensemble de
programmes ou de composants de programmes
Projection des concepts du modle sur un langage de programmation.
Il sagit dun processus manuel
Entre:
conception dtaille + contraintes de l'environnement de programmation
Rsultat: documents dcrivant:

code source de chaque module
directives: compilation, liens, ...
documentation d'implmentation
36

Programmation
Mthodes:
Automatique : Dans certains cas, cette tape peut tre automatise (gnration
automatique de code)
Manuel :
En gnral le modle statique contient tout ou partie de la structure
dclarative
- En approche fonctionnelle, il faut projeter le dictionnaire des
donnes (interfaces des fonctions) sur les variables et les
fonctions sur
des procdures.
- En approche objet :passage du modle objet au langages

objets
manuel ou drivation du code (par exemple
gnration des classes
partir des class diagrams) et
ncessit dimplanter manuellement les
associations et
agrgations
Limplantation de la dynamique est ralise en traduisant les diagrammes
dtats (state charts) en structure de contrle
37
Validation et vrification
But de cette activit est de s'assurer de l'adquation du systme
produit face aux besoins et spcifications
Spcifions-nous le bon systme c'est dire un systme correspondant aux
attentes des utilisateurs et respectant les contraintes de leur
environnement? celui qui rpond l'attente des utilisateurs ?
Elle consiste essentiellement en des revues et inspections de
spcifications ou de manuels et du prototypage rapide
Entre: documents produits par l'ensemble des tapes

prcdentes
38
Validation et vrification
Mthodes :
examens des spcifications, programmes, preuves, tests
test unitaire , test d'intgration et test systme
on distingue :
tests statiques: examen ou analyse du texte des programme
tests dynamiques : consiste en l'excutions du logiciel sur un sousensemble des donnes permettant de vrifier tous les chemins
d'accs logiques et la plage de validit des donnes et en particulier
les conditions limites

oprations effectues
acceptation ou non
39
Logiciel et Gnie logiciel (?)
Gestion de configurations et intgration

But : obtenir tout ou partie excutable du systme.
L'intgration a pour but de raliser un ou plusieurs systmes excutables
partir des composants. Les choix possibles correspondent des variantes
du systme
Entre: les composants + description des configurations
Mthodes: grer les composants du systme, leur volution,

leur mise jour, leur intgration

les excutables
les configurations
40
La phase de maintenance
Commence une fois le logiciel est oprationnel
On distingue dans cette phase:

la maintenance corrective , qui s'occupe de corriger les erreurs
dcouverts une fois le logiciel remis au client
la maintenance adaptative qui adapte le logiciel un
environnement (logiciel et matriel) qui volue
par exemple adaptation d'un logiciel une nouvelle version
d'un systme d'exploitation
la maintenance perfective , qui s'occupe d'tendre le logiciel pour y
inclure de nouvelles possibilits, de nouvelles fonctions, etc.
41

Cycle avec retour
Inconvnient dun cycle sans retour
Le cycle de vie sans retour est trop simpliste pour plusieurs raisons:
Pr-analye
Pcification
Conception
Impmentation
Test
Maintenance
Plus on avance dans le projet, plus on le matrise, et donc plus on a

tendance revenir sur certains choix faits alors que l'ensemble du
projet tait moins bien cern
Lors de la spcification d'un logiciel, certaines considrations sur
l'implmentation peuvent tre utiles. A dfaut, certains aspects du
cahier des charges pourraient tre irralistes (il s'agit donc ici de
l'anticipation partielle d'une phase future);
Certaines spcifications (c'est--dire certains aspects du cahier des
charges) peuvent changer en cours de projet, parce que le client
change d'avis.
42
Rpartition de leffort
Dans un projet bien conduit , l'effort se rpartit comme suit

15 20% programmation,
40% spcification et conception,
40% validation et vrification.
Dveloppemet
40 %
spcification
20 %
Test et
Maintenance
60%
conception
20 %
Test
40 %
Maintenance
20 %
43
Les approches alternatives de dveloppement de logiciels

Prototypage rapide (rapid prototyping)
Un prototype est un logiciel n'implmentant que les aspects les plus importants
du logiciel final et permettant ainsi de tenir compte des ractions de l'utilisateur
avant de dvelopper le produit dfinitif
Langages de trs haut niveau

Permet de produire rapidement des logiciels ayant de plus peu d'erreurs
Les applications de gestion sont un domaine typique o ces mthodes semblent
particulirement adaptes;
Exemple: le langage HIBOL, adapt aux applications de gestion.
Rutilisation de logiciel
Il s'agit ici de constituer une bibliothque de modules. Lors de la ralisation d'un
nouveau logiciel, on cherchera le plus possible utiliser des modules existants.
cette mthode ne s'applique pas lorsqu'il s'agit de raliser un logiciel dans un
domaine relativement neuf.
44
Qualit de logiciel
Les facteurs de qualit :

Internes ou de conception : visibles par les dveloppeurs
Externes: visibles par les utilisateurs.
Parmi ces derniers :
Validit : aptitude d'un produit logiciel remplir exactement ses fonctions,
dfinies par le cahier des charges et les spcifications
Fiabilit (ou robustesse) : aptitude d'un produit logiciel fonctionner dans
des conditions anormales
Extensibilit : facilit avec laquelle un logiciel se prte une modification
ou une extension des fonctions qui lui sont demandes
Rutilisation : aptitude d'un logiciel tre rutilis, en tout ou en partie,
dans de nouvelles applications
Compatibilit : facilit avec laquelle un logiciel peut tre combin avec
d'autres logiciels.
45
Qualit de logiciel :
Les facteurs de qualit :

Externes :
Efficacit : Utilisation optimales des ressources matrielles.
Portabilit : facilit avec laquelle un logiciel peut tre transfre
sous diffrents environnements matriels et logiciels
Vrifiabilit : facilit de prparation des procdures de test
Intgrit : aptitude d'un logiciel protger son code et ses donnes
contre des accs non autoriss
Facilit d'emploi : facilit d'apprentissage, d'utilisation, de
prparation des donnes, d'interprtation des erreurs et de
rattrapage en cas d'erreur d'utilisation.
46
Le cycle de vie de logiciel
Modles de cycle de vie
Dfinition :
Modles gnraux de dveloppement dcrivant les enchanements et les

interactions entre activits.
Objectif :
Obtenir des processus de dveloppement rationnels, reproductibles et
contrlable. Utiliss pour mieux matriser le processus dveloppement en
permettant de prendre en compte, en plus des aspects techniques, l'organisation
et les aspects humains
Remarques :
Une tape, telle que la conception, peut faire intervenir plusieurs activits,
comme celles de la spcification globale, du maquettage et de la validation
une activit comme la documentation peut se drouler pendant plusieurs tapes
47
Le cycle de vie de logiciel
Modles de cycle de vie

Historique :
A la fin des annes 60, le modle de dveloppement par tapes
successives est apparu. Il s'agissait du modle de la cascade
Puis, durant les annes 80, le modle en V merg. C'est encore
le modle le plus utilis aujourd'hui
Enfin, plus rcemment le modle en spirale, plus complet, mais
galement plus complexe a introduit de nouveaux aspects comme
l'analyse des risques et l'utilisation systmatique de prototypes
pour s'assurer de la bonne comprhension des besoins de
l'utilisateur final
48
Modles du cycle de vie
Modle de la cascade (waterfall)

Dans ce modle, chaque phase se termine une date prcise
par la production de certains documents ou logiciels.
on ne passe la phase suivante que si les rsultats de
ltape prcdente sont jugs satisfaisants
D'autres activits interviennent, par exemple le contrle
Pr-analye
technique et la gestion de la configuration sont prsents
Analye des besoins
tout au long du processus.
Conception prliminaire
Conception dtaille
Codage
Intgration
maintenance
49

Modle de la cascade (waterfall)
Le modle original ne comportait pas de possibilit de retour en
arrire.
Celle-ci a t rajoute ultrieurement sur la base qu'une tape
ne remet en cause que l'tape prcdente, ce qui, dans la
pratique, s'avre insuffisant.
Les dveloppements rcents de ce modle font paratre de la
validation-vrification chaque tape :
faisabilit et analyse des besoins : validation ;
conception du produit et conception dtaille : vrification ;
intgration : test d'intgration et test d'acceptation ;
installation : test du systme.
50
Analye
des beoins
Et faisabilit
Installation
Test systme
Test
Dacceptation
spcification
Conception
architcturale
Intgration
Et test
Dintgration
Conception
dtaille
Test unitaire
Programmation
Modle en V
contrairement au modle de la cascade, ce modle fait apparatre
le fait que le dbut du processus de dveloppement conditionne
ses dernires tapes.
avec toute dcomposition doit tre dcrite la recomposition,
toute description d'un composant est accompagne de tests qui
permettront de s'assurer qu'il correspond sa description.
ceci rend explicite la prparation des dernires phases (validationvrification) par les premires (construction du logiciel),
permet ainsi d'viter un cueil bien connu de la spcification
du logiciel :noncer une proprit qu'il est impossible de
vrifier objectivement aprs la ralisation.
le cycle en V est le cycle qui a t normalis
il est largement utilis, notamment en informatique industrielle et
tlcoms
51
Modle en spirale
Propos par B. Boehm en 1988, ce modle est beaucoup plus gnral que le
prcdent.
Il met l'accent sur l'activit d'analyse des risques : chaque cycle de la spirale
se droule en quatre phases :
dtermination, partir des rsultats des cycles prcdents --ou de
l'analyse prliminaire des besoins, des objectifs du cycle, des alternatives
pour les atteindre et des contraintes ;
analyse des risques, valuation des alternatives et, ventuellement
maquettage ;
dveloppement et vrification de la solution retenue, un modle
classique (cascade ou en V) peut tre utilis ici ;
revue des rsultats et vrification du cycle suivant.
52

Dterminer
Les objectifs,
Les alternatives
et les contraintes
Analye
Des risques
Evaluer les alternatives;

Identifier et rsoudre les
risques
Analye
Des risques
Analye
Des risques
Prototype
Prot Prot oprationnel
3
prototype1 2
Analye
des risques
Revue
Planification
Des besoins et
Du cycle de vie
Plan de
dveloppement
Plan de test et
Dintgration
Planification de la
Prochaine phase
Simulation, modles et
Tests de performance
s
oi n s
Conception
s
e
n
B ciel
o
i
i
t
dtaille
p
Validation
log
ce duit
n
Des besoins
code
Co pro
Test
Du
unitaire
Test
Concept
De lopration
Mise en
service
Dintgration
Test
Dacceptation
Dvelopper
Et vrifier le produit
De prochain niveau
53
Modle en spirale
principe
L'analyse prliminaire est affine au cours des premiers cycles.
Le modle utilise des maquettes exploratoires pour guider la phase
de conception du cycle suivant.
Le dernier cycle se termine par un processus de dveloppement
classique.
Ce modle a t moins expriment que les deux prcdents.
Sa mise en oeuvre demande de grandes comptences et devrait tre
limite aux projets innovants cause de l'importance qu'il accorde
l'analyse des risques. Nanmoins, ce dernier concept peut tre appliqu
aux autres modles.
Le modle en spirale utilise systmatiquement des prototypes
exploratoires afin de guider la conception.
54
Modle spirale : Risques majeurs

Dfaillance de personnel:
embauche de personnel de haut niveau, adquation entre profil et
fonction, esprit d'quipe, formation mutuelle, personnes cls
calendrier et budget irralistes:
estimation des cots et calendriers, dveloppement incrmental,
rutilisation, lagage des besoins
fonctions inappropries:
analyse de l'organisation, analyse de la mission, formulation des concepts
oprationnels, revues d'utilisateurs, manuel d'utilisation prcoce
interfaces utilisateurs inappropries:
scnarios et revues d'utilisateurs, analyse des tches, maquettage
55
Modle spirale : Risques majeurs

sur qualit:
lagage des besoins, analyse des cots-bnfices, conception tenant compte des
cots, maquettage
volatilit des besoins:
seuil lev de modification, masquage d'information, dveloppement incrmental
avec les derniers incrments les plus changeant
composants externes manquants:
inspections, essais et mesures, analyse de compatibilit, maquettage
tches externes dfaillantes;
audit, contrat avec bonus, revues frquentes
problme de performances:
simulations, modlisations, essais et mesures, prototypage
technologie inadquate: analyses techniques de faisabilit, maquettage
56

Modles par incrment
Dans les modles spirale, en V ou en cascade, un logiciel est
dcompos en composants dvelopps sparment et intgrs la
fin du processus
Dans le modle par incrments, seul un sous ensemble est
dvelopp la fois
Dans un premier temps un logiciel noyau est dvelopp, puis
successivement, les incrments sont dvelopps et intgrs.
Chaque incrment est dvelopp selon l'un des modles
prcdents.
57
Modle par incrments

Avantages
chaque dveloppement est moins complexe ;
les intgrations sont progressives ;
possibilit de livraisons et de mises en service aprs chaque incrment ;
meilleur lissage du temps et de l'effort de dveloppement cause de la
possibilit de recouvrement des diffrentes phases. l'effort est constant
dans le temps par opposition au pic pour spcifications dtailles pour les
modles en cascade ou en V.
Risques
la remise en cause du noyau de dpart
celle des incrments prcdents
ou encore l'impossibilit d'intgrer un nouvel incrment
58

Maturit du cycle de vie

Une notion de maturit du processus de dveloppement a t dfinie en
1989 puis en 1991 par le SEI: Software Engineering Institude - DoD
+ Carnegie Mellon.
Une classification selon cinq niveaux a t ainsi dfinie. Le processus est
dit:
initial si le dveloppement est chaotique: les cots, les dlais et la
qualit sont imprvisibles.
reproductible si le processus de dveloppement est artisanal et
dpendant beaucoup des individus: les cots et la qualit sont
variables. Les mthodes sont mal dfinies ou mal suivies;
dfini si le processus de dveloppement est bien suivi mais, pour
l'essentiel de manire qualitative: les dlais et les cots sont fiables
mais la qualit est variable.
gr si le processus est contrl et mesur. La qualit est fiable;
optimis si une analyse de chaque projet est effectue des fins de
l'amlioration des cots, des dlais et de la qualit.
59
Mthode de dveloppement : Mthodes

d'analyse et de conception
Objectif :
Les mthodes d'analyse et de conception fournissent des notations

standards et des conseils pratiques qui permettent d'aboutir des
conceptions raisonnables
Mais on fera toujours appel la crativit du concepteur
Classification des mthodes de dveloppement
la distinction composition/dcomposition :
les mthodes ascendantes qui consistent construire un logiciel par
composition partir de modules existants
les mthodes descendantes qui dcomposent rcursivement le un systme
jusqu' arriver des modules programmables simplement .
60
Mthode de dveloppement : Mthodes d'analyse et de

conception

la distinction fonctionnel (dirige par le traitement)/oriente objet.
Les stratgies fonctionnelles :
Un systme est vu comme un ensemble d'units en interaction, ayant
chacune une fonction clairement dfinie.
Exemple : SA, SADT, SA/RT, RAPID/USE, JSD, MASCOT,
Automates; AEFC, RDP
Les stratgies orientes objet
Considrent qu'un systme est un ensemble d'objets interagissant.
Contrairement la plupart des mthodes fonctionnelle, les mthodes
oriente-objet sont la fois des mthodes d'analyse et de conception
Exemples: OMT, UML
61
Mthode de dveloppement : Mthodes d'analyse et de

conception
La distinction formelle/non formelle

Approche non formelle ou semi-formelle
Peuvent tre des mthodes fonctionnelles ou objet
Les mthodes semi-formelles permettent de pcifier certaines
parties de lanalyse ou/et de la conception laide de langages
formels tel que le langage OCL pour UML
Approches formelles
Approches mathmatiques de spcification et de modlisation
Exemples : spcification en langage B et Z
Peuvent tre fonctionnelles ou objet
62
Approches fonctionnelles
La mthode SA (Structured Analysis):

Analyse structure
Est une mthode descendante par

raffinements successifs des traitements ou
processus chaque niveau de
dcomposition
La notation graphique utilise est celle des

diagrammes de flots de donnes
Le niveau le plus haut reprsente l'ensemble

du problme (diagramme de contexte)
Chaque diagramme de niveau infrieur

dcompose en plusieurs processus les
processus dfinis au niveau juste suprieur,
en respectant les flots de donnes entrants et
sortants.
63
La mthode SD (structured design) : Conception fonctionnelle

Elle utilise trois types de documents :
Diagramme de flux de donnes
Montrent les transformations sur les donnes sans faire
d'hypothse sur la manire dont elles seront ralises.
Diagrammes de structure du logiciel
Servent dcrire visuellement l'organisation d'un systme.
Ils montrent comment raliser les lments d'un diagramme
de flux de donnes l'aide d'une hirarchie d'units de
programmation.
64
Mthode SADT(Structured Analysis and

Design Technique)
Est une mthode d'analyse qui couvre

essentiellement la premire partie du cycle de
vie du logiciel.
Elle propose une suite cohrente et hirarchise
de diagrammes (datagrammes et actigrammes ),
obtenus par raffinements successifs:
un datagramme permet de reprsenter les
donnes. Reprsentes par des botes, et montre
les activits qui les crent ou les utilisent; cellesci sont reprsentes par des flches;
un actigramme dcrit l'enchanement des
activits, qui sont reprsentes par des botes ;
les donnes qu'elles manipulent sont
reprsentes par des flches.
65
MERISE
Est une mthode d'analyse et de conception de systmes d'information dfinie

durant les annes 1978 et 1979, conue par un ensemble de socits de
service, sous l'gide du ministre de l'industrie franais
Les points nouveaux de la premire version de cette mthode, consigns dans

l'ouvrage "La mthode MERISE", taient alors:
une couverture de tout le cycle de vie du logiciel: schma directeur, tude
pralable, tude dtaille, tude technique, production de logiciels, mise en oeuvre,
maintenance
un cycle d'abstraction reposant sur trois niveaux:
conceptuel (rponse la question "quoi ?"),
organisationnel ou logique (rponse aux questions "qui ?", "quand ?", "o ?")
physique (rponse la question "comment ?"):
66
MERISE
La mthode prconie la sparation entre les modles de donnes, analyss
avec une approche entit-association, et les modles des traitements,
prsents avec un formalisme proche de celui des rseaux de Petri
La mthode conduit raliser les six modles
MCD: Modle Conceptuel des Donnes,

MCT: Modle Conceptuel des Traitements,
MLD: Modle Logique des Donnes,
MOT: Modle Organisationnel des Traitements,
MPD: Modle Physique des Donnes,
MPT: Modle Physique des Traitements.
67
Mthodes orientes objet
L'analyse oriente objet permet d'examiner un problme en mettant en vidence

les classes et les objets correspondants, sous forme de composants
indpendants qui interagissent selon des modalits bien dfinies.
Le choix d'une mthode oriente objet n'est pas simple car celles-ci sont
nombreuses et toutes n'ont pas t testes sur des applications suffisamment
importantes pour pouvoir tre values
Dans la plupart de ces mthodes, l'tude d'un problme est ralise suivant trois
aspects:
un aspect statique ou descriptif , o on identifie les proprits des objets et
leurs liaisons avec les autres objets
un aspect dynamique , o on prcise le comportement des objets, les

diffrents tats par lesquels ils passent et les vnements qui dclenchent
ces changements d'tats. (On parle souvent de cycle de vie d'un objet )
un aspect fonctionnel , dans lequel on prcise les fonctions ralises par les
objets par l'intermdiaire des mthodes.
68
Mthode de Coad et Yourdon
La mthode OOA (Object Oriented Analysis) de Coad et Yourdon est l'une

des premires mthodes d'analyse oriente objet qui ait t bien dfinie
Sa dmarche globale est constitue de cinq activits

dfinition des classes&objets : dfinir une classe et les objets qu'elle contient ;
identification des structures : hritage et composition;
identification des sujets (domaines) suivant la complexit du problme;
dfinition des attributs ;
dfinition des services (appels communment mthodes).
Le modle gnral de la mthode est prsent comme la superposition de

cinq couches, chaque couche apportant des dtails complmentaires sur la
couche prcdente:
couche Sujet, couche Classe&objets, couche Structure, couche Attribut, couche Service
69
Mthode de Grady Booch
La mthode propose par G. Booch est une mthode de conception,

dfinie l'origine pour une programmation Ada, puis gnralise
d'autres langages
Sans prciser un ordre strict dans l'enchanement des oprations, elle

propose quatre tapes:
identifier les classe et les objets un niveau d'abstraction donn,
identifier la smantique de ces classes et de ces objets en prcisant pour
chaque classe son interface,
identifier les relations entre ces classes en distinguant d'une part les
aspects statiques, d'autre part les aspects dynamiques,
implmenter les classes et les objets.
70
Mthode Shlaer et Mellor : OOA (Object Oriented Analysis )
Repose sur la reprsentation des systmes suivant les trois axes:

l'axe de la statique pour les donnes et leurs structures;
l'axe de la dynamique pour les tats les transitions et les synchronisations;
l'axe de l'algorithmique pour les traitements et les processus.
Un systme analyser est dcoup en plusieurs sous-systmes. On

associe chacun d'eux:
un modle d'information (Information Model) suivant l'axe de la statique, de
type entit-association, pour dcrire les objets; il traduit un point de vue global
du systme
un modle de traitement (Process Model) suivant l'axe fonctionnel, pour chaque
action dtecte prcdemment. L'algorithme associ chaque action permet de
prciser les processus qui s'enchanent. Il se traduit par un diagramme de type
DFD (Data Flow Diagram).
71
Mthode OMT
La mthode OMT (Object Modeling Technique ) permet de couvrir

l'ensemble des processus d'analyse et de conception en utilisant le
mme formalisme
L'analyse repose sur les trois points de vue: statique, dynamique,

fonctionnel donnant lieu trois sous-modles
En plus de la conception du systme, la mthode OMT prsente la

conception des objets, phase au cours de laquelle on prcise des
dtails d'implmentation.
Un projet d'unification de la mthode OMT et de la mthode de Grady

Booch (Unified Method ) a t annonc en 1995.
72
Mthode OOM: Orientation Objet dans MERISE
La troisime version de MERISE, OOM, date de 1992; elle est totalement

marque par l'orientation objet, et on retrouve: la dimension statique, la
dimension dynamique et la dimension fonctionnelle.
C'est la dimension fonctionnelle qu'il est conseill de dvelopper en premier :

elle permet de reprsenter les frontires du systme modliser par rapport son
environnement en utilisant un diagramme de contexte.
Elle permet galement de dfinir les besoins par des diagrammes de flots de donnes
La dimension statique reste la plus importante des trois car elle est la plus
stable dans le temps
la description des donnes repose sur un modle entit-association tendu.
A chaque objet on associe son comportement, par l'intermdiaire des mthodes apparues
dans les diagrammes de flots de donnes.
La dimension dynamique permet de reprsenter l'enchanement des

oprations dans diffrents scnarios
73
La mthode UML
UML est la forme contracte de Unified Modeling Language qui peut se

traduire en franais par langage unifi pour la modlisation
C'est un langage de modlisation objet
Il fournit les fondements pour spcifier, construire, visualiser et dcrire

les composants d'un systme logiciel
UML se base sur une smantique prcise et sur une notation graphique
expressive. Il permet de modliser de manire claire et prcise la
structure et le comportement d'un systme indpendamment de toute
mthode ou de tout langage de programmation
74
La mthode UML
N de la fusion des mthodes objet dominantes (OMT, Booch et
OOSE), puis normalis par l'OMG en 1997, UML est rapidement
devenu un standard incontournable.
UML n'est pas l'origine des concepts objet, mais il en en

donne une dfinition plus formelle et apporte la dimension
mthodologique qui faisait dfaut l'approche objet.
La notation UML repose sur plusieurs diagrammes adapts au
dveloppement logiciel pour les phases de spcification,

conception et implmentation du cycle de vie.
Certains de ces diagrammes peuvent tre tracs dans diffrentes phases de

dveloppement, d'autres sont plus spcifiques une phase donne. Par
exemple, les cas d'utilisation sont bien adapts la formalisation de
l'analyse des besoins.
75
La mthode UML diffrents types de diagrammes

Expression des besoins
Use cases et diagrammes dactivit
Identification des entits
Diagrammes de classes : Classes, Associations,
Attributs, Oprations; Assertions, invariants,
pr-conditions, postconditions; Gnralisations,
Classes associations
Description du comportement attendu
Diagramms dinteraction : Descriptions des
interactions entre groupes dobjets:
messages changs entre objets.
Diagrammes dtats :Description des tats des
objets

Routage Et Protocoles de Routage

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Routage Et Protocoles de Routage

Enviado por

Direitos autorais:

Formatos disponíveis

1

Le Logiciel et le Gnie logiciel

Les concepts objet travers UML

La notation UML pas pas

Cest quoi le problme ?

Les diffrents diagrammes

Des travaux pratiques pour matriser UML

Logiciel et Gnie logiciel

Introduction en image : Informatique et logiciels

Logiciel et Gnie logiciel

Fonctions ralises dans un environnement

Organisation des moyens,

Logiciel et Gnie logiciel

Caractristiques dun produit logiciel

Un logiciel est un produit (manufactur) comme une voiture ou une

Un logiciel est un produit avec des caractristiques particulires

Pas de problme de fabrication en srie

Processus de dveloppement itratif : certaines tapes peuvent

Le procd de fabrication dun logiciel est invisible

Logiciel et Gnie logiciel

Caractristiques dun produit logiciel

Un logiciel est un produit avec des caractristiques particulires

Logiciel et Gnie logiciel

Quelques constats de l'ampleur de l'impact des dfaillances :

la sonde Mariner vers Vnus s'est perdue dans l'espace cause

en 1972, lors d'une exprience mtorologique en France 72

en 1981, le premier lancement de la navette spatiale a t

le dveloppement du compilateur PL1 de Control Data n'a

Logiciel et Gnie logiciel

EDF a rcemment renonc la mise en service de nouveaux

la SNCF a rencontr des difficults importantes pour la mise en

l'explosion d'Ariane 5, le 4 juin 1996, qui a cot un demi

Pourquoi : manque de mthodologie de dveloppement des

Logiciel et Gnie logiciel

La premire reconnaissance publique de la crise du logiciel a t faite

Logiciel et Gnie logiciel

Comparer lvolution du cot du logiciel et du matriel :

Logiciel et Gnie logiciel

Quelques sources de la crise

Une ide grossire du logiciel raliser est suffisante pour

Une fois que le programme est crit et fonctionne, le travail est

Logiciel et Gnie logiciel

Quelques sources de la crise

Si les spcifications du logiciel raliser changent

Si la ralisation du logiciel prend du retard par rapport aux dlais

Logiciel et Gnie logiciel

Est un domaine de recherche qui a t dfini (fait rare) du 7 au 11

Le gnie logiciel est la discipline ne en rponse la crise du logiciel.

Le gnie logiciel se caractrise par une approche rigoureuse et

Le gnie logiciel est donc l'art :

Logiciel et Gnie logiciel

Objectif du gnie logiciel

Optimiser le cot de dveloppement du logiciel.

augmentation des cots ;

Logiciel et Gnie logiciel

Cycle de vie de logiciel

Dans la ralisation d'un programme simple, fait par une personne, il

la phase d'analyse du problme;

la phase de codage et de mise au point;

la phase d'opration (le programme est oprationnel).

Cette approche n'est pas approprie pour un projet important

Dans un tel cas il est ncessaire de distinguer plus de phases

Logiciel et Gnie logiciel

Cycle de vie de logiciel