Genie Logiciel

Ecole dIngnieurs de lEtat de Vaud - 15 septembre 2006
Eric Lefranois
Gnie Logiciel
ELS - 7 dcembre 2006 - Entete.fm
Gnie logiciel - i -
Contenu
1 EN PRLIMINAIRE 1
1.1 LES OBJ ECTIFS DU COURS 1
1.2 PRINCIPALES RFRENCES BIBLIOGRAPHIQUES 2
2 LA PROBLMATIQUE 5
Les petits logiciels 6
Les gros logiciels 7
Quelques dfinitions cls 8
2.1 LA CRISE DU LOGICIEL DES ANNES 70 9
Panique bord du bateau logiciel 10
Car le logiciel est une tche complexe.. 10
Car lvolution est trop rapide.. 11
Car au del des mythes, la ralit.. 11
Naissance du gnie logiciel 13
Dfinition du gnie logiciel 14
2.2 LES QUALITS REQUISES DUN LOGICIEL 14
Qualits externes significatives 15
Correction 15
Fiabilit 15
Robustesse 15
Performance 15
Ergonomie 15
Qualits internes significatives 16
Qualits du processus de dveloppement 16
2.3 AUTOPSIE DE QUELQUES CATASTROPHES 17
1962: La perte de Mariner I (1) 17
Mars Climate Orbiter ($125M) 17
Autres checs retentissants 18
3 MODLISATION 19
3.1 LA MODLISATION DUN SYSTME INFORMATIQUE 20
3.2 DE LIMPORTANCE DE LA MODLISATION 21
Les systmes orients donnes 21
Les systmes orients traitements 21
Gnie logiciel - ii -
Les systmes orients comportement 21
Les principales approches 22
Approche traditionnelle 22
Approche Base de donnes 22
Approche oriente objet 23
Petit historique des modles utiliss 23
Systmes orients donnes 23
Systmes orients traitements 24
Systmes orients comportement 24
Modlisation Oriente Objet 24
4 CYCLES DE VIE ET MTHODE UP 25
4.1 LES DIFFRENTES PHASES DU CYCLE DE VIE: ANALYSE ET CONCEPTION 26
4.2 LE CYCLE DE VIE EN CASCADE (WATERFALL) 28
4.3 LE CYCLE EN V ET LE MODLE EN SPIRALE 30
4.4 LE MODLE INCRMENTAL ITRATIF 31
4.5 MISE EN OEUVRE: LA MTHODE UP (PROCESSUS UNIFI) 33
4.6 APPROCHE ORIENTE OBJ ET 33
Analyse oriente objet 33
Conception oriente objet 33
Un exemple: le jeu de ds 34
Dfinition des cas dutilisation 34
Modlisation du domaine 35
Dfinition des diagrammes dinteraction 35
Dfinition des diagrammes de classe de conception 36
Quelques mots sur UML 36
4.7 CYCLE DE VIE DE LA MTHODE UP 38
Initialisation (Inception) 39
Elaboration 39
Construction 39
Transition 40
Terminologie UP: disciplines, activits & artefacts 40
Disciplines et phases UP 40
5 PHASE DINITIALISATION 43
5.1 LES PRODUITS GNRS PAR LA PHASE DINITIALISATION 44
5.2 A VITER PENDANT LA PHASE DINITIALISATION 46
6 PHASE DLABORATION ET ANALYSE DES BESOINS 47
Besoins fonctionnels et non-fonctionnels 49
Les difficults rencontres lors de la spcification 51
Quelques techniques utilises lors de la spcification 52
Spcification formelle et informelle 52
Spcification semi-formelle et UML 53
7 MODLE DES CAS DUTILISATION 55
7.1 SA PLACE DANS LA MTHODE UP 56
Un dveloppement guid par les cas dutilisation 56
Quand doit-on rdiger des cas dutilisation? 56
Gnie logiciel - iii -
7.2 QUELQUES DFINITIONS PRALABLES 57
Acteur 57
Scnario 57
Un cas dutilisation 57
Un diagramme de cas dutilisation 58
7.3 DESCRIPTION DUN CAS DUTILISATION 59
La philosophie de la bote noire 59
Rdaction dun cas dutilisation: quel niveau de dtail? 59
Description dtaille dun cas dutilisation 60
La prface 61
La liste des parties prenantes et des intrts 61
Prconditions et postconditions 61
Le scnario principal (succs) 62
Extensions: les scnarios alternatifs 62
Spcifications particulires 63
Prsentation: la variante Rebecca Wirfs-Brock 64
7.4 DFINIR LE MODLE DES CAS DUTILISATION, DMARCHE GNRALE 65
En prliminaire: quest-ce quun bon cas dutilisation? 66
Cas dutilisation de base et sous-cas dutilisation 66
La stratgie de lanalyste 67
La dmarche 69
Dlimiter les frontires du systme dvelopper 70
Un diagramme de contexte 70
Reprsentation des acteurs dans un diagramme de cas dutilisation 71
Identifier les acteurs principaux et les acteurs auxiliaires 72
Les acteurs principaux 73
Les acteurs auxiliaires (ou acteurs secondaires) 73
Les acteurs externes 73
Identifier les cas dutilisation 74
7.5 UML: RELATIONS ENTRE CAS DUTILISATION 74
Relation include 74
Relation genralise 76
Reprsentation dun SOIT-SOIT 76
En dehors du SOIT-SOIT 76
La spcialisation sapplique galement aux acteurs ! 77
Relation extends 79
7.6 QUELQUES RECOMMANDATIONS 82
Rdaction des tapes 82
Oublier les interfaces utilisateurs 83
7.7 LE NIVEAU DE DTAIL 84
7.8 QUAND EST-CE QUE LON A TERMIN ? 85
7.9 COMPLMENTS DE SPCIFICATIONS 85
Le Glossaire (Glossary) 85
La Vision (Vision) 85
Les spcifications supplmentaires 85
7.10 ANNEXE: PRSENTATION DTAILLE DU CAS DUTILISATION VENTE 86
8 MODLISATION DE DOMAINE 93
La modlisation du monde rel 94
Quen est-il des mondes irrels? 94
Le Modle du domaine et la mthode UP 94
Gnie logiciel - iv -
Le Modle du Domaine et UML 94
8.1 CARACTRISTIQUES ESSENTIELLES DE LA MODLISATION DE DOMAINE 95
Le modle du domaine est une abstraction 96
Le modle du domaine est une reprsentations visuelle du monde rel 96
8.2 CONSEILS 96
8.3 HEURISTIQUE: COMMENT IDENTIFIER LES CLASSES CONCEPTUELLES 99
Analyse linguistique 99
Patterns danalyse 100
Lexprience.. 100
8.4 HEURISTIQUE: LISTE DES ASSOCIATIONS COURANTES 101
8.5 ETUDE DE CAS, LE SYSTME POS 101
9 XP & LES MTHODES AGILES 103
9.1 UN PETIT HISTORIQUE 103
9.2 QUELQUES PRINCIPES FONDAMENTAUX DU SOFTWARE MANIFESTO DE 2001
105
Individuals and interaction over processes and tools 105
Working software over comprehensive documentation 106
Responding to change over following a plan 106
9.3 MTHODES AGILES: PRINCIPES CLEF 107
9.4 SUR QUELS TYPES DE PROJ ETS UTILISER UNE MTHODE AGILE? 108
9.5 UP EST-ELLE AGILE? 109
Principes & fondements de UP en comparaison avec XP 110
UP est pilot par les cas dutilisation 110
Itratif et incrmental 111
UP est centr sur larchitecture 111
9.6 XP (EXTREME PROGRAMMING) 111
9.7 VALEURS DE XP 113
La communication pour une meilleure visibilit 113
La simplicit comme garantie de productivit 113
Le feedback pour rduire le risque 114
Le courage de prendre les bonnes dcisions 114
9.8 LES PRATIQUES ESSENTIELLES DE XP 114
Les 12 pratiques de XP 115
P1: Dveloppement pilot par les tests 115
Tests de recette (tests fonctionnels) 115
Tests de recette et spcifications XP 116
Tests unitaires 116
Rfrences 116
P2: Le Planning game - Planification itrative 117
User stories (scnarios) 118
Stricte rpartition des tches 118
Un jeu en 3 phases 119
Stand-up meetings 120
Vlocit, contrle de lefficacit et suivi du projet 120
P3: Client sur le site 121
P4: Programmation en binme 121
P5: Intgration continue 122
Gnie logiciel - v -
P6: Refactoring: remaniement de code 122
P7: Courtes itrations de livraison 124
P8: Conception simple 124
P9: Utiliser la mtaphore 125
P10: Responsabilit collective du code 125
P11: Conventions de codage 125
P12:Rythme durable: assurer le bien-tre des dveloppeurs 125
9.9 XP: ORGANISATION DE LQUIPE DE DVELOPPEMENT 126
Responsabilits des rles XP 126
Le programmeur 127
Droits du programmeur XP 127
Le client 128
Droits du client 128
Le testeur 128
Le tracker 129
Le manager 129
Le coach 129
Combinaison des rles XP 130
9.10 QUELQUES MTHODES AGILES 130
9.11 RFRENCES SUR XP 130
10 ANNEXE 1 - DIAGRAMMES DE CLASSES - UML 2.0 131
10.1 OBJ ETS, ATTRIBUTS & CLASSES 131
Reprsentation graphique 132
Nom de la classe 133
Attributs 133
Visibilit de lattribut 133
Le type dun attribut 133
La proprit dun attribut 134
La valeur par dfaut 134
Oprations 135
Visibilit dune opration 135
Liste des paramtres 135
Requtes et modificateurs 136
Accesseurs et mutateurs 136
La proprit dune opration 136
10.2 CONCEPT D'ASSOCIATION 136
Reprsentation graphique 137
Rle des objets 137
Multiplicit d'une association 138
Convention pour le nom d'une association 139
Navigabilit des associations 139
Proprits des associations 141
Classes dassociation 142
Arit d'une association 142
Associations ternaires 143
Multiplicit des associations ternaires au sens Merise et UML 144
Les relations ternaires sont rarement utilises 147
Agrgations et compositions 149
Retour sur la notion dattribut 150
Retour sur la notion dassociation 150
Les associations simples 150
Les associations de type composition 151
Gnie logiciel - vi -
Les agrgations 152
Hirarchie Attribut > Composition > Agrgation > Association simple 153
10.3 GNRALISATION - SPCIALISATION 154
Reprsentation symbolique de la relation GEN-SPEC 155
Un petit rappel: les notions de type 156
La spcialisation et son principe, types et soustypes 156
La rgle de substitution 157
GEN-SPEC et hritage 158
Reprsentation des classes abstraites 158
10.4 LES CONTRAINTES 159
11 ANNEXE 2 - DIAGRAMMES DACTIVITS 161
11.1 NOTATION DE BASE 162
11.2 PARTITION - COULOIRS DACTIVITS 164
11.3 SIGNAUX 167
12 ANNEXE 3 - DIAGRAMMES DE SQUENCE 169
12.1 NOTATION DE BASE POUR DCRIRE UN SCNARIO 170
12.2 OBJ ETS ACTIFS ET OBJ ETS PASSIFS 172
12.3 OBJ ETS TEMPORAIRES 173
12.4 MESSAGES SYNCHRONES ET ASYNCHRONES 174
12.5 CONDITIONS ET ITRATIONS 176
13 ANNEXE 4 - MVC & MODLE OBSERVATEUR 179
13.1 EN PRLIMINAIRE: LES MODLES DE CONCEPTION 179
13.2 LE MODLE MVC 180
Le M comme Modle 183
Le V comme Vue 183
Couplage Vue-Modle: Le modle Observateur 185
Le principe de sparation Modle-Vue 185
Principe du modle Observateur 186
Diagramme de classes 188
Linterface Observateur 188
La classe Observable 189
Diagramme de squence 189
C comme contrleur 189
13.3 LE MODLE OBSERVATEUR 190
API J ava et le modle Observateur 190
API Observer 191
API Observable 191
Le modles des listeners 192
13.4 MVC ET LE PATTERN COUCHES 192
Support de cours - 1 - En prliminaire
ELS - 7 December 2006
1 En prliminaire
1.1 LES OBJECTIFS DU COURS
Les objectifs du cours sont principalement les suivants:
Acqurir la capacit de crer des logiciels correctement conus, robustes et main-
tenables en utilisant des technologies objets avec des langages tels que C#, J ava,
C++, etc.
Introduire ltudiant lanalyse et la conception objet, en basant le discours sur
la notation UML, les modles de conception (patterns) et le processus unifi (UP
- Unified Process). Laccent sera plac sur lapprentissage des concepts fonda-
mentaux. Cela va donc bien au del dun simple apprentissage du langage UML,
qui nest aprs tout quune simple notation.
En particulier:
Du point de vue de analyse: acqurir les connaissances permettant de mener
bien ltape danalyse des besoins avec la spcification des cas dutilisation.
Du point de vue de conception: connatre et savoir appliquer des modles de con-
ception (design patterns) qui aideront tablir quelles responsabilits confier
tel ou tel objet, tablir de quelle manire les objets vont intragir.
Du point de vue de mthode: introduire ltudiant une mthode, une marche
suivre, pouvant tre mise en oeuvre par une quipe de dveloppeurs dans le cadre
de la ralisation dun logiciel. Il sagira notamment de la mthode dite processus
unifi (UP - Unified Process), larchtype de la dmarche incrmentale itrative.
Bien que cette mthode ne soit pas la panace et soit bien loin dtre reconnue
comme la mthode, - dautres approches seront prsentes comme les mtho-
des dites agiles dont la plus fameuse: XP (eXtrme Programming) -, elle cons-
titue une rfrence et un cadre intressant pour introduire les concepts
fondamentaux qui - une fois matriss - peuvent tre appliqus dans dautres
dmarches.
Remarquons que le fait dtre pass matre dans la manipulation dun marteau ne
fait pas de nous un bon architecte: la connaissance et la pratique dun langage de pro-
grammation ne suffit pas..
En bref, les objectifs du cours peuvent tre rsums comme suit:
appliquer des principes et des modles de conception pour crer de meilleures
conceptions objet
mener bien un certain nombre dactivits fondamentales comme lanalyse et la
conception, dans le cadre dune dmarche base sur le processus unifi, pris
titre dexemple.
mettre en oeuvre les diagrammes de modlisation les plus courants en utilisant la
notation UML
1.2 PRINCIPALES RFRENCES BIBLIOGRAPHIQUES
Ce cours sappuie sur des ouvrages consacrs au Gnie Logiciel ou encore UML.
Citons la source principale pour laquelle nous exprimons toute notre reconnaissance
Craig Larman Applying UML and patterns - Second edition - Prentice Hall
2002 2nd Edition - Une version franaise existe depuis peu.
Mais aussi:
R. Martin; Agile Software Development, Principles, Patterns, and Practices.
Prentice Hall 2002
A. Cockburn; Writing Effective Use Cases. Addison Wesley, 2000 (ISBN: 0-
201-70225-8).
M. Fowler and K. Scott; UML Distilled: A Brief Guide to the Standard Object
Modeling Language. Addison Wesley 2002, 2nd Edition.
I. J acobson, G. Booch, and J . Rumbaugh; Unified Software Development Pro-
cess. Addison Wesley 1999
Ce cours sappuie galement sur dautres cours donnes dans diverses coles ding-
nieurs:
Cours Gnie Logiciel - Pierre Melier - HES-EIVD.
Cours Gnie Logiciel - Michel Vinckenbosch - HES-EIG
Cours Gnie Logiciel - Ecole Polytechnique de Montreal
Support de cours - 5 - La problmatique
2 La problmatique
Quelques devinettes..
Pour vous mettre sur la voie, voici une premire srie de devinettes.
Y a-t-il une diffrence entre:
Construire une cabane au fond du jardin;
Construire le btiment de lEIVD?
Quel projet cote le plus cher?
Quel projet est le plus long raliser?
Quel projet ncessite le plus de personnes pour sa ralisation?
Dans quel projet la phase de construction est-elle proportionnellement la plus lon-
gue (par rapport la dure complte du projet)?
Une deuxime srie..
Le btiment de lEIVD a t construit aux environs de 1975. cette poque, il corres-
pondait aux besoins de lcole.
Peut-on dire que ce btiment correspond encore nos besoins daujourdhui?
Le btiment nest pas modulaire;
Les normes de lpoque ne conviennent plus.
La taille des btiments a une grande importance sur leur ralisation.
Est-ce la mme chose en informatique?
Cette petite introduction nous a permis de mettre en vidence limportance consi-
drable que peut prendre la taille mme du logiciel dvelopper. Aussi, nous allons exa-
miner de plus prs ce qui distingue un petit logiciel dun gros logiciel..
Les petits logiciels
Le cahier des charges est petit, facile comprendre et mme parfois transmis ora-
lement.
La conception du programme se fait souvent mentalement sans documentation.
Le cot du logiciel est faible ou ngligeable.
Le choix des technologies (systme dexploitation, environnement de dveloppe-
ment, choix des machines, etc. ) est opr par le dveloppeur.
Le dveloppement est ralis personne et dure peu de temps, parfois quelques
semaines, au plus quelques mois, dailleurs aucune estimation pralable du temps
de dveloppement nest faite le cas chant.
Le logiciel est rarement document, son usage est facile.
Le logiciel sera dploy une ou deux fois, par le dveloppeur lui-mme.
La maintenance du logiciel cesse de facto lorsque le dveloppeur cesse de le sup-
porter (dpart de la socit, changement daffectation, etc.). Cela entrane souvent
la mort du logiciel.
Toutes les conditions pour le succs du dveloppement sont donc runies!
Les gros logiciels
Le cahier des charges est volumineux. Il est mme parfois:
difficile comprendre;
mal crit, le client na pas une ide trs claire du rsultat final, il y manque
beaucoup dinformations;
crit par des personnes qui ne connaissent pas grand chose linformati-
que.
En gnral les dveloppeurs ne connaissent pas ou peu le mtier o sapplique le
logiciel.
La conception du programme est un vrai casse-tte, pleine dembches, cause
des incertitudes sur le cahier des charges et de la taille du programme raliser.
Le cot du logiciel est norme.
Le choix des technologies est prilleux:
il faut tenir compte des besoins du client;
la dure de vie des technologies doit tre plus grande que la dure de vie du
logiciel;
le choix des technologies peut entraner des dbats passionns, source de
conflits.
Le dveloppement se fait par une quipe, parfois assez grande, il peut durer des
annes.
Une estimation pralable du temps de dveloppement est importante pour pouvoir
estimer les cots du logiciel.
Lquipe de dveloppement devrait pouvoir respecter les dlais de dveloppe-
ments estims, cest un dfi.
Le logiciel doit tre parfaitement document. Cette documentation doit tre livre
en mme temps que le logiciel, il faut donc dvelopper simultanment le logiciel
et sa documentation.
Le logiciel nest pas dploy par lquipe de dveloppement:
il est peut-tre livr sur CD et diffus en grand nombre;
il est peut-tre livr trs petite chelle, mais son installation est compli-
que. Des personnes spcialement formes sont charges du dploiement.
La maintenance du logiciel est gre par un contrat, renouvel souvent danne en
anne. Le logiciel doit survivre lquipe de dveloppement
Toutes les conditions pour lchec du dveloppement sont runies.
Posez-vous seulement la question.
Dans quelle catgorie vous situez-vous lorsque vous dveloppez un projet informatique:
dans le cadre scolaire?
dans le cadre professionnel?
Maintenant, un petit exercice..
Combien cote une ligne de code, sachant que:
un bon dveloppeur cote Frs 200000.- par anne son entreprise tout frais com-
pris;
il code en moyenne 20 lignes par jour;
il est absent en moyenne 1/5 du temps (vacances, arme, maladie, etc.);
il y a environ 250 jours ouvrables par anne;
Quelques dfinitions cls
Voici quelques dfinitions cls du gnie logiciel, sur lesquelles nous reviendrons, mais
quil est ncessaire dapprhender dors et dj afin de lire plus aisment ce qui va suivre
dans le cadre de cette introduction sur le gnie logiciel.
Spcification
Activit consistant dcrire formellement ou semi-formellement le fonctionne-
ment dun systme. On doit rpondre aux questions: que doit faire le systme?,
pourquoi?
Conception
Activit consistant rflchir, modliser et dcider comment le systme va tre
implment. On doit rpondre la question: comment raliser le systme?
Implmentation
Activit consistant coder le systme
Test
Activit consistant excuter le systme ou ses parties pour vrifier quil fonc-
tionne correctement ou pour dcouvrir ses anomalies
Maintenance
Le logiciel est en service chez le client. Cette activit comprend la correction
derreurs dtectes par le client, mais aussi et surtout lajout de nouvelles fonc-
tionnalits ou encore ladaptation, la modification de fonctionnalits existentes.
2.1 LA CRISE DU LOGICIEL DES ANNES 70
Avec laccroissement de la complexit des logiciels (notamment de leur taille), le dve-
loppement ne suit pas: il faudra 10 ans pour dvelopper l OS 360 des IBM 360
Figure 1: Rapport du Congrs Amricain en 1979 sur 487 projets
Figure 2: Un rapport amricain de 1994 - Standish Group International
Les projets analyss ont tous utilis le modle en cascade (waterfall) que lon pr-
sentera un peu plus loin dans le cours.
53% des projets ont dpass le budget prvu initialement de 200% !
Environ $81 milliards dpenss pour des projets abandonns aux USA en 1995
Sources: US Gov. Accounting Report,
(in B. Cox, OO Prog.)
29%
19%
2%
3%
47%
Livr mais pas utili s
Abandonn ou
repris
Pay mais pas
li vr
Utilis aprs correction
Utilis tel que livr
Sources: US Gov. Accounting Report,
(in B. Cox, OO Prog.)
29%
19%
2%
3%
47%
Livr mais pas utili s
Abandonn ou
repris
Pay mais pas
li vr
Utilis aprs correction
Utilis tel que livr
Projet
non termin
30%
Projet termin
70%
Panique bord du bateau logiciel
les logiciels raliss ne correspondent souvent pas aux besoins des utilisateurs;
les logiciels contiennent trop d'erreurs (qualit du logiciel insuffisante);
les cots du dveloppement sont rarement prvisibles et sont gnralement prohi-
bitifs;
la maintenance des logiciels est une tche complexe et coteuse;
les dlais de ralisation sont gnralement dpasss;
les logiciels sont rarement portables;
les changements de besoin du client sont difficiles intgrer dans le dveloppe-
ment;
la performance du systme est souvent inacceptable;
le systme est difficilement rutilisable pour de futurs dveloppements (ce qui
permettrait de rpartir les cots de dveloppement sur plusieurs projets)
Et pourquoi donc ?
Car le logiciel est une tche complexe..
Reconnaissons tout dabord que a nest pas une tche facile..
Une quantit de facteurs influent de manire ngative.
Taille et complexit du systme informatiser.
Complexit attache l'environnement du systme.
Complexit de communication entre les futurs utilisateurs (diversit des points de
vue)
Complexit de communication entre les futurs utilisateurs d'une part et les dve-
loppeurs d'autre part (vocabulaire technique et non-technique)
Car lvolution est trop rapide..
Figure 3: Evolution du matriel et du logiciel
Figure 4: Evolution des langages et des outils
Car au del des mythes, la ralit..
Les mythes du ct usager
Un nonc gnral des objectifs est suffisant. On verra pour les dtails plus tard !
Traitement par lots
Distribution limite
Logiciel personnalis
Multi-utilisateurs
Temps-rel
Bases de donnes
Systmes distribus
Systmes embarqus
Le cot du matriel baisse
Les usagers deviennent
exigents
Systmes personnels
Orient-Objet
Systmes experts
Rseaux neuronnaux
Calcul parallle
Internet
1950
1960 1970 1980 1990
1re poque
2me poque
3me poque
4me poque
Epoque hroque
0/1 (code machine)
Assembleur
Premiers langages
volus avec
compilateurs
Fortran, Cobol
Puis structurs

C, Pascal,
Modula-2
Ada
Langages orients objet
Smalltalk, C++
Java
Outils CASE pour le
dveloppement intgr
Normes de conception
UML, CORBA
Frameworks de
dveloppement
WEB (Struts, Cocoon, EJB, ..)
Persistance (Hibernatus)
1960
1970 1980 1990 2000
1re gnration
2me gnrati on
3me gnration
4me gnration
La ralit: Une dfinition insuffisante des besoins des usagers est une cause
majeure de production dun logiciel de mauvaise qualit
Les besoins du projet changent, mais on incorporera les modifications facilement
parce que le logiciel est flexible !
La ralit: Les cots pour un changement du logiciel augmentent de manire dra-
matique dans les dernires phases du dveloppement.
Figure 5: Le cot du changement
Les mythes du ct dveloppeur
Une fois que le programme est crit et quil fonctionne, le travail du dveloppeur
est termin !
La ralit: 50% 70% de leffort consacr un programme se produit aprs la
livraison lusager.
Tant quun programme ne fonctionne pas, il ny a pas moyen den mesurer la qua-
lit !
La ralit: les revues de logiciel peuvent tre plus efficaces pour dtecter les
erreurs que les jeux de tests.
Dfinition Dveloppement
Maintenance
1X
1.5 - 6X
60 - 100X
Cot
Le succs dun projet tient essentiellement de la livraison dun programme fonc-
tionnel !
La ralit: Une configuration logicielle inclut toute la documentation, des don-
nes dentre pour les tests, etc
Les mythes du ct gestionnaire
Lentreprise possde des normes, le logiciel dvelopp devrait tre satisfaisant !
La ralit: les standards sont-ils utiliss, appropris et complets?
Les ordinateurs et les outils logiciels que lentreprise possde sont suffisants
La ralit: il faut plus que des outils pour raliser du logiciel de qualit. Il faut
aussi une bonne pratique.
Si le projet prend du retard, il suffira dajouter quelques programmeurs.
La ralit: Le dveloppement du logiciel nest pas une activit mcanique. Ajou-
ter des programmeurs peut empirer la situation
Naissance du gnie logiciel
7 au 11 octobre 1968, confrence Garmish-Partenkirchen (sponsorise par
lOTAN)
Le terme de software engineering est utilis pour la premire fois par les pro-
fesseurs Bauer et Bolliet, dans un rapport de la confrence scientifique.
La traduction franaise gnie logiciel est plus tardive.
Le langage Ada est une consquence directe de cette crise. Cest la rponse de
Dpartement de la Dfense amricaine ce problme.
Puis arrivent les premires mthodes: VDM (Vienna Development Method) date
du dbut des annes 70, le langage Z (Spcification formelle - Abrial) date de
1978.
Dfinition du gnie logiciel
Dfinition 1: Le gnie logiciel
Discipline dingnierie concerne par le problme pratique du dveloppement de grands
systmes logiciels.
Sommerville Ian Le gnie logiciel, Addison-Wesley France, 1992
Cette premire dfinition met en avant la problmatique lie la taille du projet. La
deuxime est un peu plus prcise quant aux objectifs de cette discipline.
Dfinition 2: Le gnie logiciel
Discipline pour spcifier, construire, distribuer et maintenir des logiciels, en assurant:
la qualit (fiables, adapts, conviviaux, volutifs)
des cots contrls
des dlais garantis
2.2 LES QUALITS REQUISES DUN LOGICIEL
La crise des annes 70 nous, telle que nous lavons dcrite, nous permet de prciser dans
ses grandes lignes les objectifs du gnie logiciel (reprise de la deuxime dfinition du g-
nie logiciel).
Dfinition 3: OBJECTIFS DU GNIE LOGICIEL
Donner les moyens ncessaires lquipe de dveloppement pour que le systme ralis:
respecte les cots et les dlais de dveloppement;
soit un produit de qualit.
Dans cette dfinition, le mot-cl qualit - mot magique -, mrite lui seul tout un
dveloppement..
On peut aborder le critre qualit selon 3 points de vue:
la qualit externe (point de vue de lutilisateur)
la qualit interne (point de vue du dveloppement)
la qualit du processus de dveloppement
Remarquons demble quil y a une grande interdpendance entre ces trois points de vue.
2.2.1 Qualits externes significatives
La correction, la fiabilit et la robustesse sadressent laspect fonctionnel du logiciel fourni
au client.
Correction
Un logiciel correct satisfait sa spcification (fonction attendue) de manire absolue.
Fiabilit
La fiabilit est une notion relative lide que sen fait lutilisateur mme du logiciel.
La fiabilit mesure le degr de confiance que lon peut avoir dans le fonctionnement du
logiciel. Il marche aujourdhui, marchera-til demain ? Peut-on compter sur ce produit ?
Robustesse
La robustesse dnote une aptitude fonctionner correctement sous des conditions anor-
males, comme par exemple:
Dans les cas non spcifis par l'analyse des besoins:
Ressource non disponible fichier non-existant , etc.
Valeur inattendue, p.ex: division par zro, date= 29/2/2002
A loccasion de pannes du rseau ou de machines
serveur ne rpond pas ,
etc.
Le systme doit alors pouvoir sadapter et continuer de fonctionner.
Performance
Qualit lie lalgorithmique (complexit polynomiale, exponentielle) .
Evaluation par mesure, analyse et simulation.
Ergonomie
Qualit lie la facilit dutilisation.
Se rattache principalement linterface utilisateur mais dpend aussi de la perfor-
mance et de la correction.
2.2.2 Qualits internes significatives
Maintenabilit (~60% du cot)
maintenance corrective: pour liminer les erreurs
maintenance adaptative: changement dans lenvironnement
maintenance perfective: changement pour amliorer ses qualits
Rparabilit
Facilit avec laquelle le logiciel peut s'adapter des corrections.
Ncessite une bonne structure modulaire avec de bons interfaces, un langage ad-
quat.
Evolutivit
Facilit avec laquelle le logiciel peut s'adapter des changements de spcifica-
tion.
Rutilisation
A priori ou posteriori.
Lide tant de dvelopper une tagre de composants.
Portabilit
Le produit est indpendant du genre denvironnement
Interoprabilit
Capacit intragir avec dautres systmes; qualit rare pour le logiciel mais cou-
rante dans dautres domaines; qualit vise par les dmarches de normalisation
2.2.3 Qualits du processus de dveloppement
Productivit et rutilisation
Respect des dlais
Echange dinformations
Bonne documentation, accessible tous
2.3 AUTOPSIE DE QUELQUES CATASTROPHES
1962: La perte de Mariner I (1)
Pour quelques lignes de FORTRAN:
DO 5 K = 1. 3
T( K) = W0
Z = 1. 0/ ( X**2) *B1**2+3. 0977E- 4*B0**2
D( K) = 3. 076E- 2*2. 0*( 1. 0/ X*B0*B1+3. 0977E- 4*
*( B0**2- X*B0*B1) ) / Z
E( K) = H**2*93. 2943*W0/ SI N( W0) *Z
H = D( K) - E( K)
5 CONTI NUE
La premire ligne est fausse, elle aurait d scrire
DO 5 K = 1, 3 Boucle avec K variant de 1 3
Au lieu de cela, le compilateur FORTRAN a compris
DO 5K = 1. 3 Boucle parcourue 1 fois avec K valant 1.3
Ainsi, la perte de Mariner est due une erreur de programmation lmentaire.
Cette erreur a mis en vidence la faiblesse de la syntaxe du langage FORTRAN
Trop grande proximit entre laffectation est linstruction de boucle;
Difficult de lecture du programme.
Le code fautif navait pas t test correctement.
Mars Climate Orbiter ($125M)
Le 23 septembre 1999 11h27, la NASA perd tout contact avec la sonde spatiale Mars
Climate Orbiter. La sonde sest dsintgre dans latmosphre de Mars en essayant de se
mettre en orbite une hauteur de 53 km au lieu des 193 km qui taient planifis.
Lorigine de la panne est une erreur parfaitement stupide:
Lockheed Martin Astronautics a utilis les mesures anglo-saxonnes;
J et Propulsion Laboratory a utilis le systme mtrique;
Personne na converti les donnes changes (1 livre =4.48 Newton).
Erreur dans les processus de validation de la NASA
Rapport de la NASA (2000)
Lerreur de navigation na pas t dtecte par la simulation informatique de la
propulsion.
Lquipe oprationnelle de navigation ntait pas assez informe de la manire
dont la sonde tait oriente dans lespace.
Une dernire mise feu des moteurs avant larrive de la sonde pour rorienter la
sonde a t envisage, mais pas ralise pour diverses raisons.
Le processus de validation des tches interconnectes ntait pas assez robuste
cause dun changement de stratgie de la NASA dans sa manire de raliser les
nouveaux projets.
Certains canaux dinformation entre groupes dingnieurs taient trop informels.
La petite quipe des missions de navigation tait surcharge de demandes et na
pu tre value temps par un groupe dexperts.
Le personnel ntait pas assez entran remplir les formulaires formels dano-
malies.
Le processus de vrification et de validation des interfaces techniques entre les
groupes tait inadquat.
Autres checs retentissants
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 lance 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.
L'explosion de la fuse Ariane 5, le 4 juin 1996, qui a cot un demi milliard de
dollars (non assur!), est due une faute logicielle d'un composant dont le fonc-
tionnement n'tait pas indispensable durant le vol.
Gnie logiciel - 19 - Modlisation
3 Modlisation
Le dveloppement de logiciels est une entreprise complexe. Notre mmoire court terme
tant fortement limite, nous prouvons le besoin naturel de modliser pour simplifier et
augmenter ainsi artificiellement notre capacit intellectuelle rsoudre les problmes.
Dfinition 4: les modles
Les modles sont des abstractions de la ralit. Ce sont des reprsentations de la ralit
qui nen gardent que lessentiel, jetant le superflu qui ne fait quencombrer lesprit.
Un modle est une synthse (ne garde que lessentiel); il sera donc souvent volon-
tairement simplifi;
Un modle a toujours un objectif prcis, celui de montrer un aspect particulier
dun problme donn. Plusieurs modles sont donc ncessaires pour reprsenter
la totalit du systme.
Indirectement, la mise en oeuvre de modles prsente encore de nombreux avantages
non dnus dintrt:
Un modle est un outil de communication
Outil de communication entre analystes, entre analystes et concepteurs, etc., un
modle peut galement tre utilis pour communiquer avec les utilisateurs du sys-
tme (les clients), sous rserve que ces derniers soient des clients avertis et sus-
ceptibles de le comprendre: un prototype est souvent plus indiqu.
Soulignons quun modle, pour tre un outil valable de communication, doit alors
sappuyer sur une smantique indpendante du temps et des personnes. En dautres ter-
mes, il doit sagir dun modle normalis (comme peut ltre UML).
Un modle est un outil de documentation
La ralisation dun modle obissant une norme de type UML gnre par la
mme occasion une documentation structure, et ceci automatiquement, sans aucun
effort (Ouf!).
Cette documentation sera utilise pendant la maintenance du systme, voire pen-
dant la phase de test.
3.1 LA MODLISATION DUN SYSTME INFORMATIQUE
Un seul modle ne suffira pas pour dcrire tout un systme informatique. Un systme peut
tre apprhend suivant diffrents points de vue et notamment:
le point de vue des donnes et de leur structuration,
le point de vue des traitements
et le point de vue dynamique.
Diffrentes approches sont donc ncessaires pour assurer la bonne comprhension dun
systme. Le langage UML, par exemple [Voir paragraphe - Quelques mots sur UML - page 36],
prvoit ainsi plusieurs types de modles qui permettent chacun dclairer ou tout du
moins de mettre laccent sur un certain aspect du systme.
Fondamentalement, on peut citer trois grands types de modles:
1. Le modle fonctionnel
Qui indique les traitement accomplis.
P.E: diagrammes de flux de donnes, diagrammes dactivits (UML)
2. Le modle comportemental
Qui indique quand et quelle occasion ces traitements sont accomplis.
P.E: diagrammes dtats et de transition (UML)
3. Le modle des donnes
Qui indique ce sur quoi ces traitements agissent.
P.E: diagrammes de classes (UML), diagrammes ER (Entit-Relation)
3.2 DE LIMPORTANCE DE LA MODLISATION
Si lapproche Objet nous semble aujourdhui naturelle, il nen a pas toujours t ainsi. Un
petit retour en arrire peut tre instructif plus dun titre.
Dun point de vue historique, remarquons que lon distingue en gnral 3 types de syst-
mes, suivant quils sapparentent plutt aux donnes, aux traitements ou encore la ges-
tion des vnements.
Les systmes orients donnes
Ces systmes sappuient sur des structures dinformation complexes et fortement dpen-
dantes.
Il peut sagir par exemple de la base de donnes du services des eaux de la ville de Lau-
sanne, du service de rservation dune compagnie daviation, etc.
Les systmes orients traitements
Ces derniers reposent essentiellement sur la mise en oeuvre de traitements complexes.
Le dveloppement de tels systmes est une entreprise dlicate en raison de la complexit
des algorithmes mis en jeu. Par contre ils ne prsentent pas vraiment de difficult du
stricte point de vue du Gnie Logiciel.
Preuve en est quils sont souvent loeuvre de scientifiques dont le background informati-
que a t dans bien des cas appris sur le tas - ce qui nenlve rien la qualit du pro-
duit -.
Citons titre dexemple les logiciels de traitement de signal, de simulation discrte (files
dattente), lintelligence artificielle, etc.
Les systmes orients comportement
Ces systmes ragissent principalement aux vnements externes auxquels il doivent ap-
porter une rponse adquate tenant compte de ltat interne du systmes.
Citons par exemple:
les systmes embarqus,
les automates tats finis,
les interfaces Homme-Machine,
etc.
Ainsi, historiquement, le monde informatique sest quelque peu cloisonn pour donner
naissance diffrentes approches.
3.2.1 Les principales approches
A lorigine, deux approches se sont dveloppes en parallle, adaptes chacune au monde
informatique qui leur avait donn naissance. Il sagit de lapproche dite traditionnelle
ou encore procdurale et de lapproche des bases de donnes.
Quelque part, on peut considrer que lapproche objet a rconcili les deux mondes.
Approche traditionnelle
Sappuie sur deux principes fondamentaux:
les donnes font partie de l'application;
il existe un lien trs troit entre les donnes et les applications.
Quand on veut changer les donnes, il faut aussi changer les applications (et vice versa).
Lapproche est essentiellement top-down (dcomposition fonctionnelle) et sappuie
sur les langages procduraux comme Pascal ou issus de Pascal.
Approche Base de donnes
Dans le monde des bases de donnes, on sappuie galement sur deux principes:
Avoir la possibilit de modifier la structure des donnes sans changer les pro-
grammes de l'application.
Avoir la possibilit de modifier les programmes de l'application sans changer la
structure des donnes.
Dans ce contetxe, l'indpendance des donnes est donc un facteur primordial!
Ds que l'importance de l'indpendance des donnes a t reconnue, on a t amen
faire beaucoup plus attention la conception des donnes (d'o lapproche modlisation
par les donnes).
Systme de gestion
de
base de donnes
Base de donnes
Facturation
Administration
du systme
Service l a
clientle
Approche oriente objet
Cette approche est venue du besoin de:
Construire des modles plus proches du monde rel.
Rutiliser des fragments de logiciels.
Elle sappuie sur la nouvelle gnration de langages qui apparaissent la fin des annes
1970 qui permettent l'encapsulation des donnes et des traitements dans un objet: ADA
(1979), Simula et Smalltalk (1980) puis C++.
Selon cette approche, un objet peut tre caractris par trois attributs: donnes, fonc-
tions et comportement. Ca nest donc pas incompatible avec les deux approches prsen-
tes plus haut, et tous les modles utiliss dans ces dernires sont utilisables en objet (et
sont dailleurs utiliss partiellement).
Mais a n'est pas une approche top-down - ni linverse dailleurs! -.
Le top-down est un bon moyen de reprsenter des choses que l'on matrise bien. ..
Mais le top-down n'est pas un bon moyen pour dvelopper, concevoir ou dcouvrir.
Voici quelques applications susceptibles de bnficier de ces techniques:
Domaine des grands logiciels
Tlcommunications
Contrle de processus industriels
Traitements rpartis
Systmes temps rel ( venir..)
3.2.2 Petit historique des modles utiliss
Le modle tait trs attach au type de systme dvelopper.
Systmes orients donnes
Diagrammes Entits-Relations (ER) - Chen, Palmer, Mac Donald (1976-78)
Pour lanalyse
Approche plat
Focalise sur les proprits statiques des donnes
Formes Normales (FN) - Codd
Pour la conception
Conception focalise sur la non redondance des informations
Systmes orients traitements
Diagrammes de Flux de Donnes (DFD) - De Marco, Yourdon (1982-83)
Pour lanalyse
Approche top-down
Focalise sur les aspects fonctionnels
Diagrammes de Structure - Myers, Constantine, Yourdon (1974)
Pour la conception
Approche top-down
Focalise sur les modules
Sappuie sur les Diagrammes de Flux de Donnes (DFD)
Systmes orients comportement
Concernant les systmes orients comportement, la conception tait trs fortement dpen-
dante du langage et des outils utiliss.
Diagrammes de Flux de Contrle (DFC) - Ward-Mellor, Hatley-Pirbai (1985, 87)
Une analyse focalise sur l'aspect comportemental
Modlisation Oriente Objet
Technique de Modlisation Objets (OMT) - Rumbaugh (1992)
Analyse et Conception Oriente Objets (OOAD) - Booch( 1980-93)
Diagrammes Entits-Actions (J SD Entity-Actions) - Jackson (1983)
Analyse Oriente Objets et Conception Oriente Objets (OOA/OOD) - Shlaer-Mel-
lor (1987-91)
Analyse Oriente Objets et Conception Oriente Objets (OOA/OOD) - Coad-You-
don (1991)
Classe & Relation - Desfray (1993)
UML (1997 - version 1)
UP (2001)
Gnie logiciel - 25 - Cycles de vie et mthode UP
4 Cycles de vie et mthode UP
Comme nous lavons mentionn dans les prliminaires du cours, nous nous atta-
cherons dcrire une mthode de dveloppement particulire, base sur la technologie
Ob jet et sur UML, qui porte le nom de mthode UP (comme Unified Process). Cette
mthode dcrit essentiellement la marche suivre loccasion de la ralisation dun logi-
ciel. De manire plus gnrale, plutt que de parler de marche suivre, on parle plutt
de cycle de vi, un concept qui donne le nom de ce chapitre.
La mthode UP nest pas unique en son genre, mais elle a toutefois le mrite de bien
poser certains concepts cl. Nous aurons galement loccasion de prsenter une autre
mthode concurrente mais qui sen rapproche: leXtrme Programming, qui sappuie
galement sur la modlisation objet.
A la base de la mthode UP, un concept cl: le dveloppement itratif, une appro-
che qui dcoupe le dveloppement en une srie de mini-projets que lon appelle itrations.
Dfinition 5: Itration
Chaque itration aboutit un systme excutable et test.
Chaque itration comprend sa propre phase danalyse des besoins, de conception,
dimplmentation et de test.
Figure 6: Dveloppement incrmental itratif
Du point de vue strictement historique, le concept mme de dveloppement itratif incr-
mental est laboutissement dun concept qui portait lorigine le nom de processus en
spirale (spiral development) ou encore processus volutif (evolutionary process).
A titre dexemple, mi-chemin du dveloppement dun projet, une itration de deux
semaines pourrait se dcomposer ainsi:
le lundi consacr la clarification et la distribution des tches dans le groupe,
pendant quune personne effectue le reverse-enginnering de litration prcdente
(gnration de diagrammes UML)
le mardi consacr la conception de diagrammes UML grossiers, conus et dessi-
ns au tableau en travaillant en binme et enregistrs au moyen dune camra
numrique, lcriture de fragments de pseudo-code, etc.
les 8 derniers jours consacrs limplmentation et le test dunits et dintgra-
tion dans le systme, mais aussi dautres activits comme par exemple des
dmonstrations aux diffrents partenaires ou encore la planification des prochai-
nes itrations.
Le modle du dveloppement itratif incrmental prsente de nombreux avantages. Pour
les apprcier leur juste valeur, nous allons revenir en arrire en prsentant la notion de
cycle de vie et les diffrents modles sur lesquels le gnie logiciel sest appuy depuis les
annes 70.
4.1 LES DIFFRENTES PHASES DU CYCLE DE VIE: ANALYSE ET
Conception
Analysedes besoins
Implmentation
& test
Intgration
& test du systme
Systme
excutable
Conception
Analysedes besoins
Implmentation
& test
Intgration
& test du systme
Systme
excutable
Itration i-1
Itration i
Conception
Analysedes besoins
Implmentation
& test
Intgration
& test du systme
Systme
excutable
Itration i+1
CONCEPTION
Dfinition 6: Cycle de vie
Le cycle de vie du logiciel modlise lenchanement des diffrentes activits du processus
technique de dveloppement du logiciel. Tous les modles diffrencient 3 grandes activi-
ts qui vont, selon le modle, intragir diffremment. Ce sont:
1. Lanalyse: comprendre le problme, les besoins
2. La conception: trouver une architecture pour rsoudre le problme
3. La ralisation: mettre en oeuvre, fabriquer
Ces 3 activits ne sont pas la caractristique des dveloppements informatiques. Par
exemple, pour fabriquer un modle mcanique du systme solaire il faut:
1. analyser le problme en observant que les plantes suivent des orbites;
2. concevoir en inventant un mcanisme qui dplace des sphres sur de telles orbites;
3. puis raliser lassemblage des sphres, ressorts et engrenages.
Toute mthode - et en particulier la mthode UP - propose une dmarche et des notations
pour aborder ces problmes.
La dmarche (le cycle de vie) dcrit quelles tapes lmentaires doivent tre suivies,
quelles questions doivent tre souleves et quel moment, quels sont les objets qui
doivent tre mis en vidence, etc.
La notation permet de prsenter et formaliser des objets solution aux informaticiens et
aux clients; il est donc souhaitable - voire indispensable- quune notation soit compr-
hensible par des non-spcialistes.
Analyse et conception
Revenons encore un peu sur lanalyse et la conception..
Dfinition 7: Analyse: le QUOI
Lanalyse est une activit qui sattache en premier lieu mener une investigation sur le
problme et les besoins, plutt qu rechercher une solution.
En gros, il sagit de rpondre la question: Quest-ce quon dsire et comment ce sera
utilis?
Le terme analyse est un peu flou. On lui prfre souvent les termes analyse des
besoins ou encore analyse des objets (recherche mene sur les objets du domaine).
Dfinition 8: Conception: le COMMENT
La conception est une activit qui sattache en premier lieu dfinir une solution con-
ceptuelle susceptible de rpondre aux besoins issus de lanalyse plutt qu dfinir une
implmentation du problme.
Notamment, il sagira par exemple de dfinir le schma conceptuel de la base de donnes
et larchitecture des classes (au moyen dun diagramme UML).
Encore une fois, le terme conception manque de prcision. On lui prfrera souvent
conception objet ou encore conception de la base de donnes.
En rsum
Do the right thing (analysis), and do the thing right (conception)
4.2 LE CYCLE DE VIE EN CASCADE (WATERFALL)
Ce modle est similaire ce qui ce fait en architecture et construction des btiments, il est
d Royce (1970).
Chaque tape du processus de dveloppement doit tre termine une date prcise avant
que la suivante ne puisse dbuter. En principe, chaque tape doit tre contrle et vaide
avant de passer ltape suivante.
Des remous..
On admet toutefois - le dveloppeur nest quun tre humain avec beaucoup de faiblesses
-, que la ralisation dune tape oblige les dveloppeurs revenir sur ltape prcdente
pour y apporter des corrections, ce qui peut provoquer certains remous.
Chaque tape produit un rsultat: il peut sagir dune documentation, de formulaires, et
bien entendu de bouts de programme.
Figure 7: Le cycle de vie en cascade
Ce modle a le mrite dtre trs simple. Les dveloppeurs se sont inspirs des autres
domaines de lingnierie; il fallait bien commencer par quelque chose de connu..
Les avantages
Il prsente un dveloppement trs linaire bien que des retours en arrire soient
prvus lorsque des erreurs ou des manques sont dtects.
Il permet de planifier aisment le dveloppement.
Par contre
Ce modle permet difficilement de grer les changements en cours de projets.
En effet, de tels changements impliquent des retours en arrire qui peuvent aller
parfois jusqu revoir la phase de spcification. Un erreur cotera dautant plus cher
quelle sera dcouverte tardivement.
Spci fication: document le plus formalis possible
Architecture du systme
& Conception dtaill e: modules et interactions
Code du logiciel (1re version)
1re version livrable
Livraison
et installation
Mises jour ultrieures
Mais surtout
Dans ce modle, la phase danalyse des besoins a une importance primordiale!
Lapproche est monumentale, il faut laborer des plans complets avant de commencer
construire. Ainsi, le client ne voit le systme ralis qu la fin pour se rendre compte
un peu tard que le produit ne correspondait pas ses besoins..
4.3 LE CYCLE EN V ET LE MODLE EN SPIRALE
Figure 8: Le diagramme en V
Sans entrer dans les dtails, le cycle en V puis le modle en spirale correspondent des
volutions du modle en cascade.
Le cycle en V introduit les notions de dcoupage modulaire et de validation - que lon
distingue trs nettement de la notion de vrification -.
Dfinition 9: Validation et Vrification (Boehm 76)
Validation: Am I building the right system?
Vrification: Am I building the system right?
En 1988, K. Boehm propose une amlioration du modle en cascade, dans laquelle la
gestion des risques fait partie du modle, en cherchant minimiser les risques encourus
et en les analysant rgulirement. Il sagit du modle en spirale.
Spcification
Codage Vrification
Intgration
Validation
Besoins
Spec.
Arch.
Code
Doc Doc
Activit Activit
Mod.
Soft
Pro.
Conception Conception
Dfinition 10: Gestion des risques
Par gestion des risques, on entend placer la priorit sur lanalyse et le dveloppement des
lments dont le dveloppement prsente des risques importants, comme par exemple:
le client nest pas trs au clair avec sa demande,
lquipe na pas dexprience sur ce type de dveloppement,
la technologie utiliser est inconnue et peut rserver de mauvaises surprises,
etc.
Le modle en spirale implique frquemment le client/utilisateur. Il reprsente le dve-
loppement comme une succession de cycles en cascade, o, chaque itration le systme
est analys, conu, ralis et test un peu plus qu litration prcdente.
Figure 9: Le cycle en spirale
Mais, tout comme avec le modle Waterfall et le modle en V, le client ne voit
le systme ralis qu la fin!
4.4 LE MODLE INCRMENTAL ITRATIF
Ce modle, prsent en dbut de chapitre, constitue laboutissement du modle en spirale.
Il est aujourdhui utilis par les mthodes dites agiles ou semi-agiles:
UP (Unified Process);
XP (Extreme Programming).
Figure 10: Le modle incrmental itratif
A la diffrence du modle en spirale
Chaque incrment donne lieu un produit fini, excutable, test et intgr.
On cherche garder chaque incrment taille humaine, en limitant le temps de
ralisation et en limitant le nombre de fonctionnalits implmentes.
Les avantages par rapport au modle en spirale
Le client peut valider en tout temps le systme, il peut influencer son dveloppe-
ment dans le bon sens.
Le systme correspond mieux aux besoins du client.
Exprience souhaite..
Au dpart, il faut tablit une vision de haut niveau qui permet destimer les cots
et les temps de dveloppement, cette opration demande beaucoup dexprience.
Le dveloppement en cascade est-il enterr?
Si lquippe de dveloppement bnficie dune grande exprience dans le
domaine et si le travail ne prsente par ailleurs aucun risque (comme par exemple
si le client sait trs bien ce quil veut), le modle itratif incrmental demande
plus de travail que le modle en cascade. Cest ainsi que pour des raisons deffica-
cit, il est encore possible de partir sur un modle en cascade.
Notons par ailleurs quil faut encore souvent convaincre le client que ce modle
de dveloppement est meilleur que le modle en cascade.
Planification initiale
Vision
P
l
a
n
i
f
i
c
a
t
i
o
n
S
p
c
i
f
i
c
a
t
i
o
n C
o
n
c
e
p
t
i
o
n
I
m
p
l
m
e
n
t
a
t
i
o
n
T
e
s
t
v
a
l
u
a
t
i
o
n
Dploiement
4.5 MISE EN OEUVRE: LA MTHODE UP (PROCESSUS UNIFI)
UP sappuie essentiellement sur deux principes: un dveloppement incrmental itratif et
lutilisation de technologies objet, que ce soit pour lanalyse, la conception et la program-
mation.
Voici quelques unes des caractristiques remarquables de cette mthode, qui tiennent
essentiellement au dveloppement itratif:
Prise en compte quasi immdiate des lments risques.
Implication permanente des utilisateurs (valuation, test) en utilisant la pratique
des demandes de changement.
Mise en oeuvre dune architecture centrale ds les premires itrations.
Technologie Objet et modlisation graphique (UML).
Contrle de qualit permanent: tests prcoces et frquents.
4.6 APPROCHE ORIENTE OBJET
Rappelons que cette approche est venue du besoin de construire des modles plus pro-
ches du monde rel et de la notion de rutilisation ([Voir paragraphe - Les principales approches
- page 22]).
Nous dirons ici quelques mots au sujet de lanalyse et de la conception, vues sous langle
de lapproche objet.
Analyse oriente objet
Lanalyse oriente objet met laccent sur la recherche et la description des objets ou de con-
cepts qui appartiennent au domaine du problme.
Comme par exemple Li vr e et Cl i ent dans un systme de gestion dune bibliothque.
Figure 11: Modlisation relation Livre-Client
Conception oriente objet
La conception oriente objet met laccent sur la recherche et la dfinition des objets logiciels
(tels quils seront implments) et sur la manire dont ces derniers vont collaborer.
Par exemple, lobjet logiciel Empr unt aura lattribut dat eEmpr unt et la mthode
pr ol onger .
Livre
Ti t r e
NbExempl ai r es
Client
Nom
Adr es s e
emprunt par
0..* 0..*
dat e
Figure 12: Modlisation conceptuelle Livre-Emprunt-Client
Un exemple: le jeu de ds
Le jeu est le suivant: les ds sont rouls. Si le total fait 7 on a gagn, sinon on a perdu !
Pour illustrer le processus de cration dun logiciel, nous allons dcomposer le dvelop-
pement en 4 tapes, les deux premires appartenant une activit danalyse, et les deux
dernires une activit de conception:
Dfinition des cas dutilisation
La dfinition des cas dutilisation intervient pendant lanalyse des besoins.
Livre
t i t r e: St r i ng
nbExempl ai r es: i nt
Client
nom: St r i ng
adr esse: Addr ess
Emprunt
dat e: Dat e
0..*
0..*
1
1
cl ass Cl i ent {
pr i vat e St r i ng nom;
pr i vat e St r i ng adr esse;
publ i c St r i ng get Nom( ) {r et ur n " " ; }
}
get Nom( ) : St r i ng
pr ol onger ( )
Dfinition des
diagrammes de
classes
Dfinition des
diagrammes
d'interaction
Modlisation du
domaine
Dnitiondes cas
d'utilisation
Cette activit ne sappuie pas sur des constructions orientes objet. Elle dcrit plutt le
systme en termes de fonctionnalits, et plus exactement en termes de processus de trai-
tements. Un cas dutilisation est une espce de scnario, crit sous forme textuelle, qui
prsente la squence des diffrentes actions qui seront menes pour accomplir une cer-
taine fonctionnalit.
Notre exemple est rduit un cas dutilisation: Lancement des ds:
1. Le joueur lance les ds.
2. Si le total est gal sept, il a gagn. Dans les autres cas, il a perdu.
Modlisation du domaine
Dans la perspective dune classification par objets, la description du domaine implique
lidentification des concepts, des attributs et des associations notables qui appartiennent
au monde rel modliser.
Cette identification pourra sexprimer sous la forme dun modle du domaine, compos de
diagrammes sappuyant sur le concept des diagrammes de classes et dinteraction.
Le modle du domaine nest pas une description dobjets logiciels, mais une
reprsentation des concepts appartenant au domaine du monde rel.
Figure 13: Modlisation du domaine (diagramme partiel)
Dfinition des diagrammes dinteraction
Un programme objet est compos dobjets logiciels qui accomplissent leur tche en col-
laborant par le biais denvois de messages.
Les diagrammes dinteraction, utiliss dans lanalyse comme dans la conception illus-
trent les collaborations entre objets.
Player
name
DiceGame
Die
faceValue
Rolls
Plays
Includes
2
2
1
1
1
1
Dans le cadre de la conception, les flux de messages qui circulent entre les objets logi-
ciels correspondent explicitement des invocations de mthodes.
Le diagramme dinteraction prsent dans la figure suivante illustre la mise en oeuvre
conceptuelle du cas dutilisation Lancement des ds.
Figure 14: Diagramme des interactions
Remarquons que ce type de diagramme reprsente une vue dynamique des collabora-
tions entre objets.
Dfinition des diagrammes de classe de conception
Contrairement au modle du domaine, le diagramme des classes reprsente des classes lo-
gicielles, et non plus des concepts du mode rel informatiser. Ainsi, on remarquera que
le joueur a disparu dans le diagramme de classes.
Contrairement aussi au diagramme dinteraction, on reprsente ici non plus une vue
dynamique du systme mais une vue statique.
Figure 15: Le diagramme de classes (partiel)
4.6.1 Quelques mots sur UML
UML comme Unified Modeling Language (Langage de modlisation unifi)
UML a t normalis en 1997 par lOMG - Object Management Group.
:DiceGame
play()
die1 : Die
fv1 :=getFaceValue()
die2 : Die
roll()
roll()
fv2 :=getFaceValue()
2
Die
faceValue : int
getFaceValue() : int
roll()
DiceGame
die1 : Die
die2 : Die
play()
1
Dfinition 11: UML - Dfinition de lOMG
UML est un langage essentiellement graphique, concu pour spcifier, prsenter,
construire et documenter les diffrents lments (artifacts) que comportent les
systmes logiciels.
Il ne sagit pas dun langage formel rigoureux. Notamment UML na pas t
prvu au dpart pour aboutir une gnration de code automatique. De ce ct,
certains efforts sont accomplis aujourdhui autour du projet MDA (Model Driven
Architecture), qui sappuie sur UML.
Il ne sagit pas non plus dune mthode: UML ne dcrit aucun processu de
dveloppement. UML est un simple outil graphique de modlisation. La mthode
qui sy rattache verra le jour sous le nom UP (Unified Method).
La puissance dUML permet de lutiliser pour tout ce qui a trait la modlisation
mtier et de manire plus gnrale pour la modlisation de systmes non logiciels.
Petite histoire en bref..
Diffrentes mthodes de modlisation base sur les objets ont t dveloppes durant les
annes 80. Il y en avait plus de 50 au dbut des annes 90. Chacune avait des avantages
et des inconvnients, aucune ne faisait lunanimit. Parmi les trois plus populaires, on
pouvait trouver :
1. la mthode de Grady Booch, appele parfois OOD
2. OMT de J ames Rumbaugh,
3. OOSE et Objectory de Ivar J acobson.
Le groupe des 3 amigos, tel quon le dsigne aujourdhui tait compos de 3 notorits
du monde du dveloppement orient Objet. Chacune des mthodes tait reconnue au
niveau international et prouve dans la pratique.
Plutt que dassister une guerre de tranches, les choses se sont droules trs diff-
remment. Booch qui travaillait alors pour le compte de lentreprise Rational Software
demanda Rumbaugh de le rejoindre, ce que fit ce dernier en 1994. En1995, Rational
rachte Objectory, lentreprise de Ivar J acobson.
Cette offensive savamment orchestre prend de cours lindustrie qui se voit oblige bon
gr mal gr et par la force des chose de participer cet effort. Un premier jet est mis
disposition sur lInternet, puis soumis lapprobation de lOMG (Object Management
Group).
Plus tard, lobjectif a t rajust pour dvelopper un langage de modlisation plutt
quune mthode, ce qui nous a apport UML.
Figure 16: Evolution dUML
4.7 CYCLE DE VIE DE LA MTHODE UP
Au sein de la mthode UP, le projet est dcoup en 4 phases majeures, qui elles-mmes se
dcoupent en itrations courtes et de dure fixe.
Figure 17: Les 4 phases de UP
Dure fixe des itrations
Dure fixe ne veut pas dire que toutes les itrations ont la mme dure, - comme pour-
rait dailleurs le faire croire la figure -, mais plutt que les itrations ont une dure fixe
lors dune planification, et que la dure dune itration ne peut en aucun cas tre modi-
fie en cours ditration.
itration
laboration construction transition Initialisation
Et ceci mme si lon a pris du retard et que les objectifs mmes de litration ne pourront
tre respects. Dans ce dernier cas la planification globale est revue au dbut de litra-
tion suivante.
Initialisation (Inception)
Comprhension de la finalit du projet, tude de faisabilit, estimations globales et inves-
tigations ncessaires pour dcider de la poursuite ou non du projet.
Cette phase nest pas consacre lanalyse des besoins. Certes, on y opre de
lanalyse, mais de manire minimaliste! Le but tant de dcider ou non de poursuivre le
projet.
Elaboration
Dveloppement dune vision plus labore des finalits du projet (objectifs et
fonctionnalits).
Identification de la plupart des besoins et des frontires relles du problme
(notamment: rdaction des Cas dutilisation et Modlisation de domaine).
Elaboration destimations plus ralistes (cot, planification globale).
Implmentation de larchitecture centrale du systme.
Rsolution des lments prsentant des risques levs.
Planification des itrations de la phase de construction
Cette phase se focalise essentiellement sur lanalyse des besoins. Notons toute-
fois que cette dernire ne sera pas forcment termine. Elle pourra tre affine, dtaille
loccasion des itrations de la phase de construction.
Notons encore que cette phase contient dj une certaine part de ralisation: implmenta-
tion de larchitecture centrale notamment, et ventuellement ralisation dlments ris-
ques.
Construction
Dveloppement itratif des diffrents lments du systme, en commenant par les l-
ments prsentant les plus grands risques.
Chaque itration gnre un sous-ensemble excutable et stable du produit final.
Cette phase comprend aussi bien de lanalyse (spcifications dtailles), que de la con-
ception que du codage et du test.
Transition
Bta tests et dploiement. Livraison finale en fin de phase de Transition.
4.7.1 Terminologie UP: disciplines, activits & artefacts
La mthode UP dcrit les diffrentes activits menes dans le cadre dun dveloppement.
Voici quelques exemples dactivits:
dessiner un diagramme de classes;
dfinir un cas dutilisation;
etc.
Une activit est opre au sein dune itration, sa dure ne dpassera pas les frontires de
litration dans laquelle elle prend sa place.
Dfinition 12: Discipline UP
Chacune des activits sinscrit dans un cadre plus large, - qui donne sa raison dtre
ladite activit -, que lon appelle discipline.
Au contraire des activits, les disciplines stalent sur plusieurs itrations, voire plusieurs
phases.
Voici quelques exemples de disciplines:
spcification (analyse des besoins);
conception;
implmentation;
tests;
installation;
etc.
Une discipline est donc un ensemble dactivits et de produits qui lui sont lis (diagram-
mes, code, graphiques, glossaire, plan de tests, etc.).
Ces produits sont souvent appels artefacts, un terme gnrique dsignant nimporte quel
produit du travail.
4.7.2 Disciplines et phases UP
En gnral, toute itration comprend un certain nombre dactivits qui se rpartissent dans
la plupart des disciplines.
Dans les premiers temps, laccent est port sur les disciplines danalyse et de conception.
Puis, au fur et mesure de lavance du projet, on note un glissement vers limplmenta-
tion, le test, etc.
Les figurent qui suivent donnent une ide de la charge de travail consacre chaque dis-
cipline selon les phases de dveloppement du projet.
Attention! Ces figures sont prsentes titre dillustration. Il sagit simplement
dexemples. Mme si, en gnral, on retrouve les mmes disciplines dun projet
lautre, la charge de travail qui leur est consacre sera chaque fois diffrente.
Figure 18: Charge de travail relative
Disciplines
Modlisation
mtier
Spcification
Conception
Implmentation
etc.
initialis
ation
laboration construction
transi-
tion
...
Figure 19: Une itration recouvre la plupart des disciplines
La discipline Environnement sattache faire des choix au niveau des outils et instal-
ler ces derniers.
Dans le cadre du cours de Gnie logiciel, on sintressera principalement aux dis-
ciplines de Modlisation mtier, de Spcification et de Conception. Les disciplines lies au
test, la gestion de configuration et la gestion de projet seront toutefois abordes.
Itrations
Disciplines
Modlisation mtier
Spcification (besoins)
Conception
Implmentation
Test
Dploiement
Gestion des changements et
des configurations
Gestion du projet
Environnement
Itration de 4 semaines (exemple)
Gnie logiciel - 43 - Phase dinitialisation
5 Phase dinitialisation
Si daventure votre quipe de dveloppement se voit soumettre un nouveau pro-
jet, point trop de hte..
Une tude prliminaire que lon dsigne par phase dinitialisation (inception phase) - et
qui peut aboutir dans bien des cas un refus du projet -, doit tre mene par vos soins. En
cas dacceptation, vous pourrez alors vous plonger dans la deuxime phase - selon le pro-
cessus UP - dite dlaboration.
Revenons maintenant cette phase dinitialisation en prsentant quelques unes des ques-
tions auxquelles vous devrez rpondre:
Quels sont les objectifs de ce projet? (pour quoi faire, dlimitation des frontires)
Quels en sont les enjeux commerciaux pour lentreprise? (Y-a-t-il des perspecti-
ves ultrieures de dveloppement?)
Le projet est-il faisable?
Doit-on vraiment le dvelopper le projet ou au contraire acheter, voire adapter, un
produit du march?
Que cotera grossirement son dveloppement?
Les futurs utilisateurs du systme ont-ils une ide claire de ce quils dsirent et
saccordent-ils entre eux?
Et, pour conclure, la principale question:
Doit-on ou non accepter ce projet?
En gros, il sagit de dcider si cela vaut ou non la peine dinvestir dans une tude plus
approfondie. Bien quil ne sagisse en aucun cas dune analyse exhaustive, il peut sav-
rer ncessaire de se lancer dans une investigation grossire des besoins du systme que
vous seriez amener dvelopper.
Dans la plupart des cas, la dure de cette phase est relativement courte: une, voire quel-
ques semaines suffisent. Elle peut tre trs brve si votre quipe de dveloppement a dj
ralis un projet du mme type en sappuyant sur sa propre exprience.
Pour rsumer les objectifs de la phase dinitialisation:
Dfinition 13: Phase dinitialisation
Une activit qui consiste dfinir:
les objectifs du projet
implications pour lentreprise, enjeux commerciaux
lampleur du projet (dure, cot) et sa faisabilit
Et enfin.. de dcider de la suite apporter au projet
5.1 LES PRODUITS GNRS PAR LA PHASE DINITIALISATION
Les diffrentes activits menes dans le cadre de cette phase dinitialisation vont gnrer
un certain nombre de documents et de produits dont la liste, non exhaustive, est prsente
ci-dessous.
Rappelons que ces diffrents produits portent galement le nom gnrique darte-
fact.
Notons demble que bon nombre des artefacts gnrs par la phase dinitialisa-
tion ne constituent que des bauches. Ils seront complts ultrieurement dans le cadre
des itrations futures. Cest le cas notamment de la modlisation des cas dutilisation qui
devrait se contenter de prsenter les noms des acteurs et des principaux cas dutilisation:
seuls 10% 20% des cas dutilisation devraient tre dcrits en dtail, au grand maximum.
Objectifs du projet
Description des buts du projet avec la liste des fonctionnalits.
Implications pour lentreprise, enjeux commerciaux
Bnfices et contraintes pour lentreprise ( court, moyen et long terme); avenir
du projet (perspectives dvolution, dure de vie).
Identification des contraintes organisationnelles (dlais, budget, personnel et
matriel).
Dbuts de spcification
Se reporter au chapitre se rattachant la phase dlaboration.
La mise en oeuvre des spcifications (analysse des besoins) sopre essentielle-
ment pendant la phase dite phase dlaboration, qui fait suite la phase dini-
tialisation.
Les dveloppeurs sont amens bien souvent commencer cette analyse ds la
phase dinitialisation, afin de pouvoir se faire une image un peu plus raliste de
lampleur du projet dvelopper.
Glossaire
Terminologie utilise dans le domaine dapplication du projet.
Le glossaire comprend galement ce que lon appelle parfois le dictionnaire des
donnes, qui rassemble les spcifications relatives aux diffrentes informations
comme les rgles de validation, les valeurs acceptables, etc.
A titre dillustration, voici un exemple dentres au sein dun dictionnaire de don-
nes: la dfinition dun numro de tlphone
:
Nom: Numr o_Tl phone
Synonyme:
Composi t i on: I ndi cat i f +No_Appel
Not es:
:
:
Nom: I ndi cat i f
Synonyme:
Composi t i on: 2{Chi f f r e}3
Not es:
:
:
Nom: No_Appel
Synonyme:
Composi t i on: 3{Chi f f r e}8
Not es:
:
:
Nom: Chi f f r e
Synonyme:
Composi t i on: [ 0| 1| 2| 3| 4| 5| 6| 7| 8| 9]
Not es:
:
Risques encourus et plan de gestion des risques
Description des risques encourus par le dveloppement, tant au niveau commer-
cial, technique, ressources (matriel et humain) que de la planification (respect
des dlais). Enumration des diffrentes solutions imagines pour y rpondre ou
pour minimiser le problme.
Elaboration de prototypes
Ici, il faudra coder!
Le but tant de vrifier le cas chant la faisabilit du projet ou den clarifier les
objectifs.
Planification de la phase dlaboration
En cas dacceptation du projet, la phase dinitialisation sera suivie par la phase
dite dlaboration. Il sagit donc de dcrire les activits mener pendant la future
phase dlaboration.
5.2 A VITER PENDANT LA PHASE DINITIALISATION
dy consacrer trop de temps (quelques semaines au maximum);
dimaginer que les diffrentes planifications et estimations labores pendant
cette phase sont dignes de confiance;
de commencer y concevoir larchitecture du systme;
domettre la dfinition des acteurs et des cas dutilisation;
de dcrire ces derniers en dtail (10% maximum, histoire de se faire un aperu de
lampleur du projet).
Gnie logiciel - 47 - Phase dlaboration et analyse des besoins
6 Phase dlaboration et
analyse des besoins
La phase dite dlaboration constitue la deuxime phase de la mthode UP.
Elle fait suite la phase dite dinitalisation.
Commenons par un petit rappel sur les principales activits menes par les dve-
loppeurs dans le courant de cette phase.
Dveloppement dune vision plus labore des finalits du projet (objectifs et
fonctionnalits).
Identification de la plupart des besoins et des frontires relles du problme
(notamment: rdaction des Cas dutilisation et Modlisation de domaine).
Elaboration destimations plus ralistes (cot, planification globale).
Implmentation de larchitecture centrale du systme (codage)
Rsolution des lments prsentant des risques levs.
Planification des itrations de la phase de construction
Cette phase se focalise essentiellement sur lanalyse des besoins. Cette der-
nire pourra tre affine, dtaille loccasion des itrations de la phase de construction.
Notons encore que cette phase contient dj une certaine part de ralisation: implmenta-
tion de larchitecture centrale notamment, et ventuellement ralisation dlments ris-
ques.
Analyse des besoins (spcification)
Lanalyse des besoins, une activit commence pendant la phase dinitialisation et com-
plte plus tard pendant la phase dite dlaboration - selon la mthode UP -, est sans doute
lactivit la plus sensible et la plus dterminante quant la russite du projet.
Dfinition 14: Analyse des besoins
Une activit qui consiste :
spcifier et rassembler les besoins auxquels devra rpondre le projet,
enregistrer ces besoins (documents, modles, etc.),
dans une forme accessible et comprhensible dune part par les futurs utilisateurs
du systme et dautre part par les membres composant lquipe de dveloppe-
ment.
Dfinition 15: Spcification et cahier des charges
Le terme spcification, ou encore spcification des besoins, analyse des besoins,
est souvent utilis pour dnoter la mme activit, celle danalyse des besoins, dont le
produit est un document que lon nomme frquemment spcifications ou encore
cahier des charges.
Ltude mene par Standish en 1994 permet de sentir toute limportance de cette activit.
Figure 20: Les facteurs contribuant lchec dun projet
La qualit de la spcification aura une grande influence sur le choix de larchitecture du
systme, sur le choix du matriel et des outils informatiques.
Notons quune des rponses possibles pour rpondre cette problmatique est
celle qui consiste mener cette activit de manire trs approfondie et de la stabiliser
avant de passer aux activits suivantes (conception et implmentation). Ctait la vision
du modle en cascade (Waterfall) dont on connat toutes les dboires. La solution prco-
nise actuellement consiste plutt accepter les changements et les prendre en compte
dans un modle itratif.
Besoins fonctionnels et non-fonctionnels
Lanalyse des besoins est en fait un terme assez vague qui requiert quelques prcisions.
Dfinition 16: Classification des besoins
En gnral, on distingue les besoins fonctionnels des autres besoins dits non-fonc-
tionnels qui rassemblent diffrentes spcifications.
Besoins fonctionnels
Ces derniers recueillent les diffrentes fonctions - traitements, oprations, services - of-
fertes par le systme dvelopper pour satisfaire les besoins du client.
Y sont dcrits galement le format des informations, les valeurs autorises pour les
entres et le comportement du systme en cas de:
valeurs illgales,
pannes,
ou de problmes divers.
Besoins non-fonctionnels
Les besoins non-fonctionnels dcrivent les conditions et contraintes devant tre respec-
7%
12% 12%
13%
6%
50%
Inadquation des
informations reues des
utilisateurs
Spcifications
incompltes
Modification dans les
spcifications
Incapacits techniques
Incapacits de gestion
Autres
tes par le systme pour accomplir les besoins fonctionnels.
Principalement:
Contraintes dutilisation (IHM)
Facteurs humains, documentation et aide.
Fiabilit
Frquence de pannes tolre, restauration du systme.
Performance
Temps de rponse, capacits de traitement, utilisation des ressources.
Portabilit
Contraintes de portabilit, dadaptation, de configuration, internationalisation
(langues)
Scurit
De manire auxiliaire:
Contraintes dimplmentation
Limitations quant aux ressources, contraintes sur le systme dexploitation, sur
les langages, sur les outils, sur le matriel, etc.
Contraintes dinterfaage
Interfaage avec dautres systmes existants ou venir.
Contraintes oprationnelles
Gestion du systme et paramtrage.
Mode de livraison du produit (packaging)
Contraintes juridiques et/ou thiques
Licences, privatisation des informations, dangers pour la sant, etc.
Dans le cadre des diffrents documents produits par la phase dinitialisation (c.f. le para-
graphe prcdent [Voir paragraphe - Les produits gnrs par la phase dinitialisation - page 52]),
notons que les besoins sont dcrits:
dans les Objectifs du projet (liste des fonctionnalits)
dans la Modlisation des cas dutilisation
Besoins fonctionnels et non-fonctionnels
dans les Spcifications complmentaires
Besoins non-fonctionnels
dans le Glossaire
Besoins fonctionnels (dictionnaire des donnes)
Exemple 1: Un correcteur dorthographe
Voici quelques spcifications extraites dune analyse de besoins pour un correcteur dor-
thographe.
Parmi ces diffrentes propositions, lesquelles appartiennent la catgorie
besoins fonctionnels, lesquelles la catgorie besoins non-fonctionnels, et dans ce
dernier cas, quelle sous-catgorie? Quelles remarques critiques peut-on formuler?
1. Lorsqu'un mot non identifi est rencontr dans le texte, l'utilisateur doit avoir le
choix entre remplacer le mot par un mot de substitution, insrer le mot dans le dic-
tionnaire, rechercher des mots similaires dans le dictionnaire afin d'en dterminer
l'orthographe correcte, ou sortir du programme.
2. Toute la ligne contenant l'ventuel mot mal crit doit tre affiche au terminal.
3. L'utilisateur doit avoir la possibilit d'afficher les mots du dictionnaire qui dbu-
tent par une chane de caractres.
4. Le programme ne doit pas s'arrter lorsque le dictionnaire est plein.
5. Chaque fois que c'est possible, les donnes entres par l'utilisateur doivent tre v-
rifies, et en cas d'erreur, le programme affichera un message appropri.
6. Le dictionnaire doit tre capable de contenir au moins 40 '000 mots. Des techni-
ques de compression sont acceptables.
7. Le logiciel doit tre capable de traiter 250 mots la minute.
8. Un mot est une chane d'un ou plusieurs caractres dlimites par des caractres ne
faisant pas partie d'un mot. Les caractres qui font partie d'un mot sont les lettres
majuscules et minuscules (sans distinction entre elles) et les apostrophes.
9. Les mthodes internes de tri et de recherches ne sont pas critiques dans la dfini-
tion du systme. Les mthodes doivent tre efficaces du point de vue du temps de
calcul et utiliser un minimum de mmoire.
10.Le dictionnaire ne doit pas dpasser la taille de 400 ' 000 octets.
11.Les mots jusqu' au moins 13 caractres doivent tre analyss pour vrifier s'ils
sont crits correctement. Les mots plus longs doivent pouvoir tre affichs au ter-
minal, afin de permettre l'utilisateur d'en vrifier l'criture.
12.Les commandes du programme doivent tre prsentes sous forme de menu clair
et concis.
Les difficults rencontres lors de la spcification
comprhension du domaine dapplication;
trouver et identifier les bonnes personnes interviewer (utilisateurs); notons ici
que le client nest pas forcment lutilisateur final du systme.
leur poser des questions pertinentes;
relever les contradictions dans les besoins noncs par les utilisateurs, des diff-
rences de terminologie, etc.
identifier les frontires du systme dvelopper;
produire une documentaion prcise, concise et claire pour tout le monde (utilisa-
teurs comme dveloppeurs).
communiquer avec le client: son langage nest pas le mme que le langage de
linformaticien;
faire valider la spcification par le client, tout en acceptant de futures modifica-
tions du cahier des charges.
Quelques techniques utilises lors de la spcification
interviews, questionnaires, observation;
analyse de documents existants;
jeux de rle;
prototypage.
Spcification formelle et informelle
Dans certains domaines, par exemple en lectronique, le niveau de formalisme de spci-
fication pour dcrire des microprocesseurs a pu tre pouss trs loin, on parle alors de sp-
cification formelle (Z, Estelle, etc.).
Les avantages de telles mthodes sont les techniques de preuve et la gnration
automatique de codes.
Les dsavantages sont principalement le formalisme, proche des mathmatiques
ou de la logique, qui force le client bien matriser ce formalisme, et dautre part la diffi-
cult matriser le niveau de dtail et les changements.
Exemple 2: la ligne Mteor du mtro parisien
Objectif
Vrifier la vitesse du mtro en fonction de valeurs fournies par des capteurs. Il y a
essentiellement trois phases excutes rgulirement sans interruption:
acquisition des valeurs laide des capteurs;
calcul de dcision;
envoi de commandes
Enjeu
Le programme doit fonctionner sans erreurs cause des risques sur la vie que cela
entrane.
Mthode
Spcification formelle laide du langage B:
Dcrire ce que doit faire le systme en terme de contrle de vitesse, laide dun
langage de description dtats du systme.
Dmarche
Gnration du code (quelque milliers de lignes) permettant de prouver que le sys-
tme se comporte tel que spcifi.
Remarque
Le problme pos se dcrit particulirement bien laide dtats et de transitions,
ce nest hlas pas le cas de beaucoup de problmes.
Langage B
Exemple de recherche dans un tableau
Spcification semi-formelle et UML
Pour dautres domaines, il vaut mieux utiliser des mthodes de spcification semi-formel-
le, bases sur la langue naturelle et des diagrammes.
La spcification oriente objets, base sur UML en est une. Le langage est suffisamment
prcis pour tre comprhensible par le client.
Gnie logiciel - 55 - Modle des cas dutilisation
7 Modle des cas dutilisation
Le modle des cas dutilisation est reconnu aujourdhui comme un excellent
moyen pour comprendre et dcrire les besoins.
Objectif
Raconter la manire dont on va utiliser le systme, - du point de vue du client (de luti-
lisateur) -, pour atteindre les diffrents objectifs.
Finalit: identifier et enregistrer les besoins fonctionnels du systme.
Historique
Le modle a t introduit en 1986 par Ivar J acobson (un des trois amigos).
Trs vite reconnu comme un des moyens les plus simples et efficaces pour dcrire les
besoins fonctionnels.
Voir aussi louvrage dAllistair Cockburn Rdiger des cas dutilisation efficaces, une
contribution trs importante au modle de cas dutilisation.
7.1 SA PLACE DANS LA MTHODE UP
Du point de vue de la mthode UP, ce modle fait partie de la discipline dite de Spcifi-
cation (requirements). Ce modle sadresse la description des fonctionnalits du
systme et de son environnement.
Cest donc pendant la phase dlaboration que le dveloppeur sera amen rdiger des
cas dutilisation, en commenant par la dfinition dun diagramme de contexte (pour
dfinir comme on le verra les frontires du systme). Le raffinement de certains cas
dutilisation sera parfois relgu la phase de construction, loccasion de telle ou telle
itration.
Un dveloppement guid par les cas dutilisation
Dfinition 17: Un dveloppement guid par les cas dutilisation
Les cas dutilisation constituent un lment essentiel de la mthode UP pour
laquelle on peut dire que le dveloppement est pilot par les cas dutilisation.
Voici quelques points cls retenir:
Les besoins
La rdaction des cas dutilisation permet de capturer la majeure partie des spcifi-
cations (des besoins). Pour le reste, se rfrer aux spcifications complmentaires
[Voir paragraphe - Complments de spcifications - page 85].
La planification et le partage du travail
Les cas dutilisation constituent une base de rfrence pour tablir la planifica-
tion des futures itrations de la phase de construction.
En effet, le travail de dveloppement accomplir dans une itration consiste le
plus gnralement implmenter un cas dutilisation au complet ou un scnario
particulier dun cas dutilisation. Au sein dune mme itration, diffrents cas
dutilisation peuvent tre implments simultanment par des quipes diffrentes.
Manuels dutilisation
Ces derniers sorganisent essentiellement autour des cas dutilisation.
Quand doit-on rdiger des cas dutilisation?
Dans le cadre de la mthode UP, la rdaction des cas dutilisation est une activit faisant
partie de la discipline dite de Spcification.
En rgle gnrale, la rdaction des cas dutilisation commence pendant la phase dini-
tialisation, une phase pendant laquelle on se contente dordinaire dtablir la liste des
acteurs et la liste des cas dutilisation en les dcrivant de manire trs succincte.
La rdaction proprement parler se droule pendant la phase dlaboration. Cela ser-
vira de base pour la planification des itrations de la phase de construction.
Elle se poursuit parfois pendant la phase de construction (rdaction de dtails).
7.2 QUELQUES DFINITIONS PRALABLES
Acteur
Un acteur est une entit - extrieure au systme - qui manifeste un certain comportement
vis vis du systme. Il peut sagir:
Dune personne
Par la suite, on parlera alors plutt de rle car une mme personne physique peut
jouer plusieurs rles. Chacun de ces rles donnera lieu un acteur diffrent.
Par exemple, la mme personne physique peut jouer la fois le rle dadministra-
teur systme et dutilisateur.
Dun systme (extrieur au systme analyser)
Scnario
Un scnario est une suite dactions et dinteractions entre les acteurs et le systme ana-
lyser.
Un scnario raconte une histoire possible se droulant entre un acteur et le systme.
La mise en oeuvre dune fonctionnalit spcifique prsente toujours plusieurs scnarios
possibles. Par exemple, loccasion du traitement dune vente, il est possible que la tran-
saction russisse (un scnario possible), ou alors quelle choue si la carte de crdit du
client est chue (un autre scnario possible).
Un cas dutilisation
Dfinition 18: Cas dutilisation
Un cas dutilisation est un ensemble de scnarios dcrivant la faon - par un acteur - duti-
liser le systme pour atteindre un certain objectif.
Il peut sagir de scnarios dchecs ou de succs: en gnral il sagira dun scnario de
succs (le scnario principal) et de quelques scnarios dchec.
A titre dillustration: Traiter une vente (systme POS)
Un diagramme de cas dutilisation
Le langage UML a prvu une reprsentation graphique des cas dutilisation sous la forme
de diagrammes dits Diagrammes de cas dutilisation.
Figure 21: Un diagramme de cas dutilisation
Comme on le verra par la suite, les cas dutilisation sont dcrits sous forme textuelle. Ces
diagrammes peuvent tre prsents titre de complment visuel. Dans la pratique, ils
sont surtout indiqus pour donner une reprsentation succincte du contexte du problme
en montrant les acteurs et la faon dont ils utilisent le systme.
La majorit des auteurs actuels, - dont font partie Allistair Cockburn, Martin
Fowler, etc. -, recommandent de se concentrer sur la rdaction des cas dutilisation et
minimisent limportance des diagrammes de cas dutilisation.
Traiter une vente
Scnario principal (succs):
1. Un client arrive la caisse avec diffrents articles
2. Le caissier enregistre chaque article achet
3. Le client prsente sa carte de crdit et sauthentifie
4. ...
etc.
Autres scnarios (chec):
Si lautorisation est rejete:
1. le caissier en est inform
2. le caissier demande une autre forme de paiement
Caissier
Acteur Cas dutilisation
interaction
Traitement dune
vente
Ces derniers taient il y a encore peu de temps trs priss pour reprsenter les interac-
tions entre cas dutilisation (en montrant pas exemple les relations dextension et de
gnralisation que nous dcrirons plus tard).
On se contente souvent aujourdhui de les utiliser pour reprsenter des diagrammes de
contexte. [Voir paragraphe - Un diagramme de contexte - page 70]
7.3 DESCRIPTION DUN CAS DUTILISATION
En gnral, les cas dutilisation sont modliss sous la forme de textes informels.
Cette modlisation peut tre accompagne de diagrammes de cas dutilisation (diagram-
mes UML qui seront prsents plus loin).
7.3.1 La philosophie de la bote noire
Un cas dutilisation se rdige en adoptant le point de vue bote noire. Cest de loin le
mode de description le plus utilis et le plus recommand.
Dans ce contexte, le systme spcifier est vu comme une bote noire (lintrieur nous
est cach) et ne sera dcrit quen termes de responsabilits. Cest--dire que lon satta-
che dcrire ce que fera le systme (le QUOI), sans dcrire comment il le fera (le
COMMENT).
Du bon..
Le systme enregistre la vente
Du mauvais..
Le systme enregistre la vente dans une base de donnes
Ou pire encore: Le systme envoie une commande SQL insert pour enregistrer la
vente.
7.3.2 Rdaction dun cas dutilisation: quel niveau de dtail?
Pour la description dun cas dutilisation, il est possible dadopter lun ou lautre des trois
styles prsents ci-dessous, dpendant du stade davancement dans lanalyse.
Rsum
Un rsum qui se contente de prsenter le scnario principal, comme par exemple:
Standard
Ce mode comprend la description des diffrents scnarios qui composent le cas dutilisa-
tion.
Dtaill
Ce mode comprend la description de tous les scnarios (tapes et variantes), ainsi que la
description des prconditions (garanties de succs).
Ce mode est dcrit dans le paragraphe qui suit.
7.3.3 Description dtaille dun cas dutilisation
La description dun cas dutilisation est compose de diffrentes sections que nous allons
dcrire ici de manire un peu plus prcise.
Traiter une vente
Un client arrive la caisse avec les articles quil dsire acheter. Le cais-
sier enregistre chacun des articles en utilisant le systme POS. Ce dernier
affiche alors le dtail des achats effectus ainsi que le total. Le client
effectue son paiement au moyen dune carte de crdit. Le paiement est
valid par le systme puis enregistr. Le systme opre une mise jour de
linventaire et imprime un reu pour le client.
Traiter une vente
Scnario principal (succs):
1. Un client arrive la caisse avec diffrents articles
2. Le caissier enregistre chaque article achet
3. Le client prsente sa carte de crdit et sauthentifie
4. ...
etc.
Autres scnarios (chec):
Si lautorisation est rejete:
1. le caissier en est inform
2. le caissier demande une autre forme de paiement
Un exemple de prsentation dtaille et donne en annexe du mme chapitre [Voir para-
graphe - Annexe: Prsentation dtaille du cas dutilisation Vente - page 86].
La prface
Une espce de prambule, dintroduction, qui devrait tre lue en pralable avant le scna-
rio principal.
La liste des parties prenantes et des intrts
Comme par exemple, pour une Vente dans le cadre de notre tude de cas:
Le caissier
Dsire un moyen efficace de saisie qui lui garantisse aucune erreur de paiement (les
diffrences de caisse sont retenues sur son salaire).
Le vendeur
Dsire une mise jour de ses commissions sur les ventes
Il sagit de rappeler dans cette section quelles sont les responsabilits du systme qui
excute un contrat entre les parties prenantes.
Prconditions et postconditions
Comme par exemple, pour une Vente dans le cadre de notre tude de cas:
Prconditions
Le caissier sest identifi et il a t authentifi
Postconditions
La vente est enregistre. La taxe est calcule correctement. Mise jour de linven-
taire. etc.
Les notions de prconditions et de postconditions sont trs influences par le discours de
Bertrand Meyer sur la programmation par contrat.
1. Prconditions
Ce qui doit toujours tre vrai avant le dbut dun scnario pour que ce dernier
puisse saccomplir correctement.
Ces prconditions ne sont pas vrifies par le cas dutilisation: elles sont
tenues pour acquises.
2. Postconditions (garanties de succs)
Ce qui doit toujours tre vrai lorsque le scnario se termine avec succs.
Ces postconditions sont garanties par le cas dutilisation et devraient tre
tenues pour acquises par les autres cas dutilisation.
Voir aussi la programmation des assertions en J ava.
Le scnario principal (succs)
Le scnario principal dcrit le chemin normal qui devrait satisfaire les intrts des parties
prenantes.
Un conseil..
Pour des raisons de clart, de lisibilit, le scnario principal devrait suivre un che-
min direct et ne comporter aucune condition, aucun branchement. Il est conseill
de reporter tout le comportement conditionnel dans la section Extensions (scna-
rios alternatifs).
Comme par exemple:
Scnario principal
1. Le Client arrive la caisse avec des marchandises et/ou des services acheter.
2. Le Caissier dmarre une nouvelle vente.
3. Le Caissier entre le code de l'article.
4. Le Systme enregistre l'article et prsente sa description, son prix et le total en
cours. Le prix est calcul partir d'un ensemble de rgles.
5. etc.
En rgle gnrale, les diffrentes actions relvent de lun ou lautre des 3 catgo-
ries:
Une interaction acteur-systme
Une validation (en principe par le systme)
Un changement dtat du systme
Extensions: les scnarios alternatifs
Comme par exemple:
3a. Code invalide :
1. Le Systme signale l'erreur et rejette la saisie.
3b. Il y a plusieurs articles de la mme catgorie et leur identification individuelle
n'a pas d'importance (exemple : cinq cartons de lait de soja) :
1. Le Caissier peut saisir le code de l'article et sa quantit.
Principe de rdactions
Les scnarios alternatifs sont des branchements qui partent du scnario principal.
Ils sont donc numrots en fonction du scnario principal.
Par exemple, une premire extension de ltape 3. sera numrote 3a., la
deuxime 3b. et ainsi de suite.
Les scnarios alternatifs sont composes de deux parties:
La condition (quelque chose qui peut tre dtect par le systme ou par un
acteur)
Le traitement correspondant, tapes par tapes.
A la fin du traitement, le scnario alternatif rejoint le scnario principal (implicite,
par dfaut), moins quune autre alternative ne soit mentionne explicitement.
Un scnario alternatif peut lui-mme avoir des extensions, comme par exemple:
7e. Le Client prsente des coupons :
1. Avant de traiter le paiement, le Caissier enregistre chaque coupon et le
Systme rduit le prix en consquence. Le Systme enregistre les coupons
utiliss pour des raisons de comptabilit.
1a. Un coupon ne correspond aucun article achet :
1. Le Systme signale l'erreur au Caissier.
Comme on peut le constater dans cet exemple, le scnario alternatif de 2me
niveau scrit directement la suite du scnario de premier niveau.
Les extensions qui peuvent intervenir tout instant sont notes au moyen dune
astrisque (*), comme par exemple:
*a. A tout moment, si le systme tombe en panne :
1.Le Caissier relance le Systme, se reconnecte et demande la rcup-
ration de l'tat prcdent.
Spcifications particulires
Les spcifications particulires permettent de modliser des spcifications non fonc-
tionnelles, des contraintes, etc. qui se rattachent au cas dutilisation.
Voici quelques exemples:
Interface utilisateur cran tactile sur grand cran plat. Le texte doit tre visible
un mtre.
Obtention de la rponse la demande d'autorisation en trente secondes maximum
dans 90 % des cas.
Une forme quelconque de rcupration fiable quand l'accs un service distant
(inventaire, par exemple) choue.
etc.
7.3.4 Prsentation: la variante Rebecca Wirfs-Brock
Cette variante, recommande par certains, est trs pratique pour lanalyse et la mise au
point de lergonomie du systme.
Elle a la particularit dutiliser un format sur deux colonnes, la colonne de gauche repr-
sentant les actions de lacteur, et celle de gauche, en regard, les responsabilits du sys-
tme.
Utiliser cette variante ou rester sur une prsentation mono-colonne? a nest quune
question de got trs personnelle: lune et lautre prsentent en effet la mme informa-
tion.
7.4 DFINIR LE MODLE DES CAS DUTILISATION, DMARCHE
GNRALE
En prliminaire, nous tcherons dtablir un certain nombre de rgles nous permettant de
reconnatre les bons cas dutilisations parmi tous ceux qui peuvent se prsenter les-
prit. Dans une deuxime tape, nous dcrirons la dmarche gnrale suivre par lanalys-
te pour rdiger au mieux le modle de cas dutilisation.
Action dacteur Action systme
1. Un client se prsente la caisse
avec des produits acheter.
2. Le caissier saisit lidentificateur
de chaque produit.
Sil y a plus dune pice dun
mme produit, le caissier a la pos-
sibilit den saisir le nombre.
4. Aprs avoir saisi tous les produits,
le caissier signale la caisse la fin
des achats.
6. Le caissier annonce le total au
client.
7. Le client effectue son paiement.
8. Le caissier saisit la somme dar-
gent paye par le client.
10.Le caissier encaisse le paiement,
et extrait le solde d du tiroir-cais-
se.
Le caissier rend la monnaie au
client, et lui donne le ticket.
12.Le client quitte la caisse avec les
produits achets

3. La caisse dtermine le produit, et
en affiche la description et le prix
unitaire.
5. La caisse calcule et affiche le total.
9. La caisse affiche le solde d au
client.
La caisse imprime un ticket.
11.La caisse enregistre lachat.
7.4.1 En prliminaire: quest-ce quun bon cas dutilisation?
A titre dexemple, considrons les 3 cas dutilisation potentiels:
Traiter une vente;
Rcuprer une erreur de transaction;
Se connecter.
Chacun de ces 3 cas est-il un cas dutilisation valide (qui a un sens a lui tout seul)
ou simplement une tape au sein dun cas dutilisation?
La rponse nest pas vidente. Elle dpend notamment du niveau auquel on se place.
Mais la question est pose: quest-ce quun bon cas dutilisation, et, de manire plus
gnrale: comment identifier les cas dutilisation?
La rgle de base peut tre exprime ainsi:
Dfinition 19: Les processus mtier lmentaires
Un processus mtier lmentaire est une tche qui ajoute une valeur commerciale
observable et mesurable, et qui laisse les donnes du systme, lorsquelle se termine,
dans un tat stable et cohrent.
Dans la phase danalyse des besoins, lanalyste doit se concentrer sur les cas dutilisation
qui se situent au niveau des processus mtier lmentaires.
Ainsi, reprenant les 3 cas dutilisation potentiels prsents ci-dessus, seul le premier
constitue un vritable cas dutilisation dit de base. Le troisime constitue plutt une
tape au sein dun cas dutilisation (ce que lon appelle parfois un sous-cas dutilisa-
tion) alors que le second sera considr comme un scnario alternatif (scnario dchec)
appartenant un cas dutilisation de base.
Cas dutilisation de base et sous-cas dutilisation
Une erreur frquente consiste dfinir trop de cas dutilisation et notamment de
considrer des sous-cas dutilisation comme des cas dutilisation de base, alors que ces
sous-cas dutilisation nen constituent en fait quune tape.
Un cas dutilisation de base doit se conformer au principe du processus mtier lmen-
taire.
Un sous-cas dutilisation reprsente une tape, une sous-tche lintrieur dun cas
dutilisation de base.
Il arrive souvent quun sous-cas dutilisation se retrouve dans plusieurs cas dutilisation
de base.
Cela se reprsentera graphiquement ainsi, au moyen dune relation dite relation include
Dfinition 20: Reprsentation dune relation include
La stratgie de lanalyste
Comment trouver cees bons cas dutilisation?
Comme il sagit didentifier et de se concentrer sur les cas dutilisation dits de base, la
stratgie consiste:
1. identifier les objectifs des utilisateurs du systme; ces objectifs correspondent
aux processus mtier lmentaires.
2. leur associer chacun un cas dutilisation de base.Le nom du cas dutilisation por-
tera simplement le nom de lobjectif atteindre.
Concrtement, lanalyste qui opre une interview des diffrents acteurs potentiels,
posera deux types de questions:
Que faites-vous?
La rponse cette question refltera une procdure utilise actuellement, accom-
pagne dune description de toutes les difficults qui lui sont associes.
En gnral, lidentification de cette procdure correspondra lidentification dun
sous-cas dutilisation.
Dans quel but le faites-vous?
La rponse cette question permet de mettre en vidence les objectifs atteindre
Caissier
Enregistrer une
vente
Afficher
l'inventaire
Authentification
Cas dutilisation de base
<<include>>
Sous-cas dutilisation
par lacteur en question.
En gnral, la dcouverte du but en question permettra didentifier un cas dutili-
sation de base.
Une petite interview titre dillustration.
Analyste
Que faites-vous en ce moment?
Caissier
Dabord, je me connecte, puis jenregistre une vente
Analyste
Pour quelle raison vous connectez-vous?
Caissier
Pour que le systme midentifie et mautorise enregistrer une vente ou accom-
plir dautres actions
Analyste
Pour quelle raison le systme doit-il vous identifier?
Caissier
Pour viter le vol ou encore la destruction du systme
Ce dialogue a permis didentifier les buts suivants:
Eviter le vol
Eviter la destruction du systme
Connexion
Authentification
Enregistrement dune vente
Seul le dernier Enregistrement dune vente peut tre considr comme un vritable pro-
cessus mtier lmentaire, cest--dire une tche mesurable qui rajoute une valeur au
systme. Ce but constituera un cas dutilisation de base.
Les deux objectifs Eviter le vol et Eviter la destruction du systme sont certes deux
objectifs atteindre par le systme. Par contre, ils ne rajoutent aucune valeur commer-
ciale. Il ne sagit donc pas proprement parler de processus mtier lmentaires. Ces
deux objectifs ne seront donc pas considrs en tant que cas dutilisation de base. Ils
seront par contre considrs en tant que contraintes (objectifs non-fonctionnels).
Enfin, lAuthentification comme la Connexion ne constituent pas des objectifs de base
(ils ne rajoutent aucune valeur commerciale en tant que tels). Par contre ils intervien-
dront sous la forme de sous-cas dutilisation.
En particulier, la tche Connexion peut tre considre comme un sous-cas dutilisation
du cas Authentification, lui-mme un sous-cas dutilisation..
Sous-cas dutilisation ou simple tape ?
Est-il pertinent de reprsenter cette sous-sous-tche par un nouveau cas dutilisation?
Devons-nous la considrer plus simplement sous la forme dune tape du cas dutilisa-
tion Authentification?
Cela dpend..
Rajouter des cas dutilisation ajoute la complexit du systme, et rappelons que le but
premier des cas dutilisation est daider la comprhension des besoins dun systme,
pas dembrouiller les pistes..
Il ny a malheureusement pas de rgle gnrale. Se fier son bon sens et son
exprience.
7.4.2 La dmarche
Revenons maintenant au modle gnral des cas dutilisation qui comprend une liste dac-
teurs et une liste associe de cas dutilisation.
Quelle sera la dmarche suivie par lanalyste pour tablir ce modle?
Dfinition 21: Dfinir le modle de cas dutilisation
Lanalyste procdera typiquement en suivant les 3 tapes suivantes:
1. Dlimiter les frontires du systme dvelopper
2. Identifier les acteurs principaux et auxiliaires
3. Identifier les cas dutilisation
Ces trois tapes ne seront pas ncessairement conduites lune aprs lautre. Ce
processus sopre gnralement de manire itrative.
7.4.3 Dlimiter les frontires du systme dvelopper
Comme le systme est vu comme une bote noire qui lon associe des responsabilits,
il sagit ici de faire le tri entre les responsabilits qui seront du ressort du systme lui-
mme des responsabilits qui seront du ressort dentits situes lextrieur du systme
comme par exemple le Systme dautorisation des paiements dans le cadre de notre tude
de cas.
Notons que les acteurs, - comme par exemple le Caissier -, ne font pas partie du sys-
tme dvelopper.
Comme on peut sen rendre compte, la dmarche est la plupart du temps itrative:
il faut parfois commencer par identifier les acteurs afin de pouvoir dfinir clairement les
frontires du systme.
Un diagramme de contexte
Les diagrammes de cas dutilisation fournissent un excellent moyen pour mettre en vi-
dence les frontires du systme dvelopper.
Dans un diagramme de contexte, on se limitera aux cas dutilisation principaux
(cas dutilisation dits de base). Les sous-cas dutilisation (comme par exemple
Authentification) ne seront pas reprsents dans de tels diagrammes.
Caissier
Systme d'autorisation de paiements
Frontire du systme
dvelopper
Responsabilit
Responsabilit
Responsabilit
Responsabilit
Responsabilit
Figure 22: Un diagramme de contexte
Dans la figure ci-dessus, notons que les acteurs principaux sont reprsents
gauche, les acteurs auxiliaires et externes droite.
Reprsentation des acteurs dans un diagramme de cas dutilisation
Il est commode de distinguer visuellement ces diffrents types dacteurs au sein mme des
Systme POS
Gestion des
utilisateurs
. . .
Caissier
Administrateur
systme
Acteur
Cas dutilisation
interaction Frontire du
systme
Gestion dun retour
de marchandise
Systme
dautorisation
des
paiements
acteur
Calculateur de
taxes
acteur
Systme de
comptabilit
Notation
alternative
pour
reprsenter
un acteur de
type
systme
informatique
Location dune
marchandise
Traitement dune
vente
acteur
Systme des
ventes
Gestion de la
scurit
Analyseur de
performances
diagrammes de cas dutilisation.
Figure 23: Distinguer visuellement les acteurs physiques des autres types dacteurs
7.4.4 Identifier les acteurs principaux et les acteurs auxiliaires
Pour ce faire, rpondre la question fondamentale: quels sont les objectifs atteindre par
ce systme et quels sont les acteurs directement intresss par ces objectifs.
Encore une fois, on peut constater que le processus nest pas linaire et procde par itra-
tions successives. Parfois, plutt que de partir des objectifs, on identifie en premier lieu
certains acteurs et on essaye alors de dcouvrir leurs objectifs..
On aboutit ainsi une liste dacteurs associs des objectifs, que lon peut reprsenter au
moyen dun tableau:
Acteur Objectifs
Caissier Traiter une vente
Traiter une location de marchandise
Traiter un retour de marchandise
Encaisser
Administrateur du
systme
Ajouter un utilisateur
Supprimer un utilisateur
Modifier un utilisateur
Grer la scurit
Directeur Dmarrer le systme
Arrter le systme
Systme POS
Traitement
dune vente
. . .
Caissier
Reprsentation dun acteur de
type Systme
informatique
acteur
Systme
dautorisation
de paiement
Dfinition 22: Les diffrents types dacteurs
Rappelons quun acteur est une entit quelconque - extrieure au systme - qui mani-
feste un certain comportement vis vis du systme.
On distingue 3 types dacteurs: les acteurs principaux, les acteurs auxiliaires et les
acteurs externes.
Les acteurs principaux
Par dfinition, les acteurs principaux attendent des services de la part du systme.
Dans une premire approche, on sattache de manire prioritaire identifier les
acteurs principaux, associs directement aux vritables objectifs du systme dvelop-
per.
Les acteurs auxiliaires (ou acteurs secondaires)
Au contraire des acteurs principaux, les acteurs dits auxiliaires fournissent des services
au systme.
Par exemple, il peut sagir dacteurs qui fournissent des informations au systme.
Dans le cadre de notre tude de cas, citons le Calculateur de taxes, le Systme dautori-
sation de paiement. Les fameux services WEB, trs en vogue ces derniers temps, cons-
tituent de bons exemples de ce type dacteurs.
Les acteurs externes
Il sagit dacteurs concerns par laccomplissement de tel ou tel cas dutilisation, sans
pour autant tre ni la source de son accomplissement, ni en constituer un acteur auxiliai-
re.
Gnralement, ces acteurs externes sintresseront aux informations gnres par le sys-
tme. Citons par exemple un systme danalyse de performance, un systme daudit, .,
etc.
Systme des ventes
(une application dis-
tante qui interroge
chaque noeud POS
du rseau)
Analyser les donnes
Acteur Objectifs
Reprsentation dans un diagramme de contexte
Les acteurs principaux sont reprsents gauche, les acteurs externes et auxiliai-
res droite. [Voir figure 22 - Un diagramme de contexte - page 71]
7.4.5 Identifier les cas dutilisation
On reprend chaque acteur, et on analyse clairement ses objectifs par rapport lutilisation
du systme. Les objectifs les plus levs correspondant aux dits processus mtier l-
mentaires sont associs chacun un cas dutilisation dits de base (voir plus haut dans
le chapitre).
7.5 UML: RELATIONS ENTRE CAS DUTILISATION
Entre cas dutilisation, nous avons dj rencontr et mentionn la relation include, mais
UML prvoit de modliser par ailleurs deux autres types de relation: les relations
extends et la relation gnralise.
Figure 24: Les relations include, extends & gnralise
7.5.1 Relation include
Nous avons dj prsent ce type de relation et rappelons simplement quelle se reprsen-
te graphiquement au moyen dune flche, portant le strotype include, associant un cas
dutilisation avec un sous-cas dutilisation.
Ce type de relation est couramment utilis en pratique et se justifie pleinement
ds que lune ou lautre des deux conditions suivantes est observe:
Factorisation: un mme sous-cas dutilisation (une tape typiquement) est uti-
lis par plusieurs cas dutilisation de niveau suprieur. On vite ainsi la rptition.
Dcomposition: un cas dutilisation dit de base est trop complexe et ncessite
dtre dcompos en sous-cas dutilisation afin den amliorer la comprhension.
Reprsentation textuelle
Du point de vue textuel, une relation include se reprsentera de la manire suivante.
Exemple: Cas dutilisation Retrait
Si on utilise linclusion pour montrer quun cas dutilisation en appelle un autre
ou en rfrence un autre, notons que cet appel nest pas obligatoire: le cas inclus ne
sera pas forcment activ
Retrait
Scnario principal:
1. Le client arrive la caisse et sauthentifie
2. Le client sauthentifie: include Authentification
etc.
Scnarios alternatifs:
..
Authentification
Scnario principal:
1. Le client prsente sa carte
2. La carte est reconnue par le systme
3. Le client saisit son mot de passe
4. ...
etc.
7.5.2 Relation genralise
Cette dernire relation modlise la spcialisation dun comportement en reprenant le sym-
bole de Gnralisation-Spcialisation dfinit dans le cadre des diagrammes de classe
UML.
Reprsentation dun SOIT-SOIT
Lea relation Gnralise est utilise essentiellement pour modliser des SOIT-SOIT.
Le cas de base (gnral est en principe un cas dutilisation abstrait. Les cas dutilisation
enfant sont de vritables cas dutilisation de base: il ne sagit pas de sous-cas dutilisa-
tion.
En dehors du SOIT-SOIT
Il arrive que la gnralisation ne soit pas utilise pour modliser un SOIT-SOIT. Auquel
cas, le cas parent ne sera pas abstrait et ne fera pas rfrence (dans sa description textuelle)
aux diffrents cas enfants qui viendront se greffer par la suite.
Rgles dutilisation
Dans le cadre de la spcialisation, un cas dutilisation enfant doit tre de mme espce
que le cas dutilisation parent:
Il interagit avec les mmes acteurs que le parent (il peut lui-mme en avoir de
spcifiques)
Il hrite des relations dfinies au niveau du parent (includes, extends, ..)
De mme quavec le diagramme des classes, on peut dire quun cas enfant est-
une-sorte de cas parent.
Un cas enfant doit tre apprhend comme une variante du cas parent.
Dposer argent
Retirer argent
Effectuer
unetransaction
Client
Un cas enfant peut par ailleurs se substituer un cas parent! Dans la figure
ci-dessus, un client peut Effectuer une transaction. Il peut donc, par application
du principe de substitution, Dposer de largent ou encore Retirer de
largent.
La spcialisation sapplique galement aux acteurs !
Dfinition 23: Spcialisation dun acteur
Un acteur B qui spcialise un acteur A possde toutes les caractristiques de lacteur A en
plus de ses caractrisqiues propres!
Voici un premier exemple avec un Moniteur de ski
Cas parent: Donner un cours de ski (cas abstrait)
Cas enfant: Donner un cours de saut - Donner un cours de slalom.
Acteur 1: Moniteur de ski
Acteur 2: Moniteur de slalom (interagit avec Donner cours de slalom)
Remarques sur le schma obtenu:
1. Un moniteur de slalom nest pas un moniteur de ski
(il est seulement capable denseigner le slalom)
2. Un cours de saut est une espce de cours de ski. Un cours de slalum est une
Moniteur de ski
Donner cours
de ski
Donner cours
de slalom
Donner cours
de saut
Moniteur de slalom
Moniteur de saut
Enregistrer
les lves
includes
espce de cours de ski.
3. Un cours de ski est soit un cours de saut, soit un cours de slalom, etc.
(On peut imaginer que Donner un cours de ski est un cas dutilisation abstrait,
mais pas obligatoirement).
4. Donner un cours de slalom hrite des relations de donner un cours de ski Il
inclut donc les sous-cas ventuels de donner un cours de ski, comme par exem-
ple Enregistrer les lves.
5. Un moniteur de ski peut tout enseigner: cest la fois un moniteur de ski et un mo-
niteur de slalum.
Voici un deuxime exemple:
Cet exemple nest pas correct !
En effet, si on applique le principe de substitution (propre au principe de Gnralisation-
Spcialisation), le cas Conclure une grosse affaire peut se substituer au cas Conclure
une affaire. Un simple vendeur peut donc conclure une grosse affaire..
Il faut donc se mfier ..
Vendeur
Conclure
une affaire
Conclure une
grosse affaire
Chef de vente
Voici le mme exemple, reprsent cette fois-ci de manire correcte:
Relation extends
La relation extends permet de modliser des comportements facultatifs ou conditionnels
dun cas dutilisation de base que lon tend en indiquant:
lendroit du cas de base o aura lieu lextension (ce que lon appelle le
point dextension), le paiement dans le cadre de notre exemple.
et la condition de dclenchement du comportement facultatif. Cette condi-
tion apparait directement dans le nom mme du cas dutilisation, comme
dans notre exemple: Paiement par chque.
Vendeur
Conclure
une affaire
Conclure une
grosse affaire
Chef de vente
Conclure une
petite affaire
Dfinition 24: Utilisation des cas dextension
On utilisera les cas dextension dans lun ou lautre des deux cas suivants:
1. Si le cas dutilisation de base est verrouill: on ne veut plus y toucher, il a dj
t trop modifi et on a dcid de gure lasse de le figer. Les ajouts sont alors ra-
jouts sous la forme dextensions)
2. Pour modliser des activits asynchrones et/ou optionnelles, qui peuvent provo-
quer des interruptions du cas de base, mais qui en aucun cas ne doivent dranger
le droulement du cas de base.
Reprsentation textuelle
Du point de vue textuel, une relation extends se reprsentera de la manire suivante.
Exemple: Cas dutilisation Dpt (le cas de base)
Dpt
Scnario principal:
1. Le client arrive la caisse
2. Le client sauthentifie
3. Le client opre un dpt pour un montant de n francs
4. Le systme enregistre le dpt
5. ...
etc.
On pourra vrifier au travers de cet exemple que le cas de base Dpt ne comporte
aucune rfrence au cas additionnel Paiement par chque.
Un exemple de relation extends
La correction orthographique peut tre vue comme une extension par rapport au cas duti-
lisation de base de saisie de texte.
Cas de base: Modification du texte
Extensions:
Trouver un synonyme
Changer la feuille de style
Vrifier lorthographe
Une extension est un rajout, optionnel, au cas de base. Il sagit dun rajout et
non pas dune variante ! (bien distinguer extension et spcialisation).
Le cas de base est lactivit principale qui peut tre interrompue par les cas
dextension. Le cas de base se dfinit indpendamment des extensions.
Paiement par chque
Extension du cas: Dpt
Point dextension: 3.(Le client opre un dpt)
Dclencheur: Le dpt est opr par chque plutt quen liquide
Scnario principal:
1. Le client prsente son chque
2. La signature est authentifie par le systme
3. ...
etc.
Modifier le
texte
Changer la feuille
de style
Trouver un
synonyme
Vrifier
orthographe
extends
extends
extends
Les extensions sont des cas dutilisation qui peuvent interrompre lactivit princi-
pale (le cas de base), mais qui nont pas dinfluence sur elle.
La dfinition dun cas dextension comporte souvent - mais pas obligatoirement -
,la spcification dun point dextension: lendroit du cas de base o le cas dextension
peut senclencher. Plutt que dtre indiqu au moyen dun numro dtape, le point
dextension est trs souvent une tiquette (un label) - qui doit avoir t dfini dans le
cas de base - afin dtre plus indpendant de modifications apportes au cas de base.
Les spcialistes du domaine recommandent aujourdhui de faire un usage modr
de la relation extends, voire de ne pas lutiliser. Auquel cas, lextension est simplement
mise en oeuvre sous la forme dun scnario alternatif qui napparait que dans la reprsen-
tation textuelle du cas dutilisation de base.
7.6 QUELQUES RECOMMANDATIONS
Rdaction des tapes
Simplicit dcriture: une tape est dcrite par une locution verbale simple:
Sujet.. Verbe .. Complment
P.e. Le client saisit son mot de passe
SI..ALORS.. proscrire !
Un vritable SI donnera lieu un scnario alternatif. Le scnario nominal
sappuie sur un comportement normal, une suite dtapes excuter squentielle-
ment.
Le style mme de rdaction doit en tenir compte, comme par exemple..
Mauvais:
i. Le systme vrifie si le mot de passe est correct
i+1. Si correct, le systme prsente le menu au client
A remplacer par:
i. Le systme vrifie que le mot de passe est correct
i+1. Le systme prsente le menu au client
Le point de vue dun oiseau
Adopter un point de vue extrieur: celui dun observateur tel un oiseau perch sur
sa branche qui observe linteraction entre le ou les utilisateurs et le systme.
Du style: Le client introduit sa carte bancaire et saisit son code.
Surtout, ne pas prsenter le point de vue du systme regardant le monde extrieur.
Montrer lobjectif de chaque tape
Chaque tape doit correspondre un mini-objectif en soi. Notamment, la lecture
dune tape ne doit pas soulever de question du type pourquoi lutilisateur fait-il
cela ?.
Ce que ne manquerait pas de susciter une tape rdige de la manire suivante:
Le client appuie sur la touche RETURN
La remplacer plutt par: Le client saisit son code.
Il faut donc montrer lintention de lutilisateur plutt que ses gestes.
Oublier les interfaces utilisateurs
Allistair Cockburn recommande vivement dadopter un style essentiel dans la rdaction
des cas dutilisation: il faut se concentrer sur lintention, sur lobjectif (le QUOI).
Dans la plupart des cas, discuter en termes dinterface utilisateur dnote plutt une
rflexion sappuyant sur le COMMENT, ce qui peut engendrer une prise dcisions
parfois trop prcoce, tenant lieu de la conception, et fermant demble la porte certai-
nes innovations.
Par exemple, on peut dcrire le cas dutilisation Authentification en mentionnant con-
crtement une bote de dialogue permettant de saisir un nom dutilisateur et un mot de
passe:
1. Lutilisateur saisit son nom et son mot de passe dans une bote de dialogue
2. Le systme authentifie lutilisateur
3. Le systme affiche la fentre principale
4. etc.
En oprant ainsi, on sinterdit par la suite dutiliser un systme innovateur du type
authentification par empruntes digitales.
Conserver un style essentiel permet de garantir un maximum de liberts par la suite.
Surtout lorsque lon se trouve en dbut de phase de spcification.
Notons toutefois que dans bien des cas, le futur utilisateur du systme imposera
ds le dpart une interface utilisateur spcifique. Lanalyste devra la prendre en compte
bon gr mal gr.
Notons galement quil faudra bien sattaquer llaboration de linterface utilisateur
un moment ou lautre.
7.7 LE NIVEAU DE DTAIL
En principe, du point de vue des diagrammes, ne pas dpasser 10 15 cas par
page!
Si lon se retrouve face 100 voire 200 cas dutilisation, comment faire ?
La solution consiste exploiter la notion de paquetage.
Au sens UML, un paquetage est un regroupement de diagrammes qui cooprent en parti-
cipant la mme fonctionnalit.
Un paquetage peut lui-mme se dcomposer en sous-paquetages.
Les critres de regroupement de plusieurs cas dutilisation dans un mme paquetage sont
habituellement:
Par thme (moyen sans doute le plus naturel)
Par fonction stratgique (on regroupe les cas dutilisation qui seront par exemple
dvelopps en mme temps)
Plus rarement, on peut regrouper par acteur.
On conseille habituellement de regrouper en premier par thme (par exemple 3 6 grou-
pes), puis par fonction stratgique.
Du point de vue du diagramme, il est possible doprer ainsi:
Dessiner sur une premire page sur laquelle apparaissent des cas dutilisation de
niveau 1 (reprsentent en fait des paquetages regroupant plusieurs cas dutilisa-
tion).
Puis dtailler chaque cas de niveau 1 (chaque paquetage) au moyen dune nou-
velle page (niveau 2) et ainsi de suite..
Il serait par exemple possible de regrouper les 3 cas dutilisation Ajouter un utili-
sateur, Supprimer un utilisateur et Modifier un utilisateur par un seul et unique
cas dutilisation de niveau 1 et qui serait intitul Gestion des utilisateurs.
7.8 QUAND EST-CE QUE LON A TERMIN ?
On a termin la rdaction des cas dutilisation:
1. Quand on a dsign tous les acteurs principaux et tous les objectifs utilisateurs par
rapport au systme.
2. Quand on a formul toutes les conditions de dclenchement, soit sous la forme de
dclencheur de cas dutilisation, soit sous la forme de conditions dextensions.
3. Quand le niveau de formulation des cas dutilisation est rdig de faon ce que:
1. Cela couvre les souhaits des clients et des utilisateurs.
2. Cela permet aux dveloppeurs de pouvoir dvelopper effectivement la fonc-
tion.
7.9 COMPLMENTS DE SPCIFICATIONS
Du point de vue des spcifications, la rdaction de cas dutilisation nest pas suffisante en
soi. Dautres besoins ncessitent une prise en charge, comme notamment la documenta-
tion, la problmatique des licences, les contraintes dinterfaage, etc.
Dans le cadre de la mthode UP, ces complments de spcifications comprennent princi-
palement les lments suivants:
Le Glossaire (Glossary)
Dj mentionn au dbut du chapitre, rappelons que ce dernier acceuille la dfinition des
termes, les dfinitions et quil peut jouer le rle de dictionnaire des donnes.
La Vision (Vision)
Une espce de rsum du projet, acceuillant essentiellement:
Les ides fondatrices du projet.
Les besoins des parties prenantes (spcifications fondamentales).
Les problmes essentiels et les solutions proposes.
Les spcifications supplmentaires
Il sagit dun terme gnrique permettant de regrouper un peu tout le reste, savoir toute
les spcifications qui nont pu tre captures ni dans le cadre de la rdaction des cas duti-
lisation ni dans le glossaire.
Rappelons au passage que les spcifications spciales qui se rapportent un cas
dutilisation en particulier peuvent tre consigns dans la section Besoins spciaux de la
rdaction dtaille du cas dutilisation. Nanmoins, certains analystes prfrent rassem-
bler ces derniers dans les spcifications supplmentaires.
Nous nous contenterons ici dnoncer le type dlments que peuvent contenir les spci-
fications supplmentaires.
Dfinition 25: Spcifications supplmentaires - Liste non exhaustive de ses lments
Contraintes de qualit
Interfaage Homme-Machine (ergonomie requise, facteurs humains)
Fiabilit
Performance
etc.
Contraintes matrielles et logicielles
Systme dexploitation, langage de programmation, topologie du rseau, etc.
Contraintes de dveloppement
Outils de dveloppement, de traitement, etc.
Contraintes de scurit
Contraintes denvironnement
Chaleur, vibrations, etc.
Prise en charge des problmes de fonctionnement
Traitement des erreurs, frquence des sauvegardes, etc.
Documentation fournir
Documentation utilisateur, installation, administration, etc.
Aspects juridiques, licences
Normes
Scurit, qualit, techniques, etc.
Informations propres au domaine
Rgles du domaine (modes de fonctionnement, workflows, documents produits,
etc.)
7.10ANNEXE: PRSENTATION DTAILLE DU CAS DUTILISA-
TION VENTE
Cet exemple est tir du livre UML et les Design Patterns - Traduction franaise du livre
de Craig Larman Applying UML & Design Patterns.
Traiter une vente
Acteur principal
Le Caissier
Parties prenantes et intrts
Le Caissier. Il veut un moyen de saisie exact et rapide et aucune erreur de paiement, car
les diffrences de caisse sont retenues sur son salaire.
Le Vendeur. Il veut que les commissions sur les ventes soient mises jour.
Le Client. Il veut des achats et un service rapide avec le minimum d'efforts. Il veut gale-
ment une preuve d'achat en cas de retour.
L'Entreprise. Elle veut enregistrer correctement les transactions et satisfaire les intrts
des clients. Elle veut tre sre que les effets recevoir du Service d'autorisation des paie-
ments sont enregistrs. Elle veut une certaine tolrance l'erreur, afin de pouvoir captu-
rer traiter les ventes mme si l'un des composants du serveur est indisponible (par
exemple la validation du crdit distance). Elle veut une mise jour automatique et
rapide de la comptabilit et de l'inventaire.
Les Services fiscaux. Ils veulent enregistrer les taxes sur chaque vente.
Le Service d'autorisation des paiements. Il veut recevoir des demandes d'autorisation
numrique conformes un format et un protocole donns. Il veut une comptabilit
exacte des effets payer au magasin.
Prconditions
Le Caissier est identifi et authentifi.
Garanties de succs (postconditions)
La vente est enregistre. La taxe est correctement calcule. La Comptabilit et l'Inventaire
sont mis jour. Les commissions sont enregistres. Le reu est gnr. Les autorisations
de paiement sont enregistres.
Scnario principal (succs)
1. Le Client arrive la caisse avec des marchandises et/ou des services acheter.
3. Le Caissier entre le code de l'article.
4. Le Systme enregistre l'article et prsente sa description, son prix et le total en
cours. Le prix est calcul partir d'un ensemble de rgles.
Le Caissier rpte les tapes 3 et 4 jusqu' ce que tous les articles soient passs.
5. Le Systme prsente le total avec les taxes calcules.
6. Le Caissier communique le total au Client et en demande le paiement.
7. Le Client paie et le Systme traite le paiement.
8. Le Systme enregistre la vente et transmet les informations la concernant et con-
cernant le paiement au systme de Comptabilit externe (pour la mise jour de la
comptabilit et les commissions) et au systme d'Inventaire (pour la mise jour de
l'inventaire).
9. Le Systme prsente un reu.
10.Le Client part avec les marchandises et le reu.
Extensions (ou scnarios alternatifs) :
*a. A tout moment, si le systme tombe en panne :
Pour permettre la rcupration et la correction de la comptabilit, s'assurer que tous les
tats et les vnements sensibles du systme peuvent tre rcuprs n'importe quelle
tape du scnario.
1. Le Caissier relance le Systme, se reconnecte et demande la rcupration de l'tat
prcdent.
2. Le Systme reconstruit l'tat prcdent.
2a. Le Systme dtecte des anomalies empchant la rcupration :
1. Le Systme signale l'erreur au Caissier, enregistre l'erreur et entre dans
un tat valide.
3a. Code invalide :
1. Le Systme signale l'erreur et rejette la saisie.
3b. Il y a plusieurs articles de la mme catgorie et leur identification individuelle
n'a pas d'importance (exemple : cinq cartons de lait de soja) :
1. Le Caissier peut saisir le code de l'article et sa quantit.
3-6a.Le Client demande au Caissier de retirer un article de ses achats :
1. Le Caissier entre le code de l'article et l'annule.
2. Le Systme prsente le total courant mis jour.
3-6b.Le Client demande au Caissier d'annuler la vente :
1. Le Caissier annule la vente sur le Systme.
3-6c.Le Caissier suspend la vente :
1. Le Systme enregistre la vente pour qu'on puisse la rcuprer sur
n'importe quel autre terminal.
4a. Le prix d'un article indiqu par le systme n'est pas le prix voulu (exemple : un
Client se plaint d'un dfaut et se voit proposer un rabais) :
1. Le Caissier saisit l'information. 2.Le Systme prsente le nouveau prix.
5a. Le Systme dtecte un chec de la communication avec le service externe de
calcul des taxes :
1. Le Systme redmarre le service sur le nud POS et continue.
1a. Le Systme dtecte que le service ne redmarre pas.
1. Le Systme signale l'erreur.
2. Le Caissier peut calculer et saisir les taxes la main ou
annuler la vente.
5b. Le Client annonce qu'il a droit une remise (employ, client privilgi) :
1. Le Caissier signale la demande de remise.
2. Le Caissier saisit le code du Client.
3. Le Systme prsente le total de la remise, calcul partir de rgles.
5c. Le Client annonce qu'il a un avoir et demande qu'il soit dduit de la vente :
1. Le Caissier signale la demande d'avoir.
2. Le Caissier saisit le code du Client.
3. Le Systme dduit l'avoir hauteur de prix=0 et dcrmente l'avoir res-
tant.
6a. Le Client a l'intention de payer en espces mais n'a pas assez de liquide :
1a. Le Client emploie une autre mthode de paiement.
1b. Le Client dit au Caissier d'annuler la Vente. Le Caissier annule la vente
sur le Systme
7a. Paiement en espces :
1. Le Caissier saisit le montant en espces reu.
2. Le Systme prsente le montant rendre et ouvre le tiroir-caisse.
3. Le Caissier dpose le montant reu et rend la monnaie au Client.
4. Le Systme enregistre le paiement en espces.
7b. Paiement crdit :
1. Le Client saisit les informations sur son compte crdit.
2. Le Systme envoie une demande d'autorisation au Service d'autorisation
des paiements externes et demande une rponse.
2a. Le Systme dtecte une erreur de communication avec le systme
externe :
2. Le Caissier demande au Client un autre moyen de paiement.
3. Le Systme reoit une autorisation de paiement et le signale au Caissier.
3a. Le Systme reoit un refus :
1. Le Systme le signale au Caissier.
2. Le Caissier demande au Client un autre moyen de paiement.
4. Le Systme enregistre le paiement crdit, y compris l'autorisation.
5. Le Systme prsente un mcanisme de saisie de la signature.
6. Le Systme demande une signature au Client. Le Client signe.
7c. Paiement par chque...
7d. Paiement par dbit...
7e. Le Client prsente des coupons :
1. Avant de traiter le paiement, le Caissier enregistre chaque coupon et le
Systme rduit le prix en consquence. Le Systme enregistre les coupons
utiliss pour des raisons de comptabilit.
1a. Un coupon ne correspond aucun article achet :
9a. Il y a des remises sur des produits.
1. Le Systme prsente les formulaires et les reus pour chaque article fai-
sant l'objet d'une remise.
9b. Le Client demande un reu sans mention de prix (pour faire un cadeau) :
1. Le Caissier demande un reu au systme et le Systme lui fournit.
Spcifications particulires
Interface utilisateur cran tactile sur grand cran plat. Le texte doit tre visible
un mtre.
Obtention de la rponse la demande d'autorisation en trente secondes maximum
dans 90 % des cas.
Une forme quelconque de rcupration fiable quand l'accs un service distant
(inventaire, par exemple) choue.
Internationalisation de la langue sur le texte affich.
Possibilit d'introduire les rgles de gestion dans les tapes 3 et 7.
etc..
Liste de variantes de donnes et de technologies
3a. Le code de l'article est saisi par un lecteur laser (si le code barres est prsent)
ou au clavier.
3b. Le code de l'article peut obir n'importe quel schma de codage UPC, EAN,
J AN ou SKU.
7a. Actuellement, en cas de paiement crdit, le Client signe un reu papier. Nous
prvoyons que d'ici deux ans, de nombreux clients voudront saisir une signature
numrique.
Frquence d'occurrence
Pourrait tre pratiquement continue.
Questions ouvertes
Qu'en est-il des variations de taux des taxes ?
Etudier le problme de la rcupration en cas d'inaccessibilit d'un service distant.
Quel est la personnalisation ncessaire pour les diffrents mtiers ?
Le Caissier doit-il prendre son tiroir-caisse quand il se dconnecte ?
Le Client peut-il utiliser directement le lecteur de cartes ou est-ce le Caissier qui
doit le faire ?
Gnie logiciel - 93 - Modlisation de domaine
8 Modlisation de domaine
La modlisation du domaine est une activit essentielle de lanalyse des be-
soins. Du point de vue de la mthode UP, cette activit fait partie de la discipline
Modlisation mtier.
Si les cas dutilisation constituent un artefact trs important de lanalyse des besoins, ces
derniers ne sont pas orients objet. Ils sont plutt orients processus puisquils
dcrivent essentiellement les fonctionnalits du systme.
Le modle du domaine, - qui reprsente les classes conceptuelles les plus importantes du
systme dvelopper -, constitue au contraire un aterfact orient objet et - ce titre -
sera directement utilis lors de la conception des classes logicielles.
La modlisation du monde rel
Dfinition 26: Modle du Domaine [Martin Fowler - 1996]
Le modle du domaine est une reprsentation des classes conceptuelles ou des objets du
monde rel dans un domaine donn.
Le monde rel dsigne le systme existant pour lequel il a t dcid de concevoir un
logiciel dans le but dune automatisation de processus, dune amlioration de la qualit,
etc.
Par exemple, pour raliser un logiciel de gestion des horaires dans une cole comme la
notre (EIVD), on dfinira un modle de domaine sappliquant:
un monde rel: lcole et son fonctionnement avec ses tudiants, son corps
enseignant et son personnel administratif;
un domaine: celui de la gestion des horaires
Quen est-il des mondes irrels?
Les dveloppeurs sont souvent amens modliser des systmes informatiques dans des
domaines loigns de mondes rels concrets et familiers comme peuvent ltre lEIVD,
une banque, une administration, etc.
Cest par exemple le cas des logiciels de tlcommunications qui manipulent des con-
cepts purement logiques ou abstraits tels que Connexion, Port, Dialogue de routage,
Protocole, etc. La dfinition dun modle de domaine est bien entendue tout fait indi-
que, la seule diffrence tant que les concepts mis en jeu seront plus abstraits et moins
familiers, on ne pourra pas toujours les toucher du doigt.
Le Modle du domaine et la mthode UP
En gnral, la dfinition du modle de domaine fait partie intgrante de la phase dlab-
oration. Il sera la fois commenc et termin pendant cette phase.
Le Modle du Domaine et UML
La reprsentation visuelle dun modle de domaine sappuie sur la syntaxe UML du dia-
gramme de classes, comme dans lexemple qui suit, qui reprsente la modlisation de la
gestion des ventes dans un magasin du monde rel.
Figure 25: Reprsentation dun modle de domaine en UML
On supposera dans ce document que le lecteur connat tout de la syn-
taxe des diagrammes de classe UML. Sinon, se reporter lannexe corres-
pondante.
8.1 CARACTRISTIQUES ESSENTIELLES DE LA MODLISATION
DE DOMAINE
Pour celles et ceux qui seraient habitus utiliser la syntaxe du diagramme de classes dans
le cadre dune conception ou dune implmentation de logiciel, ATTENTION!
La modlisation de domaine sinscrit dans le cadre de lanalyse dun problme et de sa
comprhension. Les entits que nous retrouverons dans ces diagrammes sont donc un
reflet du problme et non pas un reflet du logiciel qui sera mis en oeuvre pour informa-
tiser le problme en question.
Rassurons-nous toutefois: les diagrammes de classes qui seront labors en phase
de conception seront issus et inspirs directement des diagrammes de modlisation de
domaine. Ces derniers sont donc dune importance capitale, tant pour la comprhension
du problme que pour la conception du futur logiciel. Ils constituent en quelque sorte un
pont entre lanalyse et la conception.
Voici donc deux particularits, - que nous considrons comme essentielles -, associer
aux diagrammes de modlisation de domaine.
Registre
Article
Magasin
adresse
nom
Vente
date
heure
Paiement
montant
Ligne dcriture
quantit
Stock dans
*
1..*
1..*
Enregistre-un
Pay-par
1
1
1
1
1
1
Signale-dans 4
Concept ou objet du
domaine
Association
Attributs
0..1
Le modle du domaine est une abstraction
Du point de vue des attributs, on ignore les dtails sans intrts (la vue est partielle). Dans
loptique de la mthode UP, les dtails seront souvent repris et analyss dans le cadre des
itrations de la phase de construction.
Le modle du domaine est une reprsentations visuelle du monde rel
Les classes reprsentes modlisent les concepts du monde rel: il sagit de classes con-
ceptuelles et non pas de classes logicielles J ava ou C#.
Dfinition 27: Notion de classe conceptuelle
Une classe conceptuelle appartient au monde rel du domaine qui nous intresse. Elle en
illustre le vocabulaire. Elle peut reprsenter:
une chose ou un objet tangible (un document, un appareillage, etc.),
une personne pouvant tre implique dans le fonctionnement du systme (un
acteur principal, auxiliaire, etc.),
une ide,
etc.
Ce qui a pour consquence:
Que seuls les attributs y sont reprsents. La notion de mthode ny a pas de sens.
Que les associations sont par nature bidirectionnelles. La notion de navigabilit
des associations ny a pas de sens.
8.2 CONSEILS
Des particularits nonces prcdemment dcoulent un certain nombre de conseils quil
est bon davoir lesprit.
Sur-spcifier au niveau des classes
Ne pas trop dtailler du point de vue des attributs, mais ne pas hsiter - au contraire -
sur-spcifier avec de nombreuses classes. Chercher rduire le nombre de classes con-
ceptuelles na pas de sens.
Ne pas se polariser sur la dcouverte des attributs
Comme laccent est plac sur lidentification des concepts et sur lidentification des rela-
tions entre ces diffrents concepts, on se retrouvera ainsi avec de nombreuses classes con-
ceptuelles sans attribut, ce qui naura rien de choquant en soi. Lidentification complte
des attributs se fera plus tard, de manire itrative. Au dpart, les considrer comme du
dtail..
Ainsi, on ne va pas liminer une classe conceptuelle en sappuyant sur le fait quil ny
aura aucune information mmoriser la concernant. Un critre qui - par contre - est
important en phase de conception ou dimplmentation.
Ne rien rajouter la ralit
On doit se focaliser sur la modlisation du monde rel et se placer dans lesprit de celui
ou de ceux qui interviennent et agissent dans ce cadre. Rajouter des concepts de son pro-
pre cru serait trs dangereux.
Le choix des noms
Les noms doivent reflter le vocabulaire du domaine, au plus prs. Cela facilite la com-
prhension du modle.
Par la suite, comme le modle de domaine inspirera directement le modle conceptuel
(classes logicielles), les noms qui seront alors donns aux diffrentes classes, aux mtho-
des, etc. continueront logiquement de reflter le vocabulaire du domaine. Cest ainsi que
lon rduira le dcalage entre les concepts manipuls dans le produit final et le monde
rel. Un trs bon point pour faciliter la maintenance ultrieure du logiciel.
Quelles associations retenir?
Ne retenir que les associations pour lesquelles il est ncessaire de mmoriser la
relation; mme si ces dernires nont lieu que de manire transitoire (comme par
exemple quune vente Est-Sollicite-Par-Un-Client.
Eviter les associations redondantes (notamment celles qui drivent dautres asso-
ciations)
Payment
amount
Sale
date
time
Pays-for
Payment
amount: Money
getBalance(): Money
Sale
date: Date
startTime: Time
getTotal(): Money
. . .
Pays-for
Modle du domaine
Modle conceptuel
1 1
1
1
Source
dinspiration pour
Type de donnes: attribut ou classe conceptuelle?
Les attributs reprsentent des valeurs qui caractrisent une classe conceptuelle. A ce
titre, ils correspondent le plus gnralement des types primitifs (nombres, boolens,
caractres et textes).
Types numrs
Le type des attributs peut toutefois correspondre des types plus labors, comme
par exemple un type numr (p.e le type Semaine, le type Couleur) dont les
valeurs seront spcifies par lanalyste ou plus tard par le concepteur.
Types record
Le type des attributs peut encore correspondre des types structurs correspon-
dant la notion de record des langages de type Pascal ou Ada (p.e le type
Adressse, le type PointGraphique).
Plus tard, en phase dimplmentation, ces types seront trs souvent mis en oeuvre sous la
forme dune classe logicielle (cela dpend du langage choisi).
Dans le cadre de la modlisation de domaine, quen est-il ? Faut-il les faire apparatre
sous la forme dune classe conceptuelle ou se contenter dindiquer leur nom comme type
de lattribut.
Si ces derniers font lobjet dassociations spcifiques, dune gnralisation, dune sp-
cialisation, la rponse est claire: les faire apparatre sous la forme dune classe concep-
tuelle.
Dans le cas contraire, cela dpend..
de ce que lon dsire communiquer,
faire passer au travers du modle,
du degr de dtails, etc.
Il est donc impossible de rpondre de manire catgorique ce problme.
Un attribut nest pas une cl trangre!
Une cl trangre est une rfrence qui associerait une classe conceptuelle avec une autre.
Une cl trangre est du domaine de la conception et de limplmentation. Dans la mo-
dlisation de domaine, ces dernires sont simplement reprsentes par la ligne dassocia-
tion correspondante. Plus tard, dans les classes logicielles, elles apparatront sous la forme
dattribut et seront visuellement mises en vidence par le symbole de navigabilit des as-
sociations.
Figure 26: Cls trangres
8.3 HEURISTIQUE: COMMENT IDENTIFIER LES CLASSES CON-
CEPTUELLES
Lidentification des classes conceptuelles requiert un peu de pratique - comme toujours! -.
Analyse linguistique
Une premire mthode consiste analyser les descriptions textuelles du problme, re-
prer les noms et les considrer comme des classes conceptuelles ou des attributs po-
tentiels.
On peut se baser par exemple sur les textes rdigs dans le cadre de la dfinition des cas
dutilisation.
Les verbes reprs dans ces descriptions textuelles correspondent gnralement des
associations entre les diffrentes classes conceptuelles. Il se peut toutefois que laction
correspondante soit prise en compte sous la forme dune classe conceptuelle.
Cette mthode doit tre applique avec prudence et beaucoup de recul car le lan-
gage naturel sur lequel elle sappuie comporte beaucoup dimprcision et dambigut.
Elle a le mrite dtre extrmement naturelle et constitue une approche idale pour le
dbutant.
Attribut ou classe conceptuelle?
Une difficult que lon rencontre frquemment, lorsque lon a repr un nom, est dhsiter
entre la notion dattribut et de concept (classe conceptuelle).
Voici une petite rgle: un concept est une entit qui possde une certaine identit. Il
existe et se justifie en lui-mme: il pourra tre manipul pour lui-mme indpendam-
ment des autres entits.
Cashier
name
currentRegisterNumber
Cashier
name
Register
number
Uses
Mauvais
Bon
1 1
Un attribut jouant le rle de
cl trangre, rfrenant une
autre classe conceptuelle
Un attribut ne se justifie pas lui tout seul et na de sens quassoci au concept quil
caractrise.
Une Vente constitue par exemple un bon exemple de classe conceptuelle: elle se justi-
fie en elle-mme, on peut lenregistrer, la supprimer du registre, modifier ces caractris-
tique, etc.
Une date constitue plutt un bon exemple dattribut. Une date na souvent pas de sens
en elle-mme sinon pour caractriser un concept. On parlera par exemple de la date de
la vente xy mais pas de la date tout court.
Patterns danalyse
Une deuxime approche (autre que lanalyse linguistique) consiste mettre en oeuvre des
modles danalyse (patterns) que lon trouvera dcrits dans des ouvrages spcialiss
comme par exemple Analysis patterns de Martin Fowler ou encore Data model Pat-
terns de D. Hay.
Lexprience..
Une troisime approche consiste se baser sur sa propre exprience..
Blague mise part, voici un tableau qui contient un certain nombre de catgories couran-
tes de classes conceptuelles que lon retrouve de manire habituelle.
A titre dillustration, le domaine des ventes et celui de la rservation arienne.
Classes conceptuelles Par exemple
Objets physiques Avion, Place, Registre
Lieux Aroport, Enregistrement
Rle de personne Secrtaire, Htesse, Pilote
Conteneurs Entrept, Armoire, Catalogues
Transaction Rservation, Vente, Paiement
Evnement Annulation, Vente, Retard
Organisation Dpartement, Impts
Systme informatique externe Contrleur de taxe, Contrleur de
trafic
Concept (abstrait) PeurDuVide
Processus Inventaire, Rservation
Document Contrat, Billet, Devis, Autorisation
8.4 HEURISTIQUE: LISTE DES ASSOCIATIONS COURANTES
Comme pour lidentification des classes conceptuelles, on peut se baser sur lanalyse lin-
guistique (voir plus haut: les verbes reprs dans ces descriptions textuelles correspon-
dent gnralement des associations entre les diffrentes classes conceptuelles).
Mais on peut se baser galement sur lexprience en donnant une liste des associations
typiques que lon rencontre en modlisation de domaine.
Nom donn aux associations
Par convention, les associations seront dsignes par un verbe, en commenant par une
majuscule:
Appartient-A
ou AppartientA
8.5 ETUDE DE CAS, LE SYSTME POS
Voici le modle de domaine du systme POS tel quil pourrait tre reprsent
Outils et instruments Calculatrice
Manuels, Descriptions, spcifica-
tions
SpcificationDunProduit, Manuel-
DeRparation
Types dassociations entre deux
classes conceptuelles A & B
Par exemple
A est un lment physique de B Livre>Rayon
A est un lment logique de B Entte>Protocole
A est un membre de B Pilote>Compagnie
A dcrit B DescriptionDeVol>Vol
A communique avec B Caissier>Client
A utilise B Caissier>Registre
A contrle B Pilote>Avion
A est voisin de B VilleA>VilleB
A est un vnement associ B Dpart>Vol, Achat>Client
Classes conceptuelles Par exemple
son dbut (dans une premire analyse).
Figure 27: POS - Modle de domaine initial
Voici maintenant un modle partiel agrment dassociations et dattributs
Figure 28: POS - Modle partiel avec associations & attributs
Store Register Sale
Item
(article)
Payment
Sales
LineItem
Cashier Customer Manager
Product
Catalog
Product
Specification
Register
Item
Store
address
name
Sale
date

time
Payment
amount
Sales
LineItem
quantity
Cashier Customer
Manager
Product
Catalog
Product
Specification
description
price
itemID
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Described-by
*
Records-sale-of
0..1
Started-by
Paid-by
Initiated-by
Logs-
Completed
(TientUnJ ournalDe)
6
*
3 Records-sales-on
1
1
1
1
1
1..*
1
1
1
1
1
1
1
1
1
1 1
1
Gnie logiciel - 103 - XP & Les mthodes agiles
9 XP & Les mthodes agiles
Les mthodologies agiles, issues de lindustrie, font leur premire apparition dans les an-
nes 90. Depuis 2000, on note une grande diffusion dans les entreprises.
La caractristique premire de ces mthodes - parmi lesquelles on peut citer XP
(EXtreme Programming), Scrum, Feature Driven Development, ASD,DSDM est dtre
orientes vers lhumain (le client), et dtre dote dune nature hautement adaptative
9.1 UN PETIT HISTORIQUE
Nous sommes partis de loin.
A lorigine: lanarchie. Les dveloppements informatiques taient une activit chaotique;
on codait et on dboguait (est-ce toujours le cas?). En rponse sont apparues les mtho-
dologies que lon qualifie aujourdhui de mthodes lourdes: dveloppement en cas-
cade, le cycle en V, etc..
Le rapport Chaos 003 montre toutefois que le taux dchec des projets informatiques
est rest important.
Figure 29: Taux dchecs des projets informatiques - Rapport Chaos 003
Les raisons de cet chec?
Les promoteurs des mthodes agiles avancent quelques critiques.
La lourdeur
Il y a tellement de travail fournir pour suivre la mthodologie que l'avancement
du dveloppement est trs lent dans son ensemble. Ainsi, on dit souvent de ces
mthodologies qu'elles sont bureaucratiques.
Et bien souvent elles ne sont pas populaires.
D'o leur appellation: mthodologies lourdes, voire mme mthodologies
monumentales.
Des lacunes
Certains facteurs ont un impact trs important sur les chances de russite des pro-
jets, et ne sont pas assez pris en compte, comme notamment:
Les changements dexigences;
Linflation des fonctionnalits.
Notons que lobjectif de cette approche tait louable: le client veut des garanties sur ce
quil obtiendra en fin de projet, et le chef de projet souhaite disposer des informations
ncessaires lorganisation de son quipe. Le souhait est dobtenir un cahier des char-
ges entirement spcifi au terme de la phase danalyse.
Les mthodes agiles sappuient sur le Software Manifesto de 2001
Ds le dbut des annes 1990, en prenant le contre-pied des mthodes dites lourdes, di-
verses mthodologies plus et souples et plus lgres (dites agiles) sont mises en oeuvre
avec succs dans de nombreuses entreprises. Les reprsentants de ces diffrentes mtho-
53%
33%
46%
49%
51%
16%
27%
26%
28%
34%
15% 23% 28%
40% 31%
1994 1998 2000 2004 2002
Succs
Dlivr
Dlais et cots
non respects
Echec
dologies sont convis un sminaire de deux jours Snowbird Utah en Fvrier 2001. Il
en rsulte lAlliance Agile et le Software Manifesto de 2001 dont les principes fon-
damentaux sont dcrits ci-aprs.
9.2 QUELQUES PRINCIPES FONDAMENTAUX DU SOFTWARE
MANIFESTO DE 2001
Individuals and interaction over processes and tools
Les mthodes agiles sont orientes vers l'humain, plutt que vers le processus.
Elles s'efforcent explicitement de travailler avec la nature de l'homme plutt que
contre elle, et de souligner que le dveloppement informatique devrait tre une
activit agrable
L'un des objectifs des mthodologies traditionnelles est de dvelopper un processus dans
lequel les personnes sont remplaables.
Dans cete optique, les personnes sont traites comme des ressources disponibles sous
diffrents modles. On aura un analyste, des codeurs, des testeurs, un manager, etc..
Toujours dans cette optique, ce sont les rles qui sont importants, pas les individus.
Ainsi, lors de la planification d'un projet, on se concentre sur le nombre et le type des res-
sources, en apprhendant les dveloppeurs la manire dunits de programmation
plug-and-play.
A linverse, dans lesprit des mthodes agiles, on considre que le travail de dveloppe-
ment est une entreprise hautement crative et professionnelle: tout leffort est dans le
design et cela demande du personnel cratif et talentueux. Lindividu compte avant tout
et sa motivation est un facteur primordial la russite des projets.
Comment motiver les dveloppeurs?
Par une participation la dfinition du processus de dveloppement
Souvent les processus de dveloppement logiciel sont imposs par la direction.
En tant que tels, ils sont souvent mal accepts, surtout que la direction s'est sou-
vent carte de manire significative du dveloppement. Les mthodes agiles pr-
conisent une implication relle de tous les membres de lquipe au processus de
dveloppement. Ce dernier ne doit pas tre rigide, son caractre adaptatif est mis
en avant.
Par une implication des dveloppeurs plusieurs niveaux
Les mthodes agiles prconisent un implication des dveloppeurs tous les
niveaux: au codage bien sr, mais aussi la conception comme la planification.
Notamment, XP considre que seuls les dveloppeurs sont mme destimer le
temps qui leur sera ncessaire pour excuter une tche.
En donnant une place quivalente au dveloppement et au management
Les connaissances techniques deviennent obsoltes aprs quelques annes. Les
gestionnaires - ex-dveloppeurs en gnral - doivent donc reconnatre que leurs
comptences techniques vont rapidement disparatre et qu'ils doivent se reposer
sur d'autres dveloppeurs plus au courant des nouveauts.
Pour rpondre ce constat, les mthodes agiles prconisent de revaloriser la fonc-
tion des programmeurs en partageant les responsabilits et en proposant de don-
ner aux dveloppeurs et la direction une place quivalente dans la gestion du
projet.
Working software over comprehensive documentation
Sur plusieurs aspects les mthodes agiles sont plutt orientes code: en suivant
la voie selon laquelle l'lment clef de la documentation est le code. La diffrence
la plus immdiate est qu'elles sont moins orientes paperasse, voquant gnrale-
ment une quantit moindre de documentation pour une tche donne
Responding to change over following a plan
Les mthodes agiles sont adaptatives plutt que prdictives. Les mthodes lour-
des tendent planifier de grosses parts du processus logiciel en dtail pendant
une dure importante, ce qui fonctionne correctement tant qu'il n'y a pas de chan-
gements. Donc leur nature est de rsister au changement. Les mthodes agiles,
par contre, s'accommodent favorablement du changement. Elles s'efforcent d'tre
des processus qui s'adaptent au changement. Elles s'panouissent dans le change-
ment, au point de se changer elles-mmes
Les crateurs dXP ont dcouvert que certaines pratiques dorganisation dquipe et de
programmation permettent de rendre le logiciel plus souple, et tel point quil devien-
drait plus avantageux de le faire voluer progressivement que de chercher le spcifier
et le concevoir compltement ds le dpart.
Grer les changements
Car tout ne peut que changer.. ne serait-ce quau regard de la loi de Murphy
1
:
Une chose est toujours plus complique quelle nen a lair
Tout prend plus de temps quon ne le pense
Tout ce qui peut aller mal ira mal
Pour grer les changements, on peut sappuyer sur la gestion des configurations (CVS
par exemple), en utilisant des outils permettant principalement darchiver les artifacts et
den contrler laccs.
Par exemple, il est possible de sappuyer sur les produits suivants:
1. CVS pour contrler les diffrentes versions des artefacts et leur accs
2. Ant pour grer la construction, en association avec JUnit pour les tests.
3. Bugzilla pour la gestion des requtes de changement et rapports dincidents.
Ladaptabilit du processus de dveloppement
Ladaptation concerne au premier chef la facult tenir compte des changements des be-
soins des utilisateurs.
Mais il faut tenir compte galement de changements dans le processus mme de dvelop-
pement. Plus le temps avance, plus l'quipe va dcouvrir ce qui fonctionne pour elle et le
processus sera modifi en consquence.
Par exemple, on peut se poser les questions suivantes au terme de chaque itration:
qu'est-ce que lon a russi? qu'est-ce que lon a appris? qu'est-ce que lon peut amliorer?
Une consquence de cette approche est que lon ne doit pas sattendre trouver une
mthodologie unique au sein dune entreprise.
Du point de vue motivation, remarquons quil est constat que la plus part des bons
dveloppeurs prfrent un processus adaptatif.
9.3 MTHODES AGILES: PRINCIPES CLEF
Dfinition 28: Quest-ce quune mthode agile? Principes-clef
Les mthodes de dveloppement de type Agile:
suivent un mode de dveloppement itratif et incrmental,
1. La Loi de l'Emmerdement Maximum (LEM), constitue des principes les plus pessimistes qui soient. On peut
aller jusqu dire qu'il s'agit du pessimisme rig en loi..
une planification de projet volutive,
encouragent les livraisons frquentes au client (releases),
proposent des pratiques qui encouragent l'agilit (souplesse dadaptation) et la
rponse rapide aux changements.
Dveloppements itratifs et incrmentaux
Les mthodes agiles sont orientes client en proposant des dveloppements itratifs
et incrmentaux en ayant pour but:
Implication et collaboration du client
On part du constat que le client ne connat pas bien ses besoins et que les exigen-
ces poses au dpart ne sont pas stables. La solution consiste impliquer le client
non seulement au dbut, mais tout au long du projet, chaque itration, en lui
demandant un feed-back permanent. On souhaite si possible que le client soit pr-
sent sur le site.
Volont dadaptation rapide
Cycles de dveloppement courts et livraisons frquentes (2 4 semaines en gn-
ral)
Autres concepts fondamentaux Agile
La plupart des mthodes Agile mettent laccent sur:
Une conception la plus simple possible
Une conception volutive avec mise en oeuvre du refactoring (remaniement de
code)
Programmation en binme
Programmation pilote par les tests
Un ct moins bureaucratique
Moins orientes paperasse
Plus orientes code
9.4 SUR QUELS TYPES DE PROJETS UTILISER UNE MTHODE
AGILE?
Le choix dune mthode de dveloppement est une entreprise hautement risque.
Voici quelques facteurs prendre en compte lors du choix dune mthode agile au profit
dune mthode traditionnelle.
Petite quipe (10-15)
lquipe doit tre compose dune majorit de seniors,
qui matrisent la gestion de projet,
qui sont responsables et motivs.
Les processus adaptatifs s'appuient sur une relation de confiance avec les dve-
loppeurs. Si on considre qu'ils sont mauvais ou peu motivs, il est alors prfra-
ble dutiliser une approche prdictive.
Au del dune quipe compose dune cinquantaine de personnes (exprience
avec Crystal), il n'y a pas d'exemple dutilisation de mthode agile. Il ny a donc
pas de preuve pour quune telle approche puisse fonctionner au del dune telle
taille.
Exigences floues et variables
L'approche adaptative est particulirement bien adapte quand les besoins sont
incertains ou volatiles. Dans ces conditions, les approches traditionnelles sont
reconnues comme trs risques.
Client disponible
Et si possible quil soit toujours prsent sur le site de dveloppement.
Sinon, un processus plus formalis - comme cest le cas avec les mthodes tradi-
tionnelles - peut tre conseill.
Client partie prenante
Le client doit jouer le jeu du concept agile: planification rvise de manire per-
manente, participation la planification, donner son feed-back en permanence,
etc.
Sinon, comme ci-dessus, un processus plus formalis peut tre conseill.
Donc, attention: Agile ne sapplique pas TOUS les TYPES de PROJ ETS !!!
Agile n'est pas mettre entre toutes les mains..
9.5 UP EST-ELLE AGILE?
RUP (Rational Unified Process) a t dvelopp par Philippe Kruchten et Ivar J acobson
de Rational. Il sagit du complment mthode dUML.
Les membres de lquipe RUP sont de fermes dfenseurs du dveloppement itratif.
Toutefois, RUP est dabord un framework (une plate-forme de dveloppement) et, en
tant que framework, RUP peut saccommoder dune varit de processus: il peut tre uti-
lis de la manire agile, comme il peut ltre de manire traditionnelle en cascade..
RUP sappuie sur la mthode UP.
Dans le cadre de ce cours, la mthode UP a t prsente en suivant les prceptes de Craig
Larman qui incite utiliser UP dans sa forme agile, cest--dire lgre. Par exemple, Craig
Larmann recommande de passer les trois premiers jours de chaque itration avec la tota-
lit de l'quipe en utilisant UML pour dfinir les grandes lignes du travail faire durant
l'itration. Craig Larmann prconise galement dopter pour la programmation en bin-
me.
Toutefois, par son ct trs formel, UP nest pas considre comme faisant partie du cer-
cle des mthodes agiles. A la limite, on dira que UP est une mthode semi-agile.
Le ct formel de UP se retrouvera notamment:
dans la description prcise des artefacts qui devront tre labors par les dve-
loppeurs
dans le rle assez rigide jou par les membres de lquipe de dveloppement
par un dcoupage en 4 phases (initialisation, laboration, construction et transi-
tion) dont les objectifs sont trs prcis.
9.5.1 Principes & fondements de UP en comparaison avec XP
UP sappuie sur 3 fondements dont les deux premiers se retrouvent dans la mthode agile
XP (exTreme Programming):
pilot par les cas dutilisation
itratif et incrmental
centr sur larchitecture
UP est pilot par les cas dutilisation
Prvu initiallement pour rassembler les besoins fonctionnels des utilisateurs, les cas duti-
lisation servent dinput - de donne premire - aux diffrentes activits du processus de
dveloppement. Ces cas dutilisation sont:
rcolts (phases dinitialisation et dlaboration),
repris et spcifis pendant la phase danalyse (phase dlaboration),
mis en oeuvre pendant la phase de conception (phase de construction),
implments par les dveloppeurs (phase de construction),
contrls par les scnarios de tests (phase de construction).
Le pilotage par les cas dutilisation est galement lapanage de XP . En cela, UP sinscrit
tout fait dans le cadre des mthodes agiles.
Compare XP, on notera toutefois deux diffrences de taille:
XP est beaucoup moins formel (les scnarios sont par exemple limits 5 lignes),
XP ne connat pas de phase et implique le client trs fortement: ce dernier est res-
ponsable de lcriture des scnarios et de la planification des livraisons (en
allouant une priorit chaque scnario). Le client est responsable galement de la
spcification des tests fonctionnels. La spcification dtaille est ralise en colla-
boration avec les dveloppeurs, elle nest pas mis en oeuvre au sein dune phase
spcifique, mais opre le moment venue, au sein de litration qui ralisera le
scnario concern.
Itratif et incrmental
Cette caractristique entre tout fait dans loptique des mthodes agiles.
UP est centr sur larchitecture
Par architecture, nous entendons la structure du systme.
Les mthodes agiles - notamment XP - prconisent dlaborer en premier lieu une archi-
tecture la plus simple qui soit, qui rponde aux besoins de la premire itration, puis de la
revoir au fil du temps et des itrations. Lquipe XP doit tre capable de faire merger la
conception tout au long du dveloppement pour suivre les directions donnes par le
client.
Pour minimiser les risques dchecs, UP prconise par contre de spcifier les principaux
lments de larchitecture pendant la phase dite dlaboration.
Cest pourquoi on dit que UP est centr sur larchitecture, car la mise en oeuvre de
cette dernire fait partie intgrante du processus de dveloppement.
Notons toutefois quil ne sagit pas de la dcrire compltement, cette dernire sera raffi-
ne au cours des diffrentes itrations. Il sagit den dfinir larmature, que lon appelle
encorelarchitecture de rfrence.
De manire gnrale, larchitecture est constitue de deux couches: la couche infras-
tructure, qui est souvent indpendante de la partie mtier, et qui est le produit direct de
la culture de lentreprise et de ses comptences; et la couche mtier. Notons que la cou-
che infrastructure dpend tout de mme de certains facteurs propres lapplicatif comme
les contraintes de performances, etc..
Larchitecture de rfrence comprend donc la couche infrastructure et une partie de la
couche mtier, constitue trs souvent par les cas dutilisation les plus importants du
point de vue de la gestion des risques:
1. les plus importants du point de vue du client
2. ceux qui prsentent le plus de risques du point de vue du dveloppement
Lobjectif de la mthode UP est de mettre en oeuvre une architecture de rfrence qui
soit stable au terme de la phase dlaboration. Mais, elle sera peut-tre affine au fur et
mesure des itrations.
Larchitecture mme de lapplication, qui sappuie sue cette architecture de rfrence,
sera mise en oeuvre au fur et mesure des itrations.
9.6 XP (EXTREME PROGRAMMING)
Cest grce au talent publicitaire de Kent Beck, lun des fondateurs de XP, que cette m-
thode est devenue si populaire. On peut parfois regretter le succs de cette mthode, les
autres mthodologies agiles et leurs bonnes ides sont sans aucun doute occultes par XP.
Origine: fruit de la collaboration entre Kent Beck et Ward Cunningham dans les annes
80-90. Ces derniers redfinissent leur manire de travailler en sappuyant sur de nom-
breux projets en basant leur approche sur un dveloppement logiciel qui soit adaptatif et
oriente vers l'individu.
Les premiers succs de XP: un projet chez Chrysler en train de capoter.. Kent Beck, res-
ponsable de laudit de ce projet prconise de jeter le tout et de recommencer partir de
zro. Le projet, connu sous le nom de projet C3, est redmarr sous sa direction et con-
nat un grand succs.
Traits caractristiques de XP
XP est un regroupement cohrent de bonnes pratiques de dveloppement visant
amliorer la qualit des produits, la satisfaction des clients mais aussi celle des
dveloppeurs.
Moins structur et document que UP, sappuie en revanche sur des concepts
pragmatiques et efficaces.
Prvu plutt pour des quipes de taille moyenne (10 pers. maximum), peut nan-
moins tre applique des gros projets, mais condition dune proximit des
membres de lquipe.
Le client pilote lui-mme le projet: il choisit les fonctionnalits implmenter au
sein de chacune des itrations.
Lquipe livre trs tt une premire version du logiciel, puis les itrations
senchanent un rythme soutenu (typiquement deux semaines). On obtient ainsi
un feedback permanent de utilisateurs et on rduit ainsi grandement les risques.
Litration sy applique de manire plus stricte que sous UP: toutes les itrations
sont identiques et ralisent lensemble des tches habituellement associes un
projet informatique:
Rvision de la planification globale
Planification de litration
Analyse, conception, programmation, tests unitaires, intgration et tests
fonctionnels

Dans UP, la nature mme des itrations peut changer dune phase lautre:
En phase dlaboration: essentiellement Analyse, Conception puis Planifi-
cation
En phase de construction: essentiellement Conception, Programmation et
Tests
Dans XP, lanalyse et la conception ne sont jamais spares de limplmentation.
Le but tant de se prmunir des risques: on analyse puis on ralise le plus rapid-
ment possible dans le but dobtenir un feedback immdiat du client.
Sous XP, on prvoit toujours le pire (loi de Murphy):
que le client change davis sans arrt
que les spcifications ne sont jamais bien comprises par les dveloppeurs
(do le besoin davoir le client ct)
que lquipe aura des problmes (dmissions, ..)
XP met laccent sur la production du projet. La rdaction de documents danalyse
et de conception sont des tches annexes. La meilleure documentation est celle du
code source! La production de documents UML est une duplication de la mme
information - et il faut en plus sassurer de leur mise jour! mais notons ce sujet
que les outils de reverse engineering assurent cette mise jour, tout tant que cela
se limitera aux modles de conception dtaille proches du code -.
Amlioration en continu de la structure du logiciel (principe du refactoring)
Autogestion: lquipe sorganise elle-mme en favorisant une collaboration maxi-
male entre ses membres.
XP est une mthode extrme
Les boutons sont tourns au maximum.
Les nouvelles pratiques (nouvelles par rapport aux mthodes traditionnelles)
sont pousses lextrme, comme lide, pour amliorer la communication avec
le client, de lavoir sur le site.
9.7 VALEURS DE XP
XP sappuie sur 4 valeurs essentielles: la communication, le retour d'information, la sim-
plicit, et le courage.
La communication pour une meilleure visibilit
Notamment:
Utilisation extrme de la communication directe (orale, e-mail), du contact
humain.
Rsolution collective des problmes.
Cela entrane par contre des problmes de structuration et de traabilit.
La simplicit comme garantie de productivit
Code dbarrass de toute complexit superflue, par exemple de mcanismes de
gnricit pour un besoin futur imaginaire. On ne construit pas le logiciel en
tenant compte dvolutions futures hypothtiques.
faire la chose la plus simple qui puisse marcher
tu nen nauras pas besoin, YAGNI You Aint Gonna Need It
Simple nest pas simpliste!
Le code doit tre crit de la manire la plus lisible et la plus pure qui soit. Il sera
revu et amlior en permanence pour aller dans ce sens. Cette manire doprer
offre la garantie dun code susceptible dvoluer facilement.
Par exemple, toute redondance de code est proscrite: tout fragment de code sera
crit une seule fois et une seule (Once & only once).
Lapplication doit par contre rester assez simple pour re susceptible dvoluer
facilement
Le feedback pour rduire le risque
Risque soigneusement contrl par des boucles de feedback avec le client pour
connatre ltat rel du projet
Livraisons frquentes permettent de connatre ltat davancement et damliorer
la planification elle-mme
Le feedback est un facteur de qualit mais aussi de vitesse car il permet de sassu-
rer que le projet reste sur la bonne voie et de ragir suffisamment vite
Le courage de prendre les bonnes dcisions
Courage de dmarrer un projet sans spcification ni conception dtailles
Courage de maintenir la transparence de communication et de feedback en cas de
mauvaises nouvelles
Courage de jeter du code inutile ou trop complexe
9.8 LES PRATIQUES ESSENTIELLES DE XP
XP assemble une douzaine de pratiques qui, sans tre rvolutionnaires en soi, sont rassem-
bles de manire synergique: chaque pratique est renforce par les autres. Citons notam-
ment, parmi les principaux lments dXP:
Cycles itratifs pilots par le client
Itrations trs courtes, dont le contenu est fix par le client.
Programmation pilote par les tests
Le test au cur du dveloppement. Chaque dveloppeur crit les tests en mme
temps qu'il crit le code source. Les tests sont intgrs dans un processus de com-
pilation et d'intgration continue. Ainsi, les dveloppements futurs prennent place
sur une plate-forme stabilise.
Un processus de design volutif sappuyant sur le refactoring
Par refactoring, on entend la remise en cause continuelle de l'architecture du
systme de base chaque itration. Tout le design est concentr sur l'itration en
cours avec aucune anticipation pour des besoins futurs. Le rsultat est un proces-
sus de design qui combine discipline et adaptabilit.
Travail dquipe auto-organis
Les dveloppeurs organisent eux-mmes leur travail, interviennent sur lensemble
du code, travaillent systmatiquement en binmes, et synchronisent leurs dve-
loppements plusieurs fois par jour.
9.8.1 Les 12 pratiques de XP
Sont nonces ci-dessous les 12 pratiques de XP.
Pour assurer un feed-back permanent
P1: Dveloppement pilot par les tests
P2: Planification itrative
P3: Client sur site
Pour un processus fluide et continu
P4: Programmation en binme
P5: Intgration continue
P6: Remaniement de code (refactoring)
P7: Livraisons frquentes
Partage de la comprhension
P8: Conception simple
P9: Usage de la mtaphore
P10: Responsabilit collective du code
P11: Conventions de codage
Assurer le bien-tre des programmeurs
P12: Rythme durable
P1: Dveloppement pilot par les tests
La production de tout artefact XP doit tre associ un test.
Pour une spcification ou un scnario client: il sagira dun test fonctionnel (test
de recette).
Pour un fragment de code, il sagira dun test unitaire.
Tests de recette (tests fonctionnels)
Spcifis par le client, ce qui leur confre un ct objectif
Pour valider les fonctionnalits de lapplication (aussi appels tests daccepta-
tion).
Permettent en outre de contrler la non rgression du systme au fil de lavance-
ment.
Excuts le plus souvent possible (p.e. chaque jour) pour permettre au client de
suivre lvolution du projet, et si possible de manire automatique.
Sont mesurables: on parle de pourcentage de tests passs avec succs.
Cette mesure montre le degr davancement du projet.
Forme dun test de recette
Les tests de recette peuvent prendre plusieurs formes, notamment:
Il peut sagir de jeux de donnes (feuilles de tableur, fichiers XML, ..) qui dfinis-
sent une transformation effectue par le logiciel: pour une entre, une sortie bien
dfinie.
Il peut sagir de scripts quand il sagit de tester des squences dinteractions avec
lutilisateur.
Tests de recette et spcifications XP
Dans un projet XP, les tests de recette reprsentent les spcifications dtailles!
Ces spcifications seront toujours en phase avec le dveloppement
Dans un contexte pur XP il sagit des seules spcifications: il ny aura pas de
document proprement parler!
Toutefois, en pratique, des documents sont souvent exigs. Le client y participe
pour une large part.
Tests unitaires
Spcifis par les dveloppeurs, avant dcrire le code.
Utiliser par exemple le framework J Unit pour crire les tests unitaires.
Pour valider chaque fragment de code et contrler la non rgression du systme
au fil des remaniements.
A excuter rgulirement et si possible de manire automatique.
Rfrences
Existence de bibliothque de test: J Unit (www.junit.org)
http://www.xprogramming.com
Exemple dutilisation de JUnit
i mpor t j uni t . f r amewor k. *;
publ i c cl ass Test Vect or ext ends Test Case {
publ i c Test Vect or ( St r i ng name) {
super ( name) ;
}
publ i c voi d testAddEl ement ( ) {
// Mise en place
Vect or v = new Vect or ( ) ;
// Appels des mthodes
v. addEl ement ( " Une chai ne" ) ;
v. addEl ement ( " Une aut r e chai ne" ) ;
// Assertion
asser t Equal s( 2, v. si ze( ) ) ;
}
}
P2: Le Planning game - Planification itrative
La planification est vcue comme un jeu..
Quand s'excute le jeu?
Avant la premire itration: phases dites dexploration et dengagement
Il en rsultera un plan de livraison, savoir une planification initiale des diffren-
tes itrations avec une rpartition des diffrentes fonctionnalits implmenter
pour chaque itration.
Au dbut de chaque itration:
pour contrler le degr davancement du projet et revoir ventuellement le
plan de livraison.
pour planifier les tches de litration en cours.
.
Itrations de dveloppement
(2 4 semaines chacune)
Jeu de planification
Livraison
Les lments constitutifs du jeu
1. Le but du jeu: implmenter un maximum des fonctionnalits dsires par le client
2. Les joueurs (les dveloppeurs)
3. Les pices du jeu: scnarios utilisateurs (user stories)
User stories (scnarios)
Les scnarios seront crits sur des fiches de papier qui auront lallure suivante:
Le code pour identifier le scnario de manire unique
Le titre qui exprime le contexte et lobjectif du scnario
La priorit de ralisation (3 4 niveaux prvus)
La charge de ralisation, estime par les dveloppeurs, exprime en points.
Lusage de points en lieu et place dunits de temps permet daffiner lvaluation
des charges au fil des itrations (voir plus loin la vlocit).
En principe, un scnario doit pouvoir tre implment compltement en une itra-
tion. Un scnario trop complexe sera dcompos en plusieurs scnarios. Des sc-
narios trop courts peuvent tre regroups.
La description mme du scnario exprime en quelques lignes: pas plus de 4 5
phrases en principe.
Stricte rpartition des tches
Lestimation de la charge est place sous la responsabilit des dveloppeurs;
Titre, priorit et description sont spcifis et rdigs par le client. Ce dernier peut
tre assist par le coach car il nest pas vident sans une certaine pratique
dexprimer des besoins sous une forme aussi concise.
Code Titre
Priorit
Charge
Description
Fiche au
format A5
Papier bristol
Un jeu en 3 phases
Phase 1: phase d'exploration
Dbutant avant la premire itration de dveloppement, assez courte (un mois maximum).
Cette phase se droule comme suit:
1. Dfinition du contenu fonctionnel de lapplication
Le client (reprsentant des utilisateurs) explore et dfinit les scnarios quil sou-
haite voir implments par lapplicatif.
2. Estimation de la charge de travail
Les dveloppeurs analysent les scnarios dans le but d'estimer la charge de travail
correspondante. Cette charge est exprime en points (voir plus loin).
Les dveloppeurs peuvent raliser un spike, exprimentation de courte dure,
en pique, permettant d'valuer de manire plus prcise la charge de travail asso-
cie aux scnarios.
3. Lquipe transmet au client une estimation de sa vlocit
Cest--dire du nombre de points de scnarios que lquipe estime pouvoir raliser
en une itration (voir plus loin le concept de vlocit).
Phase 2: phase d'engagement
Le client tablit le plan de livraison
Il sagit dun plan de dveloppement qui affecte les diffrents scnarios aux itrations
venir. Le nombre de points raliss chaque itration doit correspondre la vlocit an-
nonce par les dveloppeurs.
Lensemble des scnarios qui seront raliss constitue ce quon appelle le primtre
fonctionnel de lapplicatif.
Phase 3: phase de pilotage
Cette phase commence avec la premire itration de dveloppement. Elle est active prin-
cipalement au dbut de chaque itration de dveloppement o il sagit notamment:
de contrler le degr davancement du projet et revoir ventuellement le plan de
livraison
doprer la planification des tches pour litration en cours.
Chaque itration commence par une runion de planification ditration:
1. Le client, les dveloppeurs et les testeurs se runissent
2. Mise au point sur litration passe et rvision ventuelle du plan de livraison
3. Le client dcrit les scnarios implmenter au cours de litration qui commence
4. Lquipe discute les scnarios:
Analyse: les besoins sont analyss un niveau de dtail plus fin
Conception: les dveloppeurs envisagent des solutions techniques
5. Les dveloppeurs dressent la liste des tches accomplir (travail collectif)
6. Les dveloppeurs se rpartissent eux-mmes leurs tches accomplir pendant
litration
Organisation des tches, qui dcide?
XP prconise une espce dautogestion: lquipe sorganise elle-mme en favorisant une
collaboration maximale entre ses membres.
Stand-up meetings
Chaque jour, toute lquipe se runit pour un stand-up meeting dune quinzaine de mi-
nutes, o les participants se tiennent debout pour viter que cela dure trop longtemps.
Il sagit dorganiser le travail de la journe et de faire le point sur lavancement de lit-
ration en cours.
Vlocit, contrle de lefficacit et suivi du projet
Les charges des scnarios sont exprimes en points, ou chaque point correspond gnra-
lement un jour de travail idal, cest--dire sans interruption de toute sorte, multipli par
un facteur de 2 ou 3 pour tenir compte justement des charges additionnelles difficilement
prvisibles.
Plan de livraison
Plan de l'itration 2
Ensemble de scnarios
Scnario
+
Scnario non
implment
Nouveaux scnarios identifis
au cours des itrations
Scnario non
implment
+
+
Ainsi, pour charge prvue de 2 points (2 jours dans lesprit du dveloppeur), on peut pr-
voir que 4 6 jours seront ncessaires.
La vlocit mesure la capacit de dveloppement de lquipe. Elle mesure le nombre de
points quune quipe est capable de raliser en une itration.Ce nombre de points corres-
pondant au total des scnarios raliss 100% par lquipe pendant litration.
Utilisation du concept de vlocit
La vlocit apporte une aide essentielle la planification, au pilotage des itrations et au
suivi du projet.
Lors de la phase de planification: la charge confie une itration (en termes de
scnarios raliss 100%) ne devra pas excder la vlocit de lquipe.
Pour avancer une estimation raliste des dlais de livraison.
Permet de mesurer et de constater des variations de performances de lquipe,
den analyser la cause (client en vacances, problmes de logistique, etc.) et de ra-
gir assez vite.
Ne permet pas de comparer deux projets avec des quipes et des clients diffrents!
P3: Client sur le site
Cest un souhait prcisons-le, souvent difficile raliser.
Les bnfices sont les suivants, ils conduisent de manire gnrale une acclration du
processus de dveloppement:
le client a une meilleure visibilit sur lavancement du projet
toute modification de planification (remise en question des priorits) peut tre
traite sans dlai
la documentation de spcification est notablement allge: ces documents nont
plus besoin dtre compris par les dveloppeurs en labsence des clients
Le client reprsente les utilisateurs. Pour garantir la fluidit du processus de dvelop-
pement, ce dernier doit disposer dune certaine autonomie et dun grand pouvoir dci-
sionnel. La capacit de pouvoir prendre lui-mme la majorit des dcisions.
P4: Programmation en binme
Chaque dveloppeur est associ un binme: un seul poste de travail pour deux person-
nes.
Les bnfices:
contrle mutuel des dveloppeurs (moins derreurs)
meilleure concentration
meilleure circulation de la connaissance, grce des recompositions frquentes
des binmes (les binmes changent typiquement tous les jours). Ainsi, un dve-
loppeur ne devient plus indispensable au projet.
formation facilite (en associant un dveloppeur dbutant avec un confirm)
Il est possible que ce concept saccompagne dune perte de productivit. Toutefois, les
promoteurs de XP considrent que le gain en qualit du code produit compense large-
ment cette perte de productivit ventuelle.
P5: Intgration continue
Le but est dentraner une diminution progressive des risques. Dans le modle en cascade,
les risques sont trs levs tant que la phase dintgration na pas commenc.
XP prconise que lintgration des nouveaux lments de code soit ralise plusieurs fois
par itration, voire plusieurs fois par jour, avec une validation opre par lexcution de
tests. Notamment, ds quun binme finit une tche, la version dintgration est mise
jour en sassurant que tous les tests de non rgression de lapplication passent 100%.
Pour faciliter ce travail dintgration, XP prconise lutilisation de gestionnaires de ver-
sions de type CVS (Concurrent Version System) permettant facilement de fusionner les
lments.
P6: Refactoring: remaniement de code
Cycle de codage eXtreme
Ecrire un test
Compiler le test et lexcuter, il doit chouer
Poste
de travail
Poste
de travail
Poste
de travail
Poste
de travail
Poste
de travail
Poste
de travail
Bureaux du coach
et du client
Postes de dveloppement
en binmes
Implmenter le strict ncessaire pour raliser le scnario et pour russir le test
Refactoriser pour amliorer la clart et diminuer la duplication de code
Le remaniement de code (refactoring)
Il sagit damliorer la conception du code sans modifier son comportement externe.
En regardant un classe, on peut sentir les rorganisations possibles (Rfrence: http://
www.refactoring.com)
Classes trop grandes
Mthodes trop grandes
Switch ( la place du polymorphisme)
Classe de structure (get/set sans mthodes)
Code dupliqu
Commentaires inutiles
On peut aussi sappuyer sur les fameux design patterns - voir labondante littrature
ce sujet -. Une fois quune fonction est ralise, se poser la question de savoir si la struc-
ture mise en oeuvre ne se rapprocherait pas dun design pattern connu, et si oui, revoir
son architecture en consquence.
Quant arrter le remaniement?
On arrte la remaniement quand le programme:
Na pas de duplication
Possde un minimum de classes et de mthodes
Leitmotivs
==>Once and Only Once (pas de duplication)
==>DRY: Dont Repeat Yourself
Outils de refactoring
A titre dillustration, IDEALJ est un outil de dveloppement qui automatise plus dune
vingtaine de refactorings.
Il ne sagit pas dune application automatique de rgles de remaniement, mais plutt
dune assistance au reformatage de code.
Voici quelques fonctions de remaniement offertes aujourdhui par de nombreux environ-
nements de dveloppement, comme Visual .Net notamment:
copie dune classe,
modification du nom dune classe avec mise jour automatique de toutes les rf-
rences dans le code,
ajout daccesseurs sur les variables dinstances (get & set),
extraction de mthode
Depuis une mthode, extraire une portion de code qui serait rutilisable dans une
autre mthode pour en faire une mthode elle toute seule.
P7: Courtes itrations de livraison
Lquipe livre trs tt une premire version du logiciel, puis les itrations senchanent
un rythme soutenu. On obtient ainsi un feedback permanent de utilisateurs et on rduit
ainsi grandement les risques.
La vie dune itration
Une itration dure typiquement deux semaines.
Premier jour: runion de planification
Dcision prise entre dveloppeurs et client pour dterminer quels scnarios
seront implments
Etablissement de la liste des tche effectuer pendant litration
Partage des tches au sein de lquipe
J ours suivants: implmentation
Lquipe de dveloppement sorganise elle-mme pour le suivi des tches et
assure elle-mme lanalyse (spcifications dtailles), la conception, le codage et
les tests, sans laide dun analyste ou dun architecte logiciel.
Lquipe se focalise sur limplmentation des fonctionnalits, sans changer de
cap.
Dernier jour: livraison
Nouvelle version (teste) donne au client. Sa structure interne est laisse aussi
propre que possible pour que les prochaines volutions soient le moins coteuses
possible.
P8: Conception simple
Les dveloppeurs amliorent sans cesse la structure du logiciel pour que les volutions y
restent faciles et rapides (principe du refactoring).
Lquipe doit tre capable de faire merger la conception tout au long du dveloppement.
Le code doit tre par ailleurs juste suffisant pour raliser ce quon lui demande de faire.
En loccurrence, il doit tre dbarrass de toute complexit superflue.
L M M J V L M M J V
Runion de
planification
Livraison
P9: Utiliser la mtaphore
Les mtaphores sont des expressions qui dcrivent les acteurs du systme, leurs interac-
tions.
Quelques exemples de mtaphores:
Le bureau pour les interfaces utilisateurs
Ligne de montage pour la gestion de flux de donnes
Caddie lectronique pour le e-commerce
Lannuaire papier pour lannuaire
Un noeud de rseau en TCOM
Le courrier papier pour la messagerie
Pourquoi laborer et sappuyer sur un systme de mtaphores?
Pour mettre en place un vocabulaire commun: lquipe parle des mmes choses
avec les mmes mots.
Pour favoriser la crativit
P10: Responsabilit collective du code
Si un module ne fonctionne pas, personne individuellement ne peut en tre blm.
Personne nest propritaire exclusif dune partie de lapplication, cest lquipe dans son
ensemble qui est responsable du fonctionnement de lapplication.
Le but est dliminer des dpendances entre un dveloppeur et une partie de lapplica-
tion. Ainsi, on prvient les problmes lis aux dparts en vacances, aux dmissions etc.
et cela conduit une trs grande souplesse en matire dorganisation dquipe.
P11: Conventions de codage
Les conventions de codage sont tablies en dbut de projet. Elles permettent dviter une
trop forte htrognit.
P12:Rythme durable: assurer le bien-tre des dveloppeurs
Le modle itratif a pour objectif de diminuer fortement les risques (on opre des livrai-
sons trs tt, et on a trs vite un feed-back du client).
Les risques de bourres de travail sont rduites par la mme occasion. Avec XP: plus
dheures supplmentaires! (selon les promoteurs). En pratique, lquipe adopte la rgle
suivante: pas dheures supplmentaires deux semaines de suite.
Par ailleurs, comme on sait que toute phase de forte activit est toujours suivie par une
diminution de la productivit, le cot global sen trouve amlior. On sait galement que
le stress devient la longue un facteur de dmotivation.
9.9 XP: ORGANISATION DE LQUIPE DE DVELOPPEMENT
XP prvoit les rles suivants:
1. Programmeur
2. Client
3. Testeur
4. Tracker
5. Manager
6. Coach
Pour tre le plus efficace possible, aucun membre de lquipe ne doit droger aux res-
ponsabilits qui lui ont t assignes en suivant les prceptes XP.
Il est possible que la mme personne physique puisse assumer plusieurs rles. Certains
rles sont en effet cumulatifs, mais pas tous.. Pour plus dinformations, se rfrer au
paragraphe relatif aux combinaisons de rles.
Responsabilits des rles XP
Voici un diagramme de cas dutilisation qui rsume les rles des diffrents partenaires XP.
Tracker
Manager
Programmeur
Consultant
Client
Coach
Testeur
.
Planification
Scnarios client
Tests de
recette
Tests unitaires,
code, conception
participe
<<suit>>
s'informe
value
rdige
code
<<conseille,
forme>>
dfinit
participe
participe ou s'informe
participe
dfinit, code
fait passer
Coordonne
Aide
Veille
Le programmeur
Soccupe de lexcution des tests, participe la planification, lanalyse et la
conception en plus de la programmation.
Selon XP, les activits danalyse et de conception ne peuvent pas tre dissocies
du dveloppement sans entraner une surcharge de travail nuisant la productivit
Produit du code clair, structur, simple, utile et non ambigu
Participe la responsabilit collective de lapplication
Programmation en binme (pair programming) sur la mme machine, forme
extrme de relecture de code. Les binmes changent souvent. Chacun finit par
travailler avec tous les autres membres de l'quipe.
Programme proximit du client
Figure 30: La journe du programmeur
Droits du programmeur XP
Savoir ce qui est demand avec priorits clairement exprimes
Fournir un travail de qualit en toute occasion (p.e. avoir le moins de stress possi-
ble)
Standup meeting
(09h00 du matin)
Constitution du binme
Ecrire les tests
Coder
Tester
Amliorer
le code
Intgrer
Fin journe
(17h00)
Demander et recevoir de laide des pairs et clients
Emettre et rviser ses estimations de cots
Bnficier dun rythme de travail durable
Le client
Client sur site! (si possible), ou du moins proximit
Le client intgre le projet sur sa totalit pour en devenir le pilote
A chaque itration, le client:
Choisit les fonctionnalits implmenter
Collabore avec lquipe pour spcifier les besoins en dtail (analyse)
Spcifie les tests de recettes (tests de fonctionnalits) qui seront raliss par
le testeur
Reoit une nouvelle version du logiciel quil peut tester
Choix des fonctionnalits
Les fonctionnalits sont dcrites par des scnarios client (user stories), semblable
au use case UML mais informels ( la main sur fiche A5, 3 phrases).
Le client fixe la priorit donne aux scnarios: lordre dimplmentation des sc-
narios nest pas guid par des contraintes techniques, il est dcid par le client.
Les scnarios seront rpartis entre les diffrentes itrations et au sein des diffren-
tes itrations lors des sances de planification (planning game).
Doit respecter les valeurs XP. Par exemple, recherche de la simplicit, pas de
vitrine technologique !
Droits du client
Bnficier dun plan densemble: ce qui peut tre accompli, pour quand et quel
cot
Obtenir le plus de valeur possible de chaque semaine de programmation
Constater les progrs dune application qui marche partir des tests quil spcifie
Changer davis, ajouter de nouvelles fonctionnalits pour un prix non exorbitant
Annuler tout moment le projet et disposer dune application utile et utilisable
pour son investissement ce jour
Le testeur
Bras droit du client
Met en place les outils et rdige les scripts de test de recette (tests fonctionnels)
spcifis par le client
Tous les tests doivent tre automatiss dans la mesure du possible
Testabilit essentielle. Le testeur peut dconseiller au client une fonctionnalit
difficile tester
Participe la motivation de lquipe en montrant les progrs des tests de recette
Outils possibles:
J Func, une extension de J Uni t pour lcriture de tests fonctionnels
J FCUni t , tests pour des tests sur des interfaces graphiques Swing
Ht t pUni t qui permet des tester des applications interface web
Le tracker
Responsable de la mise en oeuvre des dcisions de planification issues du planing ga-
me. Ces dcisions prcisent notamment le choix des scnarios raliser au sein des dif-
frentes itrations.
Participent au planing game: le client, les programmeurs et le testeur, avec laide du
coach.
Le tracker sinforme simplement des rsultats du planing game et soccupe de les met-
tre en oeuvre:
En dfinissant le plan ditration en dbut ditration en collaboration avec les
dveloppeurs: allocation des tches pour mettre en oeuvre les scnarios raliser.
En assurant le suivi de ces tches (contrle de lavancement)
En rfrant au coach en cas de glissement. Ce dernier envisage les solutions en
concertation avec les programmeurs, avec lancement dune nouvelle phase de
planification si ncessaire.
Le manager
Suprieur hirarchique des programmeurs
Gre les ressources matrielles: responsable de la logistique (espace de travail,
outillage, documentation, etc.)
Gre les ressources humaines
Vrifie que le client est satisfait
Sert dinterface avec lextrieur
Le coach
Rle important, il est le gardien de la mthode, lvanglisateur XP
Met en place la mthode sil sagit dune premire utilisation de XP
Vrifie que chacun joue son rle
Assure le respect des pratiques XP
Bon communicateur doubl dun technicien respect
Anime le standup meeting journalier
Combinaison des rles XP
Au sein dXP, la mme personne physique peut cumuler plusieurs rles. Par exemple, le
Client peut tre cumul au rle de Testeur. Mais cest tout! Un rle de Client ne peut pas
tre cumul un rle de Programmeur.
Voici la liste des cumuls possibles. Se lit: Un rle de Programmeur peut tre cumul
un rle de Testeur ou de Tracker ou de Coach. Les ou peuvent tre exclusifs. Le vri-
fier en tenant compte de toutes les lignes de la liste.
Programmeur Testeur - Tracker - Coach
Client Testeur
Testeur Programmeur - Client
TrackerProgrammeur - Manager - Coach
ManagerTracker
CoachProgrammeur - Tracker
9.10 QUELQUES MTHODES AGILES
Crystal A.Cockburn
Sappuie sur une amlioration continue du processus de dveloppement.
ASD (Adaptative Software Development)
Processus dcoup en 3 phases non linaires: spculation, collaboration et
apprentissage
Scrum (mle de rugby)
insiste sur les mthodes de planification
itrations (sprints) de 1 mois, plus isoles du client quavec XP
DSDM (Dynamic System Development Method)
Mthode supporte par un consortium ralisant guides et manuels
9.11 RFRENCES SUR XP
Martin Fowler ThoughtWorks
Pierre-Yves Decloux RUP & XP
xProgramming.org de Ron J effries,
extremeProgramming.org de Don Wells,
xPloration de Bill Wake,
Robert Martin et sa socit, Object Mentor, fournit beaucoup de documents sur
son site web, y compris une instance XP de RUP appele dX.
Support de cours - 131 - Annexe 1 - Diagrammes de classes - UML 2.0
10Annexe 1 - Diagrammes de
classes - UML 2.0
Les diagrammes de classe constituent le choeur du langage UML. Ces diagrammes
offrent une vue statique du systme, en prsentant les classes et les relations entre ces
classes.
10.1OBJETS, ATTRIBUTS & CLASSES
Dfinition 29: Objet
Un objet (ou instance) est une entit concrte ou abstraite que l'on peut percevoir et
propos duquel on dsire conserver des informations. Un objet a une existence propre et
se justifie en lui-mme, indpendamment des autres informations.
A titre dexemple, voici quelques exemples dobjet tirs du monde rel qui nous
entoure: M. Dupont, la mercedes dArthur, la classe IL2005, l'tudiant Folenfant, ..
Dfinition 30: Attribut
Un objet possde des proprits que l'on appelleattribut.
Un tudiant sera caractris par exemple par 3 attributs: son adresse, son nom et sa date
de naissance. Une voiture pourra tre caractrise par 4 attributs: sa marque, son modle,
son anne de construction et son numro de chssis.
En gnral, on ne s'intresse pas chaque lment individuel, rel ou potentiel, mais on
envisage des classes d'lments qui dfinissent une espce de type.
Dfinition 31: Classe
Une classe dsigne un modle pour des objets perus comme similaires, et ayant les
mmes caractristiques (notamment les mmes attributs).
En outre, du point de vue de limplmentation, une classe peut tre envisage sous langle
dune fabrique objets: il suffira alors dutiliser un oprateur appropri, comme lopra-
teur new en C++ou J ava.
Reprsentation graphique
Une classe est dcrite par un rectangle compos de trois compartiments :
1. le nom de la classe
2. la liste des attributs (proprits)
3. la liste des oprations (voir plus loin)
Les deuxime et le troisime compartiments ne sont pas forcment reprsents.
Figure 31: Reprsentation d'une classe
Nom de la classe
Le nom de la classe est crit en minuscules hormis la premire lettre, crite en majuscule.
Il est gnralement reprsent en utilisant une fonte grasse.
Le nom de la classe est crit au singulier!
10.1.1Attributs
Le nom de l'attribut est crit entirement en minuscules (y compris la premire lettre).
Syntaxe complte dun attribut
vi si bi l i t nom:t ype = val eur Par Df aut {pr opr i t }
Un exemple
- age: i nt = 0 {r eadOnl y}
Visibilit de lattribut
Le langage UML prvoit 4 abrviations, dont la signification peut dpendre du langage
utilis pour limplmentation.
+ public
- private
# protg
~ package
Le type dun attribut
Indiqu de manire optionnelle, le type de lattribut dsignera en gnral l'un ou l'autre
Etudiant
nom
prnom
age
classe
Classe
sigle
filire
degr
Etudiant Classe
ou ou
des types primitifs que l'on rencontre habituellement dans les langages de programmation,
principalement:
i nt , f l oat , char , bool ean;
mais aussi String et les ensemble de valeurs (type numrs).
En phase de conception ou encore dimplmentation, apparatrons des attributs de type
Objet, les rfrences utilises pour implmenter les associations (voir plus loin la
notion dassociation).
En phase danalyse, les attributs sont donc limits aux types primitifs, numrs plus
haut.
Figure 32: Type des attributs
La proprit dun attribut
Ecrites entre accolades {..}, les proprits permettent de signaler des proprits suppl-
mentaires pour lesquelles la syntaxe UML na pas prvu de symboles spcifiques.
Typiquement, cest essentiellement la proprit {r eadOnl y} que lon rencontrera dans
le cadre des attributs. En son absence, on peut supposer que lattribut est modifiable
par le biais dune opration correspondante, comme par exemple set Age( valeur) .
La valeur par dfaut
Indique de manire optionnelle.
Etudiant
nom: String
prnom: String
age: int
Classe
sigle: String
filiere: String
<inscrit dans
1 0..*
Classe
sigle: String
filiere: String
<inscrit dans
1 0..*
Etudiant
nom: String
prnom: String
age: int
classe: Classe Attribut rfrence
de type Objet
Analyse
Conception &
Implmentation
10.1.2Oprations
Les oprations regroupent les diffrentes tches dont une classe a la responsabilit et
quelle sait mener bien.
Les oprations sont reprsentes dans le troisime compartiment du rectangle dcrivant
la classe.
Reprsentation
Syntaxe complte dune opration
vi si bi l i t nom( par amt r es) :t ypeDeRet our {pr opr i t }
Un exemple
- est BonnePour LaCasse( ) : bool ean {quer y, abst r act }
Les paramtres, le type de retour ainsi que les valeurs de proprits sont optionnels.
Visibilit dune opration
Le langage UML prvoit 4 abrviations comme pour les attributs, dont la signification
peut dpendre du langage utilis pour limplmentation.
+ public
- private
# protg
~ package
Liste des paramtres
mode nom:t ype= val eur Par Df aut
O mode peut valoir i n, out ou encore i nout .
Vhicule
mar que
no
coul eur
dmar r er ( )
st opper ( )
Requtes et modificateurs
Les termes requte (query) et modificateur (modifier) font partie dune terminologie
permettant de distinguer les oprations qui modifient ltat du systme de celles qui ne
permettent que de linterroger, sans le modifier.
Accesseurs et mutateurs
Le terme accesseur (accessor) dsigne une opration qui retourne la valeur dun attribut
et ne fait rien dautre.
Le terme mutateur (mutator) dsigne une opration qui modifie la valeur dun attribut
sans rien faire dautre.
La distinction entre les termes requte et accesseur, de mme quentre modificateur
et mutateur, est une affaire purement interne la classe. De lextrieur, lutilisateur de la
classe en nest pas conscient, si nest que les accesseurs et les mutateurs ont souvent des
noms qui - par convention - commencent respectivement par get et set.
Trs souvent, les accesseurs et les mutateurs ne sont pas reprsents. Ca nest
quune question de convention dterminer entre les dveloppeurs.
Par exemple, la simple existence de lattribut nom peut sous-entendre automatique-
ment la prsence des deux oprations setNom et getNom. Si le mme attribut est contraint
par la proprit {readOnly}, seule lopration getNom sera alors disponible.
La proprit dune opration
Ecrites entre accolades {..}, on trouvera par exemple{quer y} ou encore {abst r act }
etc.
10.2CONCEPT D'ASSOCIATION
Dfinition 32: Association
Une association est dfinie par un lien entre deux ou plusieurs objets et o chaque objet
joue un rle particulier. Une association peut aussi possder des attributs.
Considrant le lien dengagement associant la personne Dupont avec le projet ProjX,
un attribut possible de lassociation pourrait tre la date du contrat d'engagement de
Dupont dans le cadre du projet Pr oj X.
En rgle gnrale, les associations sont binaires: elles relient deux types dobjets. Mais
lon rencontre galement des associations rflexives (mettant en jeu un seul type
dobjets) et galement les associations ternaires (qui mettent en jeu trois types dobjet).
[Voir paragraphe - Arit d'une association - page 142]
Reprsentation graphique
Une association est reprsente par une ligne reliant les classes dobjets. On y retrouve
aussi les attributs ventuels de lassociation, placs dans un rectangle reli par des points-
tills la ligne reprsentant lassociation.
Figure 33: Association
On peut imaginer plusieurs types d'associations entre deux types d'entits, comme dans
la figure suivante.
Figure 34: Associations multiples entre deux classes
Rle des objets
Le rle d'un objet, crit l'extrmit du lien d'association, dcrit la manire dont cet objet
est vu par l'autre objet. L'indication du rle n'est pas obligatoire.
Ingnieur
nom
no tel
Projet
nom
no
<participe
date engagement
Maison Personne
possde par >
loue par >
occupe par >
Figure 35: Rle des objets
Multiplicit d'une association
Dfinition 33: La multiplicit
La multiplicit d'une association indique le nombre dobjets qui participent l'associa-
tion.
La cardinalit est indique par une expression :
n entier dsignant le nombre exact d'instances
a..b intervalle de valeurs
a..* intervalle sans limite suprieure
* indiquant plusieurs , quivalent 0..*
par dfaut cardinalit 0..1
Figure 36: Lecture de la multiplicit
On lira ces diagramme ainsi:
une maison est occupe par 0 ou plusieurs occupants,
une maison est possde par exactement une personne,
une maison est loue par une personne au maximum,
une personne occupe une ou plusieurs maisons,
une personne possde zro ou plusieurs maisons,
une personne loue zro ou plusieurs maisons.
Maison Personne
loue par >
0..* 1..*
locataire
Rle de l'objet
Maison Personne
possde par >
loue par >
occupe par >
0..*
0..*
0..* 1..*
1
0..1
Convention pour le nom d'une association
Une association est dsigne par un verbe. Ainsi, on doit pouvoir lire un diagramme
UML en formulant des phrases dont le sujet et le complment d'objet sont des objets et
dont le verbe correspond l'association qui relie ces derniers.
Ainsi, dans la figure [Voir figure 37 - Reprsentation des associations en UML - page 139], ci-aprs,
l'association Di r i ge se lit :
une personne, - en tant que chef -, dirige 0 ou plusieurs personne
ou
une personne, - en tant que subordonn -, est dirige par 1 chef au maximum
Figure 37: Reprsentation des associations en UML
Le sens de lecture
Le nom de l'association (un verbe!) peut tre ventuellement accompagn d'une petite fl-
che de direction qui prcise le sens de lecture.
10.2.1Navigabilit des associations
Les lignes reprsentant les associations peuvent comporter une flche une extrmit,
voire aux deux extrmits.
mari-
0..1
mari
femme
0..1
Personne
nom
adresse
dirige >
employeur
chef
1..*
1
Entreprise
nom
adresse
employ
<travaille pour
* *
Maison Personne
occupe par >
0..* 1..*
Sens de lecture
A titre dillustration, voici 3 reprsentations possibles pour indiquer la relation existant
entre un propritaire et ses vhicules.
Figure 38: Navigabilit dune association
Du point de vue implmentation, la version c) signifie que le propritaire possde une r-
frence sur chacun des vhicules quil possde mais par contre quun vhicule ne possde
aucune rfrence sur son propritaire.
Cela peut signifier:
que lon peut interroger un propritaire pour connatre la liste de ses vhicules,
mais pas linverse;
que des messages peuvent circuler dans le sens propritaire vers vhicule, mais
pas linverse.
La version b) signifie que lon trouve des rfrences des deux cts. Il sagit dune asso-
ciation dite bidirectionnelle.
Les versions a) reprsente galement une association bidirectionnelle. A la diffrence de
b) toutefois, elle ne met pas laccent sur la notion de navigabilit.
Vhicule
Propritaire
possde >
1 1..*
Vhicule
Propritaire
possde >
1 1..*
Vhicule
Propritaire
possde >
1 1..*
Version a) - Association bidirectionnelle
Version b) - Association bidirectionnelle (identique a) )
Version c) - Association unidirectionnelle
La version a) est utilise en phase danalyse, et notamment dans la phase de
modlisation du domaine. A ce stade, les associations sont toutes bidirectionnelles par
nature.
Les versions b) et c) peuvent tre utilises en phase de spcification (pour signi-
fier par exemple quune classe A voit une classe B mais pas linverse), mais surtout en
phase de conception et dimplmentation o interviennet alors les notions spcifiques
de rfrence.
Proprits des associations
Une association peut tre contrainte au moyen dune proprit que lon indiquera lune
ou lautre de ses extrmits. Comme par exemple:
Par dfaut, une multiplicit de type plusieurs (multivalue), dnote un ensemble non
ordonn.
Ainsi, si on interroge une commande pour en connatre la liste de ses lignes de comman-
des, ces dernires ne seront pas retournes dans un ordre particulier, moins que lon
agrmente la multiplicit de la proprit {ordered}.
Par dfaut, les multiplicits multivalues ont les proprits:
{unordered} non ordonn
{unique} pas de doublons
Ainsi, les proprits {ordered} et {nonunique} permettent de modifier ces proprits par
dfaut.
La proprit {bag} est un raccourci pour dnoter un ensemble non ordonn avec doublons
autoriss.
LigneDeCommande
Commande
possde
1
1..*
{ordered} Proprit
10.2.2Classes dassociation
Il est possible de rajouter des attributs aux associations elles-mmes.
En rgle gnrale, on ajoutera les attributs lassociation elle-mme plutt
quaux classes associes lorsquon remarquera que la dure de vie de ces attributs
dpend directement de lassociation et non pas des objets associs.
En UML, cela se reprsente en traant une ligne pointille entre la ligne dassociation et
la classe dassociation.
Figure 39: Classe dassociation en UML
10.2.3Arit d'une association
Dfinition 34: Arit
L'arit d'une association correspond au nombre d'entits qui participent l'association.
Au niveau terminologique, une association d'arit n est dite association n-aire.
Comme l'ont montr les diffrents exemples que nous avons rencontrs, la majorit des
associations sont des associations binaires.
Un cas particulier d'association binaire est l'association dite rflexive, qui associe deux
entits du mme type. Lassociation mari ou encore dirige reliant deux personnes
en est une illustration.
Etudiant
adresse
nom
Classe dassociation,
avec attributs qui lui sont
propres
Inscription
Classe
sigle
filire
codeSecretaire
dateInscription
Inscrit dans classe 1 1..*
Figure 40: Association rflexive
On rencontre encore frquemment des associations ternaires, comme illustr dans le
paragraphe suivant.
Figure 41: Arit d'une association
10.2.4Associations ternaires
Se dit d'une association mettant en correspondance 3 types objets.
mari-
0..1
mari
femme
0..1
Personne
nom
adresse
dirige >
employ
chef
1..*
1
A B
A
Association binaire
Association rflexive
Association ternaire
A B
C
La figure [Voir figure 42 - Un cours comme association ternaire - page 144] nous prsente lasso-
ciation Cours, qui relie les 3 types dobjets Professeur, Classe et Matiere.
Figure 42: Un cours comme association ternaire
On notera que la notation UML utilise un losange sur lequel se trouvent connects les 3
types dobjets. Le mme losange peut tre connect une classe dassociation dans
laquelle on retrouve le ou les attributs de lassociation.
Dfinition 35: Classe d'association
On dfinit une classe d'associations comme une classe dcrivant les caractristiques
communes un ensemble dassociations reliant des types dobjets.
Multiplicit des associations ternaires au sens Merise et UML
Nous allons considrer un deuxime exemple, celui dune entreprise qui dsire conserver
une trace de linstallation des logiciels dans chacun de ses dpartements. A cet effet, une
association ternaire nous permettra denregistrer la date laquelle tel ou tel logiciel a t
install pour un dpartement donn sur un serveur spcifique.
La notation Merise est utilise dans le cadre de la modlisation des bases de donnes.
Professeur Classe
nom
prenom
sigle
filiere
Matiere
libell
salle
heure
Cours
Figure 43: :Association ternaire et notation Merise
On notera que lassociation ternaire possde un attribut: la date dinstallation du logiciel.
Pour mieux comprendre le sens donn aux cardinalits indiques sur ce schma, donnons
titre dillustration lallure que pourrait prendre la table relationnelle que lon utiliserait
pour mettre en oeuvre cette association ternaire.
Au sens de Merise, les cardinalits indiques sur le modle doivent tre interprtes de la
manire suivante:
Logiciel - [0, N]
Le mme logiciel peut apparatre plusieurs fois dans la table dassociation, ou ne
pas apparatre du tout. Autrement dit, le mme logiciel peut tre associ 0 ou
plusieurs couples <Dpartement, Serveur>.
Dpartement - [0, N]
Le mme dpartement peut apparatre plusieurs fois dans la table dassociation,
ou ne pas apparatre du tout. Autrement dit, le mme dpartement peut tre asso-
ci 0 ou plusieurs couples <Logiciel, Serveur>.
Serveur - [1, N]
Le mme Serveur peut apparatre plusieurs fois dans la table dassociation, il
apparatra au moins une fois tant donn quun serveur donn doit hberger au
moins un logiciel. Autrement dit, le mme serveur peut tre associ un ou plu-
sieurs couples <Dpartement, Serveur>.
Serveur
nom
type
Logiciel
nom
editeur
Dpartement
sigle
directeur
Installation
date installation
0,N 1,N
0,N
Logiciel Dpartement Serveur Date dinstallation
Word Info ServeurINFO_1 1er janvier 01
Word Tcom ServeurTCOM 12 mars 01
Rational Rose Info ServeurINFO_1 15 juillet 02
PowerAMC Tcom ServeurINFO_2 1er sept 02
PowerAMC Info ServeurINFO_2 1er sept 02
Voici enfin toujours le mme schma conceptuel, mais rpondant cette fois-ci au modle
UML.
Figure 44: Associations ternaires et UML
Au sens UML, et en adoptant le formalisme utilis par WinDesign (un outil de mod-
lisation), les cardinalits indiques sur le modle seront interprtes de la manire sui-
vante:
Logiciel - [0..*]
Considrant un couple <Dpartement, Serveur>, plusieurs logiciels pourront y tre
installs. Par contre il est possible quaucun logiciel ny soit install. Do la car-
dinalit [0..*].
Dpartement - [0..*]
Considrant un couple <Logiciel, Serveur>, ce mme couple pourra tre install
pour plusieurs dpartements. En revanche, il est possible quaucun dpartement
ne soit concern par cette installation.
Do la cardinalit [0..*].
Serveur - [1]
Considrant un couple <Dpartement, Logiciel>, linstallation sera opre imprati-
vement sur un serveur et un seul.
On peut noter dans ce cas particulier que linterprtation des cardinalits est plus
riche que celle introduite dans la notation Merise. En effet, elle permet de prendre en
compte les contraintes dunicit du type quun logiciel dun dpartement ne doit tre
install que sur un seul serveur.
Serveur
nom
type
Logiciel
nom
editeur
Dpartement
directeur
0..*
1
0..*
date installation
Installation
sigle
Les relations ternaires sont rarement utilises
La mise en vidence dassociations ternaires intresse avant tout la phase danalyse.
Pendant les phases de conception et dimplmentation, quand il sagira de met-
tre en oeuvre des classes dites logicielles, on se contera dassociations binaires. Les
associations ternaires seraient trop lourdes manipuler.
Notons dailleurs que la reprsentation des associations ternaires nest pas pro-
pose lheure actuelle par les outils Rational Rose et Together. Outils ddis prin-
cipalement la conception et limplmentation.
Binarisation dune association ternaire - 1re approche
Dans une pemire approche, il est possible de reprsenter une association ternaire au
moyen dune classe dassociations portant le strotype
1
<<Association ternaire>>.
Ce qui nous donne le schma suivant:
Dans cette dernire reprsentation, les multiplicits indiques sur le modle sont inter-
prtes selon le sens UML habituel:
Logiciel - Installation
Une installation concerne un et un seul logiciel. Un logiciel peut tre install plu-
sieurs fois.
Dpartement
Une installation concerne un et un seul dpartement. Plusieurs installations ont pu
tre opres pour le mme dpartement.
Serveur
Une installation est opre sur un seul serveur. Le mme serveur peut abriter plu-
1. Un strotype reprsente un lment de modlisation qui na pas t prvu par le langage UML.
Ladjonction de strotypes (dfinis par le concepteur) est un moyen dtendre le langage UML
avec ses propres spcificits. Un strotype est un texte encadr par les symboles << et >>. Dautres
exemples de strotypes: <<interface>>, <<abstract>>, etc. Le langage UML prvoit un certain nom-
bre de strotypes prdfinis (consulter les spcifications de lOMG).
Serveur
nom
type
Logiciel
nom
editeur
Dpartement
sigle
directeur
1 1
0..*
date installation
<<Association ternaire>>
Installation
0..* 0..*
1
sieurs installations.
Notons que cette dernire reprsentation ne permet plus, - dans notre exemple -,
de prendre en compte la contrainte dunicit un logiciel dun dpartement ne doit tre
install que sur un seul serveur. Par exemple, rien ninterdit ce que le logiciel
Office soit install deux fois pour le mme dpartement, sur deux serveurs diffrents.
Pour montrer ce type de contrainte, mieux vaut alors transformer lassociation ternaire en
association binaire, comme on le verra dans ce qui suit.
Binarisation dune association ternaire - 2me approche
Dans cette deuxime approche, les associations ternaires sont remplaces par une associa-
tion binaire laquelle on rattache une classe dassociations (cette dernire contient alors
les lments intressants du 3me type dobjets, celui qui participait lassociation et que
lon a supprim).
Considrons titre dillustration un systme de rservation de place davion.
La transformation de cette association ternaire consiste supprimer une des 3 classes, -
en loccurrence la classe Place - , en la remplaant par une association binaire laquelle
on rattache tous les attributs de la classe supprime.
Figure 45: Transformation dune association, de ternaire binaire
A titre dillustration, reprenons maintenant lexemple relatif linstallation des logiciels
et sa reprsentation UML avec loutil Rational Rose. Rappelons que cette reprsentation
Place
noPl ace
Vol
dat e
Personne
nom
vol place
passager
Reservation
Vol
Reservation-pour
vol
Reservati on
date
Personne
nom
passager
noPlace
ne permettait pas de prendre en compte la contrainte dunicit un logiciel dun dparte-
ment ne doit tre install que sur un seul serveur.
Dans ce schma, le concept dinstallation reprsente une une installation dun logiciel
pour un dpartement sur un serveur.
Aprs transformation en association binaire, on retrouve la possibilit de reprsenter
cette contrainte, comme lillustre la figure suivante.
Figure 46: Transformation ternaire - binaire, deuxime exemple
Cette fois-ci, le concept dinstallation reprsente non plus une installation dun logiciel
pour un dpartement sur un serveur mais plutt une installation dun logiciel pour un
dpartement. Cest peut-tre un peu subtil, mais toute la diffrence est l.
10.2.5Agrgations et compositions
UML opre un distinguo entre associations simples, associations de type agrgation et as-
sociations de type composition.
Serveur
nom
type
Logiciel
nom
editeur
Dpartement
sigle
directeur
1 1
0..*
date installation
<<Association ternaire>>
Instal lation
0..* 0..*
1
Serveur
nom
type
Logiciel
nom
editeur
Dpartement
sigle
directeur
0..*
1
date installation
Installation
0..*
0..*
En prliminaire, il est bon de revenir sur certaines notions fondamentales.
Retour sur la notion dattribut
A la diffrence dun objet, un attribut na pas de sens lui tout seul. Un attribut
ne sera jamais manipul indpendamment de lobjet quil caractrise.
Ainsi, on parlera de la hauteur dun immeuble, de lge dun individu, etc.
Supprimer un attribut na pas de sens: lobjet perdrait son identit (son sens, sa
raison dexister).
Par contre il est possible de modifier la valeur dun individu.
Un personne ne peut pas perdre sa couleur! Elle peut par contre changer de cou-
leur.
Retour sur la notion dassociation
Au contraire des attributs, les associations peut tre supprimes (la rfrence prend alors
la valeur null), sans altrer lidentit de lobjet, mme si ce dernier peut en devenir moins
performant.
Une personne ne peut pas perdre sa couleur ni sa taille (mme si cette dernire prend la
valeur 0, la personne aura toujours une taille). Par contre, une personne peut perdre son
nez, une jambe, etc.
Cet exemple montre galement que le nez dune personne peut tre manipul en tant que
tel, indpendamment de la personne laquelle il appartient. Par contre, il serait difficile
de prendre la couleur dune personne, de la mettre dan un sac, et de lui changer sa valeur
indpendamment de la personne.
Les associations simples
Les associations simples dnotent un lien faible entre les classes mises en relation: les cy-
cles de vie des objets sont trs indpendants les uns des autres. Cest le cas par exemple
de la relation entre une star et un de ses fans (quoique..).
Nez
Star
possde
1
1

couleur
taille
Fan
admir par > 0..* 1..*
Les associations de type composition
Ces dernires, reprsentes par un losange rempli de noir du ct composite, dnotent au
contraire un lien trs fort entre le composite et le composant, notamment du point
de vue de leur cycle de vie.
Si le composite est dtruit, ses composants le sont galement!
Une deuxime proprit des compositions: le partage nest pas possible.
Un composant ne peut appartenir qu un seul composite.
La multiplicit peut valoir 1 ou 0..1 du ct composite.
Figure 47: La composition en UML
Par exemple:
Composite
Composant
0. . *
Polygone Point
Contient 3. . *
Ainsi, le diagramme de la star peut tenir compte de ce type dassociation:
Les agrgations
Une agrgation dnote une association de type ensemble-lment. Elles sont reprsen-
tes au moyen dun losange non rempli de noir, plac du ct de lensemble.
Au contraire des compositions:
les cycles de vie de lensemble et de ses lments sont relativement indpendants
le partage est possible: un lment peut faire partie le cas chant de plusieurs
ensembles.
Nez
Star
possde
1

couleur
taille
Fan
admir par > 0..* 1..*
Figure 48: Lagrgation en UML
Figure 49: Autres exemples dagrgation
Hirarchie Attribut > Composition > Agrgation > Association simple
Les lecteurs qui ont bien assimil le discours qui prcde auront remarqu quil existe une
hirarchie du point de vue de la dpendance entre les diffrentes notions dattributs, de
composition, dagrgation et dassociation simple.
Catalogue
Produit
0. . *
Nez
Star
possde
1

couleur
taille
Fan
admir par > 0..*
1..*
Paquetage
Element
possde
rfrence
1..* 1..*
Il existe un lien trs fort, existentiel, entre un attribut et lobjet quil caractrise. Au con-
traire, une association simple dnote un lien de dpendance trs faible entre les objets
mis en relation.
10.3GNRALISATION - SPCIALISATION
Ce concept dnote la possibilit de regrouper dans une seule classe toutes les proprits
(c.a.d les attributs et les associations) qui seraient communes un ensemble de classes
spcifiques.
Prenons lexemple dune entreprise de location de vhicules.
Dans la figure suivante, nous remarquons que les deux classes Voiture et Camion sont tou-
tes deux des vhicules et partagent ce titre un certain nombre de caractristiques. Le
fait notamment davoir t obtenu auprs dun fournisseur (association a fourni), mais
aussi le fait dtre caractriss par trois attributs identiques (une marque, un numro
didentification et une couleur).
Attribut
Composition
Agrgation
Association simple
Lien de dpendance
Trs fort
faible
Fournisseur
Voiture
nbrPlaces
Camion
volumeMax
chargeMax
a fourni
Entrept
stock dans
marque
no
couleur
marque
no
couleur
0..*
1
a fourni
1
0..*
Le concept Gen-Spec (Gnralisation - Spcialisation) appliqu cet exemple nous
permet de regrouper ces caractristiques communes lintrieur dune seule et mme
classe. Dans notre cas, il sagira de la classe Vehicule, comme le montre la figure sui-
vante.
Figure 50: Gnralisation - Spcialisation
Pour quel bnfice?
Le schma conceptuel qui en rsulte est beaucoup plus lisible. Dautre part, toute
modification ne concernant que les caractrisques gnrales (comme par exemple de
changer le nom de lattribut noIdent par noIdentification) ne sera opre qu un seul
endroit, tout simplement et sans erreur.
Reprsentation symbolique de la relation GEN-SPEC
La relation GEN-SPEC sera reprsente au moyen dune flche dont lextrmit est un
triangle blanc.
Fournisseur
Vhicule
marque
no
couleur
Voiture
nbrPlaces
Camion
volumeMax
chargeMax
a fourni
Surtype
Soustype
Gnralisation
Spcialisation
Association
et
attributs
gnraux
Attributs
spcifiques
Entrept
stock dans
Association
spcifique
0. . * 1
Figure 51: Reprsentation de la relation GEN-SPEC
Un petit rappel: les notions de type
La classe est un concept qui permet de dfinir un type de donnes.
Considrons la dclaration suivante (exemple en J ava):
Lobjet o est de type T: cela signifie que l'on attribue o certaines proprits, et que ces
proprits doivent tre respectes par le programmeur qui utilisera cet objet.
Notamment:
1. les valeurs de o sont contraintes: o ne peut pas prendre n'importe qu'elle valeur.
En effet, la valeur de o est inscrite dans ses variables d'instance - qui sont elles-mmes
types et donc contraintes! -, et dont toute modification ne peut tre opre que sous le
contrle des mthodes.
Par exemple, une variable d'instance de type shor t (entier 16 bits) est limite aux
valeurs de -32768 +32767.
2. Lobjet o obit un certain comportement qui est dfini par les instructions des mtho-
des de la classe T.
La spcialisation et son principe, types et soustypes
Passons maintenant la notion de soustype.
Dfinition 36: Surtype - Soustype et drivation
le surtype est le type gnral, celui qui regroupe toutes les proprits communes
dautres types dobjets (les soustypes);
Vhicule
mar que
no
coul eur
Camion
vol umeMax
char geMax
Surtype
Soustype
Gnralisation
Spcialisation
cl ass T {
. . . .
}
T o = new T( ) ;
le soustype est un type spcialis dont les caractristiques comprennent dune
part les proprits qui drivent du type gnral (associations et attributs), et
dautre part de proprits qui lui sont propres, qui viennent se rajouter celles du
surtype.
La spcialisation reprend son compte toutes les proprits du type gnral sans excep-
tion. Il nest pas prvu conceptuellement de refuser certaines proprits du type gnral.
Si jamais on en prouve le besoin, il nous faut revoir la conception de notre modle.
La spcialisation consiste donc essentiellement rajouter de nouvelles proprits.
La rgle de substitution
Le modle que vous avez conu avec beaucoup denthousiasme est-il correct?
La rgle qui suit devrait tre observe en toutes circonstances
Lors dune drivation, cest--dire de la spcification dun sous-type T partir dun type
T, il est vivement recommand de ne pas altrer les proprits du type de base T. Notam-
ment, toute proprit applicable un type de base T doit rester applicable un type driv
T .
Dfinition 37: Rgle de substitution
Soient T un type de base, et T' un sous-type obtenu par drivation de T.
Considrons un bloc d'instructions qui s'adresse un objet de type T. Le mme bloc d'instruc-
tions doit pouvoir s'appliquer un objet de type T' .
Autrement dit, il doit toujours tre possible de substituer un objet de type T' un objet de type
T.
L'inverse n'est pas vrai: un objet de type T' ne peut pas tre substitu un objet de type T.
En effet, vu que le sous-type T' est un type enrichi de nouvelles mthodes, un bloc d'instruc-
tions s'appliquant T' , et qui utilise ces nouvelles mthodes, ne pourra pas s'appliquer T.
Tout ce qu'on peut faire un animal doit pouvoir tre fait avec une
vache, puisqu'une vache est-un animal.
Un animal n'est pas une vache!!
On ne peut pas demander n'importe quel animal de fabriquer du
lait. Essayez donc de traire un taureau!
La relation est-un
La relation qui relie un type avec son supertype est de type est-un (en anglais : is-a).
Par exemple, on dira:
qu'un entier positif est-un entier;
qu'un entier est-un nombre;
et par transitivit, quun entier positif est-un nombre;
quun perroquet est-un oiseau;
etc.
Un entier positif est-un entier..
Il s'agit d'une spcialisation dans le sens o on peut faire plus avec un entier
positif qu'avec un entier. Par exemple, l'opration racine-carre ne peut tre opre
qu'avec un entier positif.
Remarquons pour finir que la relation est-un est transitive, mais non rflexive: elle ne marche
que dans un sens: un oiseau est-un animal, mais un animal n'est-pas-un oiseau.
GEN-SPEC et hritage
Le concept Gnralisation-Spcialisation pourrait rappeler certains un autre concept,
plus connu sous le nom dhritage.
Il nen est rien!
Enfin, pas tout fait..
Lhritage nest pas proprement parler un concept. Il sagit plutt dun mcanisme pro-
pos par les langages de programmation orients objet afin de pouvoir rutiliser du
code dans un sens large. Notons toutefois que le concept GEN-SPEC est galement un
concept fondamental de la programmation oriente objet..
Lhritage est simplement le mcanisme qui permettra au programmeur de mettre en
oeuvre ce concept. Lhritage est un mcanisme puissant qui, sil est mal utilis, - cest
dire exploit en dehors du concept GEN-SPEC -, peut faire de grands dgts!
Reprsentation des classes abstraites
En UML, un nom de classe crit en italique indique que cette dernire est une classe ab-
straite (une classe qui ne sera jamais instancie, seules ses sous-classes le seront).
Dfinition 38: Classes abstraites et modlisation de domaine
Du point de vue de la modlisation de domaine, une classe conceptuelle sera spcifie
abstraite dans la mesure o lensemble de toutes ses sous-classes opre une partition.
Autrement dit, tout membre de la classe abstraite doit tre membre dune sous-classe.
10.4LES CONTRAINTES
Les constructions fondamentales - associations, agrgations, compositions, gnralisa-
tion, etc. - expriment des contraintes.
Malheureusement, ces contraintes dites fondamentales ne permettent pas de reprsen-
ter toutes les contraintes qui accompagnent fatalement un diagramme de classe.
Pour indiquer les contraintes, le langage UML nimpose quune seule rgle: les placer
entre accolades {..}.
Ainsi, on a pu rencontrer les proprits des attributs et des associations - comme {rea-
dOnly}, {ordered}, etc. - qui obissent cette syntaxe.
Il est possible dindiquer les contraintes lintrieur dun commentaire.
Paiement
montant: int
La classe est abstraite
Tout paiement sera soit un
paiement en espces ,
un paiement crdit ,
soit encore un paiement
par chque
PaiementEnEspeces PaiementParCheque PaiementACredit
Partition en sous-
ensembles
Figure 52: Une contrainte dans un commentaire
Les contraintes sont la plupart du temps exprimes dans un langage naturel.
Il est possible toutefois de les exprimer au moyen dun langage formel. A cette
fin UML met disposition le langage OCL (Object Constraint Language), non dcrit
dans le cadre de ce document.
LigneDeCommande
Commande
possde
1
1..*
{ordered}

date
dateLivraison
{dateLivraison >date}
Contraintes
Gnie logiciel - 161 - Annexe 2 - Diagrammes dactivits
11Annexe 2 - Diagrammes
dactivits
Un diagramme dactivits permet de dcrire une fonctionnalit comme par exemple un
processus mtier ou encore un flux de travaux (workflow).
Voici, pour les situer un peu, un certain nombre de caractristiques:
Historiquement
Les diagrammes dactivits sapparentent ce quon appelait autrefois les orga-
nigrammes. Ils ont toutefois plus de richesse, et notamment la possibilit de
reprsenter le paralllisme dexcution de certaines activits.
Laspect Objet
Un diagramme dactivits exprime le flux de contrle (ordonnancement des op-
rations) la manire dun diagramme de squence.
A la diffrence dun diagramme de squence, un diagramme dactivits ne mon-
tre pas les objets mais se concentre uniquement sur les oprations.
A priori, on ne sintresse pas qui fait quoi, mais uniquement ce qui
se fait.
Le cas chant, la notion de partition et de couloirs dactivits (voir plus
loin) permet nanmoins dapporter des prcisions sur qui fait quoi.
A quelle occasion utiliser les diagrammes dactivits?
Les diagrammes dactivits prcisent les dtails des traitements pour mettre en
oeuvre une opration ou un processus mtier.
Trs souvent, les diagrammes dactivit sont utiliss en phase danalyse pour
dcrire plus prcisment les cas dutilisation. Ils compltent laspect objet des
autres diagrammes UML.
11.1 NOTATION DE BASE
Un premier diagramme illustre la manire dutiliser les symboles graphiques de base.Il
sagit dun diagramme dactivits dcrivant laccomplissement dune transaction.
Terminologie gnrale
Un diagramme dactivits dcrit une activit qui sexprime par un combinaison
dactions.
Les transitions entre actions sont appeles flots ou arcs.
En principe, une activit ne possde quun seul flot sortant. Il est implicite que ce
flot sortant est emprunt seulement quand laction est termine.
Aiguillages
Une dcision possde un flot entrant et plusieurs flots sortants
Une fusion possde linverse plusieurs flots entrants et un flot de sortie
Les gardes doivent tre mutuellement exclusives ([else]sera slectionn si tou-
tes les autres gardes sont fausses.
Recommandation
Si possible, utiliser explicitement les symboles de dcision et de fusion, faire en
sorte quune action aie un seul flot entrant et un seul flot sortant. Le dia-
gramme gagne en clart.
Dans la figure ci-dessous, laction B reoit 3 flots dentre. Il nest pas trs clair
de savoir si laction B dmarre une fois seulement que les actions 1, 2 et 3 sont
termines ou si cette action dmarre ds que lune dentre elle est termine. Un
symbole de fusion ou de jonction apporte beaucoup de clart (mme si la jonction
est implicite avec UML 2).
Dans la figure ci-dessous, laction A dispose de 3 flots sortants. Ce diagramme est
tout fait correct. Mais, pour plus de clart on prfre faire partir les 3 flots dun
losange de dcision (figure suivante).
Cette dernire solution a le mrite de montrer que laction A est formellement ter-
mine avant que lun ou lautre de 3 flots sortants ne soit emprunt
Excution parallle
Les barres de synchronisation sont indiques en gras
Un dbranchement indique le dpart dune excution parallle de lactivit en
plusieurs fils dexcution
Avec une jonction, le flot sortant ne peut sexcuter que lorsque toutes les activi-
ts entrantes sont termines (cest en quelque sorte un point de rendez-vous)
11.2 PARTITION - COULOIRS DACTIVITS
Comme nous lavons dj signal, un diagramme dactivits exprime ce qui se fait et sat-
tache dcrire lordonnancement des oprations sans prciser qui fait quoi. Contraire-
ment un diagramme de squence, les objets responsables des traitements ne sont pas
reprsents.
Il est possible toutefois dapporter des prcisions sur les entits responsables des traite-
ments.
Ainsi, un diagramme dactivits peut faire intervenir la notion dentit organisation-
nelle.
Dfinition 39: Entit organisationnelle
Une entit organisationnelle reprsente un objet ou un groupe dobjets, - ou encore une
ou des personnes dans le cadre de la spcification dun processus dadministration-.
Les diffrentes actions reprsentes dans un diagramme dactivits peuvent tre asso-
cies telle ou telle entit organisationnelle par le biais de couloirs dactivits (swimla-
nes en anglais, suivant le mtaphore de la piscine).
Ces couloirs dactivits permettent de rpartir les activits au sein des entits organisa-
tionnelles. Placer une action dans un couloir dactivit indique quelle est effectue par
un ou par plusieurs objets de lentit organisationnelle.
Exemple: une application client-serveur chat
Les couloirs dactivits sont particulirement bien indiqus lorsquil sagit de
dcrire des systmes distribus.
A titre dillustration, considrons la mise en oeuvre dun chat, application client-ser-
veur distribue.
Voici le scnario de lactivit principale (cas dutilisation de base):
1. Un client envoie un message au serveur (un message texte pour les autres clients
connects ou un message FIN pour demander une dconnexion)
2. Le message est rceptionn par le serveur
3. Le message est analys par le serveur
4. Un message texte est renvoy par le serveur tous les clients connects.
Un message FIN entrane la dconnexion du client par le serveur
Voici un premier diagramme dactivits, exprimant lactivit principale du chat sans pr-
ciser qui fait quoi.
Voici un deuxime diagramme qui rpartit les diffrentes actions entre les organisations
Client et Serveur.
11.3 SIGNAUX
Le diagramme prcdent peut tre amlior en utilisant le concept de signal.
Le symbole ci-dessous correspond une acceptation de signal: laction accomplie
consiste simplement attendre le signal. Laction se termine quand le signal est reu.
Dans notre cas, le signal attendu correspond la rception du message dun client.
Pour mettre un signal, le symbole correspondant est le suivant:
Le diagramme dactivits du chat prendra alors lallure suivante:
Gnie logiciel - 169 - Annexe 3 - Diagrammes de squence
12Annexe 3 - Diagrammes de
squence
Un diagramme de squence permet de dcrire un scnario en mettant en vidence les
interactions entre les parties prenantes (objets ou acteurs) qui collaborent la mise en
oeuvre de ce scnario.
Voici, pour les situer un peu, un certain nombre de caractristiques:
Laspect flux de contrle
Un diagramme de squence illustre les interactions entre les objets en mettant en
vidence la liste des messages changs et lactivation correspondante des
mthodes.
A la diffrence dun diagramme dactivits, un diagramme de squence ne mon-
tre pas en dtail lordonnancement des oprations.
Diagrammes de squence et diagrammes dactivits sont donc complmentaires:
le diagramme de squence montre qui fait quoi et le diagramme dactivits
montre ce qui se fait.
A quelle occasion utiliser les diagrammes de squence?
Les diagrammes de squence sont trs souvent utiliss en phase danalyse pour
illustrer et clarifier les interactions occasionnes par la mise en oeuvre dun cas
dutilisation (dcrivant un fonctionnalit).
Dans un diagramme de haut niveau, les parties prenantes seront les acteurs et le
systme.
Dans un diagramme de 2me niveau, prlude la conception et plus proche de
la structure du futur logiciel, les parties prenantes seront des objets.
12.1 NOTATION DE BASE POUR DCRIRE UN SCNARIO
Dfinition 40: Scnario
Un scnario est une squence dvnements qui correspond lexcution dun cas duti-
lisation.
Dans une premire approche un scnario est gnralement dcrit par une liste de dclara-
tions textuelles, comme lillustre ci-dessous lexemple dun chat client-serveur:
5. Un premier client se connecte
6. Le serveur lui envoie la liste des clients connects (vide pour linstant)
7. Un deuxime client se connecte
8. Le serveur envoie la liste des clients connects chacun des clients
9. Un client envoie un message au serveur
10.Le serveur renvoie le message tous les clients connects
Le mme scnario peut tre dcrit au moyen dun diagramme de squence comme ci-
dessous:
Figure 53: Diagramme de squence du chat client-serveur
Terminologie gnrale
Les lignes verticales - lignes de vie - reprsentent les acteurs et le systme;
Une flche horizontale reprsente un message allant de lemmetteur au rcepteur;
Le temps scoule verticalement;
Les contraintes temporelles et le minutage exact ne sont pas indiqus, les systmes temps
rels peuvent tre dcrits, mais en utilisant une notation supplmentaire non standard;
Les avantages du diagramme de squence la description textuelle
Le diagramme de squence reprsente clairement quels sont les acteurs impli-
qus: lmetteur et le rcepteur de chaque message
Les diagrammes de squence sont le prlude lorganisation du comportements
des objets (un premier pas vers la conception).
Dcrire un cas dutilisation avec des diagrammes de squence
Si le cas dutilisation est dcrit par plusieurs scnarios, et si on dsire tre complet, on
trouvera un diagramme de squence par scnario (comme par exemple, un diagramme
Ligne de vie
Participants l'interaction
Ecoulement
du temps
pour le scnario principal et autant de diagrammes quil y aura de scnarios dchec).
12.2OBJETS ACTIFS ET OBJETS PASSIFS
La figure ci-dessous reprsente une interaction entre 3 objets. Il sagit en loccurrence
dun chat client-serveur et de la mise en oeuvre au sein du serveur de lopration ren-
voyant un message tous les clients connects.
Le cont r l eur ainsi que chaque cl i ent sont des objets actifs. Lobjet l i st e-
DesCl i ent s est un objet passif.
Objet passif
Un objet passif nest activ que lorsque lune ou lautre de ses mthodes est invoque.
La ligne de vie - en points tills - reprsente la priode entire durant laquelle lobjet exis-
te. Les priodes dactivation des mthodes de lobjet sont reprsentes par des rectangles.
Objet actif
Un objet actif dispose de son propre flot de contrle et il demeure actif aprs avoir rpon-
du un message ou aprs avoir envoy un message.
Le rectangle reprsentant son activation stend dans ce cas sur toute la dure de la ligne
de vie.
Dans notre exemple, lobjet unClient est considr comme un actif car il est cens
attendre de manire continue des messages en provenance du client extrieur tout en
envoyant des messages ce dernier sur demande du contrleur.
Cas dutilisation de haut niveau (acteurs et systme)
A haut niveau, comme dans celui du cas dutilisation gnral du chat [Voir figure 53 -
Diagramme de squence du chat client-serveur - page 171], les parties prenantes reprsentent en
gnral des acteurs ou le systme lui-mme. Acteurs et systme sont alors assimils
renvoyerMessage(message)
(message)
clients
control eur l isteCli entsConnects unCl ient
1: getClients
2: envoyerMessage
des objets actifs, susceptibles daccomplir des services ou de gnrer des services simul-
tanment.
12.3OBJETS TEMPORAIRES
Pour crer un participant, la syntaxe UML prvoit le dessin dune flche allant directe-
ment de lobjet crateur au rectangle reprsentant le nouveau participant.
En principe, le message de cration est libell avec le mot-cl new.
Pour montrer la suppression de lobjet temporaire, la syntaxe prvoit un X:
une destruction opre par un autre objet (comme par exemple en C++) est repr-
sente par un message entrant directement dans le X.
un X simplement reprsent en fin de ligne de vie signifie que lobjet opre une
autodestruction.
Figure 54: objets temporaires
Dans le cas denvironnements avec garbage collector, comme les objets ne sont
pas dtruits explicitement, lutilisation dun X signifie simplement que lobjet nest plus
utile.
gestionnaireDinformations
requte
instructionSQL
paramtre
requte (type, parametre)
new (parametre)
new
excute
rsultat
fabriqueRponse
rponse
autodestruction
objets temporaires
destruction
par un autre objet
appels rentrants
getParametres
valeur de retour
paramtres
de messages
Appels rentrants, retours doprations & paramtres
Notons au passage, dans la figure ci-dessus, quelques lments supplmentaires de la syn-
taxe UML:
la reprsentation dun appel rentrant en UML, illustre par limbrication de
rectangles dactivations
la reprsentation optionnelle de valeurs de retour, dans le but dapporter une cer-
taine clart au diagramme
et enfin la marque de paramtres indiqus dans le nom du message
Objets temporaires avec Together
La version que nous possdons de Together ne permet pas de montrer de manire explicite
les objets temporaires. Nous pouvons par contre lilluster partiellement en utilisant lop-
rateur new, comme ci-dessous.
12.4MESSAGES SYNCHRONES ET ASYNCHRONES
UML prvoit une syntaxe permettant de diffrencier les messages synchrones des messa-
ges asynchrones.
Messages synchrones
Sont reprsents par une flche pleine:
Un appelant qui met un appel synchrone doit attendre que celui-ci ait termin son tra-
vail. Il peut sagir par exemple de linvocation dune sous-opration.
Messages asynchrones
Sont reprsents par une flche bton:
Lappelant peut alors continuer son traitement sans atendre la rponse.
La distinction entre appels synchrones et asynchrones est souvent subtile, elle est
peu utilise de manire gnrale.
Figure 55: messages synchrones et asynchrones
Syntaxe pour les messages asynchrones jusqu UML 1.3
Together utilise une ancienne syntaxe pour marquer les messages asynchrones, comme
Objet1
requte
initiale
message1
new
messages
asynchrones
Objet2
message2
Objet3
message
synchrone
lillustre la figure ci-dessous, en utilisant la demi-flche.
12.5CONDITIONS ET ITRATIONS
De manire gnrale, les diagramme de squence sont utiliss essentiellement pour mon-
trer linteraction entres les parties prenantes, savoir la liste des messages changs. Las-
pect algorithmique est ignor.
Ainsi, lexcution conditionne dun message et la rptition dappels ne sont pas men-
tionns.
Nanmoins, il est possible dutiliser une notation supplmentaire qui permet dillustrer
ce genre de problmatique. Comme cette notation est relativement lourde, elle est rare-
ment employe.
La premire figure illustre lancienne notation UML, encore utilise avec Together et
dautres environnements. Cette notation a le mrite dtre relativement lgre.
Figure 56: Conditions & itrations, ancienne notation (Together)
UML 2.0 utilise une nouvelle notation, sappuyant sur lembotement, comme lillustre
la nouvelle figure ci-dessous.
Figure 57: Conditions & itrations, UML 2.0
condition
itration
Objet1
message1
alternative
Objet2 Objet3
Option
message2
message2
opt
alt
loop
[tant que X <10]
[y >0]
[z >100]
[else]
rptition
Gnie logiciel - 179 - Annexe 4 - MVC & Modle Observateur
13 Annexe 4 - MVC & Modle
Observateur
MVC et Observateur sont deux modles de conception, - deux Design patterns
-, qui comptent parmi les plus importants du Gnie Logiciel. Avant de les tudier de ma-
nire spcifique, nous prsenterons quelques gnralits sur les modles de conception,
gnralits qui peuvent tre ignores par lecteur averti.
13.1 EN PRLIMINAIRE: LES MODLES DE CONCEPTION
Les modles de conception, ou encore schmas de conception sont des lments es-
sentiels de la fabrication des systmes complexes, que lon travaille dans le domaine de
linformatique ou ailleurs. Ils sont plus connus sous le vocable anglais design patterns.
Dans le contexte de la programmation, il faut admettre en effet que la conception dun
logiciel orient-objet est une tche difficile. Trs souvent, la conception labore par le
dveloppeur sera spcifique du problme rsoudre. Parfois, - et cest ce qui nous int-
resse ici -, cette conception sera suffisamment gnrale pour tre rutilise et adaptable
de nouveaux problmes.
Les concepteurs dexprience savent quil faut viter de rinventer la roue chaque
exprience, quil ne faut pas chercher rsoudre un problme en partant de rien. Il vaut
mieux rutiliser des solutions qui ont fait leurs preuves. Cest ainsi quune bonne
solution sera rutilise systmatiquement.
Ces solutions sont appeles modles de conception.
Cette annexe est consacr la prsentation de deux modles de conception fondamen-
taux que lon rencontre dans la plupart des applications.
Documentation
Patterns in Java de [Mark Grand] chez Wiley
UML & design patterns de [Craig Larman] chez Wiley
Description dun modle de conception
La description dun modle de conception particlier sarticule autour de 3 particularits
essentielles:
1. Le nom du modle
On parlera par exemple du modle MVC , du modle du Producteur-
consommateur ,..
Le nom du modle est bien entendu essentiel, est fait quasiment lobjet dune
standardisation dans le monde informatique. Cela facilite la communication entre
dveloppeurs.
2. Lnonc du problme
O seront dcrites la situation ou les situations dans lesquelles le modle peut
sappliquer.
3. La solution
Qui dcrit les lments mettre en jeux (en gnral, il sagira de classes,
dobjets), leurs relations et leur collaboration. Cette solution est toujours gnri-
que, le programmeur aura pour tche de ladapter un contexte particulier.
13.2LE MODLE MVC
MVC est sans aucun doute un des modles les plus importants au sein de la grande famille
des Design patterns.
A lorigine, le modle MVC a t labor pendant la conception du langage Smalltalk,
langage orient-objet, dvelopp par Xrox, Palo Alto, afin de rsoudre les problmes
dinterfaage avec lutilisateur.
Fort de son succs, le mme modle est utilis pour concevoir larchitecture gnrale
dune petite application comportant une interface graphique.
Ainsi, la plupart des programmes raliss dans le cadre de laboratoires de Programma-
tion Oriente Objet pourraient tre conus en sappuyant sur ce modle.
Lutilisation du modle MVC nest pas limite toutefois aux applications de petite
taille.
Il a t intgr depuis dans le pattern architectural Couches (Layers). Un pattern qui
sert de base llaboration de la structure grande chelle dun systme [Voir paragraphe -
MVC et le pattern Couches - page 192].
Principe du modle MVC
Lobjectif dune telle architecture est de sparer et de dcoupler les 3 composantes dun module :
La composante Modle
Cette composante comprend une ou de plusieurs classes qui regroupent les structures
dinformations manipules par le module.
La composante Vue
La vue est galement compose dune ou de plusieurs classes. Ces dernires ralisent
linterface avec lutilisateur. La vue nest pas limite laffichage du modle; elle peut
comprendre des composants graphiques tels que boutons, menus ou encore champs de
saisie, qui permettent lutilisateur dintragir avec lapplication.
La composante Contrleur
Cette dernire composante est responsable du contrle gnral du programme, comme
notamment de lordonnancement des oprations. Dans la plupart des cas, cette compo-
sante ne comprend quune seule classe.
Les avantages obtenus
La mise en oeuvre du modle MVC prsente essentiellement deux avantages:
1/ Maintenance et mise au point
Conu de cette manire, un module sera plus facile mettre au point et maintenir :
la sparation claire des 3 composantes M, V et C permet de localiser facilement la par-
tie corriger ou modifier. Cette dernire sera en gnral, - et avec un peu de chance
-, limite lune ou lautre des 3 composantes, et pourra tre modifie indpendam-
ment des deux autres.
2/ Rutilisation
Si les trois composantes sont fortement dcouples les unes des autres, elles seront fa-
cilement rutilisables dans le cadre de nouvelles applications.
Quelques analogies avec le modle MVC
Dans le monde informatique, on peut retrouver certains principes sous-jacents au modle MVC
dans maintes architectures. Notamment, lide de sparer trs clairement les composantes Prsen-
tation, Informations et Traitements nest pas trangre au concept.
Par exemple, le modle client-serveur 3-tiers dcompose lapplication distribue en
trois couches: Client - Application serveur - Base de donnes. Lobjectif du modle tient
principalement la sparation des 3 composantes:
1/ le Client, on lon trouve tout ce qui a trait la prsentation, et que nous pourrions
assimiler la vue du modle MVC.
2/ le middle-tier: lapplication serveur, qui regroupe tout ce qui concerne les traite-
ments, mais aussi le contrle de lapplication, et qui se rapproche trs fortement du
contrleur du modle MVC.
3/ la base de donnes, dans la quelle sont enregistres les structures de donnes persis-
tantes de lapplication, et que lon pourrait assimiler la partie modle de MVC.
Figure 58: Application Client-Serveur 3-tiers, analogie MVC
On peut citer galement la technologie XML, qui vise sparer la partie Prsentation de
la partie Information, qui sont normalement intimement mlanges au sein des feuilles
HTML. La feuille XML correspondrait au modle, et la feuille XSL la vue. Ce
dcouplage permet davoir plusieurs prsentations possibles appliquer au mme
modle (la feuille XML), ou au contraire davoir plusieurs modles prsents de manire
identique par le biais de la mme feuille XSL.
Navigateur http
J VM
Java
Virtual
Machine
Rseau
Internet
Serveur Web
Applets
Requte http
Pages Web
1
Client Machine serveur
Tlchargement 2
Applet
Serveur d'application
serveur
(2me tier)
Connexion rseau
(protocole RMI,
ou sockets)
3
Serveur de
base de donnes
SGBD
Contrle
et traitements
Vue Modle
Figure 59: XML(modle) +XSL (vue) >HTML
13.2.1Le M comme Modle
Un modle est un objet qui participe la dfinition des donnes manipules par lapplication.
Supposons par exemple une application destine tablir et visualiser le bilan dune
cole telle que la notre. Parmi les modles de notre application, nous trouverons notam-
ment les informations relatives au nombre dinscriptions : nbI nscr i t s, et au nombre
de diplms : nbDi pl ms, pour chaque anne.
Dfinition 41: La couche Modle
La couche Vue est un paquetage qui comprend lensemble des objets modles de
lapplication.
13.2.2Le V comme Vue
Une vue est un objet participant la ralisation de linterface avec lutilisateur. Elle permet :
dune part de visualiser la valeur dun objet modle,
dautre part, et le cas chant, de modifier la valeur dun tel objet.
Une vue est en gnral un objet complexe, composite, qui peut contenir des sous-vues.
Feuille XML
Feuille XSL
Transformation XSLT
HTML WML PDF ...
Feuille XSL
Mode de
prsentation no1
Mode de
prsentation no2
Typiquement, une vue sera compose de graphiques, de champs daffichage, de champs
de saisie, de boutons, etc.. Souvent, on dsigne les vues par le terme anglais GUI
(Graphical User Interface).
Dfinition 42: La couche Vue
La couche Vue est un paquetage qui comprend lensemble des vues de lapplication.
En reprenant lexemple prsent ci-dessus, nous pouvons imaginer que notre modle est
associ 3 vues , qui peuvent treprsentes simultanment :
un graphique, utilis uniquement pour visualiser le modle pour les annes 1997 2001 ;
un graphique, utilis pour visualiser le modle pour une anne spcifique, offrant la pos-
sibilit den modifier la valeur au moyen de deux champs de saisie et dun bouton
OK ;
inscriptions
99 98 00 01
diplms
97
inscriptions
diplms
1999
inscriptions
diplms
263
189
OK
Annul er
un tableur, utilis pour visualiser et pour modifier les donnes du modle.
13.2.3Couplage Vue-Modle: Le modle Observateur
Entre le modle et ses diffrentes vues, MVC sappuie sur le modle observa-
teur, un modle de conception part entire.
Le principe de sparation Modle-Vue
Un constat
On se doit de constater que la partie interface utilisateur dune application est fortement
dpendante de lapplication elle-mme et a peu de chance, ce titre, dtre rutilisable
dune application lautre.
Les autres composants dune application (si ce nest la couche Contrleur) ont par con-
tre plus de chance pouvoir tre rutiliss.
Dfinition 43: Principe de sparation Modle-Vue
Tenant compte de ce qui prcde, il est donc souhaitable quil ny ait aucun couplage, -
ou la limite un couplage trs faible -, entre la Vue et et les autres composants de lappli-
cation, notamment le Modle. Cest ce lon appelle le principe de sparation Modle-Vue.
Objectifs:
Permettre de dvelopper sparment les couches Modle et Vue
Rduire limpact de lvolution des besoins de linterface sur la couche Modle
Permettre dajouter facilement de nouvelles vues sans avoir modifier la couche
Modle
Permettre davoir plusieurs vues simultanes sur le mme objet modle
Permettre de dployer la couche Modle et la couche Vue de manire distribue
(couches communiquant distance sur le rseau).
263 189
OK Annul er
inscriptions diplms
2001
2000
1999
1998
1997 210 165
249 172
204 89
232 93
Amliorer la portabilit, la rutilisation de la couche Modle
Pour appliquer ce principe, on peut remarquer:
Que les objets du Modle ne doivent pas connatre directement les objets de la
Vue et leur demander par exemple dafficher quelque chose, de changer de cou-
leur, etc.
En revanche, les objets de la couche Vue peuvent connatre directement les objets
de la couche Modle. La couche Vue na pas la prtention dtre une couche ruti-
lisable.
Que les objets de la Vue sont dots de peu dintelligence et doivent se contenter de
grer les entres/sorties, de capturer les vnements de linterface, mais ne doi-
vent surtout pas offrir de fonctionnalits propres lapplication (le propre des
composants Modle et/ou Contrleur).
Solution
Modle de scrutation
Une premire solution consiste appliquer le principe de sparation au pied de la
lettre: les objets Modle nenvoient aucun message la couche Vue.
On va mettre en oeuvre un modle de scrutation: les vues qui le dsirent vont
interroger toutes les secondes (par exemple) tous les objets modles qui la concer-
nent de manire rafrachir leur interface.
Modle Observateur (Observable)
Le modle de scrutation peut convenir dans certains cas. Par contre sil sagit
dune application de surveillance, - comme par exemple la surveillance du traffic
dun rseau de tlcommunications -, dune application de simulation sappuyant
sur des milliers dobjets modle, etc. le mode de scrutation peut savrer trs
inefficace.
Le modle Observateur autorise un faible couplage entre la couche Modle et la
couche Vue.
Lide consiste, au niveau de la couche Modle, ne connatre les objets Vue quen
terme dobjets gnriques rpondant une interface rudimentaire qui sera limite
seule et unique mthode de notification de changement dtat.
Principe du modle Observateur
Ce modle dcrit linterdpendance entre un objet (lobservable), qui change dtat, et
tous les objets qui dpendent de ce changement dtat (les observateurs).
Figure 60: Le modle Observateur
Enonc du problme
1. Dcouplage..
Lobjectif du modle est de dcoupler autant que faire ce peut le sujet observable
des observateurs. Ainsi, les classes qui reprsentent lobservable et les classes qui
reprsentent les observateurs pourront tre modifies indpendamment les unes
des autres et pourront tre rutilises sparment.
2. Attente passive: notification par callback
Lobjet observateur sera notifi par callback de loccurrence dun changement
dtat: il sera rappel par le biais dun envoi de message lui signalant lvne-
ment.
Etant dcharg davoir interroger continuellement le sujet observable, lobser-
vateur peut faire de lattente passive, et librer ainsi des ressources systme. Il
peut encore excuter une activit concurrente.
Solution
Lorsque le sujet est modifi, il diffuse des notifications tous ses observateurs:
Coucou, je suis modifi!. Il le fait de manire uniforme, sans connatre la nature des ob-
servateurs.
Les observateurs doivent au pralable avoir souscrit aux notifications, en sabonnant
auprs du sujet.
Une fois notifis, les observateurs interrogent le sujet pour connatre son tat. En rgle
gnrale, les observateurs ne sintressent qu une partie de ltat du modle.
263 189
OK Annul er
inscriptions diplms
2001
2000
1999
1998
1997 210 165
249 172
204 89
232 93
inscriptions
99 98 00 01
diplms
97
inscriptions
diplms
1999
inscriptions
diplms
263
189
OK
Annul er
inscrits=263
dipl=189
1998
1999
inscrits=232
dipl=93
Modle
Vues
Notification de changement
Modification
Diagramme de classes
Voici un diagramme de classes, exprim en UML, pour reprsenter le modle Observable,
en nous plaant dans le cadre du modle MVC
Les diffrentes vues sabonnent au modle en lui envoyant le message aj out e-
r Obser vat eur :
l eModl e. ajouterObservateur ( t hi s) ;
Le modle inscrit chaque nouvel observateur dans une liste dynamique interne.
En rponse toute modification de valeur (comme par exemple via le message
set Val eur ), le modle invoque la mthode prive not i f i er ( ) , qui a pour
effet de diffuser le message mettreAJour() tous les abonns.
Une fois notifie, une vue peut connatre la nouvelle valeur du modle en linter-
rogeant (comme par exemple via le message get Val eur ).
Linterface Obser vat eur
Cette interface doit tre implmente par tous les observateurs qui dsirent sinscrire auprs dun
observable.
Cette interface assure un dcouplage trs fort entre les observateurs et les observa-
bles: le paramtre de la mthode aj out er Obser vat eur est de type Obser vat eur .
Ainsi, la classe mme des observateurs peut tre absolument quelconque pour autant
quon y trouve la mthode met t r eAJ our .
Lobservable na pas connatre ni le nombre ni la nature des classes qui se mettront
son coute. Notamment, lobservable na pas connatre quelle partie de son tat
sintresse lobservateur qui vient de sinscrire: il lui suffira de lui envoyer la notification
met t r eAJ our .
Observable
-listeObservateurs:List
+ajouterObservateur:vo
-notifier:void
Vue
+mettreAJ our:voi
interface
Observateur
+mettreAJour:void
Modele
valeur:int
Implmentation
"valeur" est une proprit, avec un "setter" et un "ge
La classe Obser vabl e
Cette classe met en oeuvre la mcanique dinscription et de notification. Elle peut tre d-
rive (par hritage) par toutes les classes qui implmentent un modle.
Diagramme de squence
Voici maintenant un diagramme de squence illustrant le modle Observateur, exprim
encore une fois en UML.
Dans le cadre de ce scnario, on peut remarquer que la vue 1 a provoqu un changement
dtat du modle. Toutes les vues sont alors notifies - y compris la vue 1 -. En raction,
la vue 2 interroge le modle pour connatre la nouvelle valeur.
13.2.4C comme contrleur
Il arrive frquemment que le contrleur soit absent du modle MVC.
Son rle est de dfinir les ractions face aux actions de lutilisateur (modification de don-
nes, pression de bouton, slection dans une liste, etc..).
Modele
Modele
Vue1
Vue
Vue2
Vue
3.1.2: mettreAJ our():void
3.1.1: mettreAJ our():void
3.1: notifier():void
3: setVal(int):void
1: ajouterObservateur(Observateur):void
3.1.2.1: getVal():int
2: ajouterObservateur(Observateur):void
Typiquement, un contrleur est un algorithme qui va dfinir lordre des oprations
effectuer (le workflow), qui va autoriser ou non les actions commandes par lutilisa-
teur, qui va agir sur laspect des diffrentes vues (en activant ou non tel ou tel bouton,
etc..).
Si le contrleur se contente de jouer les intermdiaires entre le modle et les diffrentes
vues, sans filtrer ou sans ajouter dintelligence spcifique, autant lliminer : on
gagnera en flexibilit et en efficacit.
Si on limine le contrleur, on conseille de placer son intellenge dans le Modle
(on choisira par exemple un des objets modle en lui confiant le rle du contrleur) plu-
tt que dans la Vue, qui doit rester le plus bte possible.
13.3LE MODLE OBSERVATEUR
Ce modle est dcrit au sein mme du modle MVC. Se reporter au paragraphe corres-
pondant [Voir paragraphe - Couplage Vue-Modle: Le modle Observateur - page 185]
13.3.1API Java et le modle Observateur
La librairie J ava met disposition linterface Observer et la classe Observable.
La classe Observable peut tre utilise de deux manires :
Par hritage: en drivant la classe de lobjet observable de la classe Obser va-
bl e;
263 189
OK Ann ul er
inscriptions diplms
2001
2000
1999
1998
1997 210 165
249 172
204 89
232 93
inscriptions
99 98 00 01
diplms
97
inscriptions
diplms
1999
inscriptions
diplms
263
189
OK
Annul er
Modle
Vues
Notification de changement de valeur
Contrle de la vue (aspect, composants)
Contrleur
Notification de changement, Action, Modification de valeur
Par association: si notre observable hrite dj dune autre classe, - et comme
J ava est limit lhritage simple -, il nous suffira dassocier ce dernier une ins-
tance de la classe Obser vabl e qui les messages seront relays.
API Obser ver
interface Obser ver {
publ i c voi d update( Obser vabl e o, Obj ect ar g) ;
}
La mthode updat e est invoque chaque fois que lobjet observ est modifi. Il suffit
dinvoquer la mthode not i f yObser ver s de lobjet observ pour que tous les obser-
vateurs soient notifis.
Paramtres:
o - lobjet observ (utile si le mme observateur observe plusieurs objets diffrents)
arg - un argument pass par la mthode not i f yObser ver s
API Obser vabl e
publ i c voi d addObserver( Obser ver o)
Pour ajouter un nouvel observateur la liste des observateurs de lobjet
publ i c voi d deleteObserver( Obser ver o)
Pour supprimer un observateur de la liste
pr ot ect ed voi d setChanged( )
Pour enregistrer le fait que ltat de cet objet a t modifi: passage du flag
interne modified ltat t r ue.
publ i c voi d notifyObservers( )
Pour notifier tous les observateurs que cet objet a t modifi. Largument ar g
reu par la mthode updat e de lobservateur vaudra nul l .
Cette notification a lieu si et seulement si la mthode set Changed a t invo-
que au pralable. Lexcution de not i f yObser ver s a pour effet de remettre
le flag interne modified f al se.
publ i c voi d notifyObservers( Obj ect ar g)
Pour notifier tous les observateurs lobjet pass en paramtre a t modifi.
Largument ar g sera reu par la mthode updat e de lobservateur (deuxime
paramtre).
Typiquement, cette mthode sera invoque par le modle en mettant la valeur
this en paramtre.
Comme pour not i f yObser ver s( ) , cette notification a lieu si et seulement si
la mthode set Changed a t invoque au pralable. Lexcution de not i f y-
Obser ver s a pour effet de remettre le flag interne modified f al se.
13.3.2Le modles des listeners
Le modle Observable est efficace dans la mesure o lobservable ne gnre quun seul type
dvnements. Dans le cas contraire, les observateurs risquent dtre notifis pour des vnements
qui ne les intressent pas forcment, gnrant une perte defficacit de lapplication.
A titre dexemple, considrons lexemple du composant Swing J But t on en J ava. Ce
dernier est susceptible de gnrer diffrents types dvnements:
Des vnements de type Action (bouton press);
Des vnements de type Focus (le bouton a obtenu le focus);
Des vnements de type Key (une touche a t presse alors que le bouton a le
focus);
Des vnements de type MouseMotion (la souris est dplace sur le bouton);
etc..
Lapplication directe du modle Observateur impliquerait un abonnement tout lensem-
ble des vnements, mme si seule la pression du bouton nous intresse. Pour viter cette
lourdeur, les concepteurs du langage ont mis en place un modle inspir du modle
Observateur. Intitul modle des listeners, ce modle permet tout observateur poten-
tiel de sabonner uniquement un sous-ensemble particulier dvnements. A cette fin,
des mthodes spcifiques dinscription sont mises disposition: addAct i onLi st ener ,
addFocusLi st ener , addKeyLi st ener , etc...
13.4MVC ET LE PATTERN COUCHES
Un simple modle de conception son origine, le modle MVC a fait longue route!
Il a t intgr depuis dans le pattern architectural Couches (Layers). Un pattern qui
sert de base llaboration de la structure grande chelle dun systme.
On y retrouve la Vue (couche Prsentation), le Modle (couche Domaine) et le Contr-
leur (couche Application)
Figure 61: Le pattern Couches (Layers)
Presentation
(Alias Interface, UI, Vue
Application
(Alias Workflow, Process,
Mediation, App Controller)
Domaine
(Alias Mtier,
Services Mtier, Modle)
Services techniques
(Alias Infrastructure technique,
Services techniques de haut niveau)
Fondation
(Alias Services de base,
Infrastructure ou Services techniques de bas niveau)
La largeur de la couche dnote le degr de rutilisation potentiel
Fentres GUI
Rapports
Interface vocale
HTML, XML, XSLT, J SP, J avascript, ...
Prise en charge des requtes de la couche
Prsentation
Workflow (enchanement des oprations)
Etat des sessions
Transition des fentres
Prparation des donnes pour la
prsentation
Prise en charge des requtes de la couche
Application
Implmentation des rgles mtier
Implmentation des services du domaine
(POS, Inventaire)
Services techniques de niveau
relativement haut
P.e: frameworks de Persistence, Security
Services techniques et frameworks de bas
niveau
P.e: threads, maths, fichiers, Base de
donnes, accs rseau et I/O
Spcifique
lapplication
D
p
e
n
d

d
e
Infrastructure mtier
(Alias Services mtier de bas niveau)
Services de bas niveau utiliss souvent
dans de nombreux domaines mtier
P.e: convertisseur de devises

Genie Logiciel

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Genie Logiciel

Uploaded by

Copyright:

Available Formats

Ecole dIngnieurs de lEtat de Vaud - 15 septembre 2006

You might also like