e Processus unifi

de

dveloppement logiciel

Ivar Jacobson Grady Booch James Rumbaugh

UNIRED MODELING LANGUAGE

DITIONS EYROLLES 61, Bld Saint-Germain 75240 Paris Cedex 05 www.editions-eyrolles.com

Table des matires

H lu, lion autorise de l'ouvrage en langue anglaise intitul I Ongman, a Pearson Education Company, 1999, ISBN 0-201-57169-2 Traduit de l'anglais par Virginie Zam Validation technique : Jrme Desquilbet

The Unified Software Development Process,

Avant propos Qu'est-ce qu'un processus de dveloppement logiciel ? Objectifs du livre qui s'adresse ce livre ? Approche du livre Historique du Processus unifi L'approche Ericsson S D L : Langage de spcification et de description Objectory L'approche de Rational Processus Rational Objectory : 1995-1997 U M L : Unified Modeling Language Rational Unified Process Remerciements

l 2 3 3 4 4 5 6 V 8 9 9 10 10

e r

Pour leur contribution cet ouvrage Pour leur collaboration fidle depuis des annes Nous voudrions particulirement remercier Un processus en marche

10 11 12 12

I proprit intellectuelle du 1 juillet 1992 interdit en effet expressment la photocollcctif sans autorisation des ayants droit. Or, cette pratique s'est gnralise notaml;iblissements d'enseignement, provoquant une baisse brutale des achats de livres, au Possibilit mme pour les auteurs de crer des uvres nouvelles et de les faire diter BSl aujourd'hui menace. i de la loi du 11 mars 1957, i l est interdit de reproduire intgralement ou partielt quelque support que ce soit, sans autorisation de l'diteur ou du Centre Franais lopie, 20, rue des Grands Augustins, 75006 Paris, i ducation Company, 1999 pour l'dition en langue anglaise our la prsente dition, ISBN 2-212-09142-7

Table des matires

III 37 37 37 39 40

dessus unifi uoioppement logiciel

mu i
,><:essus unifi : pilot par l e s c a s d'utilisation, itr s u r l'architecture, itratif et incrmental i i . Processus unifi en bref

2.4 Le processus dirige les projets 2.4.1 Le processus : un cadre gnrique 2.4.2 Les relations entre activits constituent les enchanement d'activits 2.4.3 Spcialisation du processus 2.4.4 Les mrites d'un processus

15 16 17 18 19
2 1

11 Processus unifi est pilot par les cas d'utilisation

\ ,c Processus unifi est centr sur l'architecture 11 Processus unifi est itratif et incrmental

2.5 Les outils font partie intgrante du processus 2.5.1 Les outils influent sur le processus 2.5.2 Le processus conditionne les outils 2.5.3 quilibre entre processus et outils 2.5.4 La modlisation visuelle au service d'UML 2.5.5 Les outils prennent en charge tout le cycle de vie 2.6 Rfrences
CHAPITRE 3

41 41 41 42 43 44 44

**

11 ,n vi' du Processus unifi I * I IM produit > 1.5.2 Les phases d'un cycle

21 . 23

Un p r o c e s s u s pilot par l e s c a s d'utilisation 3.1 Le dveloppement pilot par les cas d'utilisation en bref

47 49

Un processus intgr
un ipiiiinr P du dveloppement logiciel : t o n n e s , projet, produit et p r o c e s s u s I pri sonnes jouent un rle crucial i i l es processus de dveloppement ont un impact m les personnes i ' l r > . rles changent ' M l )CN ressources aux travailleurs

25

27 28 28 29 30

3.2 Pourquoi les cas d'utilisation ? 3.2.1 Pour apprhender les vritables besoins 3.2.2 Pour diriger le processus 3.2.3 Pour mettre au point l'architecture et plus encore 3.3 Capture des cas d'utilisation 3.3.1 Le modle des cas d'utilisation reprsente les besoins fonctionnels 3.3.2 Les acteurs constituent l'environnement du systme 3.3.3 Les cas d'utilisation spcifient le systme

51 51 52 54 54 54 55 56 57 57 62 62 65 67 68 70 70

| Tel projet, tel produit

32

I I lu produit ne se rsume pas du code | I Qu'es) ce qu'un systme logiciel ? I..S.Z I .i\ artefacts i | l In systme dispose de plusieurs modles i i H, isi-ce qu'un modle ? ( haque modle est une vue autonome du systme ' i d Exploration d'un modle | / Relations entre modles

32 33 33 34 35 35 36 36

3.4 L'analyse, la conception et l'implmentation pour la ralisation des cas d'utilisation 3.4.1 Cration du modle d'analyse partir des cas d'utilisation 3.4.2 Chaque classe doit assumer tous ses rles de collaboration 3.4.3 Cration du modle de conception partir du modle d'analyse 3.4.4 Les sous-systmes regroupent les classes 3.4.5 Cration du modle d'implmentation partir du modle de conception 3.5 Tests des cas d'utilisation 3.6 Rsum 3.7 Rfrences

Table des matires

Table des matires

CHAPITRE 4

Un p r o c e s s u s centr s u r l ' a r c h i t e c t u r e ,

5.3 L'approche itrative est guide par la rduction des risques 5.3.1 Les itrations attnuent lesrisquestechniques 5.3.2 Les responsables ont la charge des risques non techniques 5.3.3 Traiter les risques 5.4 L'itration gnrique 5.4.1 Qu'est-ce qu'une itration ? 5.4.2 Planifier les itrations 5.4.3 Squencer les itrations 5.5 Une itration se traduit par un incrment 5.6 Itrations dans le cycle de vie

109 110 112 \YL 113 113 115 H6 116 117

4.1 L'architecture en bref 4.2 Pourquoi il nous faut une architecture . 4.2.1 Comprendre le systme 4.2.2 Organiser le dveloppement 4.2.3 Favoriser la rutilisation 4.2.4 Faire voluer le systme

71 72 74 75 75 76 76 78 81 82 84 86 89

4.3 Cas d'utilisation et architecture 4.4 tapes d'laboration de l'architecture 4.4.1 L'architecture de rfrence est un systme petit et maigre 4.4.2 Utilisation des patterns d'architecture 4.4.3 Description de l'architecture 4.4.4 C'est l'architecte qui cre l'architecture
1

5.7 Les modles voluent partir des itrations 5.8 Les itrations remettent en question l'organisation 5.9 Rfrences

120 121 122

PARTIE I I

4.5 Enfin, une description de l'architecture ! 4.5.1 Vue architecturale du modle des cas d'utilisation . 4.5.2 Vue architecturale du modle de conception 4.5.3 Vue architecturale du modle de dploiement 4.5.4 Vue architecturale du modle d'implmentation . . . 4.6 Trois concepts intressants 4.6.1 Qu'est-ce que l'architecture ? 4.6.2. Comment l'obtient-on ? 4.6.3 Comment la dcrit-on ? 4.7 Rfrences
CHAPITRE 5

90 91 91 94 95 96 96 96 96
97

Les enchanements d'activits principaux

CHAPITRE 6

123
125 126 127 127 132

Expression d e s besoins : de la vision aux besoins 6.1 Pourquoi l'expression des besoins est-elle dlicate ? 6.2 Objectif de l'enchanement d'activits des besoins 6.3 Prsentation gnrale de l'expression des besoins

Un p r o c e s s u s itratif et incrmental 5.1 Le dveloppement itratif et incrmental en bref 5.1.1 Procder par tapes modestes 5.1.2 Ce que n'est pas une itration

99 100 101 102

6.4 Rle des besoins dans le cycle de vie du logiciel 6.5 Comprhension du contexte du systme l'aide d'un modle du domaine 6.5.1 Qu'est-ce qu'un modle du domaine ? 6.5.2 laboration d'un modle du domaine 6.5.3 Utilisation du modle du domaine 6.6 Comprhension du contexte du systme l'aide d'un modle du mtier 6.6.1 Qu'est-ce qu'un modle du mtier ? 6.6.2 laboration d'un modle du mtier 6.6.3 Identification des cas d'utilisation partir d'un modle du mtier

133 133 135 136 136 137 139 141

5.2 Pourquoi un dveloppement itratif et incrmental ? 5.2.1 Rduire les risques 5.2.2 Obtenir une architecture robuste 5.2.3 Grer les exigences de changement 5.2.4 Permettre des changements tactiques 5.2.5 Parvenir une intgration continue 5.2.6 Accder trs tt la connaissance

103 103 105 106 106 107 108

Table des matires

Table des matires

VII 195

6.7 Exigences supplmentaires 6.8 Rsum 6.9 Rfrences

CHAPITRE 7

143 144 144

8.3 Rle de l'analyse dans le cycle de vie du logiciel

Expression d e s besoins s o u s forme de c a s d'utilisation . . . 7.1 Introduction 7.2 Artefacts 7.2.1 Artefact : modle des cas d'utilisation 7.2.2 Artefact : acteur 7.2.3 Cas d'utilisation 7.2.4 Artefact : description de l'architecture (vue du modle des cas d'utilisation) 7.2.5 Artefact : glossaire 7.2.6 Artefact : prototype d'interface utilisateur

147 147 149 149 150 151 155 155 156

8.4 Artefacts 8.4.1 Artefact : modle d'analyse 8.4.2 Artefact : classe d'analyse 8.4.3 Artefact : ralisation-analyse de cas d'utilisation 8.4.4 Artefact : paquetage d'analyse 8.4.5 Artefact : description de l'architecture (vue du modle d'analyse) 8.5 Travailleurs 8.5.1 Travailleur : architecte 8.5.2 Travailleur : ingnieur de cas d'utilisation 8.5.3 Travailleur : ingnieur de composants 8.6 Enchanement d'activits 8.6.1 Activit : analyse architecturale 8.6.2 Activit : analyser un cas d'utilisation 8.6.3 Activit : analyser une classe 8.6.4 Activit : analyser un paquetage 8.7 Rsum de l'analyse 8.8 Rfrences
CHAPITRE 9

197 197 198 202 206 209 210 210 210 211 212 213 219 223 227 228 230

7.3 Les travailleurs 7.3.1 Travailleur : analyste systme 7.3.2 Travailleur : spcificateur de cas d'utilisation 7.3.3 Travailleur : concepteur d'interface utilisateur 7.3.4 Travailleur : architecte

156 156 157 158 158 159 160 169 170 176 182 186 187

Conception 9.1 Introduction 9.2 Rle de la conception dans le cycle de vie du logiciel

231 231 232

7.4 Knchanement d'activits 7.4.1 Activit : identifier les acteurs et les cas d'utilisation 7.4.2 Activit : dfinir un ordre de priorit pour les cas d'utilisation 7.4.3 Activit : dtailler un cas d'utilisation 7.4.4 Activit : prototyper l'interface utilisateur 7.4.5 Activit : structurer le modle des cas d'utilisation 7.5 Rsum de l'enchanement d'activits des besoins 7.6 Rfrences
CHAPITRE 8

233 233 234 237 240 242 243 244 245

Analyse 8.1 Introduction 8.2 L'analyse en bref 8.2.1 Pourquoi l'analyse n'est ni la conception, ni l'implmentation... 8.2.2 Objectif de l'analyse : rsum 8.2.3 Quand employer l'analyse : exemples concrets

189 189 192 193 194 194

9.3 Artefacts 9.3.1 Artefact : modle de conception 9.3.2 Artefact : classe de conception 9.3.3 Artefact : ralisation-conception de cas d'utilisation 9.3.4 Artefact : sous-systme de conception 9.3.5 Artefact : interface 9.3.6 Artefact : description de l'architecture (vue du modle de conception) 9.3.7 Artefact : modle de dploiement 9.3.8 Artefact : description de l'architecture (vue du modle de dploiement)

Table des matires

Table des matires

IX

CHAPITRE 11

Test 11.1 Introduction 11.2 Rle des tests dans le cycle de vie du logiciel

311 311 312

9.4 Travailleurs 9.4.1 Travailleur : architecte 9.4.2 Travailleur : ingnieur de cas d'utilisation 9.4.3 Travailleur : ingnieur de composants 9.5 Enchanement d'activits 9.5.1 Activit : conception architecturale 9.5.2 Activit : concevoir un cas d'utilisation 9.5.3 Activit : concevoir une classe 9.5.4 Activit : concevoir un sous-systme 9.6 Rsum de la conception 9.7 Rfrences
CHAPITRE 10

245 245 246 247 248 248 264 271 278 280 281 283

11.3 Artefacts 11.3.1 Artefact 11.3.2 Artefact 11.3.3 Artefact 11.3.4 Artefact 11.3.5 Artefact 11.3.6 Artefact 11.3.7 Artefact

: modle des tests : cas de test : procdure de test : composant de test : plan des tests : anomalie : valuation des tests

313 313 314 316 317 318 318 318

Implmentation 10.1 Introduction < 10.2 Rle de l'implmentation dans le cycle de vie du logiciel 10.3 Artefacts 10.3.1 Artefact : modle d'implmentation 10.3.2 Artefact : composant 10.3.3 Artefact : sous-systme d'implmentation 10.3.4 Artefact : interface 10.3.5 Artefact : description de l'architecture (vue du modle d'implmentation) 10.3.6 Artefact : plan de construction des intgrations 10.4 Travailleurs 10.4.1 Travailleur : architecte 10.4.2 Travailleur : ingnieur de composants 10.4.3 Travailleur : intgrateur systme

283 284 285 285 285 288 289 291 291 293 293 294 294

11.4 Travailleurs 11.4.1 Travailleur 11.4.2 Travailleur 11.4.3 Travailleur 11.4.4 Travailleur

: concepteur de tests : ingnieur de composants : testeur d'intgration : testeur systme

318 318 319 319 319 320 321 322 325 326 327 328 329 329

11.5 Enchanement d'activits 11.5.1 Activit : planifier les tests 11.5.2 Activit : concevoir les tests 11.5.3 Activit : implmenter les tests 11.5.4 Activit : effectuer les tests d'intgration 11.5.5 Activit : effectuer les tests systme 11.5.6 Activit : valuer les tests 11.6 Rsum des tests 11.7 Rfrences

PARTIE I I I

Un dveloppement itratif et incrmental

CHAPITRE 12

331
333 334 335 335

10.5 Enchanement d'activits 10.5.1 Activit : implmenter l'architecture 10.5.2 Activit : intgrer le systme 10.5.3 Activit : implmenter un sous-systme 10.5.4 Activit : implmenter une classe 10.5.5 Activit : effectuer les tests unitaires 10.6 Rsum de l'implmentation 10.7 Rfrences

295 296 298 301 304 305 309 309

Enchanement d'activits de l'itration gnrique 12.1 Le besoin d'quilibre 12.2 Les phases constituent la premire division du travail 12.2.1 La phase de cration tablit la faisabilit

Table des matires

Table des matires

XI

CHAPITRE 13

12.2.2 La phase d'laboration s'intresse la capacit de ralisation 12.2.3 La phase de construction construit le systme 12.2.4 La phase de transition aborde l'environnement utilisateur . . . .

336 337 337 338 338 339 341 341 342 343 343

L a phase de cration lance le projet 13.1 L a phase de cration en bref 13.2 Premiers stades de la phase de cration 13.2.1 Avant le dbut de la phase de cration 13.2.2 Planifier la phase de cration 13.2.3 largir la vision du systme 13.2.4 Dfinir les critres d'valuation 13.3 Enchanement d'activits de l'itration typique de cration 13.3.1 Introduction aux cinq enchanements d'activits principaux . . . 13.3.2 Adapter le projet l'environnement de dveloppement 13.3.3 Identifier lesrisquescritiques

359 359 360 360 361 362 362 364 365 366 367

12.3 L'itration gnrique revisite 12.3.1 Les enchanements d'activits principaux se rptent chaque itration 12.3.2 Les travailleurs prennent part aux enchanements d'activits 12.4 La planification prcde l'action 12.4.1 Planifier les quatre phases 12.4.2 Planifier les itrations 12.4.3 Penser long terme 12.4.4 Planifier les critres d'valuation

risques

345 345 346 346

13.4 Excuter les enchanements d'activits principaux : des besoins aux tests 13.4.1 Formuler les besoins 13.4.2 Analyse 13.4.3 Conception 13.4.4 Implmentation 13.4.5 Tests 13.5 laborer l'tude de rentabilit initiale 13.5.1 Tracer les grandes lignes de l'offre 13.5.2 Estimer le retour sur investissement 13.6 valuer les itrations dans la phase de cration 13.7 Planifier la phase d'laboration 13.8 lments livrer l'issue de la phase de cration
CHAPITRE 14

367 368 371 372 373 373 373 374 375 375 376 378

12.5 Lesrisquesaffectent la planification du projet 12.5.1 Grer une liste des risques 12.5.2 Les risques affectent le plan des itrations 12.5.3 Planifier les actions entreprendre face aux 12.6 Dfinition d'un ordre de priorit pour les cas d'utilisation 12.6.1 Risques spcifiques un produit particulier 12.6.2 Risques de crer une architecture inadapte 12.6.3 Risque de ne pas bien comprendre les besoins

347 348 348 349

12.7 Ressources ncessaires 12.7.1 Les projets diffrent normment 12.7.2 Voici quoi ressemble gnralement un projet 12.7.3 A projets complexes, besoins suprieurs 12.7.4 Une nouvelle ligne de produits exige de l'exprience 12.7.5 II faut payer le prix des ressources utilises 12.8 valuer les itrations et les phases 12.8.1 Les critres ne sont pas remplis 12.8.2 Les critres eux-mmes 12.8.3 L'itration suivante 12.8.4 volution de l'ensemble des modles

350 351 352 352 353 354 355 356 356 356 357

L a phase d'laboration fabrique l'architecture de rfrence 14.1 L a phase d'laboration en bref 14.2 Premiers stades de la phase d'laboration 14.2.1 Planifier la phase d'laboration 14.2.2 Constituer l'quipe 14.2.3 Modifier l'environnement de dveloppement 14.2.4 Dfinir les critres d'valuation

379 379 380 380 381 381 381

Table des m a t i r e s

CHAPITRE 13 336 337 337 338 338 339

La phase de cration lance le projet

13.1 L a phase de cration en bref 13.2 Premiers stades de la phase de cration 13.2.1 Avant le dbut de la phase de cration 13.2.2 Planifier la phase de cration 13.2.3 largir la vision du systme 13.2.4 Dfinir les critres d'valuation 13.3 Enchanement d'activits de l'itration typique de cration 13.3.1 Introduction aux cinq enchanements d'activits principaux . . . 13.3.2 Adapter le projet l'environnement de dveloppement 13.3.3 Identifier les risques critiques

359
359 360 360 361 362 362 364 365 366 367

12.2.2 La phase d'laboration s'intresse la capacit de ralisation 12.2.3 La phase de construction construit le systme 12.2.4 La phase de transition aborde l'environnement utilisateur . . . . 12.3 L'itration gnrique revisite 12.3.1 Les enchanements d'activits principaux se rptent chaque itration 12.3.2 Les travailleurs prennent part aux enchanements d'activits 12.4 L a planification prcde l'action 12.4.1 Planifier les quatre phases 12.4.2 Planifier les itrations 12.4.3 Penser long terme 12.4.4 Planifier les critres d'valuation 12.5 Les risques affectent la planification du projet 12.5.1 Grer une liste des risques 12.5.2 Les risques affectent le plan des itrations 12.5.3 Planifier les actions entreprendre face aux risques 12.6 Dfinition d'un ordre de priorit pour les cas d'utilisation 12.6.1 Risques spcifiques un produit particulier 12.6.2 Risques de crer une architecture inadapte 12.6.3 Risque de ne pas bien comprendre les besoins

341 341 342 343 343 345 345 346 346 347 348 348 349

13.4 Excuter les enchanements d'activits principaux : des besoins aux tests 13.4.1 Formuler les besoins 13.4.2 Analyse 13.4.3 Conception 13.4.4 Implmentation 13.4.5 Tests 13.5 laborer l'tude de rentabilit initiale 13.5.1 Tracer les grandes lignes de 1 ' offre 13.5.2 Estimer le retour sur investissement 13.6 valuer les itrations dans la phase de cration 13.7 Planifier la phase d'laboration 13.8 lments livrer l'issue de la phase de cration CHAPITRE 14

367 368 371 372 373

3 7 3

373 374 375 375 376 378

12.7 Ressources ncessaires 12.7.1 Les projets diffrent normment 12.7.2 Voici quoi ressemble gnralement un projet 12.7.3 A projets complexes, besoins suprieurs 12.7.4 Une nouvelle ligne de produits exige de l'exprience 12.7.5 I I faut payer le prix des ressources utilises ,

350 351 352 352 353 354

La phase d'laboration fabrique l'architecture de rfrence

14.1 L a phase d'laboration en bref 14.2 Premiers stades de la phase d'laboration 14.2.1 Planifier la phase d'laboration 14.2.2 Constituer l'quipe 14.2.3 Modifier l'environnement de dveloppement 14.2.4 Dfinir les critres d'valuation

379
379 380 380 381 381 381

12.8 valuer les itrations et les phases 12.8.1 Les critres ne sont pas remplis 12.8.2 Les critres eux-mmes 12.8.3 L'itration suivante 12.8.4 volution de l'ensemble des modles

355 356 356 356 357

Table des m a t i r e s

XIII

CHAPITRE 16 382 383 384 384 384 386 388 392 395 397 398 398 399 399 400 401

La phase de transition finalise le produit

16.1 L a phase de transition en bref 16.2 Premiers stades de la phase de transition 16.2.1 Planifier la phase de transition 16.2.2 Constituer l'quipe de la phase de transition 16.2.3 Dfinir les critres d'valuation 16.3 Les enchanements d'activits principaux jouent un rle mineur dans cette phase

419
420 421 421 423 423 424

14.3 Enchanements d'activits de l'itration typique d'laboration 14.3.1 Formuler et affiner la plupart des besoins 14.3.2 Dvelopper 1 'architecture de rfrence 14.3.3 Procder des itrations tant que l'quipe est rduite 14.4 Excuter les enchanements d'activits principaux : des besoins aux tests 14.4.1 Formuler les besoins 14.4.2 Analyse 14.4.3 Conception 14.4.4 Implmentation 14.4.5 Tests 14.5 laborer l'tude de rentabilit 14.5.1 Prparer l'offre commerciale 14.5.2 Actualiser le retour sur investissement 14.6 valuer les itrations de la phase d'laboration 14.7 Planifier la phase de construction 14.8 Principaux lments livrer CHAPITRE 15

16.4 Activits de la phase de transition 16.4.1 Livrer la version bta 16.4.2 Installer la version bta 16.4.3 Rpondre aux rsultats des tests 16.4.4 Adapter le produit aux divers environnements utilisateur 16.4.5 Finaliser les artefacts 16.4.6 Quand le projet se termine-t-il ? 16.5 Achever l'tude de rentabilit 16.5.1 Matriser la progression 16.5.2 Rviser le plan stratgique

425 425 426 426 427 429 429 429 430 430

La construction aboutit la capacit oprationnelle initiale

15.1 L a phase de construction en bref 15.2 Premiers stades de la phase de construction 15.2.1 Constituer l'quipe de la phase 15.2.2 Dfinir les critres d'valuation 15.3 Enchanements d'activits de l'itration typique de construction

403
403 404 405 405 406

16.6 valuer la phase de transition 16.6.1 valuer les itrations et la phase 16.6.2 Post mortem du projet 16.7 Planifier la version ou la gnration suivante 16.8 Principaux lments livrer CHAPITRE 17

430 431 431 432 432

Application optimale du Processus unifi

17.1 L e Processus unifi aide grer la complexit 17.1.1 Les objectifs du cycle de vie 17.1.2 L'architecture du cycle de vie 17.1.3 Capacit oprationnelle initiale 17.1.4 Livraison du produit 17.2 Les principaux thmes

433
433 434 434 435 435 435

15.4 Excuter les enchanements d'activits principaux : des besoins aux tests 15.4.1 Besoins 15.4.2 Analyse 15.4.3 Conception 15.4.4 Implmentation 15.4.5 Tests 15.5 Matriser l'tude de rentabilit 15.6 valuer les itrations et la phase de construction 15.7 Planifier la phase de transition 15.8 Principaux lments livrer

408 409 410 411 413 414 416 416 417 417

17.3 Les responsables dirigent la transition vers le Processus unifi 17.3.1 Les raisons d'agir 17.3.2 La directive de ringnierie achve de convaincre 17.3.3 Mettre en uvre la transition

436 437 438 439

Table des m a t i r e s

17.4 Spcialiser le Processus unifi 17.4.1 Adapter le Processus 17.4.2 toffer l'infrastructure du Processus 17.5 largir le cercle de ses interlocuteurs 17.6 Profiter des avantages qu'offre le Processus unifi 17.7 Rfrences ANNEXE A

441 441 442 442 443 444

Avant-propos

Prsentation gnrale du langage UML

A . l Introduction A. 1.1 Vocabulaire A . 1.2 Mcanismes d'extensibilit

445
445 446 446

Une croyance, qui a cours chez certains, veut que les entreprises organisent leur activit autour d'un petit groupe d'individus aux comptences suprieures. Ces personnes censes connatre leur travail le feraient le plus naturellement du monde, sans directives ni procdures internes !

A.2 Notation graphique A.2.1 lments structurels A.2.2 lments comportementaux A.2.3 lments de regroupement A.2.4 lments d'annotation A.2.5 Relations de dpendance A.2.6 Relations d'association A.2.7 Relations de gnralisation A.2.8 Mcanismes d'extensibilit A.3 Glossaire A. 4 Rfrences ANNEXE B

"

447 447 448 449 449 450 450 450 451 451 459

Croyance errone dans la plupart des cas, et qui se rvle particulirement dommageable dans le cas du dveloppement logiciel. Certes, les dveloppeurs logiciels connaissent leur affaire, mais la profession est encore jeune. I l leur faut donc des directives internes que nous dsignons, dans ce livre, sous le nom de processus de dveloppement logiciel . En outre, le processus prsent dans ces pages rsultant de l'association de plusieurs mthodes auparavant indpendantes, nous nous estimons fonds le nommer Processus unifi . Ce processus fusionne non seulement le travail des trois auteurs, mais il intgre, en plus, les apports de nombreux autres intervenants et entreprises ayant contribu l'laboration d'UML, auxquels s'ajoutent un bon nombre de collaborateurs-cls de Rational Software Corporation. Ce processus, enfin, s'enrichit, de l'exprience du terrain de centaines d'entreprises qui utilisent chaque jour les versions antrieures de ce processus sur des sites clients.

Extensions du langage UML spcifiques au Processus unifi 461

B. l Introduction B.2 Strotypes B.3 Valeurs marques B.4 Notation graphique B. 5 Rfrences ANNEEXE C 461 461 464 464 465 .

Prenons l'image d'un chef d'orchestre symphonique. Pendant un concert, son rle se borne essentiellement donner le signal du dpart aux musiciens et faire en sorte qu'ils restent ensemble. Mais cela n'est possible, toutefois, que grce aux nombreuses rptitions et parce que chacun des musiciens matrise parfaitement son instrument et en joue indpendamment des autres musiciens de l'orchestre. De manire plus significative pour le sujet qui nous occupe, chaque musicien suit un processus tabli l'avance par le compositeur. C'est la partition musicale qui fournit la base des politiques et procdures guidant l'excution de l'uvre. Les dveloppeurs logiciels, en revanche, ne jouent pas de faon indpendante. Ils sont en interaction non seulement les uns avec les autres, mais aussi avec les utilisateurs. Et ils n'ont aucune partition suivre... tant qu'on ne leur fournit pas de processus.

Glossaire gnral
C. l Introduction C.2 Termes

467
467 467

Il est clair que le besoin de processus va se ressentir de plus en plus fortement, en particulier dans les entreprises dont les systmes informatiques jouent un rle stratgique : systmes financiers, systmes de contrle du trafic arien, de dfense et de tlcommunications, entre autres. Par stratgique , nous entendons que la russite ou l'accomplissement de la mission de ces entreprises ou services publics dpend du systme logiciel qui les sous-tend.

Avant-propos

3 Or, ces systmes se complexifient de jour en jour, alors mme que leurs dlais de livraison ne cessent de s'amenuiser, ce qui accrot d'autant la difficult de leur dveloppement. Toutes ces raisons expliquent que l'industrie logicielle ait besoin d'un processus capable de guider les dveloppeurs, tout comme un orchestre se fonde sur la partition du compositeur pour donner des concerts. loigns des automates sur lesquels Frederick W. Taylor fondait sa gestion scientifique , i l y a un sicle. Le crateur du processus doit adapter son processus notre poque, en particulier aux ralits de l'organisation virtuelle du travail : le travail distance par l'intermdiaire de lignes haut dbit ; la collaboration d'actionnaires (dans les petites PME/start-ups), d'employs salaris, de travailleurs indpendants et d'employs de SSII ; enfin, la pnurie continuelle de dveloppeurs logiciels.

Su'est-ce qu'un processus de d v e l o p p e m e n t logiciel ?

Un processus dfinit qui fait quoi quel moment et de quelle faon pour atteindre un certain objectif. Dans le domaine de l'ingnierie logicielle, le but consiste laborer un produit logiciel ou en amliorer un existant. Un processus digne de ce nom doit fournir des directives garantissant le dveloppement efficace de logiciels de qualit et prsenter un ensemble de bonnes pratiques autorises par l'tat de l'art. Ces dispositions permettent de rduire les risques tout en amliorant la prvisibilit. I l s'agit, d'un point de vue plus gnral, de promouvoir une vision et une culture communes.

Il est indispensable de trouver, entre ces quatre types de facteurs, un quilibre capable de subsister dans le temps. Le crateur du processus doit concevoir un processus volutif, tout comme un dveloppeur logiciel doit faire en sorte que son systme soit oprationnel non pas seulement aujourd'hui, mais dans les annes venir. D'autant qu'un processus doit voluer plusieurs annes avant d'atteindre le niveau de stabilit et de maturit qui lui permettra de rsister la rigueur du dveloppement de produits commerciaux, tout en maintenant un niveau raisonnable les risques lis son utilisation. Le dveloppement d'un nouveau produit tant assez risqu en soi, i l est inutile d'y ajouter les risques induits par un processus insuffisamment test dans la ralit. Le processus doit donc tre stable. Sans cet quilibre entre technologies, outils, personnes et organisation, l'utilisation du processus serait prilleuse.

Un tel processus est indispensable et doit servir de fil d'Ariane toutes les parties en prsence : clients, utilisateurs, dveloppeurs et responsables. Toutefois, n'importe quel processus ne fera pas l'affaire. I l faut absolument disposer de ce que l'industrie est capable de produire de meilleur au moment du dveloppement. Ce processus doit, par ailleurs, tre largement accessible afin que toutes les personnes impliques puissent en comprendre le rle dans le dveloppement en question. Un processus de dveloppement logiciel doit galement pouvoir voluer pendant de nombreuses annes, tout en hmitant sa porte ce que permet chaque instant la ralit des technologies, des outils, des personnes et des structures organisationnelles. Technologies. Le processus doit reposer sur des technologies (langages de programmation, systmes d'exploitation, systmes informatiques, capacits rseau, environnements de dveloppement, etc.) exploitables au moment de l'utilisation du processus. Par exemple, i l y a vingt ans, la modlisation visuelle n'tait gure rpandue. Elle tait trop onreuse. l'poque, la personne charge d'laborer le processus devait considrer comme pratiquement acquis que les diagrammes seraient effectus la main. Cette hypothse limitait considrablement les possibilits d'intgration de la modlisation au sein du processus. Outils. Le processus et les outils doivent tre dvelopps en parallle, ces derniers faisant partie intgrante du processus. En d'autres termes, un processus largement utilis peut supporter l'investissement ncessaire la mise au point des outils le prenant en charge. Personnes. Le crateur du processus doit limiter les comptences ncessaires son utilisation celles que possdent dj les dveloppeurs ou viser des comptences pouvant tre rapidement acquises. Dans bien des domaines, i l est dsormais possible d'intgrer dans des outils informatiss des techniques telles que la vrification de la cohrence des modles graphiques qui rclamaient auparavant des comptences tendues. Modles organisationnels. Si les dveloppeurs logiciels ne jouissent pas de la mme indpendance que les membres d'un orchestre symphonique, ils sont toutefois bien

Objectifs du livre
Cet ouvrage prsente le processus logiciel que nous avions constamment l'esprit en mettant au point le langage UML (Unified Modeling Language - Langage de modlisation unifi -). Si UML fournit un moyen standard de visualiser, spcifier, construire, documenter et communiquer les artefacts d'un systme logiciel prpondrant, nous admettons, bien entendu, qu'un tel langage doit tre utilis dans le cadre d'un processus logiciel complet. UML est un moyen, ce n'est absolument pas une fin en soi. L'objectif est d'obtenir une application logicielle robuste, rsistante et volutive. Pour parvenir ce but, il faut la fois un processus et un langage ; l'aspect processus est l'objet de cet ouvrage. L'annexe sur UML fourme dans ce livre ne vise en aucune faon l'exhaustivit. Vous trouverez une prsentation didactique dtaille d'UML dans Le Guide de l'utilisateur d'UML [11], et pourrez constamment vous rfrer au Manuel de rfrence d'UML [12].

qui s'adresse ce livre ?

Le Processus unifi de dveloppement logiciel peut tre utilis par toute personne prenant part au dveloppement de logiciels. I l s'adresse avant tout aux membres de l'quipe de dveloppement chargs des activits du cycle de vie que sont la formulation des besoins, l'analyse, la conception, l'implmentation et les tests ; en d'autres termes, des activits produisant des modles UML. Cet ouvrage sera donc utile aux analystes et utilisateurs finals (qui spcifient la structure et le comportement souhaits d'un systme), aux dveloppeurs d'applications (qui conoivent les systmes satisfaisant ces exigences), aux programmeurs (qui transforment ces conceptions en code excutable), aux testeurs (qui vrifient et valident la structure et le comportement du systme), aux dveloppeurs de composants (qui crent et cataloguent les composants), enfin aux chefs de projet et de produit.

Avant-propos

Avant-propos

Figure P.1 Rational Unified Process 5.0

Il suppose une frquentation lmentaire des concepts orients objet. Une exprience dans le dveloppement logiciel et la pratique d'un langage de programmation orient objet, si elles sont bienvenues, ne sont pas indispensables.

Vpproche du livre

Le dveloppement du Processus unifi (les versions du produit figurent dans les rectangles).

Rational Objectory Process 4.1 1996-1997

/

Plusieurs autres sources

L'approche de Rational Objectory Pr )cess 1.0-3.8 1987- 1995

/

Cet ouvrage accorde une place prpondrante aux activits (besoins, analyse et conception) sur lesquelles UML insiste en priorit. C'est dans ce contexte que le processus permet d'tablir l'architecture de systmes logiciels complexes. Le processus est, nanmoins, trait dans sa totalit, bien que de faon moins dtaille. Mais c'est bien le programme qui, en fin de compte, s'excute. Pour parvenir ce rsultat, le projet rclame les efforts de chacun des membres de l'quipe et le soutien des intervenants. Comme vous le verrez, ce processus repose sur un ventail d'activits extrmement large. Un grand nombre d'artefacts doivent tre produits et archivs, et il est indispensable de grer toutes les activits.

UML

L'approche d'Ericsson

L'tude exhaustive du cycle de vie complet d'un processus dpasse largement la porte d'un seul ouvrage. Pour atteindre son objectif, un tel ouvrage devrait couvrir les directives de conception, les modles d'artefacts, les indicateurs de qualit, la gestion de projet, la gestion de configuration, les mtriques, et plus encore, bien plus ! Grce l'expansion des accs en ligne, ce plus encore est dsormais disponible et peut tre actualis sous la pression des nouveaux dveloppements. Nous vous renvoyons donc au Rational Unified Process, nouveau produit logiciel bas sur les technologies du Web guidant les quipes de dveloppement vers des pratiques plus efficaces. (Pour de plus amples informations, consultez le site http://www.rational.com.) Parce qu'il traite intgralement le cycle de vie logiciel, le Rational Unified Process tend le Processus unifi au-del des questions abordes dans ce livre. I l propose, en plus, des enchanements d'activits (workflows) qui ne sont que peu ou pas voqus dans ces pages, comme la modlisation mtier, la gestion de projet et la gestion de configuration.

L'approche Ericsson
Le Processus unifi s'enracine profondment dans le pass. Pour reprendre les termes de Peter F. Drucker, i l s'agit d'une innovation fonde sur des connaissances . Un vaste foss temporel spare l'mergence d'une nouvelle technologie du moment o elle devient utilisable , indique-t-il. I l s'coule ensuite une longue priode avant que cette nouvelle technologie fasse son apparition sur le march sous forme de produits, de processus ou de services. L'une des raisons expliquant ce dcalage dans le temps est que l'innovation fonde sur les connaissances repose prcisment sur l'association de nombreuses connaissances et que cette maturation demande du temps. D'autre part, les personnes charges de concrtiser cette nouvelle ide ont, elles aussi, besoin de temps pour la digrer et la diffuser aux autres. La premire tape de cette mise en lumire du dveloppement progressif du Processus unifi nous ramne en 1967. C'est cette poque qu'Ericsson modlisa le systme comme un ensemble de blocs interconnects (appels sous-systmes en U M L et implments sous forme de composants ). Les blocs de niveau infrieur taient regroups en soussystmes de niveau suprieur afin d'amliorer la capacit d'administration du systme. L'quipe d'Ericsson se fondait sur les cas de trafic spcifis auparavant (dsormais nomms cas d'utilisation ) pour identifier les blocs. On pouvait alors identifier les blocs cooprant la ralisation de chacun de ces cas d'utilisation et dterminer leur spcification propre partir de leurs responsabilits connues. Le travail de conception se traduisait ensuite par la mise au point d'un ensemble de diagrammes de blocs statiques accompagns de leurs interfaces, et par leur regroupement en sous-systmes. Ces diagrammes de blocs correspondaient directement une version simplifie des diagrammes de classes ou de

istorique du Processus unifi

Aboutissement de trois dcennies de dveloppement et d'usage pratique, le Processus unifi doit son quilibre cette longue volution. La figure P.l retrace la succession des produits qui en sont issus, depuis le processus Objectory, dont la premire version est sortie en 1987, jusqu'au Rational Unified Process (sorti en 1998) en passant par le Rational Objectory Process (1997). La mise au point du processus a subi diverses influences que nous ne citerons pas toutes dans ces pages (pour la simple raison que certaines nous sont inconnues) ; nous laissons aux archologues du logiciel le soin de les identifier. En revanche, nous dcrirons le retentissement qu'ont eu les approches Ericsson et Rational sur le produit et ferons tat de plusieurs autres sources.

Avant-propos

Avant-propos

packages UML, simplifie en ceci que les diagrammes ne montraient que les associations utilises pour les communications.

tions de ce qu'UML appelle dsormais diagrammes de classes, diagrammes d'activits, diagrammes de collaboration et diagrammes de squence. SDL reprsentait donc un standard spcialis de modlisation objet. Ce langage, rgulirement actualise, est encore utilise par plus de 10 000 dveloppeurs et pris en charge par diffrents diteurs. Mis au point i l y a plus de vingt ans, une poque o la modlisation objet manquait de maturit, SDL tait trs en avance sur son temps. I l est vraisemblable qu'il sera finalement supplant par UML, standardis depuis novembre 1997.

Le premier produit des activits de conception tait une description de l'architecture logicielle, fonde sur la comprhension des besoins essentiels. Ce document dcrivait brivement tous les blocs et leur regroupement en sous-systmes. Un ensemble de diagrammes de blocs montrait les blocs et leurs interconnexions, qui transmettaient des signaux, c'est-dire un type de message. Tous ces messages taient dcrits un un dans une bibliothque de messages. La description de l'architecture logicielle et la bibliothque des messages constituaient les documents cls qui devaient, non seulement guider le travail de dveloppement, mais galement prsenter le systme aux clients. l'poque (1968), les clients n'avaient pas l'habitude de dcouvrir un produit logiciel sous forme de plan d'laboration. Pour chaque cas d'utilisation, les ingnieurs prparaient soit un diagramme de squence, soit un diagramme de collaboration. Ces diagrammes (amliors dans UML) montraient la faon dont les blocs communiquaient dynamiquement pour raliser le cas d'utilisation. Ils laboraient une spcification sous forme de graphe d'tats (ne comprenant que les tats et les transitions). Cette approche d'une conception fonde sur des blocs ayant une interface parfaitement dfinie tait primordiale pour la russite des projets. I l suffisait, ensuite, pour crer une nouvelle configuration du systme (par exemple, pour un nouveau client), de remplacer un bloc par un autre fournissant les mmes interfaces. Les blocs n'taient pas de simples sous-systmes ni des composants base de code source. Ils taient compils en blocs excutables, installs un un sur la machine cible, et fonctionnaient avec les autres blocs excutables. Chaque nouveau bloc excutable ou chaque bloc modifi devait pouvoir tre install dans un systme relayant des appels tlphoniques, sans ncessiter la moindre interruption de service. On ne peut en effet raisonnablement pas interrompre un systme de ce type pour procder de simples changements. Ce serait comme changer les pneus d'une voiture lance 100 kilomtres l'heure. En substance, l'approche utilise tait ce que l'on appelle aujourd'hui le dveloppement base de composants. Ivar lacobson est l'origine de cette mthode de dveloppement. C'est lui qui en a guid l'volution, au cours des annes qui ont prcd la priode Objectory, pour en faire un processus de dveloppement logiciel.

Objectory
En 1987, Ivar Jacobson quittait Ericsson pour fonder Objectory AB Stockholm. Lui et ses associs passrent les huit annes suivantes concevoir un processus en tant que produit, appel Objectory (contraction de Object Factory ), qu'ils tendirent des domaines autres que les tlcommunications et exportrent en dehors de la Sude. S'il figurait dj dans les travaux effectus chez Ericsson, le concept de cas d'utilisation reut alors son nom dfinitif (introduit lors de la confrence OOPSLA de 1987). Une technique d'laboration de diagrammes fut mise au point et cette notion fut largie pour accueillir une large gamme d'applications. I l devint alors vident que les cas d'utilisation devaient piloter le dveloppement. De mme que s'imposa l'ide que c'est l'architecture qui doit guider les dveloppeurs et permettre d'informer les divers intervenants. Les enchanements d'activits successifs taient reprsents par une srie de modles : modles des besoins avec des cas d'utilisation, modles d'analyse, de conception, d'implmentation et de test. Un modle offre un point de vue sur un systme. Les relations unissant les diffrents modles taient capitales, car elles permettaient aux dveloppeurs de suivre une caractristique d'un bout l'autre d'une srie de modles. En fait, la traabilit devint un pralable tout dveloppement pilot par les cas d'utilisation. Les dveloppeurs pouvaient suivre l'volution d'un cas d'utilisation travers toute la squence de modles jusqu'au code source et, en cas de problme, revenir en arrire. Le dveloppement du processus Objectory s'est traduit par une srie de versions, depuis Objectory 1.0 sorti en 1988, la premire version en ligne, Objectory 3.8, en 1995 (vous trouverez une prsentation d'Objectory dans [2]). Il est important de noter que le produit Objectory en lui-mme fut bientt envisag comme un systme. Cette faon de dcrire le processus comme un produit systme facilitait considrablement la mise au point une nouvelle version d'Objectory partir d'une version prcdente, et le rendait plus modulable aux besoins particuliers de telle ou telle entreprise. Le fait que le processus de dveloppement du logiciel Objectory lui-mme faisait l'objet d'une conception rationnelle suffisait le rendre unique. L'exprience acquise dans le dveloppement d'Objectory permit galement de mieux comprendre comment thoriser les processus sur lesquels repose un mtier quel qu'il soit. Les mmes principes pouvaient s'appliquer et furent intgrs dans un livre paru en 1995 [3].

>DL : Langage de spcification et de description

Cette priode fut marque par la sortie, en 1976, de SDL (Spcification and Description Language - Langage de spcification et de description) pour le comportement fonctionnel des systmes de tlcommunications. Mis au point par le CCITT (organisme international charg de la standardisation dans le domaine des tlcommunications) et nettement influenc par l'approche Ericsson, ce standard dfinissait un systme comme un ensemble de blocs interconnects communiquant les uns avec les autres par l'intermdiaire exclusif de messages (nomms signaux dans ce standard). Chaque bloc possdait un ensemble de processus , terme SDL pour dsigner les classes actives. De faon assez similaire aux classes du paradigme orient objet, un processus tait dot d'instances qui dialoguaient par le biais de messages. Cette mthode proposait des diagrammes qui taient des spcialisa-

Avant-propos

Avant-propos

ipproche de Rational
Rational Software Corporation ayant acquis Objectory AB l'automne 1995, la tche consistant unifier les principes de base sous-jacents aux processus de dveloppement logiciel existants s'est faite plus urgente. Rational avait mis au point un certain nombre de pratiques de dveloppement logiciel, qui compltaient, pour l'essentiel, celles dfinies dans Objectory. Ainsi, en 1981, Rational s'est mis produire un environnement interactif capable d'amliorer la productivit pour le dveloppement de systmes informatiques d'envergure , rappelaient James E. Archer et Michael T. Devlin en 1986 [4]. Us insistaient sur l'importance des notions de conception oriente objet, d'abstraction, de masquage des informations, de rutilisabilit et de prototypage. S'il existe des dizaines d'ouvrages, d'articles et de documents internes retraant les dveloppements de Rational depuis 1981, la contribution majeure au processus est sans doute la prpondrance accorde l'architecture et au dveloppement itratif. En 1990, Mike Devlin rdigeait un article visionnaire dcrivant un processus de dveloppement itratif pilot par l'architecture, tandis que Philippe Kruchten, charg de la pratique architecturale au sein de Rational, signait divers articles sur l'approche itrative et l'architecture. Nous citerons l'un de ces papiers, qui envisageait une reprsentation de l'architecture selon quatre points de vue : logique, processus, physique et dveloppement, auxquels s'ajoutait un autre point de vue illustrant les quatre prcdents l'aide de cas d'utilisation ou de scnarios |6). L'intrt d'avoir une diversit de points de vue au lieu de chercher tout intgrer dans un seul type de diagramme, s'est impos Philippe Kruchten au gr de son exprience sur d'importants projets. Cette multiplicit de points de vue permettait aux intervenants comme aux dveloppeurs d'identifier, dans la vue approprie, ce dont ils avaient besoin pour atteindre leurs diffrents objectifs.

Processus Rational Objectory : 1995-1997

l'poque de la fusion, Objectory 3.8 avait montr comment pouvait tre mis au point et modlis un processus de dveloppement logiciel sous forme de produit, jetant ainsi les bases de l'architecture originale d'un processus de dveloppement logiciel. Un ensemble de modles avait t identifi, qui devait recueillir les rsultats du processus. Si celui-ci tait au point dans des domaines tels que la modlisation par les cas d'utilisation, l'analyse et la conception, i l montrait quelque faiblesse dans la gestion des besoins autre que les cas d'utilisation, dans l'implmentation et les tests. Par ailleurs, i l n'abordait que sommairement la gestion de projet et de configuration, le dploiement et la prparation de l'environnement de dveloppement (acquisition d'outils et de procds). Le fruit de l'exprience de Rational et les pratiques mises en uvre, notamment les phases et l'approche itrative contrle, sont venus s'ajouter pour former le Rational Objectory Process 4.1. L'architecture y faisait l'objet d'une description prcise (la bible de toute quipe de dveloppement logiciel), occupait une place centrale dans le systme lui-mme et tait dpeinte par les diffrentes vues architecturales des modles. Le dveloppement itratif partait d'un concept relativement gnral pour aboutir une approche guide par la rduction des risques qui plaait l'architecture au premier plan. UML, dont les auteurs du prsent ouvrage sont l'origine de la cration, tait alors en cours de dveloppement et servait de langage de modlisation au Rational Objectory Process. L'quipe de dveloppement, dirige par Philippe Kruchten, compensa certaines des faiblesses du Rational Objectory Process en renforant la gestion de projet, notamment partir des contributions de Royce [8].

UML : Unified Modeling Language

Depuis quelque temps dj, le besoin d'un langage visuel uniforme et cohrent pour exprimer les rsultats des mthodes orientes objet encore en usage dans les annes 1990 tait devenu vident.

Certains ont peru le dveloppement itratif comme quelque peu chaotique, voire anarchique. Au contraire, l'approche en quatre phases (cration , laboration, construction et transition) a t conue pour permettre une meilleure structuration et un contrle plus rigoureux de la progression pendant l'itration. Ces phases imposent un ordre aux itrations. La planification dtaille des phases et l'ordonnancement des itrations au sein de ces phases rsultent d'un effort concert de Walker Royce et Rich Reitman, avec la participation ininterrompue de Grady Booch et de Philippe Kruchten.
1

Aux avant-postes ds les dbuts de Rational, Grady Booch formula dans l'un de ses ouvrages paru en 1996 deux principes premiers reposant sur l'architecture et l'itration : Un style de dveloppement guid par l'architecture est, en gnral, la meilleure approche pour la cration de projets complexes logiciel prpondrant. Pour russir, un projet orient objet doit suivre un processus incrmental et itratif [7].

Au cours de la mme priode, Grady Booch mettait au point la mthode Booch [9], tandis que James Rumbaugh laborait, au Centre de recherche et de dveloppement de General Electric, la mthode OMT (Object Modeling Technique) [10]. Lorsque ce dernier rejoignit Rational en 1994, tous deux s'engagrent, en association avec des clients de Rational, dans un processus d'unification de leurs mthodes. La version 0.8 de la Mthode Unifie (Unified Method 0.8) sortit en octobre 1995, l'poque o Ivar Jacobson intgrait son tour Rational. Cette collaboration trois donna naissance la version 0.9 d'UML (Unified Modeling Language). D'autres spcialistes des mthodes furent bientt mis contribution, ainsi que plusieurs socits, telles qu'IBM, HP et Microsoft, qui participrent l'mergence de ce standard. En novembre 1997, l'issue du processus de standardisation, la version 1.1

ni appele phase d'inception

Avant-propos j Avant-propos

11

d'UML fut adopte comme standard par l'OMG (Object Management Group). Pour de plus amples informations, consultez le Guide de l'utilisateur [11] et le Manuel de rfrence [11]. UML a t utilis pour tous les modles du Rational Objectory Process.

Patrik Jonsson a puis dans la documentation du Rational Objectory Process et en a class les lments extraits selon l'ordre des chapitres envisags. Il a galement pris part l'laboration des exemples et a suggr nombre d'ides sur la meilleure faon de prsenter le Processus unifi. Ware Myers a particip la rdaction de cet ouvrage et en a traduit les premiers brouillons en une prose plus lisible.

National Unified Process

Dans le mme temps, Rational se lanait dans une politique de fusion-acquisition de socits ditrices de logiciels. Chacune d'entre elles contribua, dans son champ d'expertise, au dveloppement du processus Rational Objectory : Requisite Inc. communiqua son exprience de la gestion des besoins ; SQA Inc. avait mis au point un processus de tests accompagnant son outil de test qui s'ajouta la longue exprience de Rational dans ce domaine ; Pure-Atria apporta sa connaissance de la gestion de configuration qui vint renforcer celle de Rational en la matire ; Performance Awareness ajouta les tests de performances et de charge ; Enfin, Vigortech fournit ses comptences en matire d'ingnierie des donnes. Le processus s'enrichit galement d'un nouvel enchanement d'activits pour la modlisation mtier (cf. [3]) permettant de driver les besoins partir des processus mtier que devait servir le logiciel, et fut largi la conception d'interfaces utilisateur guides par les cas d'utilisation ( partir de travaux effectus chez Objectory AB). Ds le milieu de l'anne 1998, le Rational Objectory Process tait devenu un processus complet, capable de prendre en charge la totalit du cycle de vie du dveloppement logiciel. Ce travail permit d'unifier les diverses contributions, non seulement des trois auteurs de cet ouvrage, mais aussi des nombreuses sources auxquelles ont puis Rational et UML. En juin, Rational lana une nouvelle version du produit, Rational Unified Process 5.0 [13]. Un grand nombre d'lments de ce processus propritaire entrent aujourd'hui dans le domaine public grce au prsent ouvrage. Le changement de nom rend compte du fait que l'unification s'est opre deux niveaux : d'une part, unification des approches de dveloppement l'aide d'UML, de l'autre, unification du travail de nombreux spcialistes des mthodes, employs par Rational et sur les centaines de sites clients ayant utilis le processus pendant plusieurs annes.

Parmi les rviseurs, nous tenons avant tout remercier Kurt Bittner, Cris Kobryn et Earl Ecklund, Jr., mais aussi Walker Royce, Philippe Kruchten, Dean Leffingwell, Martin Griss, Maria Ericsson et Bruce Katz pour la qualit et la pertinence de leurs commentaires. L'quipe des rviseurs comprenait galement Pete McBreen, Glenn Jones, Johan Galle, N. Venu Gopal, David Rine, Mary Loomis, Marie Lenzi, Janet Gardner et quelques anonymes, qui nous tmoignons notre reconnaissance. Nous remercions Terry Quatrani, de Rational, qui a parfait le style des chapitres 1 5, ainsi que Karen Tongish, qui a corrig les preuves de tout le livre. Enfin, nous sommes redevables Stefan Bylund pour sa revue de dtail de l'ouvrage et ses nombreuses suggestions formelles,finalementintgres dans le livre. Son intervention a largement contribu l'amlioration de la qualit du livre.

Pour leur collaboration fidle depuis des annes

emerciements
Un projet d'une telle ampleur ne peut qu'tre le fruit d'un travail collectif et nous souhaitons rendre hommage nommment tous ceux qui, nombreux, y ont contribu.

our leur contribution cet ouvrage

Birgitte L0nvig a labor le premier exemple de l'ouvrage, celui du systme interbancaire, qu'elle a men son terme en en crant tous les modles.

Nous voulons galement manifester notre reconnaissance tous ceux qui, aufildes annes, nous ont aid mettre sur pied le processus et ont accompagn notre travail sous ses divers aspects. Nous remercions en particulier les personnes suivantes : Stefan Ahlquist, Ali Ali, Gunilla Andersson, Kjell S. Andersson, Sten-Erik Bergner, Dave Bernstein, Kurt Bittner, Per Bjork, Hans Brandtberg, Mark Broms, Stefan Bylund, Ann Carlbrand, Ingemar Carlsson, Margaret Chan, Magnus Christerson, Geoff Clemm, Catherine Connor, Hakan Dahl, Stphane Desjardins, Mike Devlin, Hakan Dyrhage, Suzanne Dyrhage, Staffan Ehnebom, Christian Ehrenborg, Maria Ericsson, Gunnar M . Eriksson, Iain Gavin, Carlo Goti, Sam Guckenheimer, Bjorn Gullbrand, Sunny Gupta, Marten Gustafsson, Bjorn Gustafsson, Lars Hallmarken, David Hanslip, Per Hedfors, Barbara Hedlund, Jorgen Hellberg, Joachim Herzog, Kelli Houston, Agneta Jacobson, Sten Jacobson, Paer Jansson, Hakan Jansson, Christer Johansson, Ingemar Johnsson, Patrik Johnsson, Dan Jonsson, Bruce Katz, Kurt Katzeff, Kevin Kelly, Anthony Kesterton, Per Kilgren, Rudi Koster, Per Kroll, Ron Krubeck, Mikael Larsson, Bud Lawson, Dean Leffingwell, Rolf Leidhammar, Hakan Lidstrom, Lars Lindroos, Fredrik Lindstrom, Chris Littlejohns, Andrew Lyons, Jas Mahur, Bruce Malasky, Chris McClenaghan, Christian Meck, Sue Mickel, Jorma Mobrin, Christer Nilsson, Rune Nilsson, Anders Nodin, Jan-Erik Nodin, Roger Oberg, Benny Odenteg, Erik Ornulf, Gunnar Overgaard, Karin Palmkvist, Fabio Peruzzi, Janne Pettersson, Gary Pollice, Tonya Prince, Leslee Probasco, Terry Quatrani, Anders Rockstrom, Walker Royce, Goran Schefte, Jeff Schuster, John Smith, John Smith, Kjell Sorme, Ian Spence, Birgitta Spiridon, Fredrik Stromberg, Goran Sundelof, Per Sundquist, Per-Olof Thysselius, Mike Tudball, Karin Villers, Ctirad Vrana, Stefan Wallin, Roland Wester, Lars Wetterborg, Brian White, Lars Wiktorin, Charlotte Wranne et Jan Wunsche.

Avant-propos

Nous dsirons aussi exprimer toute notre gratitude aux personnes suivantes pour leur indfectible soutien depuis des annes : Dines Bjorner, Tore Bingefors, Dave Bulman, Larry Constantine, Goran Hemdal, Bo Hedfors, Tom Love, Nils Lennmarker, Lars-Olof Noren, Dave Thomas et Lars-Erik Thorelli.

Partie

Nous voudrions particulirement

remercier

Mike Devlin, prsident de Rational Software Corporation, qui a cru en l'intrt du processus Objectory pour tout type de dveloppement logiciel et en l'utilisation d'un processus logiciel efficace comme pierre de touche du dveloppement d'outils informatiques. Enfin, nous adressons nos remerciements Philippe Kruchten, directeur du Rational Unified Process, et tous les membres de l'quipe du processus de Rational, qui ont su associer les atouts d'Objectory aux bonnes pratiques de Rational et la mthode UML, tout en prservant la valeur de chacun de ces lments. Cet objectif serait demeur inaccessible sans l'engagement personnel et la persvrance de Philippe Kruchten dans l'laboration de ce que l'on peut, en toute modestie, qualifier de meilleur processus logiciel existant ce jour.

L e de

P r o c e s s u s

u n i f i logiciel

d v e l o p p e m e n t

Chapitre 1.

Le Processus unifi : pilot par les cas d'utilisation, centr sur l'architecture, itratif et incrmental Les quatre P du dveloppement logiciel : personnes, projet, produit et processus Un processus pilot par les cas d'utilisation Un processus centr sur l'architecture Un processus itratif et incrmental

Un processus en marche
Cet ouvrage et ceux qui viennent le complter, les versions en ligne et les outils contribuent la maturation du processus. Le Processus unifi s'inspire denombreuses sources. Dj trs largement utilis, il fournit aux cadres de direction, aux dveloppeurs et aux intervenants de toute sorte un moyen de comprhension unique du processus.

Chapitre 2.

Chapitre 3. Chapitre 4. Chapitre 5.

Il reste, toutefois, beaucoup faire : i l faut que les dveloppeurs harmonisent leurs techniques de travail, avec, bien entendu, les encouragements des divers intervenants et responsables. Pour beaucoup d'entreprises, cette petite rvolution n'est qu'une perspective lointaine. A vous de la faire advenir. Ivar Jacobson Palo Alto, Californie Dcembre 1998 ivar@rational.com

La premire partie introduit les principales ides qui sont exposes tout au long de ce livre. Dans le chapitre 1, nous dcrivons brivement le Processus unifi de dveloppement logiciel, en insistant sur le fait qu'il est pilot par les cas d'utilisation, centr sur l'architecture, itratif et incrmental. Le processus dcrit dans ces pages utilise le langage U M L (Unified Modeling Language), qui gnre des graphiques comparables, par leur contenu, aux plans d'laboration depuis longtemps en usage dans d'autres disciplines techniques, et fait reposer l'essentiel d'un projet de dveloppement sur des composants rutilisables, c'est--dire des fragments logiciels disposant d'une interface clairement dfinie. Le chapitre 2 prsente la thorie des quatre P : personnes, projet, produit et processus, et en dcrit les relations, absolument essentielles la comprhension de cet ouvrage. De mme, le processus trait dans ce livre ne saurait tre apprhend sans les concepts fondamentaux d'artefact, de modle, de travailleur et d'enchanement d'activits

( workfiow ). Le chapitre 3 aborde plus en dtail la notion de dveloppement pilot par les cas d'utilisation. Les cas d'utilisation constituent un moyen d'identifier les vritables besoins et de les utiliser pour orienter tout le processus de dveloppement. Le rle de l'architecture dans le Processus unifi est expliqu au chapitre 4 : l'architecture tablit ce qui doit tre fait. Elle met en place les diffrents niveaux de l'organisation du logiciel et s'attache crer le squelette du systme. Le chapitre 5 insiste sur la ncessit d'adopter une approche itrative et incrmentale pour le dveloppement logiciel. Ce qui signifie, en pratique, de se confronter en premier heu aux parties les plus incertaines du systme, de dfinir trs tt une architecture stable, puis d'aborder les parties les plus routinires par des itrations successives, chacune conduisant l'laboration d'un incrment jusqu' la version finale. La deuxime partie va plus en profondeur. Un chapitre est consacr chacun des principaux enchanements d'activits : expression des besoins, analyse, conception, implmentation et tests. Ces enchanements formeront, dans la troisime partie, l'essentiel des activits effectues au cours des diverses itrations des quatre phases qui composent le processus. Dans la troisime partie, nous dcrivons de faon concrte l'excution des tches dans chaque phase : laboration d'une tude de rentabilit dans la phase de cration ; mise en place de l'architecture et d'un plan dans la phase d'laboration; transformation de l'architecture en un systme livrable dans la phase de construction ; enfin, vrification du fonctionnement correct du systme au sein de l'environnement utilisateur dans la phase de transition. Nous rutilisons, dans cette partie, les principaux enchanements d'activits, que nous associons de faon spcifique chaque phase, afin de parvenir aux rsultats souhaits.

Le Processus unifi : pilot par les cas d'utilisation, centr sur l'architecture, itratif et incrmental
La tendance, aujourd'hui, en matire de logiciel est la cration de systmes de plus en plus imposants et complexes. Cette orientation s'explique, en partie, par la rapide monte en puissance des ordinateurs, qui a pour effet d'accrotre les attentes des utilisateurs. Autre influence dterminante, l'utilisation croissante de l'Internet pour l'change de toute sorte d'informations, du texte simple aux documents multimdias, en passant par les diagrammes et le texte mis en forme et dot d'images. Notre soif de logiciels de plus en plus sophistiqus s'aiguise au gr des annonces prcdant les sorties de produits : nous voulons des logiciels plus adapts nos besoins, exigence qui, son tour, augmente la complexit du logiciel. En bref, il nous en faut toujours plus. Il faut aussi que tout aille plus vite. Le dlai de mise sur le march est un autre facteur dcisif. Mais la satisfaction de tels objectifs n'est pas des plus simples. Le mode de dveloppement des logiciels ne concorde pas avec nos exigences de logiciels puissants et complexes. Aujourd'hui, la plupart des entreprises dveloppent des logiciels en utilisant les mmes mthodes qu'il y a vingt-cinq ans, ce qui pose videmment un problme. On ne peut prtendre raliser les logiciels complexes que rclament les clients sans actualiser les mthodes qui prsident leur dveloppement. Tout le problme du dveloppement logiciel se rsume, en fin de compte, la difficult qu'prouvent les dveloppeurs concilier les diffrents aspects qu'implique tout projet informatique d'envergure. Les quipes de dveloppement ont besoin d'une mthode de travail contrle, d'un processus intgrant les diverses facettes du dveloppement et d'une approche commune, c'est--dire d'un processus capable : de dicter l'organisation des activits de l'quipe ;

Cependant, l'objectif sous-jacent que poursuit une entreprise n'est videmment pas de possder un bon systme informatique , mais d'exploiter les processus mtier (ou les systmes intgrs) pour rpondre au mieux la demande du march et acclrer la production de biens et de services de qualit un prix raisonnable. Les systmes logiciels sont l'arme stratgique qui permet aux entreprises et administrations de raliser de considrables conomies de cots et de temps de production dans les secteurs secondaire et tertiaire. I l est impossible de ragir promptement la dynamique du march sans avoir, au pralable, mis en place des processus efficaces au sein de l'entreprise. Dans une conomie mondialise, en marche vingt-quatre heures sur vingt-quatre, sept jours sur sept, la plupart de ces processus seraient inoprants sans logiciels. La matrise d'un processus efficace de dveloppement logiciel est, par consquent, devenue un facteur incontournable dans le succs d'une entreprise.

lygU t L f l

Le Processus u n i f i de d v e l o p p e m e n t PARTIE I

logiciel

Le Processus u n i f i
CHAPITRE 1 I

de diriger les tches de chaque individu et de l'ensemble de l'quipe ; de spcifier les artefacts produire ; de proposer des critres pour le contrle et l'valuation des produits et des activits du projet.

P du dveloppement logiciel : personnes, projet, produit et processus. Nous consacrerons, ensuite, un chapitre chacune des trois ides fondamentales. Ces chapitres formeront la premire partie de l'ouvrage. Les deuxime et troisime parties, qui constituent le cur de l'ouvrage, dcriront en dtail les diffrents enchanements d'activits du processus.

1.2 Le Processus unifi est pilot par les cas d'utilisation

L'objectif d'un systme logiciel est de rendre service ses utilisateurs. Pour russir la mise au point d'un systme, i l importe, par consquent, de bien comprendre les dsirs et les besoins de ses futurs utilisateurs.

L'existence d'un processus clairement dfini et parfaitement gr est l'un des lments cls opposant les projets ultra-productifs aux projets infructueux. (Pour connatre les autres raisons de la ncessit d'un processus, consultez la section 2.4.4.) Aboutissement de plus de trente ans d'exprience, le Processus unifi de dveloppement logiciel offre une solution au problme du dveloppement informatique. Ce chapitre propose une vision d'ensemble du Processus unifi, tandis que les chapitres suivants examinent en dtail chacun de ses lments.

1.1 Le Processus unifi en bref

Avant toute chose, le Processus unifi est un processus de dveloppement logiciel, c'est-dire qu'il regroupe les activits mener pour transformer les besoins d'un utilisateur en systme logiciel (voir figure 1.1). Mais c'est plus qu'un simple processus. C'est un framework de processus gnrique pouvant tre adapt une large classe de systmes logiciels, diffrents domaines d'application, diffrents types d'entreprises, diffrents niveaux de comptence et diffrentes tailles de projets.

Le terme utilisateur ne dsigne pas seulement les utihsateure humains, mais galement d'autreji^ystmes. Dans ce sens, l'utilisateur reprsente une personne ou une chose (telle qu'un systme autre que le systme propos) dialoguant avec le systme en cours de dveloppement. D peut s'agir, par exemple, d'un tre humain utilisant un distributeur automatique de billets (DAB). La personne insre sa carte magntique, rpond aux questions que lui pose la machine par l'intermdiaire de son cran de visualisation, et reoit une somme d'argent liquide. Le systme ragit l'insertion de la carte de l'utilisateur et ses rponses en effectuant une squence d'actions (Annexe A) qui fournissent l'utilisateur un rsultat tangible, en l'occurrence un retrait de liquide.

Figure 1.1 lin processus de dveloppement loyit ici.

Besoins de l'utilisateur

Processus de d v e l o p p e m e n t logiciel

Systme logiciel

Le Processus unifi est base de composants, ce qui signifie que le systme logiciel en cours de fabrication est fait de composants logiciels (Annexe A) relis les uns aux autres par des interfaces clairement dfinies (Annexe A). Le Processus unifi utilise le langage UML (Unified Modeling Language) pour la cration des plans d'laboration et de construction du systme logiciel. En fait, UML fait partie intgrante du Processus unifi : l'un et l'autre ont t dvelopps de concert. Nanmoins, les traits vritablement distinctifs du Processus unifi tiennent en trois expressions cls : pilot par les cas d'utilisation, centr sur l'architecture, itratif et incrmental. Voil ce qui en fait toute l'originalit.

Ce type d'interaction est appel cas d'utilisation (Annexe A ; voir galement le chapitre 3). Un c^^^tOwationi est une fonctionnalit du systme produisant un rsultat satisfaisant pour l'utilisateur. Les cas d'utilisation saisissent les besoins fonctionnels et leur ensemble constitue le modle des cas d'utilisation (Annexe B ; voir aussi la section 2.3), qui dcrit les fonctionnalits compltes du systme. Ce modle remplace la classique spcification fonctionnelle du systme, qui rpondait la question suivante : qu'est cens faire le systme ? On peut caractriser la stratgie des cas d'utilisation en ajoutant la fin de cette question les trois mots suivants : pour chaque utilisateur ? Ces trois mots ont une implication majeure. Ils nous obligent rflchir en termes d'avantages pour les utilisateurs et non plus simplement en termes de fonctions dont il pourrait tre intressant de disposer. Mais les cas d'utilisation ne sont pas un simple outil de spcification des besoins du systme. Ils en guident galement la conception, l'implmentation et les tests ; c'est--dire qu'ils guident le processus de dveloppement. A partir du modle des cas d'utilisation, les dveloppeurs crent une srie de modles de conception et d'implmentation ralisant les cas d'utilisation. Chacun des modles successifs est ensuite rvis pour en contrler la conformit par rapport au modle des cas d'utilisation. Enfin, les testeurs testent l'implmentation pour s'assurer que les composants du modle d'implmentation mettent correctement en uvre les cas d'utilisation. Ceux-ci ne se bornent donc pas enclencher le processus de dveloppement : ils en garantissent la cohrence. Pilot par les cas d'utilisation signifie que le processus de dveloppement suit une voie spcifique, c'est--dire qu'il procde par une srie d'enchanements d'activits drivs des cas d'utilisation. Les cas d'utilisation sont spcifis, ils sont conus, et ils constituent la source qui permettra aux testeurs d'laborer les cas de test. S'il est vrai que les cas d'utilisation guident le processus, ils ne sont pas slectionns de faon isole, mais doivent absolument tre dvelopps en tandem avec l'architecture du

Dans les trois sections suivantes, nous allons dfinir ces trois caractristiques, avant de passer un survol du processus : cycle de vie, phases, versions, itrations, enchanements d'activits et artefacts. L'objectif de ce chapitre est d'introduire les ides matresses et de proposer une vue arienne du processus dans son ensemble. Aprs lecture de ces quelques pages, vous saurez, sans avoir ncessairement parfaitement compris, de quoi i l est question dans le Processus unifi. La suite du livre compltera cette vue d'ensemble en ajoutant tous les dtails ncessaires. Dans le chapitre 2, nous mettrons en contexte les quatre

U
H

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Le Processus u n i f i

J |

systme. Les cas d'utilisation guident l'architecture du systme, qui influence, son tour, leur slection. L'architecture et les cas d'utilisation voluent donc de faon parallle au cours du cycle de vie du dveloppement.

sation du systme, mais ils sont les plus significatifs, ceux qui constituent le cur mme des fonctions du systme. En clair :

1.3 Le Processus unifi est centr sur l'architecture

Le rle de l'architecture logicielle est comparable celui que joue l'architecture dans la construction d'un btiment. Le btiment est envisag de diffrents points de vue : structure, services, conduites de chauffage, plomberie, lectricit, etc. Ce regard multiple dessine une image complte du btiment avant le dbut de la construction. De la mme faon, l'architecture d'un systme logiciel peut tre dcrite comme les diffrentes vues du systme qui doit tre construit.

L'architecte cre une bauche grossire de l'architecture, en partant de l'aspect qui n'est pas propre aux cas d'utilisation (par exemple, la plate-forme). Bien que cette partie de l'architecture soit indpendante des cas d'utilisation, l'architecte doit avoir une comprhension globale de ceux-ci avant d'esquisser l'architecture. I l travaille, ensuite, sur un sous-ensemble des cas d'utilisation identifis, ceux qui reprsentent les fonctions essentielles du systme en cours de dveloppement. Chaque cas d'utilisation slectionn est dcrit en dtail et ralis sous forme de sous-systmes (Annexe A ; voir galement la section 3.4.4), de classes (Annexe A) et de composants (Annexe A). L'architecture se dvoile peu peu, au rythme de la spcification et de la maturation des cas d'utilisation, qui favorisent, leur tour, le dveloppement d'un nombre croissant de cas d'utilisation. Ce processus se poursuit jusqu' ce que l'architecture soit juge stable.

1.4 Le Processus unifi est itratif et incrmental

Le dveloppement d'un produit logiciel destin la commercialisation est une vaste entreprise qui peut s'tendre sur plusieurs mois, voire sur une anne ou plus. I l n'est pas inutile de dcouper le travail en plusieurs parties qui sont autant de mini-projets. Chacun d'entre eux reprsente une itration qui donne lieu un incrment. Les itrations dsignent des tapes de Tnchanement d'activits, tandis que les incrments correspondent des stades de dveloppement du produit. Pour garantir un maximum d'efficacit, i l est indispensable de contrler les itrations : celles-ci doivent tre slectionnes et menes bien de faon planifie. C'est la raison pour laquelle on les qualifie de mini-projets. Le choix de ce qui doit tre implment au cours d'une itration repose sut^eujtateurs. ^rfMremnf, une itration prend en compte un certain nombre de cas d'utilisation qui, - ensemble, amliorent l'utilisabilit du produit parvenu un certain stade de dveloppement. Deuximement, l'itration traite en priorit les risques majeurs. Les itrations successives exploitent les artefacts de dveloppement dans l'tat o les a laisss l'itration prcdente et les enrichissent progressivement. I l s'agit d'un mini-projet qui part des cas d'utilisation, se prolonge par le travail de dveloppement normal (analyse, conception, implmentation et tests) et ralise sous forme de code excutable les cas d'utilisation dfinis au cours de l'itration. Bien entendu, un incrment ne constitue pas ncessairement un additif. Dans les premires phases du cycle de vie, en particulier, i l n'est pas rare de remplacer une conception superficielle par une autre plus dtaille ou plus complexe. Dans les phases suivantes, en revanche, les incrments ne sont gnralement que des additifs. chaque itration, les dveloppeurs identifient et spcifient les cas d'utilisation pertinents, crent une conception en se laissant guider par l'architecture choisie, implmentent cette conception sous forme de composants et vrifient que ceux-ci sont conformes aux cas d'utilisation. Ds qu'une itration rpond aux objectifs qui lui sont fixs (ce qui est gnralement

Le concept d'architecture logicielle reprsente les_aspects^statiques.et dynarmgj^Jes plus significatifs du systme. L'architecture merge des besoins de l'entreprise, tels qu'ils sont exprims par les utilisateurs et autres intervenants et tels qu'ils sont reflts par les cas d'utilisation. Elle subit, nanmoins, l'influence d'autres facteurs, tels que la plate-forme sur laquelle devra s'excuter le systme (par exemple, l'architecture matrielle, le systme d'exploitation, le systme de gestion des bases de donnes, les protocoles de communication rseau), les briques de base rutilisables disponibles pour le dveloppement (par exemple, une infrastructure prfabrique (framework) (Annexe C) pour les interfaces utilisateur graphiques), les considrations de dploiement, les systmes existants et les besoins non fonctionnels (par exemple, les performances, la fiabilit). L'architecture propose une vue d'ensemble de la conception faisant ressortir les caractristiques essentielles en laissant de ct les dtails secondaires. Comme la dtermination de ce qui est important tient, en partie, la capacit de jugement, elle-mme forge par l'exprience, la valeur de l'architecture dpend troitement des personnes auxquelles en est attribue la tche. Le processus aide, toutefois, l'architecte s'attacher en priorit aux vrais objectifs que sont la clart, la capacit de raction aux futurs changements et la rutilisation. Quels sont les liens entre cas d'utilisation et architecture ? Tout produit est la fois forme et fonction. L'une ou l'autre isolment ne saurait suffire. Ces deux forces doivent s'quilibrer pour crer un produit russi. Dans le cas qui nous intresse, la fonction correspond aux cas d'utilisation et la forme l'architecture. I l est indispensable qu'il y ait une interaction entre les cas d'utilisation et l'architecture, ce qui revient au problme classique de l'uf et de la poule . D'un ct, les cas d'utilisation doivent, une fois raliss, trouver leur place dans l'architecture. De l'autre, l'architecture doit prvoir la ralisation de tous les cas d'utilisation ncessaires, dans le prsent et l'avenir. En fait, l'architectore et les cas d'utilisation doivent voluer de faon concomitante. Les architectes vont donc couler le systme dans une forme. Cette forme (l'architecture) doit tre conue de faon permettre l'volution du systme, non seulement dans le cadre de son dveloppement initial, mais dans les annes et les gnrations venir. Pour dterminer une telle forme, les architectes doivent travailler partir d'une comprhension gnrale des principales fonctions, c'est--dire des principaux cas d'utilisation, du systme. Ces cas d'utilisation peuvent ne reprsenter que 5 10% de tous les cas d'utili-

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Le P r o c e s s u s u n i f i
CHAPITRE 1

le cas), le dveloppement peut passer l'itration suivante. Si une itration n'atteint pas ses objectifs, les dveloppeurs doivent rtudier les dcisions prises et tenter d'adopter une nouvelle approche.

1.5 La vie du Processus unifi

Le Processus unifi rpte un certain nombre de fois une srie de cycles constituant la vie d'un systme, comme l'illustre la figure 1.2. Tout cycle se conclut par la livraison d'une version du produit (Annexe C ; voir galement le chapitre 5) aux clients et s'articule en quatre phases : cration, laboration, construction et transition. Chacune d'entre elles se subdivise son tour en itrations, comme nous l'avons indiqu plus haut. Voir lafigure1.3. Naissance

Pour rentabiliser les efforts de dveloppement, chaque quipe essaiera de ne slectionner que les itrations ncessaires pour atteindre les objectifs du projet. Dans la mesure du possible, ces itrations devront se succder selon un ordre logique. Un projet russi suivra un droulement direct, tabli ds le dbut par les dveloppeurs et dont i l ne s'loignera que de faon trs marginale. Bien sr, si des problmes imprvus viennent ajouter des itrations ou en bouleverser la squence prvue, le processus de dveloppement ncessitera plus de travail et de temps. L'limination des problmes imprvus fait partie des objectifs de rduction des risques. L'utilisation d'un processus itratif contrl prsente de nombreux avantages : Une itration contrle permet de limiter les cots, en termes de risques, aux strictes dpenses lies une seule itration. S'il faut reprendre l'itration, l'entreprise ne perd que le bnfice des efforts mal orients sur une itration, et non la valeur du produit dans son entier. Une itration contrle permet de limiter les risques de retard de mise sur le march du produit dvelopp. L'identification des risques ds les premiers stades de dveloppement en permet la rsolution prcoce, un moment o les dveloppeurs sont moins soumis la pression des dlais que dans les phases ultimes du projet. Avec l'approche classique , qui ne fait apparatre les problmes qu'au moment des tests du systme, le temps ncessaire leur rsolution dpasse gnralement les dlais prvus et conduit presque inexorablement un retard de livraison. Une itration contrle se traduit par une acclration du rythme de l'ensemble du dveloppement, car elle permet aux dveloppeurs de travailler plus efficacement vers des objectifs clairs court terme, plutt qu'en fonction d'un planning long terme soumis d'invitables dpassements. Enfin, une itration contrle prend en compte une ralit souvent ignore : les besoins des utilisateurs et les exigences correspondantes ne peuvent tre intgralement dfinis l'avance et se dgagent peu peu des itrations successives. Ce mode de fonctionnement facilite l'adaptation l'volution des besoins. Ces concepts - dveloppement pilot par les cas d'utilisation, centr sur l'architecture, itratif et incrmental - sont d'gale importance. L'architecture fournit la structure qui servira de cadre au travail effectu au cours des itrations, tandis que les cas d'utilisation dfinissent les objectifs et orientent le travail de chaque itration. L'abandon de l'une ou l'autre de ces trois notions cls attnuerait considrablement la valeur du Processus unifi. Comme un tabouret auquel i l manquerait un pied, i l s'effondrerait. Maintenant que nous avons introduit ces trois concepts, i l est temps de jeter un il au processus dans son ensemble, son cycle de vie, ses artefacts, ses enchanements d'activits, ses phases et ses itrations.

Figure 1.2 La vie d'un processus se dcompose en cycles allant de sa naissance sa mort.

Temps

Cycles donnant naissance une version

Figure 1.3 Un cycle, avec ses phases et ses itrations.

Temps

1.5.1 Le produit
Chaque cycle se traduit par une nouvelle version du systme, c'est--dire un produit prt la livraison. Ce produit se compose d'un corps de code source rparti sur plusieurs composants pouvant tre compils et excuts, et s'accompagne de manuels et de produits associs. Toutefois, le produit fini doit prendre en compte les besoins, non pas des seuls utilisateurs, mais de tous les intervenants, c'est--dire de tous ceux qui seront amens l'exploiter. Il ne peut, par consquent, se rsumer un simple code machine excutable. Le produit fini comprend les besoins, les cas d'utilisation, les spcifications non fonctionnelles et les cas de test. I l englobe l'architecture et les modles visuels (les artefacts modliss par UML). En fait, i l intgre tous les lments abords dans ce chapitre, car ce sont eux qui permettent aux intervenants (clients, utilisateurs, analystes, concepteurs, programmeurs, testeurs et responsables) de spcifier, concevoir, implmenter, tester et utiliser un systme.

Le Processus u n i f i de d v e l o p p e m e n t logiciel

Le Processus u n i f i
CHAPITRE 1

Ce sont galement ces lments qui rendent possible l'utilisation et la modification du systme sur plusieurs gnrations.

Modle des cas d'utilisation

spcifi par

Modle d'analyse

|""| impiment par vrifi par

Si les composants excutables sont indniablement les artefacts les plus importants du point de vue de l'utilisateur, leur seule prsence ne saurait suffire. Et cela pour la simple raison que l'environnement change. Les systmes d'exploitation, de bases de donnes et les machines sous-jacentes voluent. I l est possible, alors mme que se prcise peu peu le cadre de la mission, que les besoins eux-mmes se modifient et contraignent les dveloppeurs entamer un nouveau cycle qui devra tre financ par la direction. Pour mener efficacement le cycle suivant, les dveloppeurs ont besoin de toutes les reprsentations du produit logiciel (figure 1.4) : un modle des cas d'utilisation exposant tous les cas d'utilisation et leurs relations avec les utilisateurs ; un modle d'analyse poursuivant deux objectifs : dtailler les cas d'utilisation et procder une premire rpartition du comportement du systme entre divers objets appropris ; un modle de conception dfinissant (a) la structure statique du systme sous forme de sous-systmes, classes et interfaces, et (b) les cas d'utilisation raliss sous forme de collaborations (Annexe A ; voir galement la section 3.1) entre les sous-systmes, les classes et les interfaces ; un modle d'implmentation intgrant les composants (reprsentant le code source) et la correspondance entre les classes et les composants ; un modle de dploiement dfinissant les nuds physiques des ordinateurs et l'affectation de ces composants sur ces nuds ; un modle de tests dcrivant les cas de test vrifiant les cas d'utilisation ; et, bien sr, une reprsentation de l'architecture. Il est possible que le systme dispose galement d'un modle du domaine ou d'un modle du mtier dcrivant le contexte professionnel du systme. Tous ces modles sont lis. Ensemble, ils reprsentent le systme comme un tout. Les lments de chacun des modles prsentent des dpendances de traabilit (Annexe A ; voir galement la section 2.3.7) avant et arrire favorises par les liens existant avec les autres modles. I l est, par exemple, possible de remonter un cas d'utilisation (dans le modle des cas d'utilisation) partir de sa ralisation (dans le modle de conception) ou d'un cas de test (dans le modle de test), et inversement. La traabilit facilite la comprhension et les modifications ultrieures.

B
Modle de conception

Figure 1.4 Modles du Processus unifi. La plupart des modles sont lis par des dpendances. Par exemple, les dpendances entre le modle des cas d'utilisation et les autres modles sont indiques.

Modle de dploiement

s Implmentation M dl oe D O

S'

Y
Modle de tests

1.5.2 Les phases d'un cycle

Chaque cycle se droule sur une certaine dure dcoupe en quatre phases, comme le montre la figure 1.5. Une squence de modles permet aux intervenants de visualiser ce qui se passe durant ces phases. Pour chacune d'elles, les chefs de projet ou dveloppeurs peuvent pousser la dcomposition du travail en itrations et incrments qui en sont issus. Chaque phase s'achve par un jalon (Annexe C ; voir galement le chapitre 5), qui se dfinit par un ensemble d'artefacts : certains modles ou documents ont atteint un niveau de ralisation fix au pralable. Les jalons servent de nombreux objectifs, le principal tant de permettre aux chefs de projet de prendre un certain nombre de dcisions cruciales avant de passer la phase suivante du dveloppement. Ils permettent galement aux responsables, et aux dveloppeurs euxmmes, de surveiller la progression du travail en fonction de ces quatre points cls. Enfin, l'archivage du temps et des efforts consacrs chaque phase constitue un corpus de donnes qui se rvlent fort utiles pour valuer les besoins en termes de dlais et de personnel sur d'autres projets, planifier les besoins en personnel sur toute la dure d'un projet et contrler l'avancement par rapport aux projections. La figure 1.5 indique les enchanements d'activits (formulation des besoins, analyse, conception, implmentation et tests) dans la colonne de gauche, tandis que les courbes reprsentent approximativement (ne les considrez pas de faon trop littrale) le degr d'accomplissement des enchanements d'activits dans chaque phase. N'oubliez pas que chaque phase se dcompose en principe elle-mme en itrations, ou mini-projets. Une itration couvre gnralement les cinq enchanements d'activits, comme le montre la figure 1.5 dans la phase d'laboration.

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Le P r o c e s s u s u n i f i

j g

o^ATirREi^m

Phases

d'laboration, aboutit l'mergence d'une architecture de rfrence (Annexe C ; voir galement la section 4.4). l'issue de la phase d'laboration, le chef de projet est en mesure de prvoir les activits et d'estimer les ressources ncessaires l'achvement du projet. La question cl, ce stade, est la suivante : les cas d'utilisation, l'architecture et les plans sont-ils assez stables et les risques suffisamment matriss pour permettre la ralisation du dveloppement dans le respect du contrat ?

Figure 1.5 Les cinq Principaux e n c h a n e m e n t s enchanements d'activits d'activits (besoins, analyse, conception, implmentation et Analyse tests) se droulent sur les quatre Conception phases : cration, laboration, construction et Implmentation transition.

iter. iter. #1 #2
Itrations

... I Iter. I #n-1

iter. #n

La phase de cration (ou d'inception) traduit ce qui n'est, au dpart, qu'une bonne ide en une vision du produit fini et prsente une tude de rentabilit pour ce produit. Cette phase rpond essentiellement aux questions suivantes : Que va faire, en substance, le systme pour chacun de ses principaux utilisateurs ? quoi peut ressembler l'architecture d'un tel systme ? Quels sont l'organisation et les cots du dveloppement de ce produit ? Un modle simplifi des cas d'utilisation regroupant les principaux cas d'utilisation permettra de rpondre la premire question. A ce stade, l'architecture est encore provisoire, elle n'est en gnral qu'une bauche rvlant les principaux sous-systmes. C'est au cours de cette phase que sont identifis et hirarchiss les risques majeurs, qu'est planifie en dtail la phase d'laboration et qu'est livre une estimation approximative du projet dans son ensemble. La phase d'laboration permet de prciser la plupart des cas d'utilisation et de concevoir l'architecture du systme. La relation existant entre l'architecture d'un systme et le systme lui-mme est absolument primordiale. Disons, pour faire simple, que l'architecture s'apparente un squelette recouvert de peau, mais avec trs peu de muscles (le logiciel), juste assez pour permettre au squelette d'effectuer les mouvements les plus lmentaires. Le systme est ce corps dans son entier : squelette, peau et muscles. L'architecture doit donc tre exprime sous forme de vues de tous les modles du systme qui, associes les unes aux autres, figurent le systme dans son ensemble. Cela implique l'existence d'une vue architecturale de chacun des modles de cas d'utilisation, de conception, d'implmentation et de dploiement. La vue du modle d'implmentation doit comprendre les composants tmoignant du caractre excutable de l'architecture. Cette phase, au cours de laquelle sont raliss les principaux cas d'utilisation identifis pendant la phase

Comme son nom l'indique, la phase de construction est le moment o est construit le produit. En d'autres termes, le squelette (l'architecture) s'toffe de muscles (le logiciel achev). Au cours de cette phase, l'architecture de rfrence se mtamorphose en systme complet. Notre vision du systme est dsormais celle d'un produit prt tre transmis aux utilisateurs. Cette phase consomme l'essentiel des ressources mobilises. Mais l'architecture du systme est stable, et les dveloppeurs peuvent encore dcouvrir des moyens plus efficaces de structurer le systme ou suggrer des modifications architecturales mineures. l'issue de cette phase, le produit contient tous les cas d'utilisation que les chefs de projet, en accord avec les utilisateurs, ont dcid de mettre au point pour cette version. Celle-ci risque, toutefois, de prsenter quelques anomalies. D'autres seront dcouvertes et rsolues au cours de la phase de transition. La question qui se pose alors est la suivante : le produit satisfaitil suffisamment aux besoins des utilisateurs pour que certains clients l'adoptent avant sa sortie officielle ? La phase de transition couvre la priode au cours de laquelle le produit passe en version bta. Un petit groupe d'utilisateurs expriments essaient le produit en version bta et rendent compte des anomalies et dfauts constats. Les dveloppeurs corrigent ensuite les problmes signals et incorporent certaines des amliorations suggres dans une version gnrale destine un public plus large. La phase de transition suppose des activits telles que la fabrication, la formation des utilisateurs clients, la mise en uvre d'un service d'assistance et la correction des anomalies identifies aprs la livraison. L'quipe de maintenance rpartit gnralement ces anomalies en deux catgories : celles ayant un impact suffisant sur le fonctionnement pour justifier la sortie immdiate d'une version delta et celles pouvant attendre la version suivante pour tre corriges.

1.6 Un processus intgr

Le Processus unifi est bas sur les composants. I l utilise le nouveau standard de tnodli sation visuelle UML (Unified Modeling Language) et repose sur trois notions matresses : les cas d'utilisation, l'architecture et le dveloppement itratif et incrmental. Pour mettre en pratique ces ides, i l faut recourir un processus multi-facettes prenant en considration les cycles, les phases, les enchanements d'activits, la rduction des risques, le contrle qualit, la gestion de projet et la gestion de configuration. Le Processus unifi a mis en place un cadre gnral (framework) intgrant chacune de ces facettes. I l fonctionne comme une sorte de parapluie sous lequel diteurs et dveloppeurs peuvent crer des outils assurant l'automatisation du processus et les enchanements d'activits individuels, et des outils permettant de

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

i i-

btir les diffrents modles et d'intgrer les rsultats du travail tout au long du cycle de vie et de l'laboration des modles. L'objet de ce livre est de dcrire le Processus unifi en insistant particulirement sur les aspects d'ingnierie, les trois notions cls numres plus haut, la conception base sur les composants et l'utilisation d'UML. Nous allons dcrire les quatre phases et les diffrents enchanements d'activits, mais nous n'aborderons que partiellement certaines questions telles que la planification du projet et des ressources, la rduction des risques, la gestion de configuration, la capture des mtriques et le contrle qualit. Enfin, nous ne traiterons que brivement l'automatisation du processus.

2
Les quatre P du dveloppement logiciel : personnes, projet, produit et processus
L'objectif ultime de tout projet (Annexe C) logiciel est la livraison d'un produit faonn par les diverses personnes ayant uvr son dveloppement. La contribution de ces personnes est guide par un processus de dveloppement logiciel, c'est--dire un modle dcrivant les tapes suivre pour l'accomplissement du projet. Ce processus est, en gnral, automatis par un ou plusieurs outils. Voir la figure 2.1. Tout au long de cet ouvrage, nous emploierons les termes personnes, projet, produit, processus (Annexe C) et outils, que nous dfinissons de la faon suivante : Personnes : les architectes, dveloppeurs, testeurs avec la direction qui les soutient, ainsi que les utilisateurs, clients et autres intervenants sont les lments moteurs de tout projet logiciel. Les personnes dsignent de vritables tres humains, par opposition au concept abstrait de travailleur, que nous prsenterons plus loin. Projet : lment d'organisation travers lequel est gr le dveloppement du logiciel. L'aboutissement d'un projet est le produit livr sous forme de version.

r H

Produit : ensemble des artefacts crs au cours du cycle de vie du projet, tels que les modles (Annexe A), le code source, les excutables et la documentation.

Processus : un processus d'ingnierie logicielle fournit une dfinition de l'ensemble des activits requises pour transformer en produit les besoins exprims par les utilisateurs. Un processus offre un cadre gnrique ( template ) la cration de projets. Outils : logiciels permettant d'automatiser les activits dfinies par le processus.

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Les quatre P du d v e l o p p e m e n t logiciel

QATTRFW

Figure 2.1 l^es 4 x P du dveloppement logiciel.

Processus Template

significative, comme l'valuation d'un risque particulier, le dveloppement d'un soussystme (Annexe A) ou la ralisation d'une itration offrent cette possibilit. Une architecture rationnelle, dote d'interfaces clairement dfinies (Annexe A ; voir galement le chapitre 9) entre sous-systmes et composants (Annexe A ; voir galement le chapitre 10), autorise une telle rpartition du travail.

Personnes

Participants

Projet

Automatisation

Planification du projet : l'impression d'tre confront un planning irraliste est totalement dmoralisante. Personne n'aime aller travailler en sachant pertinemment que, quels que soient les efforts fournis, i l sera impossible de produire les rsultats attendus. Les techniques utilises dans les phases de cration et d'laboration permettent aux dveloppeurs de se faire une ide assez fidle de ce que devra tre le rsultat final du projet, c'est--dire de ce que devra faire le produit. I l devient alors possible d'imaginer un plan de travail raliste et d'liminer le fameux on n'y arrivera jamais .

Rsultat Produit

Clart du projet : on apprcie, en gnral, de comprendre ce que l'on fait et, si possible, d'avoir une vision globale d'un projet. La description de l'architecture fournit cette vue d'ensemble chaque personne implique dans le projet. Sentiment d'accomplissement : un cycle de vie itratif assure de frquents retours d'exprience qui, leur tour, permettent des avances. Cet change constant se traduit par une acclration du rythme de travail et un sentiment d'accomplissement plus marqu.

2.1 Les personnes jouent un rle crucial

Diverses personnes sont impliques dans le dveloppement d'un produit logiciel tout au long de son cycle de vie. Certaines financent le produit, tandis que d'autres le planifient, le dveloppent, le grent, le testent, l'utilisent ou en bnficient. Le processus guidant le dveloppement doit, par consquent, tre orient vers les personnes, c'est--dire convenir parfaitement ses utilisateurs.

2.1.2 Les rles

changent

2.1.1 Les processus de dveloppement sur les personnes

ont un impact

La faon dont s'organise et se gre un projet logiciel affecte profondment les personnes qui y prennent part. Les concepts de faisabilit, de gestion des risques, d'organisation des quipes, de planification et de clart du projet jouent tous un rle important. Faisabilit du projet : rares sont ceux qui aiment travailler sur des projets jugs infaisables. Personne n'est prt sombrer avec le navire. Comme nous l'avons vu au chapitre 1, une approche itrative du dveloppement permet d'valuer trs tt la faisabilit d'un projet. Les projets infaisables peuvent ainsi tre rapidement abandonns, ce qui vite une dmoralisation gnrale. Gestion des risques : de la mme faon, le soupon d'une analyse hasardeuse et d'une, rduction insuffisante des risques provoque un malaise. L'exploration des risques majeurs ds les phases initiales du projet permet d'attnuer ce problme. Structure des quipes : le travail en petits groupes de six huit personnes est indniablement plus productif. Or, les processus qui attribuent chaque groupe une tche

Les principales activits du dveloppement logiciel tant excutes par des personnes, il est ncessaire, pour amliorer leur efficacit, de se conformer un processus de dveloppement uniforme, soutenu par des outils et un langage de modlisation unifi (qui existe, aujourd'hui, avec UML) (Annexe C). Un tel processus autorise, non seulement, la fabrication de meilleurs logiciels en termes de dlai de mise sur le march, de qualit et de cots, mais aussi la spcification d'exigences rpondant plus fidlement aux besoins des utilisateurs. Ce type de processus permet, en outre, de choisir l'architecture la plus propice un dveloppement respectueux des dlais et des budgets allous, et offre un autre avantage : celui de faciliter la construction de logiciels plus sophistiqus. Nous avons remarqu, dans le chapitre 1, que la complexit croissante du monde rel allait de pair avec l'exigence de systmes logiciels de plus en plus complexes. Les processus mtier et les logiciels les prenant en charge auront une dure de vie plus longue. Le monde rel ne cessant d'voluer tout au long de ces cycles de vie, les systmes logiciels doivent tre conus pour voluer sur de longues priodes de temps. La comprhension et la prise en charge de ces processus mtier plus complexes et leur implmentation sous forme de logiciels exigent la collaboration de nombreux dveloppeurs. Il est indispensable, pour garantir l'efficacit du travail en quipes de plus en plus importantes, de disposer d'un processus montrant la voie suivre. Ce type d'orientation permet aux dveloppeurs de travailler plus intelligemment , c'est--dire en limitant leurs efforts ce qui cre une vritable valeur ajoute pour le client. La modlisation par les cas d'utilisation, parce qu'elle s'attache aux besoins des utilisateurs, constitue un premier pas dans cette direction. L'architecture en est un autre, qui permet l'volution des systmes sur la dure. Enfin, l'achat ou la rutilisation d'un nombre maximal de logiciels s'inscrivent dans

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Les quatre P du d v e l o p p e m e n t logiciel

CHAPITRE 2

cette mme logique, mais sont conditionns par une politique cohrente d'intgration de composants rutilisables avec les lments nouvellement dvelopps.

Figure 2.2 tes travailleurs et les ressources qui les ralisent.

Retirer de l'argent : Spcificateur de cas d'utilisation

Compte : Ingnieur de composants

Retirer de i'argent : Testeur d'intgration

Dans les prochaines annes, la plupart des dveloppeurs logiciels pourront se consacrer plus directement leur mission et dvelopper des logiciels plus complexes grce l'utilisation d'un processus automatis et de composants rutilisables. L'avenir prvisible du dveloppement logiciel accordera une place prpondrante aux personnes, car c'est bien dans le choix des collaborateurs que rside, enfinde compte, la cl du succs. Tout le problme est de leur permettre de donner le meilleur d'eux-mmes et d'accomplir ce dont seuls les humains ont le secret : tre cratifs, dtecter de nouvelles opportunits, faire usage de leur facult de jugement, communiquer avec les clients et les utilisateurs, et comprendre un monde en perptuelle volution.

Travailleurs

o J

o f~f

2.1.3 Des ressources aux travailleurs

Il existe diffrentes fonctions au sein d'une organisation dveloppant du logiciel. Vous devez, pour prparer vos collaborateurs occuper ces fonctions, non seulement user de pdagogie et leur dispenser les formations adquates, mais aussi faire preuve de discernement dans l'attribution des tches et leur assurer un encadrement efficace et rassurant. Le passage du statut de ressource latente celui de travailleur reprsente un dfi pour tout service de dveloppement informatique.

Ressources Marie

G Charles

La figure 2.2 illustre de quelle faon une personne peut incarner plusieurs travailleurs dans un projet. Un travailleur peut galement tre reprsent par diffrentes personnes travaillant en collaboration. Par exemple, un travailleur architecte pourra dsigner tout un service d'architecture. Chaque travailleur se voit confier un ventail de responsabilits et doit effectuer un ensemble d'activits dans le dveloppement du logiciel. Pour affecter les ressources aux travailleurs, le chef de projet doit identifier les comptences de chacun et les croiser avec les comptences requises pour les travailleurs, ce qui n'est pas une mince affaire, surtout lors d'une premire utilisation du Processus unifi. Les comptences des ressources (c'est--dire des personnes relles) doivent correspondre aux comptences requises par les diffrents travailleurs pour la ralisation du projet. Si certaines de ces comptences peuvent tre acquises par le biais de formations adaptes, d'autres doivent tout l'exprience. C'est le cas, par exemple, des comptences ncessaires l'laboration des cas d'utilisation, par opposition celles d'un architecte qui sont forcment le fruit d'une longue pratique. Une personne peut incarner plusieurs travailleurs au cours d'un projet : par exemple, Marie pourra dbuter le projet comme rdactrice de cas d'utilisation et devenir, plus tard, ingnieur de composants. Lors de la rpartition des ressources, le chef de projet doit veiller limiter autant que possible les changes d'artefacts d'une ressource l'autre de faon fluidifier au maximum le processus. Par exemple, l'ingnieur du cas d'utilisation Retirer de l'argent (Annexe A ; voir galement le chapitre 7) va accumuler un grand nombre d'informations sur les responsabilits de la classe Compte (Annexe A). I l parat donc logique qu'il soit aussi l'ingnieur de composants de la classe Compte. Une autre solution consisterait former une autre personne cette tche, mais les dperditions d'informations, les risques de malentendu et autres mprises en compromettraient l'efficacit.

Nous avons retenu le terme de travailleur (Annexe C) pour dsigner les fonctions attribues aux membres d'une quipe et que ceux-ci acceptent d'assumer [4], Le type de travailleur renvoie au rle que joue un individu particulier dans le dveloppement du logiciel, comme spcificateur de cas d'utilisation, architecte, ingnieur de composants ou testeur d'intgration. Nous n'utilisons pas le terme rle ( la place de travailleur) pour deux raisons essentielles : d'abord, parce que ce terme a une signification prcise diffrente dans UML, ensuite, parce que le concept de travailleur doit tre trs concret. I l est important de rflchir aux fonctions occupes par chacun en termes de travailleurs individuels. Nous avons galement besoin du terme rle pour dsigner les rles que remplit chaque travailleur. Un travailleur peut ainsi jouer plusieurs rles vis--vis des autres travailleurs dans les diffrents enchanements d'activits. Par exemple, le travailleur ingnieur de composants pourra prendre part diffrents enchanements d'activits dans lesquels il jouera chaque fois un rle spcifique. Chaque travailleur (c'est--dire chaque instance de travailleur ) a la responsabilit d'un ensemble d'activits, comme les activits impliques par la conception d'un sous-systme. Pour tre efficaces, les travailleurs ont besoin des informations ncessaires la ralisation de ces activits. Ils doivent comprendre la nature de leur rle par rapport celui des autres travailleurs, mais aussi disposer des outils appropris. Les outils doivent, non seulement, les assister dans la ralisation de leurs tches, mais aussi les prserver de toute information non pertinente. Pour atteindre ces objectifs, le Processus unifi dcrit formellement les fonctions (c'est--dire les travailleurs ) pouvant tre assumes au cours du processus de dveloppement.

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Les quatre P du d v e l o p p e m e n t logiciel

CHAPITRE 2

2.2 Tel projet, tel produit

Un projet de dveloppement dbouche sur une nouvelle version d'un produit. Le premier projet du cycle de vie (c'est--dire le premier cycle de dveloppement, parfois appel projet tout neuf ) permet de mettre au point et de livrer le systme, ou produit, initial. Les cycles de projet successifs prolongent la vie du systme sur plusieurs versions. Pour une prsentation plus dtaille de la gestion de projet, consultez les ouvrages [9] et [10]. Tout au long du cycle de vie, une quipe de projet doit se soucier des changements, des itrations et du contexte dans lequel est men le projet : Une squence de changements : si les projets de dveloppement de systmes aboutissent la livraison de produits, le chemin qui y mne est ponctu d'une srie de changements. A mesure qu'avancent les phases et les itrations, les travailleurs doivent bien garder l'esprit ce fait tabli de la vie du projet. Chaque cycle, chaque phase et, oui, chaque itration transforme le systme d'un tat un autre. Le premier cycle du dveloppement est un cas particulier, puisqu'il fait passer le systme du nant un tat concret. Chaque cycle conduit une version et, au-del d'une squence de cycles, l'volution se poursuit sur plusieurs gnrations. Une srie d'itrations : les travailleurs effectuent les activits lies chaque phase d'un cycle par une srie d'itrations. Chaque itration met en uvre un ensemble de cas d'utilisation ou contribue la rduction de certains risques, et se dcompose elle-mme en une srie d'enchanements d'activits : besoins, conception, implmentation et tests. Le fait que les itrations accomplissent chacun de ces enchanements d'activits nous permet de les envisager comme des mini-projets.

2.3.1 Qu'est-ce qu'un systme

logiciel ?

Un systme logiciel se rsume-t-il au code machine et aux excutables ? I l en est constitu, bien videmment. Mais qu'est-ce que le code machine ? C'est une description ! Une description sous forme binaire de ce qui peut tre lu et compris par un ordinateur. Un systme logiciel est-il un code source ? C'est--dire une description crite par des programmeurs et pouvant tre lue et comprise par un compilateur ? Sans aucun doute. Cette rponse pourrait tre juge satisfaisante. On peut poursuivre ce petit jeu de questions-rponses sur la conception d'un systme logiciel en termes de sous-systmes, de classes, de diagrammes d'interaction (Annexe A), de diagrammes d'tats-transitions (Annexe A) et d'autres artefacts. Constituent-ils le systme ? Oui, ils en font partie. Qu'en est-il des besoins, des tests, des ventes, de la production, de l'installation et du fonctionnement ? Constituent-ils le systme ? Oui, ils font galement partie du systme. Un systme se compose de tous les artefacts ncessaires sa reprsentation sous des formes lisibles aussi bien pour les machines que pour les travailleurs et les intervenants de toute sorte. Les machines sont les outils, compilateurs ou ordinateurs cibles. Les travailleurs regroupent les responsables, architectes, dveloppeurs, testeurs, personnes du marketing, administrateurs et autres. Enfin, les intervenants reprsentent les personnes finanant le projet, les utilisateurs, les commerciaux, les chefs de projet, les responsables hirarchiques, les quipes de production, les agences de rglementation, etc. Dans cet ouvrage, nous utiliserons le terme travailleur pour dsigner ces catgories de faon collective, sauf mention contraire explicite.

2.3.2 Les artefacts

Artefact (Annexe C) est un terme gnral dsignant toute sorte d'information cre, produite, modifie ou utilise par les travailleurs dans la mise au point du systme. Parmi ces artefacts, citons les diagrammes UML et le texte qui leur est associ, les esquisses et les prototypes d'interfaces utilisateur (Annexe C ; voir galement les chapitres 7 et 13), les composants, les plans des tests (voir chapitre 11) et les procdures de test (voir chapitre 11). Il existe principalement deux types d'artefacts : les artefacts d'ingnierie et les artefacts de gestion. Cet ouvrage s'attache essentiellement aux artefacts d'ingnierie crs lors des diffrentes phases du processus (c'est--dire les phases d'expression des besoins, d'analyse, de conception, d'implmentation et de tests). Le dveloppement de logiciels ncessite, toutefois, l'utilisation d'artefacts de gestion. Certains de ces artefacts ont une dure de vie assez brve, puisqu'ils ne survivent pas au projet lui-mme. C'est le cas de l'tude de rentabilit, du plan de dveloppement (qui comprend les plans de versions et d'itrations), du plan d'affectation des personnes aux diffrents travailleurs (c'est--dire aux diverses fonctions ou responsabilits du projet) et de l'organisation des activits des travailleurs au sein de ce plan. Ces artefacts sont dcrits sous forme de texte ou de diagrammes, l'aide d'un quelconque mode de visualisation, ncessaire pour clarifier l'engagement de l'quipe du projet vis--vis de ses acteurs financiers. Les artefacts de gestion comprennent galement les spcifications de l'environnement de dveloppement :

Un cadre pour l'organisation : tout projet implique la prsence d'une quipe dont la mission est de produire un rsultat dans le respect de certaines contraintes professionnelles de dlais, de budgets et de qualit. Ces personnes sont employes sur le projet en tant que travailleurs. Le concept de processus offre un cadre humain pour la ralisation du projet. Ce cadre (ou template ) indique les types de travailleurs ncessits par le projet et les artefacts utiliser. Le processus fournit galement tout un arsenal de principes et de conseils, de mthodes heuristiques et de pratiques prsents sous forme de documentation qui accompagnent dans leur tche les diffrents collaborateurs du projet.

2.3 Un produit ne se r s u m e pas du code

Dans le contexte du Processus unifi, le produit mis au point est un systme logiciel. Le terme produit, tel qu'il est employ dans ces pages, ne renvoie pas seulement au code livr, mais au systme dans son entier.

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Les quatre P du d v e l o p p e m e n t logiciel

CHAPITRE 2

les logiciels d'automatisation des processus, mais aussi la plate-forme matrielle indispensable aux dveloppeurs et servant de rfrentiel pour les artefacts d'ingnierie.

Modle des cas d'utilisation

Modle d'analyse

Modle de conception

Modle de dploiement

Modle d'implmentation

Modle des tests

2.3.3 Un systme

dispose de plusieurs

modles

Figure 2.4 Ensemble principal de modles du Processus unifi .

1

1. En termes UML, ces paquetages reprsentent les units mtier ou units de travail dans le Processus unifi et non des lments de modle permettant de modliser un systme particulier. Voir galement l'explicationfigurantdans l'encadr de la section 7.1.

Le type d'artefact le plus pertinent utilis par le Processus unifi est le modle. Chaque travailleur a besoin d'un point de vue unique sur le systme (voir la figure 2.3). Lors de la conception du Processus unifi, nous avons identifi tous les travailleurs intervenant dans un projet et les diffrentes perspectives susceptibles de leur tre utiles. Les points de vue ainsi runis sont structurs en entits de niveau suprieur, c'est--dire en modles, de telle sorte qu'un travailleur puisse retrouver n'importe quel point de vue partir de l'ensemble des modles.
Figure 2.3

2.3.4 Qu'est-ce qu'un modle ?

Un modle est une abstraction d'un systme, dcrivant le systme modlis d'un certain point de vue et un certain niveau d'abstraction [1]. Le point de vue peut tre, par exemple, celui de la spcification ou de la conception du systme.

Travailleurs participant au
dveloppement logiciel. (Certains simi des

Utilisateurs

travailleurs ftngletons ;
d'autres sont imilii types et inuiii objets).

Ces abstractions du systme sont labores par les architectes et les dveloppeurs. Par exemple, les travailleurs chargs de modliser les exigences fonctionnelles pensent le systme comme ayant des utilisateurs en dehors du systme lui-mme et des cas d'utilisation en son sein. Ils ne se soucient pas de l'apparence extrieure du systme, mais uniquement de ce qu'il peut faire pour ses utilisateurs. En revanche, les travailleurs laborant la conception rflchissent aux lments structurels, tels que les sous-systmes et les classes. Ils s'attachent au fonctionnement de ces lments abstraits dans un contexte donn et leur collaboration pour la production de cas d'utilisation, et en donnent une interprtation particulire.

2.3.5 Chaque modle

Concepteurs

est une vue autonome du

systme

Un modle est une abstraction smantiquement ferme du systme. C'est une vue autonome, en ceci que l'utilisateur d'un modle n'a besoin d'aucune autre information (en provenance, par exemple, d'autres modles) pour l'interprter.

Analystes

La fabrication d'un systme procde donc de la construction de modles gnraux partir de diffrents modles dcrivant tous les points de vue possibles sur le systme. La slection des modles d'un systme est, en ce sens, l'une des dcisions stratgiques que doit prendre l'quipe de dveloppement. Le chapitre 1 nous a permis de prsenter les modles fondamentaux du Processus unifi (voir la figure 2.4). Le Processus unifi fournit un ensemble de modles soigneusement choisis pour le dmarrage d'un projet, qui mettent en lumire le systme pour tous les travailleurs, y compris les clients, utilisateurs et chefs de projet. Ces diffrents modles ont t slectionns avec l'objectif de satisfaire au besoin d'informations de tous ces travailleurs.

L'ide d'autonomie signifie que les dveloppeurs ne conoivent leurs modles que comme une interprtation unique de ce qui se produira dans le systme lorsque sera dclench un vnement dcrit par le modle. Outre le systme en question, un modle doit dcrire les interactions entre le systme et son environnement. I l doit donc contenir, en plus du systme en cours de modlisation, les lments pertinents de son environnement, c'est--dire ses acteurs (Annexe A ; voir galement chapitre 7). La plupart des modles d'ingnierie sont dfinis par un sous-ensemble soigneusement slectionn du langage UML. Par exemple, le modle des cas d'utilisation se compose des cas d'utilisation et des acteurs. C'est fondamentalement tout ce qui permet de le comprendre. Le modle de conception dcrit les sous-systmes et les classes du systme et la faon dont ils interagissent pour raliser les cas d'utilisation. L'un et l'autre de ces modles livrent deux interprtations diffrentes, quoique cohrentes, des ractions du systme face des stimuli extrieurs mis par les acteurs. Ces interprtations divergent du simple fait qu'elles sont destines tre utilises par des travailleurs ayant des tches et des missions diffrentes. Le modle des cas d'utilisation prsente une vue externe du systme, contrairement au modle de conception qui en offre une vision interne. De mme, le modle des cas d'utilisation saisit les usages du systme, alors que le modle de conception en reprsente la construction.

Le Processus unifi de dveloppement logiciel

Les quatre P du dveloppement logiciel

pj

tfli

PARTIE I

2.3.6 Exploration d'un modle Un modle identifie toujours le systme en cours de modlisation. Cet lment du systme contient, par consquent, d'autres lments. Le sous-systme de plus haut niveau (Annexe B) reprsente le systme en cours de fabrication. Dans le modle des cas d'utilisation, le systme se compose de cas d'utilisation, tandis qu'il regroupe des sous-systmes, interfaces et classes dans le modle de conception. Il contient galement des collaborations (Annexe A) identifiant tous les sous-systmes ou classes participants, sans se limiter ceuxci puisqu'on peut y trouver des diagrammes d'tats-transitions ou des diagrammes d'interaction. Dans le modle de conception, chaque sous-systme peut, son tour, englober des constructions de mme type, ce qui implique une hirarchisation des lments figurant dans ce modle. 2.3.7 Relations entre modles Un systme contient toutes les relations (Annexe A) et contraintes existant entre les lments contenus dans diffrents modles [1]. Il ne se r s m donc pas la simple juxtapou e sition de ses modles, mais comprend galement les relations qui les unissent. Par exemple, chaque cas d'utilisation du modle des cas d'utilisation entretient une relation avec une collaboration du modle d'analyse (et vice-versa). UML nomme ce type de relation d p n a c de traabilit, ou tout simplement trace (Annexe A). Consultez la figure 2.5, e dne dans laquelle sont indiques les traces dans une seule direction. Il existe aussi des traces entre, par exemple, les collaborations du modle de conception et celles du modle d'analyse, ou entre les composants du modle d'implmentation et les sous-systmes du modle de conception. On peut ainsi utiliser les traces pour relier les lments d'un modle ceux d'un autre modle.
Figure 2.5 / \ sont lis les par itoiit-ment

2.4 Le processus dirige les projets

Le terme processus souffre d'un usage excessif. On le rencontre dans bien des contextes diffrents (processus mtier, processus de dveloppement, processus logiciel, entre autres) sous des acceptions diverses. Dans le contexte du Processus unifi, il fait rfrence au principal processus mtier de toute socit de dveloppement informatique, c'est--dire d'une organisation dont l'activit consiste mettre au point des logiciels et en assurer le suivi (sur la conception d'une socit de dveloppement logiciel, voir le [2]). On trouve a glement, dans ce type d'activit, d'autres processus, tels que le processus de support, qui implique une interaction avec les utilisateurs du produit, et le processus de ventes, qui d b t ue par une commande et aboutit la livraison d'un produit. Toutefois, nous nous intressons principalement, dans cet ouvrage, au processus de dveloppement [3].

CI
Modle des cas d'utilisation
a d e s

4hn
N

I I
Modle d'analyse
N

I I
Modle de conception

4B
N

1 f
Modle d'implmentation

uni

/,Il

irnubilit.

mations ae

aux autres , t ' A

dpendances de traabilit avec

a des dpendances de traabilit avec

a des dpendances de traabilit avec

Le fait que les lments de deux modles soient lis ne modifie en rien leur rle l'intrieur de leur propre modle. Les relations de traabilit entre lments de diffrents modles n'ajoutent aucune information smantique permettant de mieux comprendre les modles eux-mmes. Elles ne font que relier les modles les uns aux autres. La capacit de remonter d'un modle un autre est fondamentale dans le dveloppement logiciel pour favoriser, entre autres, la clart et la propagation des modifications.

2.4.1 Le processus : un cadre gnrique Dans le Processus unifi, le terme processus renvoie l'ide de cadre ( template ) pouvant tre rutilis par la cration d'instances de celui-ci. Il est comparable, dans le paradigme orient objet, un format de classe permettant de crer des objets. L'expression instance de processus est synonyme de projet. Dans cet ouvrage, un processus de dveloppement logiciel dfinit les activits ncessaires la transformation des besoins des utilisateurs en un ensemble cohrent d'artefacts constituant un produit logiciel et, plus tard, la transformation des volutions de ces besoins en un nouvel ensemble d'artefacts tout aussi cohrent. Le terme besoin dsigne les besoins exprims par les utilisateurs et sera parfois remplac par exigence. Au dpart, il n'est pas ncessaire de comprendre ces besoins dans leur intgralit. La saisie complte de ces besoins exigera, en gnral, une comprhension plus pointue de l'activit du client et du cadre de travail des utilisateurs. Ce processus aboutit la production d'un ensemble cohrent d'artefacts, vritable rfrence reprsentant un systme d'applications ou une famille de tels systmes comprenant un produit logiciel. Un processus est donc la dfinition d'un ensemble d'activits, et non l'excution de ces activits. Enfin, le processus ne couvre pas seulement le premier cycle du dveloppement (la premire version), mais les cycles ultrieurs les plus courants. Dans les versions suivantes, c'est une instance du processus qui prend en compte les modifications progressives des besoins et les rpercute dans les artefacts. 2.4.2 Les relations entre activits constituent les enchanement d'activits Nous dcrivons un processus en termes d'enchanements d'activits. Quelle est la source de ces e c an m ns ? Ils ne rsultent pas de la simple division du processus en un certain nombre de nh e e t sous-processus en interaction. De mme, nous n'utilisons pas les organigrammes classiques pour dcrire la faon dont le processus se d c m oe en units plus rduites. Ces diagrammes o p s n'offrent pas une reprsentationfidlede la structure des e c an m ns d'activits. nh e e t

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t
PARTE I

logiciel

Les quatre P du d v e l o p p e m e n t logiciel

CHAPITRE 2

La notation en poisson est le raccourci d'un enchanement d'activits.

la place, nous identifions dans un premier temps les diffrents types de travailleurs prenant part au processus. Puis, nous recensons les artefacts qu'il faudra crer au cours du processus pour chaque type de travailleur. Cette identification, bien sr, n'est pas instantane. Le Processus unifi capitalise sur une longue exprience pour la dtection d'un ensemble ralisable d'artefacts et de travailleurs. Une fois cet ensemble identifi, nous pouvons dcrire le flux du processus travers les diffrents travailleurs et la faon dont ces derniers crent et produisent des artefacts ou utilisent ceux dvelopps par les autres. La figure 2.6 montre un diagramme d'activits (Annexe A) dcrivant l'enchanement des activits de la modlisation des cas d'utilisation. Remarquez la prsence de traves (Annexe A) : i l y en a une pour chaque travailleur. Le travail passe d'un travailleur l'autre, chacun excutant une ou plusieurs activits (symbolises par des engrenages) de cet enchanement.

Collaboration de travailleurs et d'artefacts permettant de dcrire le flot des Besoins du processus

Prenons, par exemple, l'enchanement d'activits de l'expression des besoins. Celui-ci implique diffrents travailleurs : analyste systme, architecte, spcificateur de cas d'utilisation et concepteur d'interface utilisateur, et, entre autres artefacts, le modle des cas d'utilisation et les cas d'utilisation. On pourrait ajouter les ingnieurs de composants et les testeurs d'intgration, ainsi que des ralisations de cas d'utilisation (Annexe B ; voir aussi les chapitres 8 et 9), des classes, des sous-systmes et des interfaces.

Analyste systme

O O
O

Figure 2.6 Enchanement d'activits avec travailleurs et activits figurant dans des traves .

Identifier les acteurs et les cas d'utilisation

Structurer le modle des cas d'utilisation

2.4.3 Spcialisation

du

processus

Architecte

Dfinir l'ordre de priorit des cas d'utilisation

D
Spcificateur de cas d'utilisation Dtailler un cas d'utilisation

Aucun processus de dveloppement logiciel n'est universel ! Les processus varient parce qu'ils existent dans diffrents contextes, mettent au point diffrents types de systmes et rpondent diffrents types de contraintes professionnelles (planification, cots, qualit ou fiabilit, par exemple). C'est pourquoi, dans les faits, un processus de dveloppement logiciel doit pouvoir tre adapt et configur afin de satisfaire aux besoins rels d'un projet ou d'une organisation en particulier. Le Processus unifi a t conu pour tre spcialis (sur la conception d'un processus, voir [6]). I l s'agit, en effet, d'un processus gnrique, c'est-dire d'un cadre gnral de processus. Chaque organisation utilisant le Processus unifi finira par le spcialiser pour l'adapter sa propre situation (c'est--dire son type d'application, de plate-forme, etc.) (sur la spcialisation d'un processus, voir [8]).

O
Prototyper l'interface utilisateur

Concepteur d'interface utilisateur

Le Processus unifi peut donc tre spcialis pour convenir diffrents besoins en termes d'application et d'entreprise. En mme temps, i l est souhaitable que ce processus reste cohrent, tout au moins au sein d'une mme entreprise. Cette cohrence permettra l'change rapide de composants, de personnes et de responsables d'un projet l'autre, et la comparaison des mtriques valuant le niveau de progression. Plusieurs types de facteurs influent sur la modification du processus : Les acteurs lis l'organisation : structure de l'entreprise, culture interne, organisation el gestion des projets, comptences disponibles, exprience antrieure et systmes logiciels existants. Les facteurs lis au domaine : domaine d'application, processus mtier prendre en charge, communaut des utilisateurs et offres proposes par la concurrence. Les facteurs lis au cycle de vie : dlai de mise sur le march, dure de vie prvue du logiciel, technologie et expertise mises en uvre dans le dveloppement du logiciel, plan de livraison des versions suivantes. Les facteurs techniques : langage de programmation, outils de dveloppement, base de donnes, frameworks et architectures standard sous-jacentes, communication et distribution.

Il est alors facile d'identifier les activits que doivent excuter ces travailleurs lorsque vient leur tour. Ces activits reprsentent un travail significatif pour une personne agissant comme travailleur. On peut, en outre, voir instantanment partir de ces descriptions si une personne en particulier a besoin d'intervenir plus d'une fois dans l'enchanement d'activits. L'ensemble du processus peut donc tre dcrit sous forme d'lments appels enchanements d'activits (Annexe C). En termes UML, un enchanement d'activits est le strotype (Annexe A) d'une collaboration laquelle participent travailleurs et artefacts. I l est donc possible (et c'est gnralement le cas) que les travailleurs et artefacts prenant part un enchanement d'activits soient impliqus dans d'autres enchanements. Nous utiliserons, pour les enchanements d'activits, la notation fournie dans la figure 2.7.

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Les quatre P du d v e l o p p e m e n t logiciel

cTpTrRE2wM

.5 Les outils font partie intgrante du processus

Les processus actuels de dveloppement logiciel sont pris en charge par des outils. I l est impensable, aujourd'hui, de mettre au point des logiciels sans recourir un processus reposant sur des outils. Processus et outils sont livrs ensemble, les outils faisant partie intgrante du processus [5], [7].

Telles sont les causes. Mais quels sont leurs effets ? Vous pouvez, par exemple, dcider de supprimer certains travailleurs et artefacts du Processus unifi pour reflter plus fidlement l'organisation d'entreprises moins dveloppes sur ce plan. Ou encore ajouter de nouveaux travailleurs et artefacts ne figurant pas encore dans le processus, pour en amliorer l'efficacit sur votre projet. I l n'est pas impossible, non plus, de remanier la description d'un artefact prcis pour lui imposer une structure diffrente. Nous savons, pour en tre rgulirement tmoins, que les ingnieurs se conforment globalement ce que suggre le Processus unifi sur les premiers projets, puis, l'exprience aidant, qu'ils se mettent dvelopper leurs propres extensions plus ou moins significatives. Quels sont les aspects de la conception mme du Processus unifi qui en permettent la spcialisation [6] ? La rponse est simple, bien qu'elle exige quelque effort de comprhension. Le produit Objectory a, lui-mme, t conu l'aide d'lments qui sont, en ralit, des objets : des cas d'utilisation, des collaborations et des classes. Ces classes ne sont pas, en l'occurrence, des objets logiciels, mais des objets mtier (c'est--dire des travailleurs et des artefacts) et peuvent tre spcialises ou changes contre d'autres sans aucune modification de la conception du processus. Vous verrez, dans les chapitres suivants, que nous employons, pour la description des enchanements d'activits, des objets : les travailleurs et les artefacts.

2.5.1 Les outils influent sur le processus

Le processus est nettement influenc par l'existence d'outils adapts. Ceux-ci se rvlent particulirement efficaces pour automatiser les tches rptitives, prserver la structure des lments, grer de grandes quantits d'informations et vous guider le long d'un chemin de dveloppement spcifique.

2.4.4 Les mrites

d'un

processus

L'utilisation d'un processus commun aux diverses quipes de dveloppement procure de nombreux avantages : Chaque membre de l'quipe de dveloppement comprend quel est son rle dans le dveloppement du produit. Les dveloppeurs apprhendent mieux l'activit des autres dveloppeurs, des stades antrieurs ou postrieurs du mme projet, sur des projets diffrents au sein de la mme entreprise, sur des sites disperss, ou mme sur des projets se droulant dans d'autres entreprises. Les dirigeants et responsables, mme s'ils sont incapables de lire du code, comprennent ce que font les dveloppeurs par le biais des graphiques d'architecture. Les dveloppeurs, dirigeants et responsables peuvent passer d'un projet l'autre, ou d'une division l'autre, sans avoir faire l'apprentissage d'un nouveau processus. La formation peut tre standardise l'chelle de l'entreprise et dispense sous forme de cursus complets ou de cours acclrs. Le droulement du dveloppement logiciel est reproductible, ce qui signifie qu'il peut tre planifi et budgt avec suffisamment de prcision pour viter les mauvaises surprises. Malgr tous ces avantages, certains maintiennent qu'un processus commun ne rsout pas les problmes vraiment dlicats . Ce quoi nous rpondons tout simplement : bien sr que non . Seules les personnes sont en mesure de rsoudre les problmes. Mais un processus rigoureux favorise et amliore considrablement le travail d'quipe. Prenez, titre de comparaison, la mise sur pied d'une opration militaire. Certes, la conduite d'une bataille se rsume, en fin de compte, l'action des individus sur le terrain, mais l'issue dpend aussi de l'efficacit de leur organisation.

Moins i l y a d'outils, plus le processus dpend d'une charge de travail manuel, ce qui en compromet le formalisme. En pratique, l'essentiel du travail formel doit alors tre report aux activits d'implmentation. L'absence d'outils automatisant le maintien de la cohrence travers tout le cycle de vie rendrait difficile la coordination des modles et de l'implmentation, et compliquerait le dveloppement itratif et incrmental. Soit on parviendrait des incohrences, soit i l faudrait fournir un norme travail manuel pour actualiser et coordonner les documents, ce qui ferait chuter la productivit de l'quipe. Tous les contrles de cohrence devraient tre effectus la main, tche titanesque, pour ne pas dire impossible. Non seulement les artefacts mis au point ne seraient pas exempts de dfauts, mais cette procdure prendrait beaucoup plus de temps. Il existe des outils permettant d'automatiser les activits de faon plus ou moins complte, d'amliorer la productivit et la qualit, et de raccourcir les dlais. L'utilisation d'outils modifie le processus et le formalise. De nouvelles activits, difficilement ralisables sans outils, peuvent ainsi tre intgres, et le travail gagne en prcision tout au long du cycle de vie, puisqu'il devient possible d'utiliser un langage de modlisation formel tel qu'UML pour garantir la cohrence interne de chaque modle et sa cohrence par rapport aux autres modles. On peut aussi utiliser un modle unique et gnrer, partir de celui-ci, diverses parties d'un autre modle (par exemple, de la conception l'implmentation et vice-versa).

2.5.2 Le processus

conditionne les outils

Le processus, qu'il soit explicitement ou implicitement dfini, spcifie les fonctionnalits des outils, c'est--dire les cas d'utilisation des outils. Le fait mme de l'existence d'un processus suffit lgitimer l'utilisation d'outils. Ces derniers ne sont l que pour automatiser autant que possible le processus. Il est indispensable, pour automatiser un processus, de se faire une ide parfaitement claire des cas d'utilisation qui seront ncessaires chaque travailleur et des artefacts qu'il aura grer. L'automatisation du processus fournit le moyen, d'une part, de faire travailler simultanment plusieurs personnes et, d'autre part, de vrifier la cohrence de tous les artefacts produits.

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Les quatre P du d v e l o p p e m e n t logiciel

CHAPITRE 2 B

de dveloppement qui servira de cadre l'utilisation de ces outils. Ceci doit tre absolument clair. S'il persiste ne serait-ce que l'ombre d'un doute dans votre esprit, demandez-vous s'il serait raliste de prtendre dvelopper le systme informatique d'une banque sans comprendre la nature mme des processus qui en rgissent l'activit.

2.5.4 La modlisation

visuelle au service d'UML

Nous venons de dmontrer l'importance des outils dans l'accomplissement de l'objectif du processus. Examinons, maintenant, un exemple significatif d'outil de ce type dans le contexte de l'environnement de support d'UML : l'outil de modlisation pour UML. UML est un langage visuel. En tant que tel, l'outil est cens prsenter certaines caractristiques communes un grand nombre d'applications de dessin, comme l'dition en ligne, la mise en forme, le zoom, l'impression, la couleur et le trac automatique. En plus de toutes ces caractristiques, U M L dfinit des rgles syntaxiques spcifiant le mode d'utilisation simultane des lments du langage. L'outil doit donc garantir le respect de ces rgles, ce qui dpasse les possibilits de la plupart des outillages de dessin, qui n'assurent pas ce genre de service.

Les outils qui mettent en uvre un processus automatis doivent tre simples utiliser. Pour en garantir une utilisation la plus large possible, les concepteurs de ces outils doivent troitement rflchir la faon dont est men le dveloppement logiciel. Quelle sera, par exemple, l'approche qu'adoptera un travailleur face telle tche ? Comment se rendra-t-il compte de l'aide que peut lui procurer l'outil ? Quelles seront les tches rcurrentes et, partant, qu'il sera utile d'automatiser ? l'inverse, quelles seront les tches peu frquentes, qui ne justifieront pas d'tre automatises par un outil ? De quelle faon un outil peut-il amener un travailleur consacrer du temps aux tches importantes qu'il est seul capable d'excuter et laisser l'outil le soin d'effectuer les tches rptitives dans lesquelles celuici montre toute son efficacit ? Pour rpondre de telles questions, l'outil doit tre simple comprendre et utiliser. Enfin, pour justifier le temps d'apprentissage, son utilisation doit se traduire par un vritable bond de la productivit. Plusieurs raisons spcifiques plaident pour l'objectif de la simplicit d'utilisation. Les travailleurs doivent pouvoir essayer plusieurs solutions et comprendre aisment la conception d'entre elles. Si la solution essaye se rvle impraticable, i l faut qu'ils puissent passer directement une autre approche. Les outils doivent aider rutiliser autant d'lments que possible, pour viter de repartir de zro chaque nouvelle approche. En somme, i l est fondamental non seulement que les outils prennent en charge l'automatisation des tches rptitives et la gestion des informations reprsentes par les diffrents modles et artefacts, mais galement qu'ils favorisent et accompagnent les activits cratives qui constituent le cur de tout dveloppement significatif.

2.5.3 Equilibre entre processus

et outils

Dvelopper un processus sans s'interroger sur la faon dont il sera automatis reste, par consquent, une pure vue de l'esprit. l'inverse, la mise au point d'outils sans connaissance pralable du processus (framework) qu'ils devront mettre en uvre risque d'tre infructueuse. I l faut donc trouver un quilibre entre processus et outils. D'un ct, le processus dclenche le dveloppement d'outils. De l'autre, les outils guident le processus de dveloppement. La mise au point du processus et le dveloppement des outils qui le prendront en charge doivent donc tre concomitants. chaque version du processus doit correspondre une version des outils, et chaque version doit reflter cet quilibre. La ralisation d'un quilibre proche de l'idal ncessitera plusieurs itrations, qui se nourriront rgulirement des retours d'exprience des utilisateurs.

Malheureusement, l'application sans aucune exception de rgles syntaxiques de ce type rendrait l'outil parfaitement inutilisable. En effet, le modle en cours de modification prsentera frquemment des erreurs syntaxiques que l'outil devra temporairement autoriser. I l faudra, par exemple, que soit admise la prsence d'un message dans un diagramme de squence (Annexe A ; voir aussi le chapitre 9), alors mme qu'aucune opration n'aura t dfinie pour la classe. UML comprend un certain nombre de rgles smantiques qui doivent galement tre prises en compte. Ces rgles peuvent tre intgres l'outil de modlisation, soit par le biais d'une application immdiate, soit sous forme de routines appeles la demande et parcourant le modle pour dtecter les erreurs courantes ou rechercher les inexactitudes smantiques ou syntaxiques. En somme, l'outil de modlisation doit aller au-del de la simple prise en charge d'UML pour favoriser la crativit du dveloppeur dans son utilisation d'UML. Le choix d'UML comme langage standard offre une meilleure prise en charge par des outils que tout autre langage de modlisation. Cette ouverture s'explique par l'acuit de la dfinition d'UML, mais tient aussi au fait qu'UML est dsormais un standard industriel largement utilis. Au lieu de se rsumer une concurrence acharne entre diteurs d'outils pour la prise en charge de l'ventail le plus large possible de langages de modlisation, le jeu consiste dsormais dterminer qui assure la meilleure prise en charge d'UML. Cette nouvelle rgle du jeu ne peut que bnficier aux utilisateurs et consommateurs de logiciels. UML n'est qu'un langage de modlisation. I l ne dfinit pas le processus d'utilisation d'UML pour le dveloppement de systmes logiciels. L'outil n'a donc pas appliquer un processus, mais si l'utilisateur en utilise un, il peut le prendre en charge.

Cette relation entre processus et outil ressortit, elle aussi, au problme de l'uf et de la poule. Lequel des deux prexiste l'autre ? Dans les dernires dcennies, c'est souvent l'outil qui venait en premier, le processus n'tant alors pas clairement dfini. Du coup, les outils ne donnaient pas les rsultats escompts lorsque les utilisateurs les appliquaient des processus de type tout ou rien . Constat qui a souvent branl notre foi dans les outils. Le dveloppement logiciel relevait encore et toujours de l'artisanat sans grande efficacit. En d'autres termes, le processus doit s'enrichir de la confrontation avec les outils, qui doivent eux-mmes prendre en charge un processus soigneusement pens. Nous voulons affirmer avec conviction qu'une automatisation russie du processus ( l'aide d'outils) n'est envisageable que si l'on mne, en parallle, le dveloppement du framework

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I I

M
u

Les quatre P du d v e l o p p e m e n t logiciel i 6 7 8 IVAR JACOBSON and STEN JACOBSON, "Designing a Software Engineering Process," Object Magazine, June 1995. IVAR JACOBSON and STEN JACOBSON, "Designing an integrated SEPSE," Object Magazine, September 1995. IVAR JACOBSON and STEN JACOBSON, "Building your own methodology by specializing a methodology framework," Object Magazine, November-December 1995. GRADY BOOCH, Object Solutions: Managing the Object-Oriented MA: Addison-Wesley, 1996. Project, Reading,

2.5.5 Les outils prennent en charge tout le cycle de vie

Divers outils existent, qui assurent la prise en charge de chaque aspect du cycle de vie logiciel (Annexe C) : Les outils de gestion des besoins permettent de stocker, parcourir, rviser les divers besoins ou exigences d'un projet logiciel, d'en assurer la traabilit et la navigabilit. I l arrive que soit prcis l'tat d'un besoin et que l'outil permette de suivre l'volution de ce besoin travers d'autres artefacts du cycle de vie, tels que des cas d'utilisation ou des cas de test (voir le chapitre 11). Les outils de modlisation visuelle permettent d'automatiser l'utilisation d'UML, c'est-dire de modliser et d'assembler visuellement une application. Ils assurent, en outre, l'intgration dans des environnements de programmation et garantissent le maintien de la cohrence entre modle et implmentation. Les outils de programmation fournissent une large gamme d'outils, notamment des diteurs, compilateurs, dbogueurs, dtecteurs d'erreurs et analyseurs de performances. Les outils de contrle qualit permettent de tester les applications et les composants, c'est--dire d'enregistrer et d'excuter les cas de test guidant les tests d'une I H M et de l'interface d'un composant. Dans un cycle de vie itratif, les tests de non-rgression sont encore plus stratgiques que dans le dveloppement conventionnel. L'automatisation des cas de test est essentielle pour garantir un niveau de productivit lev. Par ailleurs, nombre d'applications doivent galement tre soumises des tests de rsistance au stress et aux lourdes charges. Comment l'architecture de cette application se comportera-t-elle face 10 000 utilisateurs simultans ? I l n'est pas inutile de connatre la rponse cette question avant de procder au dploiement de l'application sur le 10 OOOme poste utilisateur. Outre ces outils ddis une fonction, i l en existe d'autres qui traversent tout le cycle de vie, comme les outils de gestion de version et de configuration, de dtection des dfauts, de documentation, de gestion de projet et d'automatisation du processus.

10 WALKER ROYCE, Software Project Management: A Unified Framework, Reading, MA: Addison-Wesley, 1998.

2.6 R f r e n c e s
OMG Unified Modeling Language Spcification. Object Management Group, Framingham, MA, 1998. Internet: www.omg.org. IVAR JACOBSON, Martin Griss, and Patrik Jonsson, Software Reuse: Architecture, Process and Organization for Business Success, Reading, MA: Addison-Wesley, 1997. WATTS S. HUMPHREY, Managing the Software Process, Reading, MA: AddisonWesley, 1989. Ivar Jacobson, Maria Ericsson, and Agneta Jacobson, The Object Advantage: Business Process Reengineering with Object Technology, Reading, MA: Addison-Wesley, 1995. IVAR JACOBSON and STEN JACOBSON, "Beyond methods and CASE: The software engineering process with its intgral support environment," Object Magazine, January 1995.

3
Un processus pilot par les cas d'utilisation
L'objectif du Processus unifi est de guider les dveloppeurs vers l'implmentation et le dploiement efficaces de systmes rpondant aux besoins des clients. Cette efficacit se mesure en termes de cot, de qualit et de dlai de fabrication. Le passage de l'estimation des besoins du client leur implmentation est loin d'tre naturel. D'abord, parce que les besoins du client ne se laissent pas si facilement apprhender. I l faut disposer d'un moyen qui permette de les communiquer de faon claire toute personne implique dans le projet. Il faut, ensuite, tre en mesure de concevoir une implmentation oprationnelle rpondant ces besoins. I l faut, enfin, vrifier la pleine satisfaction de ces besoins en testant le systme. En raison de sa complexit, le systme est dcrit sous forme d'enchanements d'activits qui donnent peu peu naissance un systme oprationnel. Comme nous l'avons indiqu au chapitre 1, le Processus unifi est pilot par les cas d'utilisation, centr sur l'architecture, itratif et incrmental. Nous allons l'examiner, dans ce chapitre, sous l'angle des cas d'utilisation, point de vue prsent dans [1] et approfondi dans [2]. L'importance dcisive de l'architecture et les aspects itratif et incrmental feront respectivement l'objet des chapitres 4 et 5. Nous esprons, grce cette sparation des diffrents thmes, simplifier la notion de dveloppement pilot par les cas d'utilisation. C'est dans ce mme esprit que nous ne faisons que survoler la prparation du modle de dploiement, la conception de sous-systmes forte intgrit, le dveloppement de composants d'implmentation appropris (voir la section 10.3.2) et la ralisation d'autres types de tests. Ces questions ne contribuent en rien l'expos des cas d'utilisation et n'expliquent pas en quoi ces derniers orientent le travail de dveloppement ; elles ne seront donc approfondies que dans la troisime partie de l'ouvrage. La figure 3.1 illustre la srie d'enchanements d'activits et de modles du Processus unifi. Les dveloppeurs commencent par saisir les besoins des clients sous forme de cas d'utilisation dans le modle du mme nom. Puis, ils analysent et conoivent le systme rpondant ces cas d'utilisation, et crent ainsi un modle d'analyse, suivi d'un modle de conception

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus p i l o t par les cas d'utilisation

CHAPITRE 3

et d'un modle de dploiement. Vient ensuite l'implmentation du systme dans un modle d'implmentation qui comprend tout le code, c'est--dire les composants. Enfin, les dveloppeurs laborent un modle des tests permettant de vrifier que le systme offre les fonctionnalits dcrites dans les cas d'utilisation. Tous les modles sont lis les uns aux autres par des dpendances de traabilit. Le modle d'implmentation est le plus formel, dans le sens o i l est exploitable par une machine, c'est--dire qu'il peut tre compil et h sous forme d'excutables, tandis que le modle de cas d'utilisation, le moins formel de tous, est principalement exprim en langage naturel.

3.1 Le d v e l o p p e m e n t pilot par les cas d'utilisation en bref

La capture des besoins poursuit deux objectifs : identifier les vritables besoins (voir le chapitre 6) et les exprimer de faon adapte pour les utilisateurs, les clients et les dveloppeurs. Par vritables besoins , nous entendons les besoins qui, une fois implments, apporteront aux utilisateurs les avantages attendus. Les exprimer de faon adapte pour les utilisateurs, les clients et les dveloppeurs signifie que la description des besoins doit tre comprhensible par les utilisateurs et les clients. C'est l'un des enjeux majeurs de cet enchanement d'activits. Un systme s'adresse en principe diffrents types d'utilisateurs, chacun tant identifi en tant qu'acteur. Les acteurs utilisent le systme selon les interactions dcrites par les cas d'utilisation. Un cas d'utilisation est une squence d'actions qu'effectue le systme afin de produire des rsultats satisfaisants pour l'acteur. L'ensemble des acteurs et des cas d'utilisation constituent le modle des cas d'utilisation [3], [4]. /

Modle des cas d'utilisation

Analyse Modle d'analyse

Conception Modle de conception Modle de dveloppement

Figure 3.1 Le Processus unifi se compose d'une srie d'enchanements d'activits allant des besoins aux tests ( gauche, de haut en bas). Les enchanements d'activits dveloppent des modles, du modle des cas d'utilisation au modle des lests.

Implmentation

Modle d'implmentation

Les tapes-d'analyse et de conception transforment le modle des cas d'utilisation d'abord en.un modle d'analyse, puis en un modle de conception. Disons, pour tre bref, que le mod'3'analyse et le modle de conception sont, l'un et l'autre, des structures composes de classificateurs (Annexe A) et d'un ensemble de ralisations (voir les chapitres 8 et 9) dcrivant de quelle faon cette structure ralise les cas d'utilisation. Les classificateurs sont, enjjnral, des lments assimils,.des classes . Ils possdent, notamment, des attributs et des oprations (Annexe A), et peuvent tre dcrits l'aide de diagrammes d'tats-transitions (Annexe A). Certains peuvent tre instancis, prendre part des collaborations, etc. UML comprend diffrents types de classificateurs. Les sous-systmes, classes et interfaces sont des exemples de classificateurs dans cette structure. Les acteurs, cas d'utilisation, composants et nuds (Annexe A ; voir galement la section 9.3.7) en sont d'autres.

Modle des tests

Si les cas d'utilisation se sont largement imposs pour la capture des besoins des systmes logiciels en gnral, et pour les systmes base de composants en particulier [6], ils reprsentent davantage qu'un simple outil de saisie des besoins : ils orientent tout le processus de dveloppement. Ces artefacts se rvlent un instrument inestimable pour l'identification et la spcification des classes, des sous-systmes, des interfaces (Annexe A) et des cas de test, ainsi que pour la planification des itrations du dveloppement et de l'intgration du systme (voir le chapitre 10). Pour chaque itration, ils guident le droulement des enchanements d'activits, depuis l'expression des besoins jusqu'aux tests en passant par l'analyse, la conception et l'implmentation, et assurent la cohsion des diffrents enchanements.

Le modle d'analyse fournit une spcification dtaille des besoins et tient lieu de premire bauche du modle de conception, tout en tant un modle part entire. I l permet une meilleure comprhension des cas d'utilisation dcrits dans l'enchanement d'activits des besoins en les prcisant sous forme de collaborations entre classificateurs conceptuels (par opposition aux classificateurs de conception qui seront implments par la suite). Le modle d'analyse sert galement la cration d'un systme ractif et robuste, dot d'une architecture et faisant une rutilisation massive de composants. I l se distingue du modle de conception en ce qu'il est davantage un modle conceptuel qu'un plan d'laboration de l'implmentation. Il peut tre transitoire et ne pas survivre aux deux ou trois premires itrations. Dans certains cas, toutefois, notamment pour les systmes complexes d'envergure, le modle d'analyse pourra tre conserv et actualis pendant toute la dure du systme. Il existe, alors, une relation transparente (par le biais des dpendances de traabilit) entre la ralisation d'un cas d'utilisation dans le modle d'analyse et la ralisation correspondante dans le modle de conception. Chaque lment du modle d'analyse peut tre retrouv partir de l'lment du modle de conception le ralisant. (Le modle d'analyse, son but et ses relations avec le modle de conception sont abords en dtail dans les sections 8.1 8.3.)

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus p i l o t par les cas d'utilisation

CHAPITRE 3 Wm

Le modle de conception prsente les caractristiques suivantes : Bien que hirarchique, i l contient des relations transcendant cette hirarchie. Il s'agit des relations habituelles en U M L : associations, gnralisations et dpendances (Annexe A). Les ralisations de cas d'utilisation sont des strotypes de collaboration. Une collaboration exprime la participation et le rle des classificateurs dans l'accomplissement d'une tche utile, telle que la ralisation d'un cas d'utilisation. Le modle de conception est galement un plan d'laboration de l'implmentation. Une correspondance directe relie les sous-systmes du modle de conception aux composants du modle d'implmentation.

qu'il excute les cas d'utilisation. Toute personne ayant test un logiciel par le pass a, sans le savoir, test des cas d'utilisation, mme si cette activit n'tait pas dcrite dans les mmes termes l'poque [8]. La nouveaut, et la diffrence, c'est que le Processus unifi permet la planification des tests dans les premires phases du cycle de dveloppement. Ds que les cas d'utilisation sont dfinis, i l est possible de spcifier les tests correspondants (tests bote noire ) et de dterminer l'ordre dans lequel ils seront raliss, intgrs et tests. Les tests des cas d'utilisation pourront ensuite tre dtaills (tests bote blanche ), mesure qu'avancera la ralisation des cas d'utilisation pendant la conception. Chaque faon d'excuter un cas d'utilisation, c'est--dire chaque chemin menant la ralisation d'un cas d'utilisation, peut servir de cas de test ( cas de test candidat ). Nous avons, jusqu' maintenant, prsent le Processus unifi comme une squence d'tapes, trs proche de l'ancienne approche en cascade. Notre unique souci tait de rester aussi clair que possible. Nous verrons, au chapitre 5, une faon beaucoup plus intressante de dployer ces diverses tapes selon une approche itrative et incrmentale. En fait, ce que nous avons dcrit dans les pages prcdentes correspond une seule itration. Un projet de dveloppement intgral se composera d'une srie d'itrations, dont chacune (sauf peut-tre la premire) consistera effectuer les enchanements d'activits des phases de besoins, d'analyse, de conception, d'implmentation et de test. Examinons de plus prs les avantages que prsentent les cas d'utilisation avant d'aborder plus en dtail les diffrents enchanements d'activits.

Le modle d'analyse est cr partir du modle des cas d'utilisation [5]. Chaque cas d'utilisation du modle des cas d'utilisation trouvera sa ralisation dans le modle d'analyse. Le dualisme cas d'utilisation/ralisation assure une traabilit parfaite entre la formulation des besoins et l'analyse. L'tude des cas d'utilisation l'un aprs l'autre permet de dgager les classes prenant part leur ralisation. Par exemple, le cas d'utilisation Retirer de l'argent peut tre ralis par les classes d'analyse Retrait, Compte, Distributeur et quelques autres qu'il n'est pas ncessaire d'indiquer ici. Les dveloppeurs attribuent des responsabilits (Annexe A) dfinies dans le cas d'utilisation en tant que responsabilits des classes. Dans notre exemple, la classe Compte assumerait des responsabilits telles que retirer un montant du compte . Cette mthode permet de faire apparatre un ensemble de classes qui, associes les unes aux autres, raliseront les cas d'utilisation et rendront vraiment service aux utilisateurs.

3.2 Pourquoi les cas d'utilisation ?

Plusieurs raisons expliquent l'intrt et le succs des cas d'utilisation, dont l'usage s'est dsormais impos partout [6]. Nous retiendrons ici les deux principales raisons : \ Les cas d'utilisation offrent un moyen la fois systmatique et intuitif de saisir les besoins | fonctionnels (Annexe C ; voir galement les chapitres 6 et 7) en insistant sur l'intrt que doit en attendre l'utilisateur. Ils orientent tout le processus de dveloppement, puisque la plupart des activits telles que l'analyse, la conception et les tests sont effectues partir des cas d'utilisation. La conception et les tests peuvent, en effet, tre planifis et coordonns en termes de cas d'utilisation. Cette caractristique devient encore plus vidente lorsque l'architecture du projet s'est stabilise, aprs la premire srie d'itrations.

L'tape suivante consiste concevoir les classes et les ralisations de cas d'utilisation de faon exploiter au mieux les produits et les technologies (ORB, kits de construction d'IHM et systmes de gestion de bases de donnes) permettant d'implmenter le systme. Les classes de conception sont regroupes en sous-systmes, entre lesquels peuvent tre dfinies des interfaces. Les dveloppeurs laborent galement le modle de dploiement, qui leur permet de dfinir l'organisation physique du systme sous forme de nuds informatiques et de vrifier que les cas d'utilisation peuvent tre implments en tant que composants s'excutant sur ces nuds. Ensuite, les dveloppeurs implmentent les classes ainsi conues en un ensemble de composants de fichiers (code source) dans le modle d'implmentation, partir duquel peuvent tre produits (c'est--dire compils et lis) les excutables tels que les DLL, les JavaBeans ou les composants ActiveX. Les cas d'utilisation aident dterminer l'ordre d'implmentation et d'intgration des composants. Enfin, les testeurs vrifient, au cours de l'enchanement des activits de test, que le systme met effectivement en uvre les fonctionnalits dcrites dans les cas d'utilisation et qu'il satisfait la configuration exige. Le modle des test se compose des cas de test (et d'autres lments qui seront abords plus tard, au chapitre 11). Un cas de test dfinit un ensemble de donnes d'entre, de conditions d'excution et de rsultats. Un grand nombre de ces cas de test peuvent tre directement drivs des cas d'utilisation. I l existe donc une dpendance de traabilit entre le cas de test et le cas d'utilisation correspondant. Ce qui signifie que les testeurs vrifieront que le systme fait bien ce que les utilisateurs attendent de lui, c'est--dire

3.2.1 Pour apprhender

les vritables

besoins

Selon Karl Wieger, le point de vue qu'offrent les cas d'utilisation renforce l'objectif final du gnie logiciel : crer des produits qui permettent aux clients de se consacrer au travail productif [9]. Plusieurs constatations viennent tayer cette affirmation. D'abord, la structure des cas d'utilisation favorise l'identification de logiciels rpondant aux objectifs des utilisateurs. Les cas d'utilisation reprsentent les fonctions que fournit un systme pour rendre service ses utilisateurs. I l devient possible, en se plaant du point de vue de chaque type d'utilisateur, d'identifier les cas d'utilisation qui lui permettront de faire

Le Processus u n i f i de d v e l o p p e m e n t logiciel
M m PARTIE I

Un processus p i l o t par les c a s d'utilisation

CHAPITRE 3 Wm

son travail. Si, en revanche, on se met envisager un ensemble de fonctions, sans rflchir aux cas d'utilisation employs par les diffrents utilisateurs, i l sera difficile d'estimer la pertinence ou l'intrt de ces fonctions. qui sont-elles utiles ? A quels besoins mtier rpondent-elles ? Quels avantages procurent-elles l'entreprise ?

cas d'utilisation. Les cas d'utilisation nous aident galement dvelopper des interfaces qui simplifient les rapports qu'entretiennent les utilisateurs avec le systme. Les ralisations des cas d'utilisation sont, par la suite, testes pour vrifier que les instances (Annexe A) des classes sont en mesure d'excuter les cas d'utilisation [8].
1

Les cas d'utilisation ne se bornent pas lancer le processus de dveloppement, ils en assurent aussi la cohsion, comme le montre la figure 3.2. (L'ellipse ombre, l'arrire-plan,
symbolise la faon dont les cas d'utilisation crent ce lien).

Besoins

Analyse

jjljl
1

Conception

! 1 plmentation 1

Les meilleurs cas d'utilisation sont ceux qui confrent le plus de valeur ajoute l'entreprise laquelle est destin le systme. Un cas d'utilisation apportant une valeur ngative ou permettant l'utilisateur d'accomplir une chose qui devrait lui tre impossible ne peut tre qualifi de cas d'utilisation. On parlerait plutt de cas d'abus , puisqu'il spcifie une utilisation du systme qui devrait tre proscrite. Un cas d'utilisation qui permettrait un Client de la banque de retirer de l'argent d'un compte ne lui appartenant pas tomberait dans cette catgorie. Les cas d'utilisation qui ne prsentent que peu ou pas du tout de valeur ajoute seront moins souvent utiliss. Ce sont des cas d'inutilit , totalement superflus.

Figure 3.2 Les cas d'utilisation lient les uns aux autres les principaux enchanements d'activits.

Tests

Comme nous l'avons mentionn au chapitre 1, bien des gens estiment que le simple fait de se demander ce que doit faire le systme ne suffit pas obtenir les rponses adquates. Ces personnes prfrent disposer d'une liste de fonctions systme qui, premire vue, peut sembler plus utile, mais qui, y regarder de plus prs, ne reflte pas ncessairement les besoins des utilisateurs. Si elle peut paratre insignifiante, la stratgie des cas d'utilisation qui consiste reformuler la question en lui ajoutant trois mots (que voulez-vous que fasse le systme pour chaque utilisateur ?) livre des rsultats tout fait diffrents. Cette mthode oblige comprendre de quelle faon le systme doit servir chacun de ses utilisateurs et guide les dveloppeurs dans l'identification des fonctions qui leur sont ncessaires. Elle vite, galement, de suggrer des fonctions superflues dont nul n'aura besoin. Autre avantage, les cas d'utilisation sont intuitifs. I l n'est pas ncessaire, pour les utilisateurs et les clients, d'apprendre dchiffrer une notation complexe puisque les cas d'utilisation sont essentiellement formuls en franais courant (c'est--dire en langage naturel), ce qui en simplifie la lecture et permet de suggrer des modifications. La formulation des besoins implique les utilisateurs, les clients et les dveloppeurs. Et, en la matire, ce sont les utilisateurs et les clients qui sont les experts. Le rle des dveloppeurs consiste favoriser leurs changes et les aider exprimer leurs besoins. Le modle des cas d'utilisation permet de s'accorder avec les utilisateurs et les clients sur les fonctions que doit remplir le systme auprs de ses utilisateurs. On peut envisager le modle des cas d'utilisation comme la spcification complte de tous les moyens possibles d'utiliser le systme (les cas d'utilisation), et pouvant faire partie du contrat scell avec le client. Ce modle contribue dlimiter le systme en dfinissant tout ce qu'il doit faire pour ses utilisateurs. Vous trouverez, dans [12], une approche intressante de la structuration des cas d'utilisation, tandis que [11] fournit une bonne entre en matire sur le sujet.

Il faut galement s'assurer que l'on saisit les bons cas d'utilisation, afin de fournir aux utilisateurs ceux dont ils ont rellement besoin. Le meilleur moyen de traiter ce problme est, videmment, de travailler avec rigueur dans la phase de formulation des besoins. Mais ce n'est gnralement pas suffisant. Un systme en cours d'excution permet de complter la validation des cas d'utilisation par rapport aux besoins rels des utilisateurs. Les cas d'utilisation aident les chefs de projet planifier, affecter et surveiller la plupart des tches effectues par les dveloppeurs. Pour chaque cas d'utilisation, le chef de projet identifiera un certain nombre de tches. La spcification de chaque cas d'utilisation reprsente, en soi, une tche particulire. Tout comme la conception et les tests de chacun de ces cas d'utilisation. Le chef de projet peut mme estimer le travail et les dlais ncessaires la ralisation de ces diverses tches. Les tches identifies partir des cas d'utilisation facilitent l'estimation de la taille du projet et des ressources ncessaires, et peuvent tre attribues des dveloppeurs particuliers, qui en seront responsables. Le chef de projet peut ainsi confier une premire personne la responsabilit de spcifier cinq cas d'utilisation pendant la formulation des besoins, une deuxime personne la charge de concevoir trois cas d'utilisation et une troisime la tche de spcifier les cas de test pour deux cas d'utilisation.

3.2.2 Pour diriger le processus

Comme nous l'avons indiqu, le fait d'tre pilot par les cas d'utilisation signifie qu'un projet de dveloppement procde selon une srie d'enchanements d'activits initis partir des cas d'utilisation. Les classes se dgagent naturellement de la lecture des descriptions de cas d'utilisation, lorsque les dveloppeurs cherchent les classes susceptibles de raliser les

Les cas d'utilisation constituent un mcanisme essentiel de traabilit entre modles. Il est possible de suivre l'volution d'un cas d'utilisation de la phase de besoins sa ralisation dans l'analyse et la conception, travers les classes qui participent sa ralisation, (indirectement) travers les composants et, enfin, travers les cas de test qui en assurent la vrification. Cette traabilit est un aspect fondamental de la gestion de projet. Lorsqu'un cas d'utilisation est modifi, i l faut vrifier les ralisations, classes, composants et cas de test qui lui correspondent, et ainsi de suite (voir [10]). La traabilit entre les cas d'utilisation et les autres lments des modles permet de prserver la cohrence du systme et de l'actualiser dans son ensemble en fonction de l'volution des besoins. 1. Il s'agit l d'une simplification. En ralit, il est probable que chaque cas d'utilisation ncessite l'intervention de classes (sous-systmes, etc.) dj dveloppes. Il faudra donc modifier les cas d'utilisation pour les adapter ces briques de base existante. Cette question est aborde dans la section 4.3.

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus p i l o t par les c a s d'utilisation

CHAPITRE 3 Wm

3.2.3 Pour mettre au point l'architecture et plus encore...

forme le modle des cas d'utilisation [2], [3]. Un diagramme de cas d'utilisation (Annexe A ; voir galement la section 7.4.1) dcrit une partie du modle des cas d'utilisation et montre un ensemble de cas d'utilisation et d'acteurs, ainsi que les associations pouvant relier un acteur un cas d'utilisation (voir la figure 3.3). Efflfl Modle de cas d'utilisation du systme de DAB L'acteur Client de la banque utilise le systme de DAB pour effectuer des retraits et des dpts sur des comptes et pour virer de l'argent d'un compte un autre. Ces actions sont reprsentes par les trois cas d'utilisation de la figure 3.3, qui indique les interactions par le biais d'associations vers l'acteur.

Les cas d'utilisation favorisent la mise en uvre d'un dveloppement itratif. Chaque itration, l'exception peut-tre de la toute premire du projet, est pilote par les cas d'utilisation travers tous les enchanements d'activits, des besoins la conception et aux tests, et donne lieu un incrment (Annexe C). Chaque incrment de dveloppement est ainsi la ralisation oprationnelle d'un ensemble de cas d'utilisation. En d'autres termes, un certain nombre de cas d'utilisation sont identifis et implments chaque itration. Les cas d'utilisation aident galement la conception de l'architecture. La slection d'un ensemble appropri de cas d'utilisation (c'est--dire ceux qui sont pertinents sur le plan architectural) raliser au cours des premires itrations permet l'implmentation d'un systme ayant une architecture stable et qui servira de socle aux cycles de dveloppement suivants. Nous reviendrons sur ce sujet au chapitre 4. Les cas d'utilisation constituent, par ailleurs, un excellent point de dpart pour la rdaction du manuel d'utilisation et la description des interactions entre l'utilisateur et le systme, puisque chacun d'eux dcrit une faon d'utiliser le systme.

:
;

Figure 3.3 Exemple de diagramme de cas d'utilisation comprenant un acteur et trois cas d'utilisation.

Retirer de l'argent

Dposer de l'argent

linlin, il est possible, en estimant la frquence d'excution de certains chemins des cas d'utilisation, de dterminer quels sont ceux qui exigent les meilleures performances. De telles estimations permettent, leur tour, de prvoir la capacit des processeurs du matriel sousjacent ou encore d'optimiser le schma de base de donnes pour certaines utilisations. Elles peuvent galement servir amliorer l'utilisabilit, c'est--dire slectionner les chemins auxquels se consacrer en priorit lors de la conception de l'interface utilisateur.

Effectuer des virements entre comptes

3.3.2 Les acteurs constituent l'environnement du

systme

3.3 Capture des cas d'utilisation

Nous allons maintenant examiner le droulement du travail au sein des diffrents enchanements d'activits. Nous nous attacherons essentiellement, comme nous l'avons indiqu prcdemment, l'aspect pilot par les cas d'utilisation . La section suivante ne s'intressera qu' l'expression des besoins fonctionnels sous forme de cas d'utilisation, mme lorsque d'autres types de besoins devront galement tre recenss. Durant cet enchanement, nous identifions les exigences des utilisateurs et des clients en tant que besoins. Les besoins fonctionnels sont exprims sous forme de cas d'utilisation regroups dans un modle du mme nom, tandis que les autres besoins peuvent tre joints aux cas d'utilisation concerns, figurer dans une liste part ou encore tre dcrits d'une autre faon.

Les acteurs ne reprsentent pas forcment tous des tres humains. Il peut s'agir d'autres systmes ou de matriel externe destins dialoguer avec le systme. Chaque acteur endosse un ensemble cohrent de rles lors de ses interactions avec le systme. Un utilisateur physique peut agir en tant qu'un ou plusieurs acteurs et jouer le rle de ces diffrents acteurs dans leurs interactions avec le systme, tandis que plusieurs utilisateurs peuvent agir en tant qu'occurrences diverses d'un mme acteur. Des milliers de personnes pourront, par exemple, se comporter en acteur Client de la banque. Les acteurs communiquent avec le systme par le biais de messages (Annexe A) changs pendant le droulement des cas d'utilisation. La dfinition du comportement des acteurs et de celui du systme cre une sparation nette entre les responsabilits des acteurs et celles du systme, sparation qui contribue la dlimitation de la porte du systme. Il suffit, pour identifier et spcifier tous les acteurs, d'examiner quels sont, d'une part, les personnes qui utiliseront le systme et, d'autre part, les autres systmes qui devront dialoguer avec lui. Chaque catgorie de ces utilisateurs ou systmes est ensuite reprsente sous la forme d'un acteur.

3.3.1 Le modle des cas d'utilisation les besoins fonctionnels

reprsente

Le modle des cas d'utilisation aide le client, les utilisateurs et les dveloppeurs s'accorder sur l'utilisation du systme. Un systme s'adresse en gnral plusieurs types d'utilisateurs, chacun tant reprsent en tant qu'acteur. Les acteurs utilisent le systme comme ils dialoguent avec les cas d'utilisation. L'ensemble des acteurs et des cas d'utilisation d'un systme

Le Processus u n i f i de d v e l o p p e m e n t logiciel
H PARTIE I

Un processus p i l o t par les c a s d'utilisation

CHAPITRE 3

3.3.3 Les cas d'utilisation spcifient

le

systme

Les cas d'utilisation sont faonns pour rpondre aux besoins des utilisateurs dans leur utilisation du systme. Le modle des cas d'utilisation saisit tous les besoins fonctionnels du systme. Voici notre dfinition prcise d'un cas d'utilisation :
Un cas d'utilisation spcifie une squence d'actions, avec ses variantes, effectue par le systme et produisant un rsultat satisfaisant pour un acteur pouvant tre particulier.

de leur ct, peuvent se rpartir la tche de saisir les besoins, puis utiliser les rsultats (essentiellement les cas d'utilisation) comme donnes d'entre pour l'analyse, la conception, l'implmentation et les tests du systme.

3.4 L'analyse, la conception et l'implmentation pour la ralisation des cas d'utilisation

L'analyse et la conception conduisent la transformation du modle des cas d'utilisation en un modle d'analyse, puis de conception, c'est--dire en une structure de classificateurs et de ralisations de cas d'utilisation. Le but est de rentabiliser la ralisation des cas d'utilisation, afin que le systme offre des performances appropries et puisse voluer dans le temps. Nous allons voir, dans cette section, comment passer par l'analyse pour mettre au point une conception de la ralisation des cas d'utilisation. Dans les chapitres 4 et 5, nous verrons en quoi l'architecture et le dveloppement itratif et incrmental contribuent la mise au point d'un systme rentable, capable de rpondre l'volution des besoins.

Le meilleur moyen d'identifier les cas d'utilisation est d'observer la faon dont les utilisateurs ont besoin du systme pour faire ce qu'ils ont faire (pour dcouvrir un moyen de structurer les cas d'utilisation partir des objectifs, consultez [10]). Chaque type d'utilisation du systme apportant un avantage l'utilisateur est potentiellement un cas d'utilisation ( cas d'utilisation candidat ). Ces cas d'utilisation potentiels seront ensuite amliors, modifis, scinds en plusieurs cas d'utilisation plus limits, ou intgrs d'autres cas d'utilisation plus complets. On peut considrer le modle des cas d'utilisation comme pratiquement termin lorsque tous les besoins fonctionnels ont t correctement identifis sous une forme comprhensible pour le client, les utilisateurs et les dveloppeurs. La squence d'actions effectue par un cas d'utilisation au cours de son droulement (c'est-dire une instance de cas d'utilisation) constitue un chemin spcifique de ce cas d'utilisation. Un grand nombre de chemins sont possibles, dont beaucoup sont presque identiques ; chacun reprsente une variante dans l'excution de la squence d'actions spcifie par le cas d'utilisation. Pour accrotre la lisibilit d'un modle de cas d'utilisation, i l convient de regrouper au sein d'un mme cas d'utilisation les descriptions de chemins (ou variantes) proches les unes des autres. Par identification et description d'un cas d'utilisation , nous entendons vritablement l'identification et la description des divers chemins pouvant tre runis en un seul et mme cas d'utilisation. BUfflH Cas d'utilisation Retirer de l'argent Voici la squence d'actions (trs simplifie) d'un chemin possible pour ce cas d'utilisation : 1. Le Client de la banque s'identifie. 2. Le Client de la banque choisit le compte duquel il veut effectuer son retrait et spcifie le montant du retrait. 3. Le systme dduit le montant du compte et dlivre l'argent.

3.4.1 Cration

du modle

d'analyse partir des cas d'utilisation

Le modle d'analyse s'enrichit de l'analyse d'un nombre croissant de cas d'utilisation. On slectionne, pour chaque itration, un ensemble de cas d'utilisation raliser dans le modle d'analyse. Le systme est labor comme une structure de classificateurs (classes d'analyse) et de relations entre ces classificateurs. On dcrit galement les collaborations ralisant les cas d'utilisation, c'est--dire les ralisations de cas d'utilisation. Puis on choisit, dans l'itration suivante, un autre groupe de cas d'utilisation raliser, qui viennent s'ajouter ceux de l'itration prcdente. Les sections 5.3 et 12.6 expliquent comment identifier et slectionner les groupes les plus importants de cas d'utilisation pour les premires itrations, et btir ainsi une architecture stable ds le dbut du cycle de vie du systme.

Les cas d'utilisation servent galement d' emplacement rserv pour les besoins non fonctionnels (Annexe C ; voir galement le chapitre 6), tels que les exigences de performances, de disponibilit, de prcision et de scurit, spcifiques un cas d'utilisation. Par exemple, l'exigence suivante peut tre associe au cas d'utilisation Reti rer de l'argent : le temps de rponse un Client de la banque, entre la slection du montant retirer et la dlivrance a^sJ)HJets dojt~^ secondes dans 95% des cas.
J

Pour tre clair, tous les besoinsloTn^nhls sont dlimits sous forme de cas d'utilisation, auxquels peuvent tre associs une grande partie des besoins non fonctionnels. En fin de compte, le modle des cas d'utilisation permet de prsenter les besoins en un format simple grer. I l est parfaitement comprhensible aux clients et utilisateurs qui peuvent s'en servir pour communiquer leurs besoins de faon cohrente et sans redondances. Les dveloppeurs,

Une mthode pratique consiste identifier et dcrire les cas d'utilisation d'une itration dans un premier temps, puis lire intgralement la description de chaque cas d'utilisation (comme l'illustre la section 3.3.3) et suggrer les classificateurs et associations ncessaires sa ralisation. Opration qui se rpte en un effort coordonn pour tous les cas d'utilisation d'une itration. Selon le stade du cycle de vie auquel on se trouve et le type d'itration en cours, i l est possible qu'une architecture soit dj en place et guide l'identification de nouveaux classificateurs et la rutilisation de classificateurs existants (voir la section 4.3). Chaque classificateur joue un ou plusieurs rles dans la ralisation d'un cas d'utilisation, rles qui spcifient les responsabilits, attributs, etc., dont doit disposer le classificateur pour prendre part cette ralisation. Ces rles peuvent tre envisags comme des embryons de classificateurs. En fait, en UML, un rle est galement un classificateur en lui-mme. On peut, par exemple, se reprsenter le rle d'une classe comme une vue de cette classe. Cette vue comprend, par consquent, tout le contenu de la classe, c'est--dire ses responsabilits, attributs, etc., mais uniquement ceux qui prsentent un intrt pour son rle dans la ralisation d'un cas d'utilisation. Le rle d'une classe peut galement tre dcrit comme ce qui

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t
PARTIE I

logiciel

Un p r o c e s s u s p i l o t par les c a s d'utilisation

CHAPITRE 3

Strotypes d'analyse

reste de la classe une fois qu'a t appliqu un filtre liminant tous les rles de cette classe n'ayant pas de responsabilits partages. Le concept de rle n'est dcrit que brivement ici et, pour des raisons de clart, ne sera pas dvelopp dans la 2 partie qui aborde en dtail tous les classificateurs.
m e

li'jj.'JJU

Exemple : La ralisation d'un cas d'utilisation dans le modle d'analyse La figure 3.4 indique de quelle faon le cas d'utilisation est ralis par une collaboration (c'est--dire une ralisation de cas d'utilisation), l'un et l'autre tant relis par une dpendance de traabilit (la traabilit est un strotype de dpendance signale par des guillemets la franaise), et fait apparatre que quatre classes prennent part cette ralisation en y jouant un rle. Comme on peut le voir sur cette figure, la ralisation d'un cas d'utilisation, ou collaboration, est reprsente par une ellipse en pointills.

Figure 3.4

Modle des cas d'utilisation i traabilit > Retirer de l'argent

M o d l e d'analyse

( 'lasses d'analyse participant la ralisation du cas l'utilisation Retirer de l'argent. 1rs classes i Hstributeur et Interface guichet \<>ni des classes frontires, la classe Retrait est une . lasse de contrle et la classe Compte est une classe entit.

Retirer de l'argent

Le modle d'analyse utilise trois types de strotypes pour les classes : les classes frontires , les classes de contrle et les classes entits . Les classes Distributeur et interface guichet sont des classes frontires, qui servent en gnral modliser les interactions entre le systme et ses acteurs (c'est--dire les utilisateurs et les systmes externes). La classe Retrait est une classe de contrle qui permet en principe de reprsenter la coordination, le squencement, les transactions et le contrle d'autres objets. On emploie galement ce type de classe pour encapsuler le contrle li un cas d'utilisation spcifique (ici, le cas d'utilisation Retirer de l'argent). La classe Compte est une classe entit, normalement utilise pour modliser les informations durables et souvent persistantes. Chacun de ces trois strotypes de classe encapsule, par consquent, diffrents types de comportement (ou fonctionnalit, si vous prfrez) et contribue l'laboration d'un systme robuste, qui sera dtaille au chapitre 8. Ces strotypes favorisent aussi l'identification d'lments rutilisables, puisque les classes entits sont gnriques pour un grand nombre de cas d'utilisation et, donc, d'applications diffrentes. La rpartition des classes d'analyse selon ces trois catgories (aborde plus en dtail dans [2]) est pratique depuis de nombreuses annes, maintenant. Son usage s'est larirgement rpandu et a t adopt par UML [12].

Participant

nHHHHHHIBHHI

mm

Distributeur

Interface guichet

Une classe participant plusieurs ralisations de cas d'utilisation dans le modle d'analyse Le ct gauche de la figure 3.5 montre un ensemble de cas d'utilisation pour un systme de DAB (le mme que celui de la figure 3.3), tandis que le ct droit dvoile la structure du systme correspondante, c'est--dire, dans ce cas, les classes d'analyse ralisant les cas d'utilisation. La structure du systme est modlise dans un diagramme de classes (Annexe A). Si l'on utilise gnralement des diagrammes de classes pour reprsenter les classes et leur relations, ceux-ci peuvent galement montrer des sous-systmes et des interfaces (comme nous le verrons en abordant la conception dans la section 3.4.3). Pour plus de limpidit, nous avons utilis des ombrages diffrents pour indiquer les ralisations de cas d'utilisation auxquelles prend part une classe et dans lesquelles elle joue un rle. (Les classes interface guichet et Compte prennent part et jouent des rles dans les trois ralisations d'utilisation. Les autres classes ne participent qu'elles ne jouent qu'un seul qu' la ralisation rle.) tion, c'est--dire de cas d'utilisad'un seul cas

Compte

On commence gnralement par examiner quelques cas d'utilisation, en crer la ralisation et identifier les rles des classificateurs. Puis, on renouvelle le processus pour d'autres cas d'utilisation et l'on suggre de nouveaux rles de classificateurs. Certains de ces rles plus tardifs peuvent tre spcifis en tant que rles indits ou modifis de classificateurs existants, ou exiger la cration de nouveaux classificateurs. On revient ensuite aux tout premiers cas d'utilisation. Ces allers-retours entre cas d'utilisation permettent de construire peu peu un modle d'analyse stable. Chaque classificateur peut ainsi participer et jouer des rles dans plusieurs ralisations de cas d'utilisation.

Modle des cas d'utilisation

Modle d'analyse

Retirer d e l'argent

Effectuer d e s virements entre comptes

Figure 3.5 Le diagramme montre la ralisation de chaque cas d'utilisation ( gauche) sous forme de structure de classes d'analyse ( droite). Par exemple, les classes Interface guichet, Retrait, Compte et Distributeur participent toutes la ralisation du cas d'utilisation Retirer de l'argent.

D p o s e r d e l'argent

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus p i l o t par les c a s d'utilisation

CHAPITRE 3

Il a fallu, pour tracer le diagramme de classes du systme DAB (figure 3.5), lire les descriptions des trois cas d'utilisation, puis examiner les diffrents moyens de les raliser. On aurait pu procder de la sorte : La ralisation des trois cas d'utilisation, Retirer de l'argent, Effectuer des virements entre comptes et Dposer de l'argent, implique la classe frontire Interface guichet etla classe entit Compte. Le droulement de chacun de ces cas d'utilisation est d'abord pris en charge par un objet (Annexe A) de l'Interface gui chef, avant de passer un objet de contrle qui coordonne l'essentiel du cas d'utilisation en question. La classe de cet objet est propre chaque cas d'utilisation. La classe Retrait participe donc au cas d'utilisation Retirer de l'argent, et ainsi de suite. L'objet Retrait demande au Di stri buteur de dlivrer un montant et l'objet Compte de dbiter le compte. L'objet Vi rement demande aux deux objets Compte impliqus dans la ralisation du cas d'utilisation Effectuer des virements entre comptes d'actualiser leur solde. L'objet Dpt accepte l'argent par l'intermdiaire du Rcepteur d'espces et demande l'objet Compte d'augmenter son solde. Jusqu' prsent, nous avons tent de dfinir une structure de systme stable pour l'itration en cours. Nous avons identifi les responsabilits des classificateurs participants et dtermin les relations les unissant les uns aux autres. Mais nous n'avons toujours pas identifi en dtail l'interaction qui doit avoir lieu lors de la ralisation du cas d'utilisation. Nous avons la structure ; i l nous faut maintenant lui imposer les diffrentes modalits d'interaction ncessaires la ralisation de chaque cas d'utilisation.

Figure 3.6 Diagramme de collaboration pour la ralisation du cas d'utilisation Retirer de l'argent dans le modle d'analyse.

: Retrait Le diagramme montre le dplacement du point de vue d'objet en objet, mesure que s'excute le cas d'utilisation et que sont changs les messages entre objets. L'envoi d'un message depuis un objet fait passer l'objet rcepteur au premier plan et l'amne assumer l'une des responsabilits de sa classe. Le nom d'un message renseigne sur l'intention de l'objet appelant lors de l'interaction avec l'objet invoqu. Plus tard, au cours de la conception, ces messages seront pris en charge par une ou plusieurs oprations fournies par les classes de conception correspondantes (comme nous le verrons dans la section 3.4.3). Le diagramme de collaboration peut galement tre complt par du texte expliquant de quelle faon les objets dialoguent pour excuter le flot d'vnements du cas d'utilisation. Il existe d'autres moyens de dcrire une ralisation de cas d'utilisation, comme l'emploi de texte structur ou de pseudo-code.

Efflfl

Description du flot d'vnements de la ralisation d'un cas d'utilisation Nous allons maintenant dcrire la ralisation du cas d'utilisation Reti rer de l'argent travers les interactions entre objets et acteurs apparaissant dans la figure 3.6. Un Cl i ent de la banque choisit de retirer de l'argent et active l'objet Interface guichet. Le Client de la banque s'identifie et spcifie le montant du retrait et le compte dbiter (1). L'Interface guichet vrifie l'identit du Client de la banqueetdemandeun objet Retrait d'effectuer la transaction (2). Si l'identit du Client de la banque est correcte, l'objet Retrait doit confirmer que le Client de la banque a bien le droit de retirer du Compte la somme spcifie. L'objet Rc t r a i t confirme en demandant l'objet Compte de valider la requte et, si celle-ci est correcte, de dbiter le compte (3). L'objet Retrait autorise ensuite le Di stri buteur dlivrer le montant demand par le Client de la banque (4). Enfin, le Client de la banque reoit le montant demand (5). Remarquez que cet exemple simple ne montre qu'un chemin de ralisation du cas d'utilisation, lorsque tout se passe sans encombre. Il se produirait une complication si, par exemple, le solde du Compte tait trop bas pour permettre le retrait.

Comme nous l'avons indiqu prcdemment, chaque cas d'utilisation fait l'objet d'une ralisation, disposant elle-mme d'un ensemble de classificateurs participants, qui jouent diffrents rles. La comprhension des modles d'interaction signifie que l'on dcrit de quelle faon est effectue ou excute (ou encore instancie) la ralisation d'un cas d'utilisation : par exemple, ce qui se passe lorsqu'un Client de la banque effectue un retrait, c'est--dire lorsqu'il excute un cas d'utilisation Retirer de l'argent. Nous savons que les classes Interface guichet, Retrait, Distributeur et Compte participeront la ralisation de ce cas d'utilisation. Nous savons galement quelles seront leurs responsabilits. En revanche, nous ne savons toujours pas comment ces classes (ou, plus exactement, comment les objets de ces classes) vont dialoguer pour excuter la ralisation du cas d'utilisation. C'est maintenant ce qu'il faut dterminer. On utilise principalement des diagrammes de collaboration (Annexe A) pour modliser les interactions entre objets au cours de l'analyse. (UML fournit aussi des diagrammes de squence, sur lesquels nous reviendrons quand nous aborderons la conception dans la section 3.4.3.) Un diagramme de collaboration ressemble un diagramme de classes, sauf qu'il montre les instances et les liens (Annexe A) plutt que les classes et les associations. Ce type de diagramme signale les interactions squentielles ou parallles des objets en numrotant les messages changs. Bgjfl Utilisation d'un diagramme de collaboration pour dcrire la ralisation d'un cas d'utilisation dans le modle d'analyse Dans la figure 3.6, nous utilisons un diagramme de collaboration pour dcrire la faon dont la ralisation du cas d'utilisation Retirer de l'argent est excute par une socit d'objets d'analyse.

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus p i l o t par les c a s d'utilisation

CHAPITRE 3

M o d l e des c a s d'utilisation

M o d l e d'analyse

M o d l e de conception

ce stade, nous aurons analys chaque cas d'utilisation et identifi ainsi tous les rles des classes participant la ralisation de chaque cas d'utilisation. Nous allons maintenant aborder la faon d'analyser chaque classe.

3.4.2 Chaque classe doit assumer tous ses rles de collaboration

Les responsabilits d'une classe sont une simple compilation de tous les rles qu'elle joue dans toutes les ralisations de cas d'utilisation. Le regroupement de ces rles et la suppression des ventuels chevauchements permet de dgager une spcification de toutes les responsabilits et de tous les attributs de la classe. Les dveloppeurs chargs d'analyser et de raliser les cas d'utilisation doivent galement spcifier les rles des classes. Chaque dveloppeur responsable d'une classe recense tous les rles de celle-ci au sein d'un ensemble complet de responsabilits de la classe, puis les intgre un ensemble cohrent de responsabilits.

Figure 3.7 Ralisation d'un cas d'utilisation dans diffrents modles.

traabilit o Retirer de l'argent Retirer de l'argent

traabilit .-"", < Retirer de l'argent

Les ralisations de cas d'utilisation dans les diffrents modles obissent plusieurs objectifs. Souvenez-vous, comme nous l'avons vu dans la section 3.4.1 (figure 3.4), que les classes d'analyse Interface guichet, Retrait, Compte et Distributeur participent toutes la ralisation du cas d'utilisation Reti rer de l'argent dans le modle d'analyse. Mais une fois conues, elles spcifient et donnent toutes lieu des classes de conception plus sophistiques, adaptes l'environnement d'implmentation, comme l'illustre la figure 3.8. Modle d'analyse
Interface Distributeur

Retrait

Compte

A /S

A. A A

Les dveloppeurs chargs d'analyser les cas d'utilisation doivent s'assurer que les classes ralisent correctement les cas d'utilisation. Si une classe change, le dveloppeur qui en est responsable doit vrifier que celle-ci peut toujours remplir ses rles dans les ralisations de cas d'utilisation. Si c'est un rle qui volue, le dveloppeur du cas d'utilisation doit en informer le dveloppeur de la classe. Les rles aident ainsi les dveloppeurs de classes, comme les dveloppeurs de cas d'utilisation, prserver l'intgrit de l'analyse.

3.4.3 Cration du modle d'analyse

de conception partir du

modle

Figure 3.8 Classes de conception du modle de conception remontant vers des classes d'analyse du modle d'analyse.

Modle de conception

n traabilit

Chargeur d u distributeur

Gestionnaire de clients

Classe persistante

Le modle de conception est d'abord cr partir du modle d'analyse, avant d'tre adapt l'environnement d'implmentation choisi, comme un ORB, un kit de construction d'IHM ou un systme de gestion de base de donnes. Ce modle peut galement tre modifi de faon a rutiliser des systmes existants (Annexe C) ou d'autres cadres gnraux dvelopps pour le projet. Le modle d'analyse constitue donc une premire bauche du modle de conception, qui servira lui-mme de plan d'laboration l'implmentation. A l'instar du modle d'analyse, le modle de conception dfinit des classificateurs (classes, sous-systmes et interfaces), des relations entre ces classificateurs et des collaborations ralisant les cas d'utilisation (c'est--dire les ralisations de cas d'utilisation). Toutefois, les lments dfinis dans le modle de conception sont les quivalents en conception des lments plus conceptuels spcifis dans le modle d'analyse, en ce sens que les premiers (les lments de conception) sont adapts l'environnement d'implmentation, contrairement aux seconds. En d'autres termes, le modle de conception est plus physique par nature, tandis que le modle d'analyse est plus conceptuel . Il est possible de remonter jusqu' la ralisation d'un cas d'utilisation dans le modle d'analyse partir de la ralisation correspondante dans le modle de conception. E E PE XM L Ralisations de cas d'utilisation dans les modles d'analyse et de conception La figure 3.7 dcrit la ralisation du cas d'utilisation Retirer de 1 ' a rgent la fois dans le modle d'analyse et dans le modle de conception.

Lecteur de carte

Guichet espces

Gestionnaire de transactions

Gestionnaire de comptes

Par exemple, la classe d'analyse Interface guichet est conue par quatre classes de conception : cran, Clavier, Lecteur de carte et Gestionnaire de cl ients (qui est une classe active et entoure, ce titre, d'une bordure paisse ; voir l'Annexe A). Remarquez que, dans la figure 3.8, la plupart des classes de conception ne remontent qu' une seule classe d'analyse, ce qui est normal pour des classes de conception, spcifiques une application et conues pour prendre en charge une ou plusieurs applications. La structure du systme dfinie par le modle d'analyse est donc naturellement prserve pendant la conception, bien que quelques compromis puissent se rvler ncessaires (notamment lorsque le Gestionnaire de cl i ents participe la conception des classes Interface guichet et Distributeur). Par ailleurs, les classes actives (Gestionnaire de cl ients, Gestionnaire de transactions et Gestionnaire de comptes) reprsentent des processus organisant le travail des autres classes (non actives), une fois le systme distribu (nous reviendrons sur cette question dans la section 4.5.3).

Le Processus u n i f i de d v e l o p p e m e n t logiciel PARTIE I

Ira

Un processus p i l o t par les c a s d'utilisation

CHAPITRE 3

En consquence, la ralisation du cas d'utilisation Retirer de l'argent dans le modle de conception doit dcrire la faon dont est ralis le cas d'utilisation en termes de classes de conception correspondantes. La figure 3.9 illustre un diagramme de classes faisant partie de la ralisation du cas d'utilisation.
i i(|iin' :i.9

: cran

Gestionnaire

: Gestionnaire de transactions

Insrer la carte

Carte insre (ID) Demander le code secret

Montrer la requte Spcifier le code secret Code secret (PIN) Demander le montant retirer Exiger la validation du code secret (PIN)

Figure 3.10 Diagramme de squence faisant partie d'une ralisation du cas d'utilisation Retirer de l'argent dans le modle de conception.

Gestionnaire de transactions Classe persistante

Montrer la requte Prciser le montant Montant (M) Exiger la disponibilit du montant (M) Exiger le retrait du montant (M)

Diagramme de i lusses luisant /nulle d'une .. tllsatlon du cas d'utilisation ; . tlin le l'argent ,l,m \ modle de ttmcrptlon. I Inique classe de conception participe t) la

a alisatton du cas
d'utilisation dans i.h/ui-lle elle joue des Mes.

Cm t o pe L'exemple choisi le montre bien : le modle de conception est susceptible de contenir de nombreuses classes. I l faut donc trouver le moyen de les hirarchiser. Les sous-systmes, que nous abordons dans la section ci-dessous, offrent cette possibilit.

Il est clair que ce diagramme de classes introduit, par rapport au diagramme du modle d'analyse (figure 3.5), un niveau suprieur de dtail, ncessaire l'adaptation du modle de conception l'environnement d'implmentation. Comme dans l'analyse (figure 3.6), il faut identifier en dtail l'interaction entre objets de conception se produisant lors de la ralisation du cas d'utilisation dans le modle de conception. On utilise principalement des diagrammes de squence pour modliser les interactions entre objets de conception, comme le montre la figure 3.10. Le diagramme de squence montre le dplacement du point de vue d'objet en objet, depuis le coin suprieur gauche, au fur et mesure de l'excution du cas d'utilisation et des changes de messages entre objets. L'envoi d'un message depuis un objet fait passer l'objet rcepteur au premier plan et l'amne assumer l'une des responsabilits de sa classe. Vous pouvez vous livrer un exercice intressant, qui consiste comparer ce diagramme de squence son quivalent en analyse (c'est--dire le diagramme de collaboration) de la figure 3.6. En fait, les deux premiers messages du diagramme de collaboration sont conus par tous les messages du diagramme de squence de la figure 3.10, ce qui donne une ide de la complexit et du niveau de dtail introduit dans le modle de conception par rapport au modle d'analyse.

3.4.4 Les sous-systmes

regroupent les classes

Prenons le cas d'un systme contenant plusieurs centaines ou milliers de classes. Sans un niveau de regroupement suprieur, le systme serait impossible apprhender. Les classes sont donc rparties en sous-systmes, qui permettent le regroupement smantique de classes et d'autres sous-systmes. Chaque sous-systme fournit et utilise lui-mme un ensemble d'interfaces, qui en dfinissent le contexte (acteurs, autres sous-systmes et classes). Les sous-systmes de bas niveau sont appels sous-systmes de service (Annexe B ; voir galement le chapitre 9), car les classes qu'ils contiennent rendent un service (pour une description plus prcise du concept de service, consultez la section 8.4.5.1). Les sous-systmes de service constituent une unit grable de fonctionnalits facultatives (ou potentiellement facultatives), et ne doivent pouvoir tre installs dans un systme client que dans leur intgralit. Ils permettent galement de modliser des groupes de classes ayant tendance changer en mme temps. Les sous-systmes peuvent tre dtermins en procdant de bas en haut ou de haut en bas. Dans le premier cas, les dveloppeurs suggrent les sous-systmes partir des classes dj identifies ; ils proposent alors des sous-systmes qui regroupent les classes en units de fonctions clairement dfinies. S'ils choisissent, en revanche, de procder de haut en bas, c'est l'architecte qui dtermine les sous-systmes de haut niveau et leurs interfaces, avant mme qu'aucune des classes n'ait t identifie. Les dveloppeurs sont ensuite chargs de travailler sur des sous-systmes particuliers pour trouver et concevoir les classes qu'ils contiendront. Les sous-systmes ont t prsents au chapitre 1 et seront abords plus en dtail dans les chapitres 4 et 9.

j r y ^ H

P r o c e s s u s u n i f i de d v e l o p p e m e n t logiciel

Un processus p i l o t par les c a s d'utilisation

CHAPITRE 3

Les sous-systmes regroupent les classes

3.4.5 Cration du modle de conception

d'implmentation

partir du

modle

Les dveloppeurs rpartissent les classes dans les trois sous-systmes que montre la figure 3.11. Ces sous-systmes ont t choisis de faon regrouper toutes les classes en fonction de leur rle : celles fournissant l'interface utilisateur sont places dans un premier sous-systme, celles concernant les comptes dans un deuxime, et celles spcifiques l'application dans un troisime. L'intrt de placer toutes les classes de l'interface utilisateur dans le sous-systme I nterf ace du DAB est que ce sous-systme peut ensuite tre remplac par un autre offrant au sous-systme Gestion des transactions les mmes fonctionnalits. Un autre sous-systme Interface du D B pourra avoir une implmentation trs diffrente A de l'interface utilisateur, destine, par exemple, recevoir et dlivrer des pices plutt que des billets. Les classes spcifiques l'application, telles que la classe Retrait, places dans le soussystme Gesti on de transactions se retrouvent toutes dans un sous-systme de service diffrent. Chacun de ces sous-systmes de service dtiendrait en ralit plusieurs classes, qu'il n'est pas utile de faire figurer dans cet exemple simple.

Au cours de l'enchanement d'activits de l'implmentation, sont dvelopps tous les lments excutables ncessaires la production d'un systme excutable : les composants, les composants fichiers (code source, shell scripts, etc.), les composants tables (lments de base de donnes), et ainsi de suite. Un composant est une partie physique et remplaablc d'un systme, conforme la ralisation d'un ensemble d'interfaces qu'elle doit fournir. Le modle d'implmentation intgre les composants, qui comprennent tous les excutables (Annexe A ; voir galement le chapitre 10) tels que les composants ActiveX et les JavaBeans, ainsi que d'autres types de composants. BMH Composants dans le modle d'implmentation La figure 3.12 montre les composants qui implmentent les classes de conception partir du modle de conception (tel qu'il est prsent dans la section 3.4.3)
M o d l e de conception les Figure 3.12 Composants implmentant classes de conception. Modle d'implmentation

La figure 3.11 montre galement les interfaces entre les sous-systmes. Un cercle reprsente une interface. La ligne continue reliant une classe une interface indique que la classe fournit l'interface. La prsence d'une flche en pointills entre une classe et une interface signifie, en revanche, que la classe utilise l'interface. Pour plus clart, nous ne montrons pas les interfaces fournies ou utilises par l'acteur ; nous optons, ici, pour des associations ordinaires.
sous-systme ; sous-systme sous-systme i

Gestionnaire de clients ^- -.^ traabilit * Alimentation distributeur Chargeur du traabilit distributeur <Guichet <-

< excutable : client.exe ,."7 A ,<' compilation fichier client.c

Interface d D B u A Lecteur de carte

Gestion des transactions

Gestion des retraits

Gestionnaire de transactions Gestionnaire de clients Chargeur d u distributeur Capteur du distributeur Guichet espces * sous-systme d service e Gestion des comptes

Classe persistante Gestionnaire de comptes Cm t o pe

Figure 3.11 lYot3 sous-systmes , / un sous-systme de service (en gris dans le sous\ Gestion ,/<w transactions) ,lc nuire exemple titnpl du DAB.

I fichier I distributeur.o

Par exemple, le composant de fichiers distributeur.o contient le code source (et donc l'implmentation) destrois classes Chargeur du di stri buteur,Capteur du di s t r i buteur et Guichet espces. Ce composant de fichiers est ensuite compil et li avec le composant de fichiers client.c dans le composant client.exe qui, lui, est excutable.

L'interface Vi rements dfinit les oprations permettant d'effectuer des retraits, des dpts et des virements entre comptes, et l'interface Retraits celles ncessaires pour effectuer des retraits d'un compte. Enfin, l'interface Dl i vrance spcifie les oprations qu'utilisent les autres sous-systmes, tels que le sous-systme Gesti on des transacti ons, pour dlivrer la somme demande au client de la banque.

Un composant suppose un contexte architectural dfini par ses interfaces. Il est galement remplaable, ce qui signifie que les dveloppeurs peuvent le remplacer par un autre, ventuellement meilleur, tant que ce dernier fournit et exige les mmes interfaces. I l y a gnralement un moyen direct d'implmenter un sous-systme de service du modle de conception en composants pouvant tre allous des nuds dans le modle de dploiement. Chaque sous-systme de service est implment par un seul composant si celui-ci est toujours allou un seul type de nud dans le modle de dploiement. Si le composant est allou plusieurs nuds, le sous-systme de service peut tre scind (en gnral, par la division de cer-

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus p i l o t par les cas d'utilisation

CHAPITRE 3

taines classes) en autant de parties qu'il y aura de types de nuds. Chaque partie du soussystme de service sera, dans ce cas, implmente par un composant.

Identification d'un cas de test partir d'un cas d'utilisation La figure 3.13 montre un cas de test, Retirer de l'argent-flot de base, indiquant le moyen de tester le flot de base du cas d'utilisation Retirer de l'argent.
M o d l e des cas d'utilisation M o d l e des tests

Ijgg

Un sous-systme de service implment sous forme de composants

Supposons que l'on choisisse une solution client/serveur (voir la section 9.5.1.1) pour l'exemple du DAB. On pourrait alors imaginer qu'une partie du sous-systme de service Ges t i on des ret rai ts (figure 3.11) contient la classe Retrai t, dploye la fois sur le client et sur le serveur. Le sous-systme de service Gesti on des retraits serait donc implment par deux composants : Retrait sur le cl ient et Retrait sur le serveur . Si les composants sont implments dans un langage de programmation orient objet, l'implmentation des classes est galement directe. Chaque classe de conception correspond une classe de l'implmentation, telle qu'une classe C++ ou Java. Chaque composant fichier peut implmenter plusieurs classes de ce type, selon les conventions propres chaque langage de programmation. Mais l'implmentation ne se borne pas au dveloppement du code ncessaire la cration d'un systme excutable. Les dveloppeurs chargs d'implmenter un composant doivent galement le tester unit par unit avant de le soumettre aux tests d'intgration et aux tests systme.

Figure 3.13 Un cas de test du modle des tests indiquant le moyen de tester un cas d'utilisation (Retirer de l'argent) dans le modle de cas d'utilisation.

o
Retirer de l'argent

< traabilit Retirer de l'argent -Flot de base

Remarquez que nous introduisons l un nouveau strotype pour les cas de test : un symbole de cas d'utilisation revtu d'une croix. Ce symbole permet de dsigner les cas de test dans les diagrammes (voir le chapitre 11). Le cas de test prcise les entres, le rsultat attendu et les autres conditions pertinentes pour la vrification du flot de base du cas d'utilisation Retirer de l'argent : Entres : Le compte 12-121-1211 du Cl ient de la banque montre un solde de 3 500 FF. Le Cl ient de la banque s'identifie correctement. Le Cl i ent de la banque demande retirer 2 000 FF du compte 12-121-1211. Il y a assez d'argent (au moins 2 000 FF) dans le DAB. Rsultat : Le solde du compte 12-121-1211 du Cl ient de la banque descend 1 500 FF. Le Cl ient de la banque reoit 2 000 FF du DAB. Conditions : Aucun autre cas d'utilisation (instance) n'est autoris accder au compte 12-121-1211 pendant ce cas de test. Notez que ce cas de test repose sur la description du cas d'utilisation Retirer de l'argent tel qu'il est illustr dans la section 3.3.3. L'identification des cas d'utilisation ds le dbut du processus permet trs tt de planifier les activits de test et de suggrer des cas de test utiles. Ces cas de test peuvent ensuite tre amliors au cours de la conception, lorsqu'on en sait plus sur la faon dont le systme excutera les cas d'utilisation. Certains outils gnrent des cas de test partir d'un modle de conception ; les seuls lments entrer la main sont les donnes ncessaires pour l'excution des tests. Les tests des cas d'utilisation peuvent tre effectus soit du point de vue d'un acteur traitant le systme comme une bote noire, soit d'un point de vue propre la conception ; le cas de test est alors labor pour vrifier que les instances des classes participant la ralisation du cas d'utilisation font bien ce qu'elles doivent faire. Les tests bote noire peuvent tre identifis, spcifis et planifis ds que les besoins sont peu prs stables. Il existe d'autres types de tests, comme les tests systme, les tests d'acceptation et les tests de la documentation utilisateur. Nous en dirons plus ce sujet au chapitre 11.

3.5 Tests des cas d'utilisation

Les tests permettent de vrifier que le systme implment correctement sa spcification. On met au point un modle des test compos de cas de test et de procdures de test (Annexe C ; voir galement le chapitre 11), que l'on excute ensuite pour s'assurer que le systme fonctionne comme prvu. Un cas de test est un ensemble d'entres de test, de conditions d'excution et de rsultats attendus dtermin dans un objectif prcis, comme de tester un chemin de cas d'utilisation particulier ou de vrifier le respect d'une exigence spcifique. Une procdure de test spcifie la faon de procder l'installation, l'excution d'un cas de test prcis, et l'valuation de ses rsultats. Les procdures de test peuvent galement tre drives des cas d'utilisation. Les anomalies dtectes sont ensuite analyses afin de localiser le problme. Enfin, les problmes sont hirarchiss et corrigs par ordre d'importance. Aprs avoir commenc dterminer les cas d'utilisation dans la section 3.3, nous avons analys, conu et implment un systme ralisant ces cas d'utilisation. Nous allons maintenant voir comment contrler leur implmentation. En un sens, i l n'y a l rien de nouveau. De tout temps, les dveloppeurs ont test des cas d'utilisation sans le savoir. Vrifier que le systme fonctionne d'une faon comprhensible aux utilisateurs constitue depuis toujours le moyen pratique de tester les fonctions d'un systme. Et pourtant, c'est une approche nouvelle. En quoi est-elle nouvelle ? En ce que l'on identifie les cas de test (comme les cas d'utilisation dans l'enchanements d'activits des besoins) avant mme de commencer la conception du systme et que l'on vrifie ensuite que la conception met rellement en uvre les cas d'utilisation.

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

3.6

Rsum

Les cas d'utilisation pilotent le processus. Pendant l'enchanement d'activits des besoins, les dveloppeurs expriment ces besoins sous forme de cas d'utilisation, sur lesquels s'appuient les chefs de projet pour planifier le dveloppement. Au cours de l'analyse et de la conception, les dveloppeurs crent les ralisations de cas d'utilisation en termes de classes ou de sous-systmes, puis ils implmentent les composants. Les composants sont intgrs dans des incrments qui ralisent chacun un ensemble de cas d'utilisation. Enfin, les testeurs vrifient que le systme implment les cas d'utilisation ncessaires aux utilisateurs. En d'autres termes, les cas d'utilisation assurent la cohsion de toutes les activits de dveloppement et guident le processus de dveloppement dans son ensemble. C'est peut-tre l le premier intrt de l'approche pilote par les cas d'utilisation. Toutefois, si les cas d'utilisation apportent de nombreux avantages un projet, ils ne sont pas tout. Le chapitre suivant aborde un autre aspect fondamental du Processus unifi : le fait qu'il est centr sur l'architecture.

3.7

Rfrences

Un processus centr sur l'architecture

Nous avons ouvert le chapitre 3 par une simplification, en prtendant que les cas d'utilisation allaient, eux seuls, vous frayer un chemin travers la spcification des besoins, l'analyse, la conception, l'implmentation et les tests jusqu' la production d'un systme. Mais le dveloppement logiciel ne se rsume pas un parcours aveugle travers les enchanements d'activits, guid par les seuls cas d'utilisation.

fl

Les cas d'utilisation ne suffisent pas. Pour chafauder un systme oprationnel, i l faut quelque chose de plus. Ce plus , c'est l'architecture. On peut se reprsenter l'architecture d'un systme comme la vision commune sur laquelle doivent s'accorder tous les travailleurs (c'est--dire les dveloppeurs et les autres intervenants), ou qu'ils doivent au moins accepter. L'architecture offre une perspective claire de tout le systme, indispensable pour en matriser le dveloppement. Il nous faut une architecture capable de dcrire les lments de modle qui comptent le plus nos yeux. Comment dterminer quels sont ces lments ? Leur importance tient au fait qu'ils orientent notre travail sur le systme, aussi bien dans le cycle en cours que pour l'ensemble du cycle de vie. Ces lments de modle significatifs sur le plan architectural comprennent une partie des sous-systmes, des dpendances, des interfaces, des collaborations, des nuds et classes actives (Annexe A ; voir galement la section 9.3.2) et dcrivent les fondements du systme qui permettront d'abord de le comprendre, puis de le dvelopper et de le faire voluer moindre cot. Comparons un projet logiciel la construction d'un garage priv. L'entrepreneur s'interrogera d'abord sur l'usage que compte faire l'utilisateur du garage. On peut imaginer qu'il y aura un cas d'utilisation Abriter la voiture, pour garer la voiture, la laisser au garage et la ressortir. L'utilisateur a-t-il d'autres usages en tte ? Supposons qu'il veuille galement se servir du garage comme atelier personnel. Cette demande devra amener l'entrepreneur fournir une source de lumire : quelques fentres et un clairage lectrique. Un grand

1 IVAR JACOBSON, "Object-oriented development in an industrial environment," Proceedings ofOOPSIA'87, Spcial issue of SIGPLAN Notices 22(12): 183-191, December 1987. 2 IVAR JACOBSON, MAGNUS CHRISTERSON, PATRIK JONSSON, and GUNNAR VERGAARD, Object-Oriented Software Engineering: A Use-Case Driven Approach, Reading, MA: Addison-Wesley, 1992 (Revised fourth printing, 1993). 3 IVAR JACOBSON, "Basic Use Case Modeling," ROAD 1(2), July-August 1994. 4 IVAR JACOBSON, "Basic Use Case Modeling (continued)," ROAD 1 (3), SeptemberOctober 1994. 5 IVAR JACOBSON, "Use cases and objects," ROAD 1(4), November-December 1994. 6] IVAR JACOBSON and MAGNUS CHRISTERSON, "A growing consensus on use cases," Journal of Object-Oriented Programming, March-April 1995. 7 IVAR JACOBSON and STEN JACOBSON, "Use-case engineering: Unlocking the power," Object Magazine, October 1996. 8 KARL WIEGER, "Use c^ses: Listening to the customer's voice," Software Development, Mardi 1997. 9 E. ECKLUND, L . DELCAMBRE, and M. FREILING, "Change cases: Use cases that identify future requirements," Proceedings, Confrence on Object-Oriented Programming Systems, Languages, & Applications (OOPSLA'96), ACM, 1996, pp. 342-358. 10 ALISTAIR COCKBURN, "Structuring use cases with goals," Report on Analysis & Design (ROAD), 1997. 11 GERI SCHNEIDER and JASON WINTERS, Applying Use Cases: A Practical Approach, Reading, MA: Addison-Wesley, 1998. 12 OMG Unified Modeling Language Spcification. Object Management Group, Framingham, MA, 1998. Internet: www.omg.org.

t Le Processus u n i f i de d v e l o p p e m e n t logiciel

Un processus c e n t r sur l'architecture mw

Qprr}E~4mm\

nombre d'outils fonctionnent l'lectricit ; i l faudra donc aussi prvoir une demi-douzaine de prises de courant et une puissance en watts suffisante pour les prendre en charge. D'une certaine faon, l'entrepreneur met au point une architecture simple. I l peut le faire de tte, parce qu'il a dj vu un garage auparavant. De mme, i l a dj vu un tabli. I l sait ce dont a besoin un tre humain pour travailler son tabli. L'approche de l'entrepreneur n'est donc pas tout fait l'aveuglette , puisqu'il connat dj l'architecture typique d'un garage. I l ne lui reste qu' assembler les diverses parties de faon rpondre aux utilisations qui seront faites du garage. Si l'entrepreneur n'avait jamais vu de garage et ne s'attachait qu' l'usage qui en sera fait, i l aurait de fortes chances de se retrouver face un trange btiment. I l ne doit donc pas s'arrter exclusivement sa fonction, mais en considrer la forme. La construction d'une maison de dix pices et celle d'une cathdrale, d'un centre commercial ou d'un gratte-ciel sont des entreprises trs diffrentes. Les mthodes permettant d'difier des btiments d'une telle envergure ne manquent pas et leur conception ncessite l'intervention d'une quipe d'architectes, qui doivent s'informer mutuellement de la progression de l'architecture. Ce qui signifie qu'ils doivent prsenter cette dernire sous une forme non seulement comprhensible aux autres membres de l'quipe, mais galement accessible aux profanes, c'est--dire le propritaire, les utilisateurs et les autres intervenants. Enfin, cette architecture doit tre communique aux entrepreneurs et fournisseurs de matriaux par le biais de plans de construction.

Mais la phase de construction d'un btiment implique d'autres professionnels : charpentiers, ouvriers, maons, couvreurs, plombiers, lectriciens, etc. Chacun d'entre eux a besoin de dessins techniques du btiment plus dtaills et spcialiss qui, tous, doivent tre cohrents les uns avec les autres. Les circuits d'aration et d'adduction d'eau, par exemple, ne doivent pas se trouver au mme emplacement physique. Le rle de l'architecte consiste traiter les aspects les plus significatifs de la conception globale du btiment. I l labore ainsi un ensemble de dessins dcrivant les parties essentielles du btiment, telles que les fondations enfouies. Un ingnieur de structure dtermine ensuite la taille des poutres qui devront soutenir la structure, forme des murs, des planchers et du toit. La structure comprend aussi les systmes d'ascenseurs, de conduite d'eau, d'lectricit, de climatisation, d'assainissement, etc. Ces dessins architecturaux manquent, toutefois, des dtails suffisants pour servir de base de travail aux quipes charges de la construction. On confie donc des dessinateurs d'architecture spcialiss dans diffrents domaines le soin de prparer les plans et les spcifications qui fourniront toutes les informations ncessaires sur le choix des matriaux, les sous-systmes d'aration, les sous-systmes lectriques, d'adduction d'eau, etc. L'architecte a la responsabilit globale du projet, mais ce sont ces concepteurs qui lui apportent tous les dtails. En gnral, l'architecte est expert dans l'intgration des divers aspects du btiment, mais i l n'est spcialiste d'aucun de ces domaines. Une fois que tous ces dessins dtaills sont prts, on constate que les dessins architecturaux ne couvrent que les parties significatives du btiment : ils se contentent d'offrir une vue de tous les autres dessins, avec lesquels ils restent parfaitement cohrents. Au cours de la construction, un grand nombre de professionnels utiliseront les dessins architecturaux (c'est--dire les vues des plans dtaills) pour se forger une image fidle du btiment, mais ils se baseront plutt sur les plans dtaills pour effectuer leur travail. Comme un btiment, un systme logiciel est une entit unique, mme si l'architecte logiciel et les dveloppeurs prfrent le prsenter depuis diffrents points de vue afin d'en mieux saisir la conception. Ces diffrents points de vue constituent des vues (Annexes A et C) plus claires des modles du systme. Ensemble, elles dvoilent l'architecture. L'architecture logicielle englobe toutes les dcisions d'importance sur les sujets suivants :

De la mme faon, le dveloppement des systmes logiciels (ou d'un systme logiciel et du matriel sur lequel i l s'excute) rclame de la prvoyance et la conservation des rflexions liminaires sous une forme exploitable par les dveloppeurs et par les autres intervenants. De plus, ces rflexions, cette architecture, ne sortent pas toutes armes du front de Zeus : i l faut plusieurs itrations, dans les phases de cration et d'laboration, pour mettre au point cette architecture. En fait, l'objectif premier de la phase d'laboration consiste tablir une architecture saine sous la forme d'une architecture de rfrence (Annexe C) excutable. On dispose alors de bases solides pour aborder la phase de construction et procder l'dification du systme dans son ensemble.

4.1 L'architecture en bref

Il nous faut une architecture. Soit. Mais qu'entend-on prcisment par architecture de systmes logiciels ? I l suffit de se plonger dans la littrature existant sur le sujet pour repenser la parabole des aveugles et de l'lphant. Un lphant est la somme de ce que chacun des aveugles a rencontr isolment : un grand serpent (la trompe), un bout de corde (la queue) et un petit arbre (la patte). De mme, l'ide d'architecture, tout au moins si l'on veut la dfinir en une phrase, est ce qui se trouve devant l'auteur ce stade. Reprenons la comparaison de l'architecture logicielle et de la construction de btiments. Du point de vue du client, un btiment forme, en gnral, une seule unit. I l peut tre intressant, pour l'architecte, de crer un modle l'chelle, ainsi que des dessins du btiment de diffrents points de vue. En principe peu dtaills, ces dessins sont comprhensibles par le client.

l'organisation d'un systme logiciel ; les lments structurels et leurs interfaces qui comprendront le systme, ainsi que leur comportement tel qu'il est spcifi dans les collaborations entre ces lments ; la composition des lments structurels et comportementaux au sein de sous-systmes dont la taille augmente de faon progressive ; le style architectural (Annexe C) que suit cette organisation : les lments et leurs interfaces, leurs collaborations et leur composition. Mais l'architecture logicielle ne s'intresse pas seulement la structure et au comportement ; elle se soucie galement de l'usage, des fonctionnalits, des performances, de la capacit de raction (resilience), des possibilits de rutilisation, de la clart, des contraintes et compromis conomiques et technologiques, enfin de l'esthtique. La section 4.4 nous donnera l'occasion d'aborder le concept d'architecture logicielle en termes plus concrets et de dcrire la faon de le reprsenter l'aide du Processus unifi.

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus c e n t r sur l'architecture

CHAPITRE 4

4.2.1 Comprendre le

systme

Pour qu'une socit puisse dvelopper un systme, i l faut que celui-ci soit comprhensible tous ceux qu'il va concerner. Rendre les systmes modernes comprhensibles constitue un dfi majeur pour plusieurs raisons : ces systmes ont un comportement complexe ; ils fonctionnent dans des environnements complexes ; ils sont complexes sur le plan technologique ; ils associent souvent informatique distribue, plates-formes et produits commerciaux (comme les systmes d'exploitation et les systmes de gestion de base de donnes), et des composants et frameworks rutilisables ; ils doivent rpondre aux besoins de personnes et d'organisations exigeantes ; dans certains cas, ils sont si tentaculaires que les responsables doivent en scinder le dveloppement en un grand nombre de projets, clats gographiquement parfois, ce qui ne fait que compliquer leur coordination. En plus, ces facteurs changent constamment. On en arrive une situation potentiellement difficile comprendre. Le recentrage du dveloppement sur l'architecture (Annexe C) est le seul moyen de ne pas tre confront une totale incomprhension. La premire exigence d'une description d'architecture est, par consquent, de permettre aux dveloppeurs, responsables, clients et autres intervenants de comprendre avec suffisamment de dtails ce qui doit tre fait et de favoriser ainsi leur participation. Les modles et diagrammes mentionns au chapitre 3 y contribuent et peuvent servir dcrire l'architecture. En se familiarisant avec UML, chacun trouvera l'architecture plus facile apprhender lorsqu'elle modlise avec ce langage.

Nous allons, toutefois, avancer ici une premire dfinition de la description de l'architecture (Annexe C). Nous avons indiqu que l'architecture est reprsente sous forme de vues des modles : vue du modle des cas d'utilisation, vue du modle d'analyse, vue du modle de conception, etc. Cet ensemble de vues concorde parfaitement avec les 4+1 vues voques dans [3]. tant donn qu'une vue d'un modle est un extrait, ou une coupe, de celui-ci, une vue du modle des cas d'utilisation, par exemple, ressemblera au modle des cas d'utilisation lui-mme : elle montrera les acteurs et les cas d'utilisation, mais uniquement ceux qui auront une signification sur le plan architectural. De la mme faon, la vue architecturale du modle de conception s'apparentera un modle de conception, mais elle n'affichera que les lments de conception ralisant les cas d'utilisation significatifs pour l'architecture. La magie n'a pas sa place dans une description d'architecture. Celle-ci ressemble une description complte du systme avec tous ses modles (il existe quelques diffrences sur lesquelles nous reviendrons plus tard), mais en plus petit. quel point ? La taille d'une description d'architecture est variable : i l n'y a pas, en la matire, de rgle absolue. Toutefois, d'aprs notre exprience de systmes assez divers, nous estimons qu'elle doit comprendre de 50 100 pages. Cette indication s'applique aux systmes une seule application (systme d'applications, voir Annexe C) ; les descriptions d'architecture de suites de systmes d'applications (Annexe C) seront plus volumineuses.

4.2 Pourquoi il nous faut une architecture

Un systme logiciel vaste et complexe exige la prsence d'un architecte, qui seul pourra mener les dveloppeurs vers une vision commune. Il est toujours difficile de se faire une ide d'un systme logiciel, car celui-ci n'existe pas dans notre monde en trois dimensions. I l est souvent sans prcdent ou unique sous un certain angle ; i l utilise des technologies non prouves ou une association indite de technologies ; i l pousse des technologies existantes jusqu' leurs limites ultimes. I l doit, en plus, tre conu pour accueillir tout un ensemble de changements venir. Avec la complexit croissante des systmes, le problme de la conception va au-del des algorithmes et des structures de donnes du calcul : la conception et la spcification de la structure globale du systme s'imposent comme un nouveau type de problme [1]. Il n'est pas rare, en outre, qu'un systme existant remplisse dj certaines fonctions du systme propos. Le fait qu'il faille dterminer ce que fait le systme, souvent avec une documentation partielle ou inexistante, et quelle part du code pourra tre rutilise ne fait qu'ajouter la complexit du dveloppement. Il nous faut une architecture pour : comprendre le systme ; organiser le dveloppement ; favoriser la rutilisation ; faire voluer le systme.

4.2.2 Organiser le

dveloppement

Plus l'quipe du projet logiciel est importante, plus on dpensera de temps dans les communications ncessaires la coordination des efforts des dveloppeurs. Ce temps supplmentaire augmente avec la dispersion gographique du projet. La scission du systme en soussystmes ayant des interfaces clairement dfinies, dont la responsabilit sera attribue un groupe ou un individu, permet de rduire la charge des communications entre les divers groupes, que ces derniers se trouvent dans le mme btiment ou sur diffrents continents. Une bonne architecture doit explicitement dfinir ces interfaces afin de rendre possible la rduction des communications. Lorsqu'elle est bien dfinie, une interface communique efficacement aux dveloppeurs de toutes parts ce qu'ils doivent savoir du travail des autres quipes. La stabilit des interfaces permet aux logiciels situs de part et d'autre de celles-ci d'voluer de faon indpendante. La prsence d'une architecture approprie, d'un ct, et les patterns de conception (Annexe C), de l'autre, aident identifier les meilleures interfaces entre soussystmes. Nous en avons un exemple avec le pattern Frontire-Contrle-Entit (voir la

jpjj Le Processus u n i f i de d v e l o p p e m e n t logiciel

Un processus c e n t r sur l'architecture

CHAPITRE 4 WM

section 3.4.1), qui nous a permis de rpartir les problmes entre comportement spcifique aux cas d'utilisation, classes frontires et classes gnriques.

4.2.3 Favoriser la

rutilisation

mentation existantes. En d'autres termes, le systme lui-mme doit savoir ragir aux changements, les tolrer. On pourrait aussi dire que le systme doit savoir voluer avec lgance. l'inverse, les systmes mal charpents se dgradent avec le temps et supportent difficilement l'ajout de correctifs. I l arrive un moment o leur actualisation n'est plus rentable. Le systme AXE d'Ericsson - De l'importance de l'architecture Le systme de commutation tlphonique AXE d'Ericsson a t dvelopp au dbut des annes 1970 sur la base d'une des premires versions de nos principes d'architecture. Artefact fondamental, la description de l'architecture logicielle a guid tout le travail de dveloppement pendant la dure de vie du systme. L'architecture reposait sur un certain nombre de principes dsormais intgrs au Processus unifi. L'un de ces principes tait celui de la modularit des fonctions. Les classes, ou leurs quivalents en conception, taient regroupes en blocs fonctionnels, ou sous-systmes de service, que les clients pouvaient considrer comme facultatifs (mme si ces lments taient livrs tous les clients). Chaque sous-systme de service prsentait une forte cohsion interne. Les changements apports au systme taient en gnral locaux un service et affectaient rarement plus d'un sous-systme de service. Un autre principe consistait sparer la conception des interfaces de la conception des soussystmes de service. Le but tait de tendre vers des conceptions par lments interchangeables ( plug-able ), dans lesquelles plusieurs sous-systmes de service pourraient prendre en charge la mme interface. Il devenait alors possible d'changer un sous-systme de service contre un autre sans modifier les clients du sous-systme en question (clients qui ne dpendent que des interfaces et non du code rel du sous-systme). Un troisime principe imposait d'assurer la correspondance directe d'un sous-systme de conception vers un ou plusieurs composants d'implmentation. Les composants du soussystme de service pouvaient tre distribus sur diffrents nuds de calcul du rseau. Il y avait exactement un composant pour chaque nud de traitement sur lequel devait s'excuter le sous-systme de service. De la sorte, si le sous-systme de service devait s'excuter sur l'ordinateur central (disons, un serveur), il y avait exactement un composant pour ce soussystme de service. Si le sous-systme devait tre implment la fois sur un client et sur un serveur, il y avait deux composants. Ce principe a permis une administration directe des changements du logiciel sur les diffrentes installations.

Ayons recours une analogie pour expliquer l'importance de l'architecture pour la rutilisation. L'industrie de la plomberie est depuis longtemps standardise. Les plombiers bnficient de composants standard. Ainsi, au lieu de se dmener pour trouver les joints correspondant aux dimensions de composants cratifs issus de sources diverses, le plombier choisit, parmi un ensemble standardis, des pices qui s'emboteront sans problme. Tout comme le plombier, les dveloppeurs forms la rutilisation connaissent le domaine du problme (Annexe C) et les composants que l'architecture dfinit comme tant appropris. C'est aux dveloppeurs de trouver le moyen de relier ces composants de sorte qu'ils obissent la configuration systme exige et ralisent le modle des cas d'utilisation. S'il existe des composants rutilisables, c'est ceux-l qu'ils choisissent. l'instar des joints de plomberie standard, les composants logiciels rutilisables sont conus et tests pour s'imbriquer, ce qui rduit le cot et les dlais de construction et donne des rsultats prvisibles. Comme dans l'industrie de la plomberie o la standardisation a pris des sicles pour s'imposer, la standardisation des composants logiciels ncessite une certaine exprience, mais on peut esprer l'avnement, d'ici quelques annes, d'une composantisation massive. Celle-ci est, en fait, dj en cours. Certes, i l reste l'industrie du logiciel accder au niveau de standardisation qu'a dj atteint le domaine du matriel informatique sous de nombreux aspects ; mais le recours une architecture saine et des interfaces explicites constitue un premier pas encourageant dans cette voie. Une architecture saine offre aux dveloppeurs un socle stable sur lequel chafauder leur travail. Le rle de l'architecte consiste dfinir ce socle et les sous-systmes qui devront en faire partie. Pour tre rutilisables, les composants doivent tre conus de faon tre parfaitement intgrables les uns aux autres [2]. Une architecture bien pense doit rentabiliser la recherche de composants rutilisables et permettre de trouver facilement ceux qui sont le plus appropris. I l ne fait aucun doute que la gnralisation d'UML va acclrer le processus de composantisation, ta prsence d'un langage de modlisation standard tant un pralable la fabrication de composants spcifiques au domaine susceptibles d'tre rutiliss.

4.2.4 Faire voluer

le

systme

S'il y a une chose dont on peut tre sr, c'est que tout systme de taille relativement importante volue. Il voluera mme au cours du dveloppement. Par la suite, quand i l sera oprationnel, les changements d'environnement appelleront d'autres volutions. Dans les deux cas, le systme doit tre facile modifier : les dveloppeurs doivent pouvoir remanier des parties de la conception et de l'implmentation sans avoir se soucier des rpercussions inattendues que pourraient avoir ces changements sur l'ensemble du systme. I l faut, d'une manire gnrale, qu'ils puissent implmenter dans le systme de nouvelles fonctions (c'est-dire des cas d'utilisation) sans constater d'effet spectaculaire sur la conception et l'impl-

Mais un autre principe prconisait un faible couplage entre sous-systmes de service. Les signaux taient les seuls moyens de communication entre ces sous-systmes. Comme ces signaux taient asynchrones (c'est--dire qu'ils appliquaient une smantique envoisans-attente ), ils prenaient en charge non seulement l'encapsulation, mais galement la distribution.
1

i . Ou rpartition

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus c e n t r sur l'architecture

H|

Grce un dveloppement initial et ultrieur guid par une architecture bien conue, le systme AXE est toujours utilis aujourd'hui et compte plus de cent clients et quelques milliers d'installations. Il devrait encore accueillir de nouveaux changements pendant plusieurs dcennies.

les produits logiciels systme sur lesquels devra reposer la construction, notamment le systme d'exploitation ou un systme spcifique de gestion de base de donnes relationnelle ;

4.3 Cas d'utilisation et architecture

Nous avons laiss entendre qu'il existait quelque interaction entre les cas d'utilisation et l'architecture. Le chapitre 3 a montr comment dvelopper, en principe, un systme fournissant ses utilisateurs les cas d'utilisation dont ils ont besoin. Si le systme propose les cas d'utilisation appropris (c'est--dire ceux offrant la fois performances, qualit et utthsabilit), les utilisateurs peuvent s'en servir pour mener bien leurs missions. Mais comment y parvenir ? La rponse, comme nous l'avons dj suggr, consiste btir une architecture permettant d'implmenter de faon rentable les cas d'utilisation, dans le prsent et l'avenir. Clarifions, maintenant, les modalits de cette interaction en examinant, d'abord, ce qui influence l'architecture (voir lafigure4.1), puis ce qui a un impact sur les cas d'utilisation.
Contraintes et facteurs favorables C a s d'utilisation

les produits de middleware (couche de middleware ; Annexe C) choisis. I l faudra, par exemple, slectionner un ORB, c'est--dire un mcanisme de mise plat (marshalling) et d'acheminement transparents des messages aux objets distribus dans des environnements htrognes [6], ou un framework indpendant de la plate-forme, c'est--dire un systme prfabriqu , pour crer les interfaces utilisateur graphiques ; les systmes existants qu'intgrera le systme. La conservation, au sein de l'architecture, d'un systme existant tel qu'un systme bancaire permet de rutiliser un grand nombre de fonctionnalits, mais elle ncessite galement d'adapter l'architecture ce vieux produit ; les standards et politiques d'entreprise auxquels on se pliera. On pourrait, par exemple, choisir le Langage de dfinition d'interfaces (IDL) de l'OMG [7] pour spcifier toutes les interfaces de classes, ou le standard de tlcommunications TMN [8] pour dfinir les objets dans le systme ; les besoins non fonctionnels gnraux (c'est--dire non spcifiques aux cas d'utilisation), tels que les besoins en termes de disponibilit, de temps de rcupration ou d'utilisation de la mmoire ; les besoins en distribution spcifient le modle de distribution du systme, par exemple travers une architecture client-serveur. Les lments du ct droit de lafigure4.1 peuvent tre envisags comme des contraintes et des facteurs favorables menant un certain type d'architecture.

Logiciel systme Middleware (y compris les frameworks) - Systmes existants

Architecture

<r

- Standards et politiques - Besoins non fonctionnels

Figure 4.1 Diffrents types de besoins et de produits influencent l'architecture, et non pas seulement les cas d'utilisation. L'exprience acquise sur des travaux antrieurs et les structures que l'on peut identifier comme patterns d'architecture se rvlent galement utiles pour la mise au point de l'architecture.

Exprience :

- Besoins de distribution

L'architecture est mise au point en plusieurs itrations dans la phase d'laboration. On pourrait imaginer, comme modle de pense, l'approche simplifie et quelque peu nave qui suit. On commence par opter pour une conception de haut niveau, telle qu'une architecture en couches (Annexe C). Puis, on faonne l'architecture par quelques constructions (Annexe C ; voir aussi le chapitre 10) au cours de la premire itration. La premire construction s'attarde sur les parties gnrales aux applications (Annexe C), c'est--dire aux parties gnrales au domaine en question et non spcifiques au systme envisag : on slectionne le logiciel systme (couche de logiciel systme ; Annexe C ; voir aussi la section 9.5.1.2.2), le middleware, les systmes existants, les standards et les poli tiques utiliser. C'est le moment o l'on dcide des nuds quifigurerontdans le modle de dploiement et de leurs interactions. I l faut, enfin, trancher sur la faon de traiter les exi gences non fonctionnelles gnrales, telles que les exigences de disponibilit. Pour celle pK mire passe, une comprhension gnrale de l'application suffit. La deuxime construction, en revanche, s'intresse aux aspects spcifiques aux applications (couche spcifique l'application ; Annexe C). On choisit un ensemble de cas d'utilisation pertinents sur le plan de l'architecture, puis on procde la capture des besoins, qui sont ensuite analyss, conus, implments et tests. Ce processus aboutira la cration de soussystmes implments sous forme de composants prenant en charge les cas d'utilisation retenus. I l se peut galement que quelques changements interviennent dans les composants

Architectures prcdentes Patterns d'architecture

Comme nous l'avons dj mentionn, l'architecture est influence par les cas d'utilisation que nous voulons faire prendre en charge par le systme. Ces cas d'utilisation agissent, en effet, comme des pilotes pour l'architecture. Aprs tout, on veut obtenir une architecture adapte l'implmentation des cas d'utilisation retenus. On slectionne, dans les premires itrations, quelques cas d'utilisation jugs indispensables la cration de l'architecture. Parmi ces cas d'utilisation pertinents pour l'architecture, figurent ceux dont les clients ont le plus besoin pour la version venir et peut-tre pour les versions suivantes. Toutefois, l'architecture ne subit pas la seule influence des cas d'utilisation significatifs sur le plan de l'architecture, mais galement celle des facteurs suivants :

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un ^ p r o c e s s u s c e n t r sur l'architecture
CHAPITRE 4

Cas f d'utilisation Gi f u* \t

significatifs sur le plan architectural implments lors de la premire construction ( un moment o l'on ne rflchissait pas en termes de cas d'utilisation). Les composants modifis et les nouveaux composants sont mis au point pour raliser les cas d'utilisation, ce qui permet d'adapter au mieux l'architecture aux cas d'utilisation. On procde ensuite une autre construction, et ainsi de suite, jusqu' ce que soit termine l'itration. Si l'itration s'achve la fin de la phase d'laboration, l'architecture doit en plus tre stable. Une fois que l'on dispose d'une architecture stable, on peut implmenter les fonctionnalits compltes en ralisant le reste des cas d'utilisation pendant la phase de construction. Les cas d'utilisation implments durant cette phase sont essentiellement dvelopps partir des besoins des clients et des utilisateurs (voir la figure 4.2). Mais les cas d'utilisation subissent galement l'influence de l'architecture choisie dans la phase d'laboration.
E n t r e s des clients E n t r e s des utilisateurs J -> C a s d'utilisation

Figure 4.3 Ces cas d'utilisation orientent le dveloppement de l'architecture, tandis que l'architecture guide la ralisation des cas d'utilisation.

Ar-chitecture '

ligure 4.2 / n i us d'utilisation peuvent tre I labors partir des entres fournies Ml 1rs clients et les utilisateurs. i . pendant, ils sont galement influencs 1:11 l'architecture dj en place.

Architecture

Qui vient en premier : les cas d'utilisation ou l'architecture ? Voil un exemple typique du problme de l'uf et de la poule. Le meilleur m o y e n de rsoudre ce type de problme consiste procder par itrations. On construit d'abord une architecture provisoire partir d'une bonne comprhension du domaine (AnnaeC), sans toutefois considrer le dtail des cas d'utilisation. Puis, on choisit quelques cai d'utilisation significatifs et l'on adapte l'architecture pour qu'elle prenne en charge l s cas d'utilisation en question. On prend ensuite e d'autres cas d'utilisation, en fonction desquels on amliore encore l'architecture, et ainsi de suite. A chaque itration, on slectionne e on implment un ensemble de cas d'utilisation t afin de valider et, si ncessaire, d'amliorer l'architecture. Ces itrations successives permettent galement de poursuivre l'implmentation des parties de l'architecture spcifiques aux applications partir des cas d'utilisation slectionns. Les cas d'utilisation contribuent, par consquent, l'amlioration progressive de l'architecture mesure qu'on s'achemine vers le systme complet. Ce n'est pas le moindre des avantages du dveloppement pilot par les cas d'utilisation. Nous reviendrons sur cette approche itrative au chapitre 5. En rsum, une bonne architecture est une architecture qui permet de dterminer, de faon rentable, les cas d'utilisation qui conviennent, pour le prsent et l'avenir.

On utilise, lors de l'identification de nouveaux cas d'utilisation, la connaissance que l'on a de l'architecture dj en place, l'aune de laquelle seront valus l'intrt et le cot de chaque suggestion de cas d'utilisation. Certains de ces cas d'utilisation seront plus faciles implmenter que d'autres.

ITffiHIl

Adaptation des cas d'utilisation l'architecture dj en place Le client a exig une fonction de supervision de la charge du processeur. Cette fonction a t spcifie sous la forme d'un cas d'utilisation mesurant la charge un niveau de haute priorit de l'ordinateur. L'implmentation de ce cas d'utilisation aurait, en principe, ncessit quelques modifications du systme d'exploitation temps rel utilis. Mais l'quipe a prfr implmenter la fonctionnalit dsire par un dispositif externe indpendant effectuant des appels au systme et mesurant le temps de rponse. Le client obtenait ainsi des mesures plus fiables et l'quipe de dveloppement n'avait pas besoin de modifier l'architecture sous-jacente, beaucoup plus stratgique.

4.4 tapes d'laboration de l'architecture

L'architecture est mise au point par itrations successives, essentiellement pendant la phase d'laboration. Chaque itration se droule selon la description fournie au chapitre 3, en partant des besoins, suivis de l'analyse, de la conception, de l'implmentation et des tests, mais se concentre sur les cas d'utilisation et les autres besoins pertinents pour l'architecture. Cette phase d'laboration dbouche alors sur une architecture de rfrence, c'est--dire un squelette du systme paissi de quelques muscles .

Aprs avoir ngoci avec le client, on dtermine s'il n'y a pas moyen de simplifier l'implmentation en alignant davantage les cas d'utilisation et la conception qui en rsulte sur l'architecture en place. Cela signifie qu'il faut considrer quels sont les sous-systmes, interfaces, cas d'utilisation, ralisations de cas d'utilisation, classes, et ainsi de suite, qui existent dj. Cet alignement des cas d'utilisation sur l'architecture permet de rentabiliser la cration de nouveaux cas d'utilisation, sous-systmes et classes en exploitant ce dont on dispose. Par consquent, d'un ct, l'architecture est influence par le choix des cas d'utilisation que l'on souhaite faire prendre en charge par le systme : les cas d'utilisation orientent l'architecture. De l'autre, on emploie la connaissance que l'on a de l'architecture pour optimiser l'expression des besoins sous forme de cas d'utilisation : l'architecture guide les cas d'utilisation (voir lafigure4.3).

Quels sont les cas d'utilisation significatifs sur le plan architectural ? Nous approfondirons cette question dans la section 12.6. Pour l'instant, nous nous bornerons indiquer que les cas d'utilisation significatifs pour l'architecture sont ceux qui permettent de rduire les risques les plus importants, ceux qui comptent le plus pour les utilisateurs et ceux qui aident couvrir les principales fonctionnalits afin que rien ne reste dans l'ombre. L'implmentation, l'intgration et les tests de l'architecture de rfrence donnent l'architecte et aux autres travailleurs la garantie que l'architecture, ce stade, est fonctionne vraiment. Ce qui ne saurait tre prouv par une analyse et une conception sur le papier . L'architecture de rfrence oprationnelle fournit donc une dmonstration laquelle peuvent ragir les diffrents travailleurs.

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus c e n t r sur l'architecture

CHAPITRE 4

4.4.1 L'architecture de rfrence

est un systme

petit et maigre

l'issue de la phase d'laboration, nous avons dvelopp les modles du systme qui reprsentent, d'un point de vue architectural, les cas d'utilisation les plus importants et leurs ralisations. Nous avons galement dcid, comme l'explique la section 4.3, Cas d'utilisation et architecture , quels sont les standards respecter, les logiciels systme et middleware utiliser, les systmes existants rutiliser et quels sont les besoins en matire de distribution. Nous disposons, ainsi, des premires versions du modle des cas d'utilisation, et des modles d'analyse, de conception, etc. Cet agrgat de modles (voir la figure 4.4) constitue l'architecture de rfrence ; c'est un petit systme maigre . Celui-ci comprend tous les modles que comportera le systme abouti la fin de la phase de construction, ainsi que le squelette des sous-systmes, composants et nuds qui figureront dans le systme final, sans toutefois que la musculature ne soit totalement en place. Mais ces lments ont un comportement et se constituent de code excutable. Ce systme bien maigre se transforme ensuite en un systme complet, avec quelques changements ventuels de structure et de comportement, changements forcment mineurs puisqu'on dispose par dfinition d'une architecture stable la fin de la phase d'laboration. Si ce n'est pas le cas, la phase d'laboration doit se poursuivre jusqu' ce que soit atteint cet objectif.
Figure 4.4 ; 'architecture ii'lt'rence de est une sur de

Chaque version voluerait partir de la version prcdente. Les diffrents modles de la figure 4.4 ne sont videmment pas dvelopps indpendamment les uns des autres. Chaque cas d'utilisation du modle des cas d'utilisation correspond, par exemple, une ralisation de cas d'utilisation dans les modles d'analyse et de conception et des cas de test dans le modle des tests. Le processus et la structure des nuds doit satisfaire au niveau de performances exig par les cas d'utilisation. (Sinon, i l faut modifier les cas d'utilisation ou le modle de dploiement, par exemple en changeant le mode d'affectation des classes actives aux nuds pour obtenir de meilleures performances. De telles modifications du modle de dploiement ou du modle de conception sont susceptibles de conduire des remaniements dans le modle des cas d'utilisation, si ces changements ncessitent de modifier certains cas d'utilisation. Les lments des diffrents modles sont, comme nous l'avons dit dans la section 2.3.7, lis les uns aux autres par des dpendances de traabilit .

D
1

D
1

Lt3

vi I lion interne du I rystime centre l,i description i hitecture.

Modle des cas d'utilisation

Modle d'analyse
1

Modle de conception

. . . . . .

Modle de Modle dploiement d'implmentation

MModle ^Holo des tests

Toutefois, l'architecture de rfrence, c'est--dire la version interne du systme telle qu'elle existe la fin de la phase d'laboration, ne se limite pas des artefacts de modles. Elle comprend galement une description de l'architecture. En ralit, cette description s'labore au fur et mesure (et parfois mme en amont) des activits qui donnent naissance aux versions des modles faisant partie de l'architecture de rfrence. Le rle de la description de l'architecture consiste guider l'quipe de dveloppement tout au long de la dure de vie du systme, non seulement pour les itrations du cycle en cours, mais pour tous les cycles venir. Cette description constitue le standard qui devra tre suivi par les dveloppeurs, aujourd'hui et dans le futur. L'architecture devant tre stable, le standard doit l'tre aussi. La description de l'architecture peut revtir diverses formes. I l peut s'agir d'un extrait des (versions des) modles faisant partie de l'architecture de rfrence, ou de la rcriture de ces extraits sous une forme plus lisible. Nous reviendrons l-dessus dans la section 4.4.3, Description de l'architecture . Cette description contient, nanmoins, des extraits (ou vues) des modles de l'architecture de rfrence, qui seront actualiss au gr de l'volution du systme et de l'enrichissement des modles dans les phases plus tardives. Si l'on admet que l'architecture de rfrence a donn heu une architecture stable, c'est--dire que les lments de modles significatifs sur le plan architectural sont stables et ne bougeront pas dans les itrations venir, on peut considrer que la description de l'architecture est, elle aussi, stable et qu'elle inclura tout moment les vues des modles du systme. Il est fascinant de constater que l'on peut parfaitement mettre au point une architecture stable pendant la phase d'laboration du premier cycle de vie, alors mme que seuls quelque 30% de la premire version du produit ont t investis. Cette architecture servira de fondations au systme pendant toute sa dure de vie. Comme chaque modification de ce socle cotera cher et sera, dans certains cas, trs douloureuse, i l est important de parvenir une architecture stable ds les premiers stades du travail de dveloppement. D'une certaine faon, la mise au point d'une architecture pour un systme particulier revient crer quelque chose de nouveau. D'un autre ct, i l y a des annes que l'on dveloppe des architectures. Exprience et connaissances se sont donc accumules dans ce domaine. I l existe de nombreuses solutions gnriques (structures, collaborations et architectures physiques) ayant volu avec les annes que tout architecte expriment doit connatre. On dsigne gnralement ces solutions du nom de patterns , comme les patterns d'architecture dcrits dans

Dans la figure 4.4, la zone ombre de chaque modle reprsente la version du modle mise au point la fin de la phase d'laboration, c'est--dire la version du modle faisant partie de l'architecture de rfrence. Le rectangle dans son entier (zones ombre et non ombre) reflte la version du modle qui mergera l'issue de la phase de transition, c'est--dire la rfrence reprsentant la version destine au client (le lecteur devra se garder de tirer des conclusions htives partir de la taille des zones ombres dans la figure 4.4, qui n'apparaissent ici qu' titre indicatif). Entre l'architecture de rfrence et la version client de rfrence, plusieurs rfrences intermdiaires reprsentent les versions internes (Annexe C) des modles remanis. Nous aurions pu illustrer ces nouvelles versions par une succession d'incrments chafauds les uns au-dessus des autres, partir de l'architecture de rfrence. I Ceci n'est pas tout fait exact. l'issue de la phase d'laboration, nous disposons d'une version du modle des cas d'utilisation contenant la fois les cas d'utilisation significatifs pour l'architecture et ceux (disons, jusqu a K<)%) qui sont ncessaires la cration d'une tude de rentabilit. Ainsi, le modle des cas d utilisation et le modle d'analyse de l'architecture de rfrence sont-ils plus complets que ne l'indique lafigure4.4. Nous nous permettons, toutefois, cette simplification pour la clart de notre propos.

i < Processus u n i f i de d v e l o p p e m e n t logiciel

CMIIIt I

Un processus c e n t r sur l'architecture

CHAPITRE 4

|4] et les patterns de conception traits en dtail dans [5]. Ces patterns gnriques constituent des ressources dans lesquelles l'architecte pourra puiser.

Uses, donnent lieu des collaborations concrtes dont on peut retrouver directement la trace dans les cas d'utilisation. Les patterns de conception sont traits en dtail dans [5]. S'ils s'utilisent de la mme faon, les patterns d'architecture s'intressent principalement la structure plus large granularit et aux interactions des sous-systmes et mme des systmes eux-mmes. I l existe de nombreux patterns d'architecture, dont nous n'voquerons ici que les plus intressants. Le pattern Broker [4] est un mcanisme gnrique de gestion de la distribution des objets. Il permet aux objets d'appeler d'autres objets distants par l'intermdiaire d'un courtier ( broker ) qui transmet l'appel au nud et au processus dtenant l'objet dsir. L'appel esl transmis en toute transparence, si bien que l'objet appelant n'a pas besoin de savoir si l'objcl appel est distant ou non. Le pattern Broker fait un usage frquent du pattern de conception Proxy, qui fournit un objet mandataire local ayant la mme interface que l'objet distant, afin de rendre parfaitement transparents le style et les dtails de la communication distribue. D'autres patterns facilitent la comprhension du matriel et simplifient la conception des systmes au-dessus de ce matriel : les patterns Client-serveur, Trois niveaux (Three-Tier) et d'Egal gal (Peer-to-peer), entre autres. Ils dfinissent une structure pour le modle de dploiement et suggrent le mode d'affectation des composants sur les nuds. Nous illustrerons, dans la section 4.5, la faon dont on peut appliquer le pattern Client-serveur au systme de DAB dcrit au chapitre 3. Dans notre exemple, la distribution client-serveur comprend un nud client excutant tout le code des interfaces utilisateur et une partie du code de la logique mtier (classes de contrle) pour chaque DAB physique. Le nud serveur dtient les comptes rels et les rgles mtier par rapport auxquelles sont vrifies toutes les transactions.

4.4.2 Utilisation des patterns d'architecture

Les ides avances par l'architecte Christopher Alexander sur la faon dont les langages de patterns permettent de systmatiser les principes et pratiques fondamentaux de la conception de btiments et de l'amnagement de lieux publics ont inspir plusieurs spcialistes de l'objet qui ont, leur tour, dfini, collect et test un ensemble de patterns logiciels [10]. I ,cs spcialistes dfinissent un pattern comme une solution un problme rcurrent de Conception. La plupart de ces patterns de conception sont amplement dcrits dans des ouvrages qui les prsentent l'aide de canevas de documents standard. Ces canevas gnriques donnent un nom au pattern et prsentent un rsum du problme et des forces qui le suscitent, une solution en termes de collaborations avec des classes et d'interactions entre objets de ces classes. Ils proposent galement des exemples d'utilisation du pattern dans certains langages de programmation, ainsi que diverses variantes du pattern, un rsum des avantages et des effets de son utilisation, et des rfrences d'autres patterns proches. Alexander exhorte les ingnieurs logiciels retenir le nom et l'intention d'un grand nombre de patterns standard et s'en servir pour la cration de conceptions plus saines et comprhensibles. Certains, tels que les patterns Faade, Dcorateur, Observateur, Mandataire, Stratgie et Visiteur, sont largement cits et utiliss.

Figure 4.5 L'architecture en couches organise les systmes par couches de soussystmes.

Couche spcifique l'application

Couche gnrale aux applications

I .es spcialistes ont galement utilis le concept de pattern, sous un modle de document lgrement diffrent, pour regrouper des solutions standard des problmes architecturaux rcurrents. Citons, entre autres, les patterns Couches, Canaux & filtres (Pipes & Filters), broker, Tableau noir (Blackboard), Mta-donnes horizontales & verticales, MVC (ModleVue-Contrleur). D'autres ont mis au point des patterns utiliser pendant l'analyse ( patterns d'analyse ), l'implmentation ( idiomes faisant correspondre des structures orientes objet courantes des aspects spcifiques certains langages tels que C++ et Smalltalk), et d'autres destins optimiser la structure des quipes (patterns organisationnels ). En principe, les patterns de conception assurent une correspondance assez directe avec les langages de programmation orients objet. On en trouve des exemples en C++, Java et Smalltalk, tandis que les patterns d'architecture se proccupent essentiellement des systmes ou sous-systmes et des interfaces, et prsentent des exemples ne comportant gnralement pas de code. Pour dcouvrir un schma de classification intressant, consultez [9].

Couche de middleware

De notre point de vue dtermin par les modles, nous dfinirons un pattern comme une collaboration gnrique pouvant tre spcialise, selon la dfinition d'un template (Annexe A). Les patterns de conception deviennent, ainsi, des collaborations entre classes et instances, dont le comportement est expliqu par des diagrammes d'interaction. Nous utilisons les collaborations gnriques, car elles proposent des solutions conues pour tre suffisamment gnrales. L'hritage, l'extension et d'autres mcanismes permettent ensuite de spcialiser le pattern (par exemple, en spcifiant le nom des classes, leur nombre, etc., apparaissant dans la collaboration gnrique). Dans bien des cas, les collaborations gnriques, une fois spcia-

Couche de logiciel systme Le pattern Couches (Layers) peut tre appliqu une multitude de systmes. I l dfinit l'organisation du modle de conception en couches, selon laquelle les composants d'une couche ne peuvent faire rfrence qu'aux composants de la couche situe immdiatement au-dessous. Ce pattern est d'une importance dterminante, car i l simplifie la comprhension et l'organisation du dveloppement de systmes complexes. I l rduit les dpendances en

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus c e n t r sur l'architecture

faisant en sorte que les couches infrieures ignorent les dtails ou les interfaces des couches suprieures. I l facilite, enfin, l'identification de ce qui peut tre rutilis et fournit une structure d'aide la prise de dcisions sur ce qui doit tre achet ou construit. Les systmes architecture en couches disposent, en leur sommet, de sous-systmes d'applications individuels, labors partir de sous-systmes des couches infrieures, tels que des frameworks ou des bibliothques de classes (voir la figure 4.5). La couche gnrale aux applications contient des sous-systmes qui ne sont pas spcifiques une seule application, mais peuvent tre rutiliss pour diverses applications du mme domaine ou du mme mtier. L'architecture des deux couches infrieures peut tre labore sans prendre en compte les dtails des cas d'utilisation, car ces couches ne sont pas spcifiques au mtier, alors que l'architecture des deux couches suprieures est, quant elle, cre partir des cas d'utilisation pertinents sur le plan architectural (ces couches sont spcifiques au mtier).

bilit) des modles contenus dans l'architecture de rfrence et comprenant les lments significatifs sur le plan architectural. Bien sr, un grand nombre des lments de modles faisant partie de l'architecture de rfrence apparatront dans la description de l'architecture. Mais tous n'y figureront pas, car, pour obtenir une architecture de rfrence oprationnelle, il sera peut-tre ncessaire de dvelopper certains lments de modles peu intressants sur le plan architectural, mais indispensables la production de code excutable. tant donn que l'architecture de rfrence ne sert pas seulement dvelopper une architecture, mais aussi spcifier les besoins du systme au point qu'un plan dtaill peut tre dfini, i l est possible que le modle des cas d'utilisation de cette architecture contienne galement plus de cas d'utilisation que ne l'exige le point de vue strictement architectural. La description de l'architecture sera actualise tout au long de la dure de vie du systme, afin de reflter les changements et ajouts pertinents sur le plan architectural. I l s'agit, en principe, de changements mineurs tels que : l'identification de nouvelles interfaces et classes abstraites ; l'ajout de nouvelles fonctionnalits des sous-systmes existants ; la mise niveau, par de nouvelles versions, de composants rutilisables ; le ramnagement de la structure des processus. Il est possible que la description de l'architecture elle-mme doive en tre modifie, mais i l n'est pas ncessaire de l'toffer. Elle doit simplement tre actualise pour rester pertinente (voir lafigure4.6). Comme nous l'avons dit plus haut, la description de l'architecture prsente les vues des modles et comprend ainsi des cas d'utilisation, des sous-systmes, des interfaces, certains composants et classes, des nuds et des collaborations. Elle intgre galement les besoins significatifs sur le plan architectural qui ne sont pas dcrits par les cas d'utilisation. Les autres besoins, non fonctionnels, sont formuls en tant qu'exigences supplmentaires, comme celles concernant la scurit et les principales contraintes en matire de distribution et de concurrence (Annexe C ; voir galement la section 9.5.1.4). La description de l'architecture doit, en outre, contenir une brve description de la plate-forme, des systmes existants et des logiciels commerciaux utiliser, comme Java RMI (Remote Method Invocation) pour la distribution des objets. Par ailleurs, i l convient de dcrire les frameworks mettant en uvre les mcanismes gnriques (Annexe C ; voir galement la section 9.5.1.4), tels que les mcanismes de stockage et de rcupration des objets partir d'une base de donnes relationnelle. Ces mcanismes ayant t conus pour raliser des collaborations rutilisables, ils peuvent tre rutiliss par plusieurs ralisations de cas d'utilisation. Enfin, la description de l'architecture doit galement documenter tous les patterns d'architecture auxquels on aura eu recours. La description de l'architecture met en lumire les principales questions de conception afin que chacun puisse les examiner et livrer ses ractions. Ces questions doivent ensuite faire l'objet de discussions, tre analyses etfinalementtranches. I l pourra s'agir, par exemple, d'estimer la charge sur les performances ou les besoins en mmoire, et d'imaginer les exigences futures, susceptibles de briser l'architecture.

Une couche (Annexe C) est un ensemble de sous-systmes partageant le mme degr de gnralit et de volatilit des interfaces : les couches infrieures sont gnrales plusieurs applications et doivent bnficier d'interfaces plus stables, contrairement aux couches suprieures, plus spcifiques aux applications et pouvant, par consquent, disposer d'interfaces plus mouvantes. Parce qu'elles ont des interfaces moins changeantes, les couches infrieures peuvent servir de base l'laboration des couches suprieures. Les sous-systmes des diffrentes couches peuvent rutiliser des cas d'utilisation, d'autres sous-systmes de niveau infrieur, des classes, interfaces, collaborations et composants issus de couches infrieures. On peut appliquer de nombreux patterns d'architecture au sein d'un mme systme. Les patterns structurant le modle de dploiement (c'est--dire les patterns Client-serveur, trois niveaux et gal gal) peuvent tre associs au pattern Couches, qui contribue la structuration du modle de conception. Les patterns concernant les questions de structure des diffrents modles sont souvent orthogonaux les uns par rapport aux autres. Mme les patterns qui traitent du mme modle peuvent parfaitement s'associer, comme, par exemple, le pattern Broker et le pattern Couches, qui sont tous deux utiliss dans le modle de conception. Le pattern Broker traite du mode de distribution transparente des objets, tandis que le pattern Couches suggre l'organisation de l'ensemble de la conception. Dans les faits, le pattern Broker serait ralis en tant que sous-systme de la couche de middleware. Il arrive qu'un pattern prdomine sur les autres. Par exemple, dans un systme couches, le pattern Couches dfinit l'architecture globale et la dcomposition du travail (attribution des couches diffrents groupes), tandis qu'on pourra utiliser le pattern Canaux & filtres dans l'une ou l'autre de ces couches. l'inverse, dans un systme canaux et filtres, l'architecture globale sera reprsente comme un flot entre filtres, alors mme que l'organisation en couches sera explicitement utilise pour certains de ces filtres.

4.4.3 Description de l'architecture

L'architecture de rfrence mise au point dans la phase d'laboration survit, comme nous l'avons observ dans la section 4.4.1, sous la forme d'une description de l'architecture. Celle-ci trouve son origine dans les versions des diffrents modles issus de la phase d'laboration, comme le montre la figure 4.6. La description de l'architecture est un extrait ou, comme nous l'avons dit, un ensemble de vues (ventuellement rcrites pour plus de lisi-

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus c e n t r sur l'architecture

CHAPITRE 4

Architecture de rfrence
Modle des cas d'utilisation Modle d'analyse Modle Modle do de conceptlon dploiement Modle d'implmentation Modle des tests

Architecture de rfrence la fin de la construction

Modle des cas d'utilisation Modle d'analyse Modle Modle Modle d'implmende de conceplion dploiement tation Modle des tests

I
Description de l'architecture Version de la phase d'laboration
Modle des cas d'utilisation Modle d'analyse Modle Modle de de conceplion dploiement Modle d'Implmentation

Description de l'architecture Version de la phase de construction

Modle de Modle d'implmen-

Il peut tre utile de s'interroger sur ce que n'est pas l'architecture. La plupart des classes, dont les oprations, interfaces et attributs sont privs aux sous-systmes ou aux sous-systmes de service (invisibles au reste du systme), ne sont pas pertinentes sur le plan architectural. Les sous-systmes qui sont des variantes d'autres sous-systmes n'ont aucun intrt du point de vue de l'architecture. L'exprience prouve que moins de 10% des classes sont pertinentes pour l'architecture. Les 90% de classes restantes ne comptent pas pour la simple raison qu'elles ne sont pas visibles au reste du systme. Les changements qu'elles peuvent subir n'affectent rien de primordial en dehors du sous-systme de service. De mme, la plupart des ralisations de cas d'utilisation sont-elles insignifiantes pour l'architecture, puisqu'elles n'imposent aucune contrainte supplmentaire au systme. C'est pourquoi les architectes peuvent planifier une architecture partir d'une simple fraction des cas d'utili sation et des autres besoins. En majorit, les ralisations de cas d'utilisation ne reprsenlenl qu'un comportement subsidiaire, facile implmenter, mme si ces ralisations constituent l'essentiel des fonctions offertes par le systme. Et c'est bien l que nous voulons en venir : la plupart des fonctionnantes du systme sont simples implmenter une fois que l'architecture est en place. La description de l'architecture ne comprend pas les informations uniquement ncessaires la validation ou la vrification de l'architecture. On n'y trouve donc pas de cas, ni de procdures de tests, et elle ne Uvre aucune vue architecturale du modle des tests. Ces questions ne relvent pas de l'architecture. Toutefois, comme l'indique lafigure4.6, l'architecture de rfrence contient une version de tous les modles, y compris une version du modle des tests. La rfrence sous-jacente la description de l'architecture a donc subi des tests. Comme toutes les rfrences.

Figure 4.6 Pendant la construction, les diffrents modles sont ports leur terme (rectangles pleins dans le coin suprieur droit). La description de l'architecture, toutefois, ne s'toffe pas de faon significative (en bas droite), puisque l'essentiel de l'architecture a t dfini au cours de la phase d'laboration. Quelques changements mineurs (indiqus par un remplissage diffrent) viennent effectivement modifier l'architecture.

4.4.4 C'est l'architecte qui cre l'architecture

Bien que dtaille lorsque c'est ncessaire, la description de l'architecture demeure une vue de haut niveau. D'un ct, elle ne prtend pas l'exhaustivit ; i l n'est pas question de noyer les participants sous un dluge de dtails. C'est une feuille de route, et non une spcification complte du systme. D'un autre ct, elle doit prsenter tout ce qui est susceptible d'intresser l'un ou l'autre des participants. I l sera donc assez courant qu'elle atteigne une centaine de pages. Les gens n'hsiteront pas consulter un document volumineux s'il contient tout ce qu'ils ont besoin de savoir sous une forme immdiatement comprhensible. Aprs tout, c'est le rle de la description de l'architecture : contenir tout ce qui permettra aux dveloppeurs de faire leur travail. On peut avoir l'impression, en Usant une description d'architecture, qu'elle se contente de survoler certains sous-systmes, alors qu'elle se rpand en dtails sur les interfaces et les collaborations d'une poigne d'autres sous-systmes. La raison de cette diffrence de traitement tient au fait que les sous-systmes hautement spcifis sont ceux qui comptent sur le plan de l'architecture et qu'ils doivent rester sous le contrle direct de l'architecte (voir les sections 12.4.2 et 14.4.3.1).

C'est l'architecte, entour de quelques dveloppeurs, qui cre l'architecture. Ensemble, ils conjuguent leurs efforts pour mettre au point un systme qui devra prsenter des performances et un niveau de qualit levs, ainsi que les caractristiques suivantes : utilit, capacit de tests, convivialit, fiabilit, haute disponibilit, prcision, extensibilit, tolrance aux changements, robustesse, facilit de maintenance, portabilit, scurit, sret et rentabilit. Ils savent, nanmoins, que le respect de ces contraintes exige des compromis, ce qui justifie la prsence de l'architecte : c'est lui, en effet, qui dtient la plus haute responsabilit technique sur ces questions. C'est lui qui choisit parmi les patterns d'architecture, slectionne les produits existants et organise les dpendances de sous-systmes de faon srier les problmes. Srier les problmes signifie, dans ce cas, crer une conception vitant qu'un changement intervenant sur un sous-systme ne se rpercute sur plusieurs autres soussystmes. Le vritable objectif est de rpondre aux besoins de l'application en utilisant les meilleurs moyens disponibles dans l'tat actuel de la technologie, un cot supportable pour l'application. En d'autres termes, d'tre capable d'implmenter de faon rentable les fonctionnaUts (c'est--dire les cas d'utiUsation) de l'application aujourd'hui et l'avenir. L'architecte reoit, dans cette tche, le soutien d'UML et du Processus unifi. UML dispose, en effet, de puissantes constructions permettant de formuler l'architecture, tandis que le Processus unifi

V V V J | Le Processus u n i f i de d v e l o p p e m e n t logiciel

Un processus c e n t r sur l'architecture

mm*

propose des principes et conseils sur ce qui constitue l'essence mme d'une bonne architecture. Mais, en fin de compte, mme avec l'aide de ces outils, l'architecture choisie rsulte d'un jugement fond sur l'exprience et la comptence. C'est l'architecte qui doit porter ce jugement. Lorsque, la fin de la phase d'laboration, il prsente une description de l'architecture au responsable du dveloppement, ce geste a la signification suivante : je sais, maintenant, que nous pouvons construire le systme sans rencontrer de surprises techniques majeures . Un architecte comptent puise deux types de sources. L'une est la connaissance du domaine dans lequel i l travaille : i l doit, en effet, tre parfaitement inform pour collaborer avec tous les intervenants, et non pas seulement avec les dveloppeurs. L'autre est la connaissance du dveloppement logiciel, jusqu' l'criture mme du code, car l'architecte doit communiquer l'architecture aux dveloppeurs, coordonner leurs efforts et comprendre leurs ractions. L'exprience acquise sur des systmes semblables au systme en cours de dveloppement se rvlera galement prcieuse.

section 12.6.2), alors que le modle lui-mme regroupe tous les cas d'utilisation. I l en va de mme pour la vue architecturale du modle de conception : elle a l'apparence d'un modle de conception, mais elle ne ralise que les cas d'utilisation intressants pour l'architecture. Autre raison pour laquelle i l est dlicat de prsenter un exemple de description : l'architecture n'offre d'intrt que pour les systmes rels. Or, si l'on veut ici parler d'un systme en dtail, i l faudra que ce soit un systme minuscule. Cela tant, nous allons maintennni uli liser l'exemple simple du DAB tir du chapitre 3 pour illustrer les consquences de ces vues architecturales. Nous procderons en comparant le contenu des vues et celui des modles complets du systme. La description de l'architecture s'articule en cinq sections et consacre chacune d'elles a un modle diffrent. I l y a donc une vue du modle des cas d'utilisation, une vue du modle d'analyse (qui n'est pas toujours maintenue), une vue du modle de conception, une vue du modle de dploiement et une vue du modle d'implmentation. I l n'y a pas de vue du modle des tests, car celui-ci ne joue aucun rle dans la description de l'architecture et ne sert qu' tester l'architecture de rfrence.

4.5.1 Vue architecturale du modle

des cas d'utilisation

La vue architecturale du modle des cas d'utilisation prsente les principaux acteurs et cas d'utilisation (ou scnarios de ces cas d'utilisation). Au sujet du modle des cas d'utilisation du systme de DAB, voir la section 3.3, Capture des cas d'utilisation . J^BR Vue architecturale du modle des cas d'utilisation du systme de DAB Dans l'exemple du DAB, Reti rer de l'argent est le cas d'utilisation le plus important. Sans lui, lesystmede DAB n'auraitaucun sens. Les cas d'utilisation Dposer de l'argent et Effectuer des virements entre comptes sont jugs moins importants pour le client moyen de la banque.

L'architecte occupe un poste dlicat dans l'quipe de dveloppement logiciel. I l est prfrable qu'il ne soit pas le chef de projet, car ce poste implique de nombreuses responsabilits autres que celles de l'architecture. I l faut absolument, en revanche, qu'il bnficie du soutien sans faille de la direction, la fois pour crer l'architecture et pour veiller son application. Il doit, en mme temps, faire preuve d'assez de souplesse pour accepter les retours utiles des dveloppeurs et des autres intervenants. Voil donc le portrait sommaire de l'architecte. Pour les systmes d'envergure, i l est possible qu'un seul architecte ne suffise pas ; i l pourra tre plus judicieux de dsigner un conseil d'architectes charg de dvelopper l'architecture et d'en assurer la maintenance.

La mise au point de l'architecture ncessite un temps considrable. Ce laps de temps, fix l'avance sur le planning, risque de gner certains responsables (chefs de projet), habitus voir le temps de dveloppement largement consacr l'implmentation et aux tests. Pourtant, l'exprience nous montre, l encore, que la dure totale du dveloppement dcrot nettement lorsqu'une architecture saine guide les phases plus tardives. Nous aborderons ce point dans le chapitre 5.

4.5 Enfin, une description de l'architecture !

Aprs avoir discut, dans les pages prcdentes, de ce qu'est une architecture sans en donner la moindre illustration, nous allons maintenant prsenter un exemple concret de description d'architecture. Mais i l nous faut, d'abord, expliquer la difficult de l'entreprise.

Pour dfinir l'architecture, l'architecte suggre donc de procder l'implmentation intgrale du cas d'utilisation Reti rer de l'argent pendant la phase d'laboration. Aucun autre cas d'utilisation (ou partie de cas d'utilisation) n'est estim intressant dans la perspective architecturale. (En pratique, une telle dcision serait preuve d'une grande perspicacit, mais elle , n'est l que pour servir notre propos.) La vue architecturale du modle des cas d'utilisation devra donc montrer la description complte du cas d'utilisation Retirer de l'argent.

4.5.2 Vue architecturale du modle

de conception

Rappelez-vous qu'une description d'architecture n'est qu'un extrait des modles du systme (c'est--dire qu'elle n'ajoute rien de nouveau). La premire version de la description de l'architecture est un extrait de la version des modles dont on dispose la fin de la phase d'laboration du premier cycle de vie. Comme on ne cherche pas crer une version plus lisible de ces extraits, la description de l'architecture ressemble de prs aux modles ordinaires du systme, ce qui signifie que la vue architecturale du modle des cas d'utilisation voque un modle de cas d'utilisation normal. La seule diffrence est que la vue architecturale ne contient que les cas d'utilisation pertinents sur le plan de l'architecture (voir la

La vue architecturale du modle de conception prsente les classificateurs de ce modle ayant une importance cruciale pour l'architecture : les principaux sous-systmes et interfaces, ainsi que quelques-unes des classes primordiales, essentiellement les classes actives. Cette vue expose galement la faon dont les principaux cas d'utilisation sont raliss en termes de classificateurs, c'est--dire les ralisations des cas d'utilisation. Nous retrouverons

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus c e n t r sur l'architecture

CHAPITRE 4

les classes actives dans la section 4.5.3, en voquant la vue du modle de dploiement (dans lequel les classes actives sont affectes des nuds). MWffl Vue architecturale du modle de conception du systme de DAB Dans la section 3.4.3, nous avons identifi trois classes actives : Gesti onnai re de clients, Gestionnaire de transactions et Gestionnaire de comptes (figure 4.7), qui figurent dans la vue architecturale du modle de conception. Gestionnaire de clients < Gestionnaire

sous-systme* Interface DAB Client de la banque

Retrait sous-systme Gestion des transactions Virements sous-systme Gestion des comptes

Dlivrance

K)<

->CH I

Virements Figure 4.8

Figure 4.7 Structure statique de la vue architecturale du modle de conception pour le systme de DAB. Diagramme de classes dcrivant les classes actives.

> de transactions

Gestionnaire de comptes

Dpts

Historique de DAB. Diagramme de

Structure statique de la vue architecturale du modle de conception pour le systme classes dcrivant les sous-systmes et les interfaces qui les relient.

Par ailleurs, la section 3.4.4 nous a appris l'existence de trois sous-systmes : I nterf ace du DAB, Gestion des transactions et Gestion des comptes ; voir la figure 4.8. Ces soussystmes tant ncessaires la ralisation du cas d'utilisation Reti rer de l'argent, ils sont donc signifiants sur le plan de l'architecture. Le modle de conception comprend bien d'autres sous-systmes qui ne seront pas pris en compte ici.

La structure statique ne suffit pas. Il faut galement montrer la faon dont les sous-systmes du modle de conception ralisent les cas d'utilisation signifiants pour l'architecture. Nous allons, donc, nouveau dcrire le cas d'utilisation Reti rer de l'argent, cette fois par les interactions entre sous-systmes et acteurs, comme le montre la figure 4.9 l'aide d'un diagramme de collaboration (Annexe A). Les objets des classes appartenant aux sous-systmes dialoguent les uns avec les autres pour excuter une instance de cas d'utilisation. Ces objets changent des messages, comme l'indique le diagramme. Les messages portent des noms qui spcifient, grce la notation :: , les oprations que dtiennent les interfaces des soussystmes. Par exemple : Retrait: .effectuer (montant, compte). Retrait dsigne l'interface fournie par une classe du sous-systme Gesti on des transactions.
Figure 4.9 Sous-systmes collaborant l'excution du cas d'utilisation Retirer de l'argent.

Le sous-systme Interface du DAB gre toutes les entres mises par le client de la banque et les sorties qui lui sont adresses, comme l'impression de reus et l'acceptation des commandes effectues. Le sous-systme Gesti on des comptes, quant lui, conserve toutes les informations persistantes des comptes et intervient dans toutes les transactions concernant les comptes. Enfin, le sous-systme Gestion des transacti ons contient les classes de comportement spcifique aux cas d'utilisation, notamment le comportement spcifique au cas d'utilisation Reti rer de l'argent. Dans l'exemple de la section 3.4.4, nous avions mentionn que les classes spcifiques aux cas d'utilisation se retrouvaient souvent, en fin de compte, dans diffrents sous-systmes de service : par exemple, un sous-systme de service diffrent pour chacune des classes Ret ra i t, Vi rement et Dpt du sous-systme Gesti on des transactions (n'apparaissant pas dans la figure 4.8). En fait, chaque sous-systme de service de ce type contient en gnral plusieurs classes, mais notre exemple est extrmement simple.

Client de la banque'* 5 : argent!)

1 : Identifier(montant) 2 : Retrait: effectuer 3 : Virements: : valider et (montant, compte) retirer(montant, compter*" 1 1 1 sous-systme sous-systme sous-systme sous-systme Interface Gestion des Gestion des Gestion des DAB transactions comptes 4 : Dlivrance::autoriserDl!vrance (montant) Les points suivants expliquent brivement le flot de la ralisation du cas d'utilisation Le texte en est presque identique celui de la section 3.4.1 (description de la ralisation du cas d'utilisation), mais il est ici prsent sous l'angle des sous-systmes et non sous celui des classes. Pr-condition : le client de la banque dispose d'un compte en banque oprationnel pour le

Les sous-systmes de la figure 4.8 assurent un comportement les uns par rapport aux autres par le biais d'interfaces telles que l'interface Vi rements, fournie par le sous-systme Gest i on des comptes. Les interfaces Vi rements, Retrait et Dl i vrance sont dcrites dans la section 3.4.4. Il existe galement des interfaces Vi rement, Dpts et Historique ; mais comme elles sont pas impliques dans le cas d'utilisation voqu dans cet exemple, nous n'en donnons pas d'explication.

La t u Cl ient de la banque choisit d retirer d l'argent et s'identifie auprs d l'I nterf ace du ' ce r e e e DAB, par ee pe e utilisant une carte magntique ayant u numro et u code secret. Le Cl i ent de Ta xm l n n n b a n q u e indique galement le montant d retrait et le compte partir duquel il souhaite l'effectuer. N u supposons, u os ici, que le sous-systme 1 nterf ace du DAB est e m s r d valider l'identit du client. n e ue e Interface du DABdemandeausous-systmeGestion des transactions d'effectuer le retrait. C sous-systme est charg d'effectuer toute la squence d retrait c m e u e transaction atomique, d faon que le e e om n e montant soit la fois dduit du compte et dlivr a Cl ient de la banque. u

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus c e n t r sur l'architecture

CHAPITRE 4

3. Gestion des transactionsdemandeau sous-systme Gestion des comptes d'effectuer le retrait. Le sous-systme Gestion des comptes dtermine si le montant peut ou non tre retir et, si oui, dduit la s m e du compte et renvoie un m s a e indiquant que le retrait est possible. om es g 4. Gestion des transactions autorise le sous-systme Interface du DAB dlivrer la s m e o m. 5. Interface du DAB dlivre la s m e a Cl ient de la banque. om u

Client du DAB Client du DAB Client de la banque

/

4.5.3 Vue architecturale du modle

de

dploiement

Figure 4.10 Le modle de dploiement dfinit trois nuds : Client du DAB, Serveur d'applications du DAB et Serveur de donnes du DAB.

Internet

Serveur d'applications du DAB

Le modle de dploiement dfinit l'architecture physique du systme en termes de nuds connects. Ces nuds sont des units matrielles sur lesquelles s'excutent les composants logiciels. I l est frquent que l'on sache quoi ressemblera l'architecture physique du systme avant de commencer dvelopper le systme. Les nuds et connexions peuvent alors tre modliss dans le modle de dploiement ds l'enchanement d'activits des besoins. C'est au cours de la conception que l'on dcide quelles classes seront actives, c'est--dire quelles sont celles qui seront des threads ou des processus. On dtermine galement le rle et le cycle de vie de chaque objet actif, mais aussi le mode de communication, de synchronisation et de partage des informations entre ces diffrents objets. Les objets actifs sont affects aux nuds du modle de dploiement en fonction, d'une part, des capacits de ces nuds, notamment leur capacit de traitement et la taille de leur mmoire, et, d'autre part, des caractristiques des connexions, comme leur largeur de bande ou leur disponibilit. Les nuds et connexions du modle de dploiement et l'affectation des objets actifs ces nuds peuvent tre dcrits par le biais de diagrammes de dploiement (Annexe A), qui peuvent galement indiquer la faon dont les composants excutables sont allous aux nuds. Le systme de DAB de notre exemple est distribu sur trois nuds diffrents. I f l l f l f l Vue architecturale du modle de dploiement du systme de DAB

Serveur de donnes du DAB

Une fois les nuds dfinis, il est possible de dployer dessus les fonctionnalits. Par souci de simplicit, nous dployons chaque sous-systme (voir la figure 4.8) dans son entier sur un seul nud. Le sous-systme Interface du DAB est ainsi dploy sur le nud Cl ient du DAB, le sous-systme Gestion des transactions sur le nud Serveur d'applications du DAB, et le sous-systme Gesti on des comptes sur le nud Serveur de donnes du DAB. Chaque classe active de ces sous-systmes (voir la section 3.4.4 et la figure 3.10) est donc dploye sur le nud correspondant et reprsente un processus s'excutant sur le nud. Chaque processus entretient et conserve dans son espace de processus les objets des autres classes (les classes ordinaires, non actives) du sous-systme. La figure 4.11 montre le dploiement des objets actifs. (Les objets actifs apparaissent sous
forme de rectangles entours de larges bordures.)

: Client du DAB : Gestionnaire

: Serveur d'applications du DAB : Gestionnaire de transactions

: Serveur de donnes du DAB : Gestionnaire de comptes

Le Cl i ent de la banque accde au systme par l'intermdiaire d'un nud Cl i ent du DAB, qui accde au Serveur d'applications du D B pour effectuer les transactions A (figure 4.10). Le Serveur d'applications du D B utilise, son tour, le Serveur de A donnes du DAB pour effectuer des transactions spcifiques sur, par exemple, des comptes. Ceci n'est pas seulement vrai pour le cas d'utilisation Reti rer de l'argent, que nous avons class comme signifiant pour l'architecture, mais aussi pour d'autres cas d'utilisation, tels que Dposer de l'argent ou Effectuer des virements entre comptes. Dans la section 3.4.3, nous dcrivons les classes slectionnes pour la ralisation du cas d'utilisation Retirer de l'argent.

Figure 4.11 Vue architecturale du modle de dploiement. Les classes actives du systme de DAB sont distribues entre les nuds.

Il s'agit l d'un exemple naf de distribution du systme. Dans un vritable systme, la distribution serait, videmment beaucoup plus complexe. On aurait pu, comme solution alternative ce problme, utiliser un middleware de distribution des objets tel qu'un ORB.

4.5.4 Vue architecturale du modle

d'implmentation

Le modle d'implmentation prsente une correspondance directe avec les modles de conception et de dploiement. Chaque sous-systme de service du modle de conception se traduit gnralement par un composant pour chaque type de nud sur lequel il doit tre ins-

Le Processus u n i f i de d v e l o p p e m e n t logiciel

Un processus c e n t r sur l'an liili i lun

CHAPITRE 4

tm
|

PARTIE

4.7

Rfrences
1 2 3 4 5 D A V I D GARLAN and M A R Y SHAW, Software A rchitecture: Perspectives on an Emerging Discipline, Upper Saddle River, NJ: Prentice-Hall, 1996. IVAR JACOBSON, M A R T I N GRISS, and PATRIK JONSSON, Software Reuse: Architecture, Process and Organization for Business Success, Reading, MA: Addison-Wesley, 1997. P.B. KRUCHTEN. "The 4+1 view model of architecture," IEEE 1995. Software, November

tall. Mais pas toujours. I l arrive qu'un mme composant (par exemple, un composant gestionnaire de mmoire tampon) soit instanci et excut sur plusieurs nuds. Certains langages fournissent des constructions, telles que les JavaBeans, permettant de regrouper les composants. Sinon, les classes sont rparties en fichiers de code reprsentant l'ensemble de composants choisi.

Nous avons mentionn, dans la section 3.4.5, que le sous-systme de service Gestion des retraits pouvait ventuellement tre ralis par deux composants : Retraits sur le serveur et Retraits sur le cl ient . Le composant Retraits sur le s e r v e u r pourrait implmenter la classe Retrait, tandis que le composant R e t r a i t s sur le client implmenterait une classe Mandataire de retraits. Dans notre exemple simple, ces composants n'implmenteraient chacun qu'une seule classe. Dans un vritable systme, en revanche, les sous-systmes de service comprendraient davantage de classes, si bien que chaque composant en implmenterait plusieurs.

F. BUSCHMANN, R. MEURIER, H. ROHNERT, P. SOMMERLAD, M . STAL, A System of Patterns, New York: John Wiley and Sons, 1996. ERICH GAMMA, RICHARD HELM, RALPH JOHNSON, and JOHN VLISSIDES, Design Patterns: Elments of Reusable Object-Oriented Software, Reading, MA: AddisonWesley, 1994. OMG, Inc. The Common Object Request Broker: Architecture and Spcification (CORBA), Framingham, MA. 1996. ISO/IEC International Standard 10165-4 = ITU-T Recommendation X.722. ITU-T Recommendation M.3010, Principles for a Tlcommunication Management Network. THOMAS J. MOWBRAY and RAPHAL C. M A LVEAU, CORBA Design Patterns, New York: John Wiley and Sons, 1997.

4.6 Trois concepts intressants

4,6.1 Qu'est-ce que l'architecture ?
C'est ce que l'architecte spcifie dans une description d'architecture. La description de l'architecture laisse l'architecte la matrise technique du dveloppement du systme. L'architecture logicielle s'intresse la fois aux lments structuraux significatifs du systme, tels que les sous-systmes, les classes, les composants et les nuds, et aux collaborations se produisant entre ces lments par l'intermdiaire des interfaces. Les cas d'utilisation orientent l'architecture de telle sorte que le systme offre les usages et fonctionnalits dsirs tout en satisfaisant des objectifs de performances raisonnables. Outre son exhaustivit, l'architecture doit montrer assez de souplesse pour accueillir de nouvelles fonctions et permettre la rutilisation de logiciels existants.

6 7 8 9

10 CHRISTOPHER ALEXANDER, SARA ISHIKAWA, MURRAY SILVERSTEIN, with M A X JACOBSEN, INGRID FIKSDAHI-KING, SHLOMO ANGEL, A Pattern Language: Towns, Buildings, Construction, New York: Oxford University Press, 1977.

4.6.2. Comment l'obtient-on ?

L'architecture est dveloppe de faon itrative au cours de la phase d'laboration au travers de l'expression des besoins, de l'analyse, de la conception, de l'implmentation et des tests. Les cas d'utilisation signifiants sur le plan de l'architecture, ainsi que certaines entres d'un autre type, permettent d'implmenter l'architecture de rfrence, ou squelette , du systme. Cet ensemble d'entres supplmentaires comprend les besoins logiciels du systme, les middleware, les systmes existants rutiliser, les besoins non fonctionnels, et ainsi de suite.

4.6.3 Comment la dcrit-on

La description de l'architecture est une vue des modles du systmes : modles des cas d'utilisation, d'analyse, de conception, d'implmentation et de dploiement. Elle dcrit les parties du systme qu'il est important, pour les dveloppeurs et les autres intervenants, de comprendre.

Un processus itratif et incrmental

Pour tre efficace, un processus logiciel doit comporter une squence de jalons (Annexe C) clairement articuls fournissant aux responsables et l'quipe de dveloppement les critres ncessaires au passage d'une phase l'autre du cycle de vie d'un produit. Le processus parcourt chaque phase par une srie d'itrations et d'incrments (Annexe C) qui conduisent ces critres. Dans la phase de cration, le critre essentiel est celui de la viabilit, accessible au travers des activits suivantes : l'identification et la rduction des risques (Annexe C ; voir galement la section 12.5) pesant sur la viabilit du systme ; la transformation, par le biais de la modlisation des cas d'utilisation, d'un sous-ensemble de besoins cls en une architecture candidate ; une premire estimation approximative du cot, des efforts, du calendrier de dveloppement et de la qualit du produit ; le commencement d'une tude de rentabilit (pour plus d'informations sur l'tude de rentabilit, consultez les chapitres 12 16), afin de vrifier, l encore de faon approximative, la rentabilit conomique du projet. Dans la phase d'laboration, le critre essentiel est celui de la capacit construire le systme au sein d'une infrastructure conomique, accessible au travers des activits suivantes : l'identification et la rduction des risques affectant de faon significative la construction du systme ; la spcification de la plupart des cas d'utilisation reprsentant les fonctions dvelopper ; l'extension de l'architecture candidate aux proportions d'une architecture de rfrence excutable ;

wwmm m m M

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus i t r a t i f et i n c r m e n t a l cTAPn^REJmW

la prparation d'un plan de projet (Annexe C) suffisamment dtaill pour guider la phase de construction ; la ralisation d'une estimation suffisamment prcise pour justifier le lancement d'une offre ; lafinalisationde l'tude de rentabilit : le projet vaut la peine d'tre entrepris. Dans la phase de construction, le critre essentiel est celui d'un dbut de fonctionnement du systme dans l'environnement utilisateur, critre accessible au travers des activits suivantes : une srie d'itrations menant rgulirement des constructions et des incrments, afin de dmontrer la viabilit du systme de faon excutable tout au long de cette phase. Dans la phase de transition, le critre essentiel est celui du fonctionnement complet du systme, accessible au travers des activits suivantes :

Parvenir un juste quilibre entre cas d'utilisation et architecture revient, grosso modo, harmoniser forme et fond dans le dveloppement d'un produit. Seul le temps le permet. Savoir ce qui vient en premier nous ramne, encore et toujours, au problme de l'uf et de la poule, comme nous l'avons indiqu dans la section 4.3. Ce sont d'interminables itrations, survenues au cours du long processus d'volution, qui ont donn naissance la poule et l'uf. De la mme faon, aufilde ce processus plus court qu'est le processus de dveloppement logiciel, les dveloppeurs recherchent consciencieusement cet quilibre (entre cas d'utilisation et architecture) travers une srie d'itrations. L'approche itrative-el-in< \v mentale du dveloppement constitue bien, par consquent, le troisime pivot du Processus unifi.

5.7.1 Procder

par tapes

modestes

Ce troisime aspect propose une stratgie de dveloppement d'un produit logiciel par petites tapes faciles grer : on planifie un peu ; on spcifie, on conoit et on implment un peu ; on intgre, on teste et on excute un peu chaque itration. Ds que vous tes satisfait d'une tape, vous pouvez passer la suivante. Entre deux tapes, vous obtenez des retours qui vous permettent d'ajuster votre point de vue pour l'tape suivante. Puis, vous passez une autre tape, et encore une autre. l'issue de l'ensemble des tapes prvues, vous avez mis au point un produit livrable aux clients et utilisateurs. Les itrations des premires phases cherchent essentiellement dlimiter la porte du projet, liminer les risques majeurs et esquisser l'architecture de rfrence. Puis, mesure qu'avance le projet, que sont peu peu carts les derniers risques et que sont implments les composants, la forme des itrations change et se traduit par des incrments.

la modification du produit afin d'liminer les problmes non identifis dans les phases antrieures ; la correction des anomalies (Annexe C ; voir galement la section 11.3.6). L'un des objectifs du Processus unifi est de permettre aux architectes, dveloppeurs et intervenants d'une manire gnrale de saisir l'importance des premires phases. Nous ne pouvons, en ce sens, que rappeler les conseils prodigus par Barry Boehm, i l y a dj plusieurs annes [1] : Je ne puis insister davantage sur l'importance dcisive que revt le jalon Architecture du cycle de vie (LCA) [qui correspond notre jalon definde la phase d'laboration] pour votre projet et votre carrire. Si vous ne satisfaites pas au critre du jalon LCA, inutile de poursuivre le dveloppement. Runissez nouveau les intervenants et laborez ensemble un nouveau plan de projet qui rpondra ce critre. Les phases, et les itrations qui les constituent, font l'objet d'une tude plus dtaille dans la troisime partie de l'ouvrage.

5.1 Le d v e l o p p e m e n t itratif et incrmental en bref

Un projet de dveloppement logiciel transforme un delta (ou changement) des besoins des utilisateurs en un delta (ou changement) du produit logiciel (voir la section 2.2). Avec une approche itrative et incrmentale, l'accommodation se fait petit petit. En d'autres termes, on scinde le projet en une srie de mini-projets, dont chacun constitue une itration. Chaque itration se prsente de la mme faon que n'importe quel projet de dveloppement logiciel : planification, enchanements d'activits (besoins, analyse et conception, implmentation, tests) et prparation de la version. Mais une itration n'est pas une entit totalement indpendante : c'est une tape d'un projet. Elle tire d'ailleurs beaucoup de cette appartenance un projet. Nous qualifions les itrations de mini-projets , parce qu'elles ne sont pas, en soi, ce que les intervenants nous ont demand de faire. En outre, chacun de ces mini-projets s'apparente au vieux modle en cascade, car i l met en uvre les activits de ce type de modle. On pourrait dire de chaque itration que c'est une mini-cascade . Le cycle de vie itratif livre des rsultats tangibles sous forme de versions internes (quoique prliminaires). Chacune de ces versions ajoute un incrment et prouve qu'elle a procd la

Comme nous l'avons fait remarquer dans les chapitres 3 et 4, le fait que le processus de dveloppement logiciel soit pilot par les cas d'utilisation et centr sur l'architecture constitue deux des trois aspects fondamentaux du Processus unifi. Ces aspects ont un impact technique vident sur le produit rsultant du processus. L'influence capitale qu'exercent les cas d'utilisation signifie que chaque phase conduisant la livraison finale du produit se rfre ce que font rellement les utilisateurs, ce qui permet de s'assurer que le systme rpond leurs vritables besoins. Par ailleurs, la place centrale accorde l'architecture induit une orientation du travail de dveloppement vers la ralisation d'un pattern architectural qui guidera la construction du systme ds les premires phases, et garantira ainsi une progression en douceur non seulement vers la livraison de la version en cours, mais aussi vers toute la dure de vie du produit.

11- Processus u n i f i de d v e l o p p e m e n t logiciel

fMIIII I

Un processus itratif et i n c r m e n t a l
CHAPITRE 5

rduction des risques dont elle tait charge. Ces versions peuvent tre prsentes aux clients et aux utilisateurs et susciter ainsi des retours prcieux pour la validation du travail.

ce n'est pas un phnomne ne concernant que les dveloppeurs ; ce n'est pas une tentative indfiniment renouvele jusqu' ce que les dveloppeurs tombent par hasard sur quelque chose qui fonctionne ; ce n'est pas un processus imprvisible ; ce n'est pas une excuse pour l'absence de plan et une gestion inexistante. En fait, l'itration contrle est loin d'tre excute au hasard. Elle est planifie. C'est un outil qui permet aux responsables de matriser le projet. Elle permet de rduire, ds les premiers stades du cycle de vie, les risques susceptibles de menacer la progression du dveloppement. A l'issue des itrations, les versions internes (Annexe C) ouvrent la voie aux retours des intervenants, qui permettent, leur tour, de rectifier trs tt l'orientation du projet.

Les personnes charges de la planification tentent d'ordonner les itrations de faon tracer une voie directe entre itrations et de permettre chacune d'entre elles d'exploiter la base de connaissances que constituent les itrations prcdentes. Les premires itrations du projet dvoilent un pan inexplor des besoins, des problmes, des risques et du domaine de la solution (Annexe C), tandis que les itrations plus tardives se traduisent par des incrments successifs qui finissent par constituer la version externe (Annexe C), c'est--dire le produit destin au client. La vritable russite, pour les planificateurs, c'est de parvenir une squence d'itrations en perptuelle avance : ne jamais avoir revenir en arrire pour colmater le modle aprs avoir appris quelque chose de nouveau au cours d'une itration ultrieure. L'ide, en somme, c'est d'viter de grimper le long des parois d'un monticule de neige fondue : deux pas en avant, une glissade en arrire.

5.2 Pourquoi un d v e l o p p e m e n t itratif et incrmental ?

La rponse tient en quatre mots : pour de meilleurs logiciels. En une phrase, pour atteindre les jalons majeurs et mineurs qui permettent de matriser le dveloppement. Enfin, pour tre un peu plus prcis : pour prendre en main trs tt les risques importants ; pour proposer une architecture qui guidera le dveloppement logiciel ; pour fournir une infrastructure prfabrique (framework) capable de mieux prendre en compte les exigences incontournables et les autres changements ; pour laborer progressivement le systme, de faon incrmentale, au lieu de tout faire d'un coup, vers la fin, lorsque les changements cotent cher ; pour offrir un processus de dveloppement favorisant la productivit de l'quipe.

En rsum, un cycle de vie se compose d'une squence d'itrations. Certaines, en particulier les premires, aident apprhender les risques, tablir la faisabilit du projet, construire le noyau initial du logiciel et laborer l'tude de rentabilit. Les autres, notamment les plus tardives, ajoutent des incrments jusqu' ce que l'on parvienne un produit livrable au client. Les itrations contribuent la planification, l'organisation, la surveillance et au contrle du projet. Rparties dans les quatre phases du dveloppement, elles prsentent chacune leurs propres besoins en termes de ressources humaines, de financement, de calendrier et de critres d'entre et de sortie. Au dbut de chaque phase, les responsables peuvent dcider du mode d'excution de chaque itration, des rsultats qu'elle devra livrer et des risques qu'elle devra attnuer.

!> 1.2 Ce que n'est pas une

itration

Certains responsables pensent que l'expression itratif ou incrmental est un charmant euphmisme pour bidouillage . Es craignent que les mots ne servent qu' jeter un voile pudique sur le fait que les dveloppeurs ne savent pas ce qu'ils font. On peut concder, dans la phase de cration et mme au dbut de la phase d'laboration, que cette crainte n'est pas totalement dnue de fondement. Si, par exemple, les dveloppeurs n'ont pas rsolu les risques majeurs ou significatifs, i l faut alors reconnatre que cette position se dfend. S'ils n'ont pas encore dmontr la viabilit du concept sous-jacent, ni tabli une architecture de rfrence, l encore, cette affirmation est exacte. Si, enfin, ils n'ont toujours pas dtermin de quelle faon implmenter les besoins dcisifs, i l faut nouveau se rendre l'vidence. I l est possible, somme toute, qu'ils ne sachent pas ce qu'ils font. Est-il alors judicieux de prtendre qu'ils savent quand mme ce qu'ils font ? De faire reposer un plan sur des informations insuffisantes ? De suivre un plan auquel on ne pourra se fier ? Bien sr que non. titre indicatif, insistons sur ce que n'est pas un cycle de vie itratif : ce n'est pas un bidouillage de fortune ; ce n'est pas une attraction pour dveloppeurs ;

5.2.1 Rduire

les risques

Comme toute autre activit d'ingnierie, le dveloppement logiciel est soumis des risques. Le risque est inhrent l'engagement de ressources actuelles vers des attentes futures , selon le prophte du management Peter F. Drucker [2]. Dans le dveloppement logiciel, on s'accommode de cette ralit en identifiant les risques ds que l'on peut et en les traitant le plus tt possible. Un risque est une exposition pouvant conduire une perte ou un dommage. Le risque est un facteur, un phnomne, un lment ou une volution constituant un danger dont le degr reste incertain. En matire de dveloppement logiciel, on peut dfinir un risque comme un problme ayant quelque probabilit de compromettre la russite d'un projet. Par exemple : i l est possible que l'ORB (Object Request Broker) (Annexe C) initialement prvu ne soit pas en mesure de grer 1 000 recherches distantes la seconde d'objets de comptes clients ; i l est possible qu'un systme temps rel doive acqurir des donnes d'entre dont le volume n'a pas t spcifi dans la phase de cration. I l est galement possible qu'il ait traiter les donnes par d'importants calculs qui, toutefois, ne sont pas expliqus en dtails.

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus itratif et i n c r m e n t a l
CHAPITRE 5

Cascade

Cration

Priode d'intgration et de tests de l'approche / en cascade

Gravit des risques

Itratif, incrmental

^Construction

Il est possible, enfin, qu'il ait mettre un signal de commande dans un laps de temps court, mais non prcis ; il est possible qu'un systme de commutation tlphonique ait rpondre diverses entres en un nombre de millisecondes spcifi par l'oprateur de tlcommunications client. Ce qu'il faut au domaine logiciel, crivait Barry Boehm i l y a de nombreuses annes, c'est un modle de processus capable de crer une approche du processus logiciel oriente vers la rduction des risques, au lieu d'un processus essentiellement guid par la production documents ou la cration de code [3]. Le Processus unifi satisfait ces critres en traitant les principaux risques dans les deux premires phases, celles de cration et d'laboration, et tous les autres risques par ordre d'importance, ds le dbut de la phase de construction. I l permet d'identifier, de grer et de rduire les risques ds les premires phases au moyen des itrations. Ce qui vite le surgissement tardif de risques non identifis ou ignors de nature menacer tout le projet.

iter.
#n-1

iter.

Figure 5.1 Les risques graves sont identifis et rduits trs tt dans le dveloppement itratif, contrairement ce qui se passe dans le dveloppement en cascade. L, les risques les plus srieux persistent jusqu ' ce qu 'ils soient traits par l'intgration et les tests du systme (ligne pointille). Les itrations indiques au bas de la figure ne sont, videmment, pertinentes que pour l'approche itrative et incrmentale.

Temps

Selon Capers Jones, environ les deux tiers des grands projets logiciels ne parviennent pas valuer correctement les risques. I l reste donc du pain sur la planche ! La premire tape consiste s'attaquer aux risques trs tt dans le processus de dveloppement.

L'approche itrative de la rduction des risques n'a qu'une trs lointaine parent avec l'approche en cascade (Annexe C). Le modle en cascade montre le droulement du dveloppement dans une seule direction, travers une srie d'tapes : besoins, analyse, conception, implmentation et tests. Cette approche mobilisait tous les dveloppeurs du projet au moment de l'implmentation, de l'intgration (Annexe C) et des tests. Et c'est au cours de l'intgration et des tests que les problmes commenaient fuser de toutes parts. Le chef de projet tait alors oblig de raffecter certains membres de l'quipe (en gnral, les dveloppeurs les plus chevronns) pour qu'ils rsolvent ces problmes avant que le travail puisse reprendre son cours. Mais, i l paraissait dlicat, alors que les dveloppeurs taient dj tous occups, de dgager les plus comptents d'entre eux pour traiter les problmes nouvellement identifis. En plus, pour aggraver la situation, la raffectation des dveloppeurs les plus expriments aux tches de nettoyage entranait souvent l'immobilisation des dveloppeurs moins qualifis qui n'avaient plus qu' attendre, assis sur leur chaise. Les dlais arrivaient chance, les cots s'accumulaient. Dans le pire des cas, la concurrence arrivait en premier sur le march. Si l'on dessine le trac de l'apparition des risques par rapport au stade du dveloppement, comme dans la figure 5.1, on s'aperoit que le dveloppement itratif commence rduire les risques les plus graves ds les premires itrations. Quand arrive le moment de la construction, i l reste peu de risques srieux et le travail peut se poursuivre en toute quitude. Avec l'approche en cascade, en revanche, les risques srieux ne sont pas traits avant le big bang de l'intgration du code.

5.2.2 Obtenir une architecture robuste

La mise en place d'une architecture robuste est, en soi, le rsultat des itrations menes dans les premires phases du dveloppement. Dans la phase de cration, par exemple, on cherche laborer une architecture de base capable de satisfaire aux exigences majeures, de surmonter les risques dcisifs et de rsoudre les principaux problmes du dveloppement. L'investissement consenti dans ces phases reste modeste et l'on peut se permettre d'effectuer ces itrations pour s'assurer de la solidit de l'architecture. Par exemple, on se trouve, aprs la premire itration de la phase d'laboration, en mesure de faire une premire valuation de l'architecture. A ce moment-l, i l est toujours temps de modifier cette architecture, si besoin est, pour rpondre aux besoins des principaux cas d'utilisation et aux exigences non fonctionnelles. Si l'on suit l'approche en cascade, au moment o l'on dcouvre qu'il est ncessaire de modifier l'architecture, les efforts engags dans le dveloppement sont dj tels que le moindre changement entrane une lourde sanction financire. En plus, on se trouve, ce moment-l, tout prs de la date de livraison prvue. cartel entre cots et dlais, il est probable qu'on hsitera se lancer dans une rorientation architecturale majeure. La prpondrance accorde l'architecture ds la phase d'laboration permet d'viter ce genre de dilemme. On stabilise ainsi l'architecture un niveau de rfrence trs tt dans le cycle de vie, lorsque les cots sont encore faibles et que les dlais de livraison restent un horizon lointain.

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus itratif et i n c r m e n t a l

5.2.3 Grer les exigences de changement

Une fois que l'quipe d'assurance qualit a test une itration, les chefs de projet, architectes et autres intervenants peuvent l'valuer en fonction de critres prdfinis. Ils dterminent si l'itration a, ou non, produit l'incrment voulu et si les risques ont, ou non, t correctement traits. Cette valuation permet aux responsables d'estimer la russite ou l'chec de l'itration. Si c'est un succs, ils peuvent autoriser le passage l'itration suivante. Si l'itration n'est que partiellement russie, ils peuvent la prolonger ou diffrer les questions non rsolues et le travail de fignolage l'itration suivante. Dans le cas extrme o l'valuation serait totalement ngative, il reste possible d'annuler tout le projet.

5.2.5 Parvenir une intgration

continue

Les utilisateurs ont plus de facilit comprendre un systme qui fonctionne, mme s'il ne fonctionne pas parfaitement, qu'un systme qui n'existe que sur le papier. De la mme faon, ils ont du mal admettre la progression d'un projet si l'on n'a rien d'autre leur prsenter que des documents crits. Du point de vue des utilisateurs et des autres intervenants, i l est donc plus productif de faire voluer le produit travers une srie de versions excutables, ou constructions , que de prsenter des piles de documentation sibylline. Une construction est une version oprationnelle d'une partie d'un systme faisant la dmonstration d'un sous-ensemble des fonctions du systme. Chaque itration peut procder par une srie de constructions pour approcher du rsultat prvu, c'est--dire de l'incrment. Le fait de disposer d'un systme en tat de fonctionnement partiel ds les premires phases permet aux utilisateurs et aux autres intervenants de suggrer des amliorations et de signaler des besoins ayant pu tre ngligs. Le plan (budget et calendrier) n'tant, ce moment-l, pas encore grav dans le marbre, les dveloppeurs peuvent plus facilement prendre en compte les rvisions. Dans le modle en cascade sens unique, les utilisateurs ne voient aucun systme en tat de marche avant l'intgration et les tests. A ce stade, les changements, mme ceux qui ont de l'importance ou ceux pouvant paratre modestes, entranent presque invitablement des rallonges budgtaires et temporelles. Le cycle de vie itratif permet donc aux utilisateurs de dtecter plus tt dans le cycle de dveloppement la ncessit d'ajouter ou de modifier des exigences, et aux dveloppeurs de les intgrer. En fin de compte, l'laboration du systme se faisant par une srie d'itrations, la prise en compte des remarques et l'intgration des rvisions ne reprsentent gure qu'un changement incrmental.

l'issue de chaque itration, l'quipe du projet dmontre qu'elle a procd la rduction de certains risques et livre un nombre croissant de fonctions aux intervenants, qui peuvent ainsi constater l'volution du projet.

5.2.4 Permettre des changements tactiques

L'approche itrative et incrmentale permet aux dveloppeurs de rsoudre les problmes et les questions soulevs par les premires constructions et d'intgrer les changements afin de les corriger presque immdiatement. Grce cette approche, les problmes sont rgulirement mis au jour, un rythme que les dveloppeurs n'prouvent aucune difficult soutenir. l'inverse, l'avalanche de rapports d'anomalies qui s'abat au moment du big bang de l'intgration dans l'approche en cascade a souvent pour effet de dsorganiser la progression du projet. Dsorganisation qui peut aller jusqu' l'interruption pure et simple du projet : les dveloppeurs ploient sous la pression, les chefs de projet se rongent les sangs et les autres responsables sont pris de panique. Une srie de constructions oprationnelles, l'inverse, procure chacun un agrable sentiment d'accomplissement. Les testeurs, rdacteurs de manuels, dveloppeurs d'outils, membres des quipes de gestion de configuration et d'assurance qualit peuvent adapter leur propre planning l'volution du calendrier du projet. Ils sont avertis trs tt des retards prvus, au moment mme o les dveloppeurs rencontrent les problmes qui les susciteront, ce qui leur laisse le temps d'adapter leur planning. En revanche, lorsque les problmes restent dissimuls jusqu'aux tests, il est trop tard pour se rorganiser de faon efficace.

La livraison frquente de constructions oblige les dveloppeurs conclure rgulirement leur travail par une partie de logiciel excutable. I l devient difficile, dans ces conditions, de soutenir mordicus que le projet est 90% termin . On rencontre ce genre d'optimisme exagr lorsque le dcompte des lignes de code ou des artefacts produits (Annexe C) laisse entrevoir que le produit est presque termin. En l'absence de constructions utilisables, il est parfaitement possible que la tche la plus ardue reste venir. D n'est pas exclu que certains problmes n'aient pas encore t rvls par des tentatives d'intgration et de test du systme. A l'inverse, tant donn que les itrations successives fonctionnent, elles produisent des rsultats indiquant trs prcisment l'tat d'avancement du projet. Mme si les dveloppeurs n'atteignent pas les rsultats escompts dans les premires itrations, il leur reste suffisamment de temps pour ressayer et amliorer les modles dans les versions internes suivantes. Le fait de travailler d'abord sur les problmes les plus dlicats leur donne maintes occasions d'amliorer les solutions proposes. La ligne paisse de la figure 5.2 (prsente l'origine dans [5]) illustre le fonctionnement du dveloppement itratif. Un incrment (ou construction) est assembl ds les premiers stades du calendrier, alors que seuls 2 4% du projet sont ici cods. Cette tentative fait apparatre certains problmes, indiqus par les petits creux de la ligne de progression, mais qui sont rapidement surmonts et n'empchent donc pas la reprise de la progression. partir de l, le projet cre de frquentes constructions, chacune pouvant mener une interruption temporaire du projet. Les incrments tant relativement modestes par rapport l'intgration finale du produit entier (sur la ligne du bas), la rcupration peut tre assez rapide.

>

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus i t r a t i f et i n c r m e n t a l

Tests finals de q u a l i t j D b u t de l'intgration de l'approche en cascade

vite leur retard. Si certains de ces nouveaux collaborateurs ont du mal comprendre un point particulier ou s'ils commettent une erreur, celle-ci ne met pas en pril la progression long terme du projet, puisqu'elle apparat ds la tentative de construction suivante. L'approche itrative aide aussi la prise en charge des risques non techniques, tels que les problmes d'organisation. I l est possible, par exemple, que les dveloppeurs n'apprennent pas assez vite : construire des applications l'aide d'un ORB ; utiliser les outils de test ou de gestion de configuration (Annexe C) ;

Progression (% c o d ) 1009080706050403020-

construction.' construction \j,''

'construction

Dveloppement en cascade

Rupture tardive de la conception,

se conformer au processus de dveloppement logiciel.

construction 10V
10

Dveloppement itratif
20 25 30 35 40 45

Au fil des itrations, une petite quipe se familiarise avec ces nouvelles technologies, outils et processus, les utilise de plus en plus frquemment et gagne en comptence. mesure que le projet avance, l'quipe s'toffe et peut ainsi passer de 5 10 personnes, puis 25 et finalement une centaine. Grce cette volution mesure, le noyau dur de l'quipe peut guider les nouveaux venus au rythme de leur arrive. L'approche itrative permet l'quipe d'origine d'optimiser le processus et les outils avant que la masse des dveloppeurs ne se joignent eux. En travaillant par phases et par itrations, les dveloppeurs ont de meilleures chances de satisfaire aux besoins rels des clients et de rduire les risques. La construction d'incrments permet chacun d'observer son niveau de progression, tandis que la rduction des difficults tardives raccourcit le dlai de mise sur le march. Enfin, cette approche itrative bnficie non seulement aux dveloppeurs et, en fin de compte, aux utilisateurs, mais galement leurs responsables. Ceux-ci peuvent, en effet, prendre la mesure des vritables progrs en prenant acte des itrations acheves.

Temps (mois) Figure 5.2 Dans l'approche en cascade (ligne claire), les dveloppeurs ne dbutent pas l'implmentation avant d'avoir finalis l'expression des besoins, l'analyse et la conception. Les problmes demeurent, un niveau trs bas jusqu' l'intgration et aux tests qui les rvlent en bloc (Rupture tardive de la conception). Dans le dveloppement itratif, l'implmentation dbute plus tt et les constructions frquentes permettent de mettre au jour trs tt les problmes.

Dans l'approche en cascade, comme le suggre le diagramme, c'est une intgration unique proche de la date de livraison qui rvle une pliade de problmes. L'ampleur des problmes et l'invitable prcipitation qui rgne ce stade signifient que la plupart des corrections ne seront pas srieusement prpares. La dcouverte des problmes et leur correction diffrent souvent la livraison au-del de la date prvue. Ce qui revient dire que le dveloppement itratif prend, enfinde compte, moins de temps que le dveloppement en cascade. En plus, le produit issu d'un projet en cascade risque d'tre fragile, c'est--dire difficile maintenir.

5.3 L'approche itrative est guide par la rduction des risques

Un risque est une variable d'un projet qui met en danger, voire compromet totalement, la russite du projet en question. C'est la probabilit selon laquelle un projet peut tre confront des vnements indsirables, comme des retards de calendrier, des dpassements de budget ou une annulation pure et simple (voir le glossaire dans [4]).

5.2.6 Accder

trs tt la connaissance

Aprs une ou deux itrations, tous les membres de l'quipe se font une ide assez claire de la nature des diffrents enchanements d'activits. Ils savent ce qui vient aprs la phase d'expression des besoins et ce qui suit l'analyse. Le risque de paralysie dans l'analyse (trop de temps consacr l'analyse) est largement attnu. L'intgration de nouveaux collaborateurs est, en outre, facilite puisque ceux-ci peuvent tre forms sur le tas. Il n'est plus ncessaire d'laborer des pilotes dans le simple but d'aider les membres de l'quipe comprendre l'articulation du processus. Ils entrent tout de suite dans le vif du sujet en se livrant des tches directement lies au projet. A condition qu'ils reoivent la formation adquate et qu'ils soient entours de personnes exprimentes, ils rattraperont

Les itrations sont identifies, hirarchises et menes en fonction des risques et de leur ordre d'importance. Ceci est vrai lorsqu'on value de nouvelles technologies. Ceci est encore vrai lorsqu'on uvre la satisfaction des besoins, fonctionnels ou non, des clients. Ceci est toujours vrai quand, dans les premires phases, on tablit une architecture qui sera robuste, c'est--dire capable de faire face aux changements avec peu de risques d'avoir reconcevoir quoi que ce soit. Oui, on organise les itrations de faon rduire au maximum les risques. D'autres risques relvent des performances (vitesse, capacit, prcision), de la fiabilit, de la disponibilit, de l'intgrit de l'interface du systme, de l'adaptabilit et de la portabilit (Annexe C). Nombre de ces risques n'apparaissent pas tant que le logiciel mettant en uvre

I o Processus u n i f i de d v e l o p p e m e n t logiciel
rMIIII I

Un processus itratif et i n c r m e n t a l
CHAPITRE 5

les fonctions sous-jacentes n'a pas t implment et test. C'est pourquoi il est ncessaire tic mener des itrations d'exploration des risques tout au long du dveloppement jusqu'au codage et aux tests, et mme dans les phases de cration et d'laboration. L'objectif est d'pingler le risque le plus tt possible. Il est intressant de constater que, en principe, tous les risques techniques peuvent tre relis un cas d'utilisation ou un scnario d'un cas d'utilisation. Ici, relis signifie que le risque est attnu si le cas d'utilisation est ralis avec ses besoins fonctionnels et non fonctionnels. ( 'ette observation ne s'avre pas seulement pour les risques relevant des besoins ou de l'architecture, mais aussi pour la vrification du matriel et des logiciels sous-jacents. Une slection attentive des cas d'utilisation permet de tester toutes les fonctions de l'architecture sous-jacente. I .a rduction des risques est cruciale pour les itrations menes dans les phases de cration et d'laboration. Dans la phase plus tardive de construction, les risques ont, dans l'ensemble, t ramens un niveau normal, ce qui signifie qu'ils donnent lieu des pratiques de dveloppement ordinaires. Les itrations doivent, si possible, tre ordonnes de telle sorte que chacune se nourrisse de celle qui prcde. Dans cette phase, on essaie, en particulier, d'viter d'avoir reprendre plusieurs itrations dans le cas o leur ordre n'ait pas t judicieusement tabli.

les cas d'utilisation initialement slectionns n'aident pas trouver la structure de soussystmes capable de faire voluer le systme par l'intgration de cas d'utilisation plus tardifs. Dans les premires itrations, disons dans la phase d'laboration, nous n'avons peut-tre pas remarqu que plusieurs acteurs allaient utiliser le mme cas d'utilisation par le biais d'interfaces diffrentes. On trouvera un exemple de ce type de situation avec la prsence de plusieurs interfaces pour le retrait d'argent liquide : la premire emploie une interface utilisateur graphique et un ordinateur personnel ; la seconde un protocole de communication sur un rseau. Si l'on ne prvoit, dans la conception, que de rpondre l'un de ces deux cas d'utilisation, il est fort possible que l'on se retrouve avec une architecture n'ayant pas d'interface interne permettant d'ajouter de nouveaux types d'interaction. On court le risque qu'un tel systme soit difficile faire voluer ; certaines infrastructures prfabriques (frameworks) (Annexe C) prvues pour tre rutilises n'ont jamais t utilises en dehors du projet sur lequel elles avaient t construites. Une infrastructure de ce type risque de ne pas fonctionner correctement avec d'autres infrastructures, ou alors sa rutilisation ne sera pas des plus simples ; i l est possible que la nouvelle version du systme d'exploitation que l'on prvoit d'utiliser n'ait pas atteint un niveau de qualit suffisant pour tre parfaitement fiable. Le risque auquel on s'expose alors est d'avoir retarder la livraison de son propre logiciel en attendant la mise niveau du systme d'exploitation.

5.3.1 Les itrations

attnuent

les risques techniques

Les risques ont fait l'objet de nombreuses classifications (voir [3] et [4]). I I suffira, pour notre propos, de suggrer quelques pistes sans prtendre l'exhaustivit. Nous avons, pour notre part, identifi quatre grandes catgories de risques. 1. Les risques lis aux nouvelles technologies : i l peut tre ncessaire de rpartir les processus sur un grand nombre de nuds, ce qui risque de crer des problmes de synchronisation ; i l est possible que certains cas d'utilisation dpendent de techniques de calcul qui ne sont pas encore tout fait au point, comme la reconnaissance du langage naturel ou l'utilisation de la technologie du Web.

3. Les risques lis la construction du systme attendu, c'est--dire d'un systme capable de prendre en charge la mission qui lui est confie et d'assister les utilisateurs qui l'emploieront. Ce type de risque souligne l'importance de l'identification des besoins fonctionnels et non fonctionnels, qui revient essentiellement trouver les bons cas d'utilisation et les bonnes interfaces. Il est fondamental de dterminer trs tt quelles sont les fonctions les plus importantes et de s'assurer qu'elles sont rapidement implmentes. Nous classons ici les cas d'utilisation par ordre d'importance pour la satisfaction des besoins des clients et des exigences de performances. Nous considrons la fois le comportement et les capacits telles que les performances. L'ordre dans lequel sont traits les cas d'utilisation, au moment de leur slection, est fonction du degr et du type de risque qu'ils prsentent : par exemple, la possibilit de risques entrans par l'excution mme du cas d'utilisation. Il existe, en particulier dans les phases de cration et d'laboration, une corrlation troite entre certains besoins (et les cas d'utilisation qui les expriment) et les risques qu'ils comportent. Les cas d'utilisation que slectionne l'quipe ont un impact sur l'architecture qu'ils dveloppent. Par exemple : le cas d'utilisation Transfert d'appel s permet un abonn au tlphone de basculer ses appels sur un autre numro. Cette redirection doit-elle s'appliquer tous les appels ? Qu'en est-il d'un appel de rveil ? L'abonn sera probablement sur le lieu de son numro habituel et ne souhaitera pas que l'appel soit redirig. 4. Certains risques sont lis aux performances. Par exemple : le temps de rponse d'un cas d'utilisation doit tre infrieur une seconde ; le nombre d'instances de cas d'utilisation concurrentes dpasse 10 000 par jour.

2. Les risques lis l'architecture. Ces risques sont tellement importants que c'est pour standardiser leur rsolution que nous avons conu le Processus unifi. En effet, la phase d'laboration du Processus et les itrations architecturales qui la composent prvoient une place explicite pour les prendre en compte. La mise en place, trs tt, d'une architecture souple (risk-accommodative) permet d'vacuer le risque de ne pas pouvoir facilement prendre en compte les changements. On limine ainsi le risque d'avoir, plus tard, refaire une bonne partie du travail. Cette architecture rsistante aux risques est robuste. La prise en charge fluide des changements est caractristique de la robustesse architecturale (Annexe C). L'autre avantage de disposer trs tt d'une architecture solide est d'indiquer les possibilits d'intgration de composants rutilisables, ce qui permet assez vite d'envisager d'avoir recours des produits du commerce, plutt que de les fabriquer. Cela vite galement de dcouvrir trop tard qu'un systme sera trop cher construire. Par exemple :

Le Processus u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

Un processus itratif et i n c r m e n t a l
CHAPITRE 5

L'identification de zones de problmes telles que celles-ci dpend largement de l'exprience. Personne ne pouvant srieusement prtendre disposer de toute l'exprience ncessaire, i l faut qu'un petit groupe d'individus examinent le systme propos, dressent des listes de problmes susceptibles de se produire et se rendent ensemble aux runions d'identification des risques. Ces runions ne sont pas destines rsoudre les problmes, mais simplement les identifier et tablir l'ordre dans lequel ils seront tudis plus en dtail, lors des itrations des phases de cration et d'laboration.

l'quipe doit appliquer ses plans de secours (Annexe C). Si l'on se retrouve face un tueur de projet , on prend d'abord une grande respiration, puis on examine calmement la situation. Faut-il poursuivre ou abandonner le projet ? ce stade, l'investissement temporel etfinancierreste encore timide. Lerisqued'apparition d'un tueur de projet tait connu, ce qui explique que l'on ait men des itrations tt dans le dveloppement. On peut,finalement,se rjouir d'avoir dtect un risque d'une telle ampleur avant d'impliquer tous les dveloppeurs dans le projet.

5.3.2 Les responsables ont la charge des risques non techniques

Les risques non techniques sont ceux qu'une direction perspicace est en mesure de dtecter et d'carter. Les exemples suivants entrent dans cette catgorie : le service manque de personnel ayant de l'exprience sur certains aspects inhabituels du projet ; les membres du service envisagent d'implmenter certaines parties du systme propos dans un langage qu'ils dcouvrent seulement ; le calendrier propos par le client semble trop serr et ne pourra tre tenu que si chaque tape se droule sans le moindre problme ; le respect du calendrier propos est conditionn par la livraison, aux dates prvues, de sous-systmes dvelopps par des sous-traitants utiliss pour la premire fois ; r i l est possible que le client ne puisse pas toujours donner son approbation dans les dlais ncessaires pour pouvoir livrer en temps et en heure. Les risques de ce type dpassent le cadre de cet ouvrage. Il est suffisant, ici, d'indiquer que le service logiciel doit les identifier, mettre en place les moyens administratifs de suivre les dveloppements dans chaque zone de risque et s'assurer que les responsables entreprennent les actions ncessaires lorsque l'un de ses risques se matrialise.

Il faut du temps pour traiter un risque. La solution de l'vitement ou du confinement exige une rvision du planning ou du travail dj effectu, tandis que la rduction peut ncessiter la construction d'un lment permettant de mettre au jour ce risque. La surveillance, enfin, suppose le choix, l'installation et l'excution d'un mcanisme appropri. Ces deux dernirei options (la rduction et la surveillance) exigent, l'une et l'autre, un vritable effort de dve loppement, c'est--dire du temps. Le traitement des risques rclame du temps ; or, il esl rare que l'quipe d'un projet puisse traiter tous les risques la fois. I l est, par consquent, pri mordial de hirarchiser les itrations. C'est ce que nous entendons par dveloppement itratif guid par la rduction des risques . Une gestion saine des risques, en somme.

5.4 L'itration g n r i q u e
Comme nous l'avons vu, les itrations se distinguent nettement les unes des autres dans les diffrentes phases du dveloppement, tout simplement parce les dfis auxquels sont confronts les dveloppeurs diffrent dans chaque phase. Notre propos, dans cette section, est de prsenter le concept d'itration un niveau gnrique : qu'est-ce qu'une itration ? Comment la prvoit-on ? Comment est-elle squence ? Quel rsultat produit-elle ? Dans la troisime partie de l'ouvrage, les itrations de chacune des quatre phases font l'objet de chapitres spars.

5.3.3 Traiter les risques

Une fois les risques identifis et hirarchiss, l'quipe doit dcider du traitement appliquer chacun d'entre eux. I l y a, en gros, quatre attitudes possibles : l'vitement, le confinement, la rduction ou la surveillance. Certainsrisquespeuvent et doivent tre vits, par exemple en rvisant la planification du projet ou en modifiant les exigences. D'autres risques doivent tre confins, c'est--dire que leur porte doit tre rduite de faon n'affecter qu'une petite partie du projet ou du systme. Il est possible de rduire certains risques en essayant de voir s'ils se matrialisent ou s'ils disparaissent. L'avantage, si un risque se matrialise, c'est que l'quipe en sait plus son sujet. Elle est alors plus mme de trouver un moyen de l'viter, de le confiner ou de le surveiller. Certainsrisques,toutefois, sont rebelles toute tentative de rduction. L'quipe n'a plus, ds lors, qu' les surveiller et regarder s'ils se matrialisent. Dans une telle hypothse,

5.4.1 Qu'est-ce qu'une itration

Une itration est un mini-projet, c'est--dire un droulement plus ou moins complet des principaux enchanements d'activits, aboutissant une version livre en interne. Cette dfinition donne une comprhension intuitive de ce qu'est une itration. I l nous faut maintenant l'approfondir pour dcrire le travail qui s'effectue vritablement au cours d'une itration et ne pas rester la surface.

On peut se reprsenter une itration comme un enchanement d'activits, c'est--dire une collaboration entre travailleurs (Annexe C) utilisant et produisant des artefacts. Dans te Pro cessus unifi, nous faisons la distinction entre enchanement d'activits principal et enchanement d'activits d'itration (Annexe C). Les cinq enchanements d'activits principaux nous sont dsormais familiers : besoins, analyse, conception, implmentation et tests. Leur prsence n'obit, en fait, qu' des raisons strictement pdagogiques, afin de nous aider dcrire les enchanements d'activits des itrations. I l n'y a donc rien de magique dans ce qui constitue un enchanement d'activits principal ; on aurait aussi bien pu utiliser un autre ensemble d'enchanements d'activits principaux, comme celui qu'intgrent l'analyse et la conception . Cet enchanement principal simplifie la description d'enchanements d'acti1

Le P r o c e s s u s u n i f i de d v e l o p p e m e n t logiciel
PARTIE I

___

Un processus i t r a t i f et i n c r m e n t a l mm

cTtATnmWwk
Chaque itration fait l'objet d'une valuation, son terme. L'un des objectifs de cette valuation consiste dterminer si de nouveaux besoins sont apparus ou si des besoins existants ont subi des modifications susceptibles d'affecter les itrations ultrieures. La planification des dtails de l'itration suivante inclut galement l'tude de l'impact que peuvent avoir les risques subsistants sur la suite du travail. Il est ncessaire, ce stade, d'insister particulirement sur la fonction des tests de nonrgression (Annexe C). Avant de terminer une itration, i l faut s'assurer qu'aucune partie du systme qui fonctionnait dans les itrations prcdentes n'a t endommage. Les tests de non-rgression revtent une importance dcisive dans un cycle de vie itratif et incrmental, car chaque itration produit un rsultat substantiel s'ajoutant l'incrment prcduii n entrane un certain nombre de changements. Notons qu'il est malais de procder tics testa de non-rgression une telle chelle (chaque construction de chaque itration) sans dispose] d'outils adquats. Les chefs de projet ne doivent pas donner le feu vert l'itration suivante avant qu'aient t atteints les objectifs de l'itration en cours. Si ce n'est pas le cas, le plan devra tre modifi pour prendre en compte la nouvelle situation.

vits plus concrets, de la mme faon qu'une classe abstraite aide la description de classes concrtes. Ces enchanements plus concrets sont les enchanements d'activits des itrations. Les enchanements principaux sont traits en dtail dans les chapitres 6 11 et servent la description des enchanements d'activits des itrations, objet des chapitres 12 16. ^ Besoins ^ ^ Analyse ^ ^ Conception ^ ^ Implmentatio^ ^ Tests ^

Figure 5.3 Chaque itration parcourt les cinq enchanements d'activits principaux. Elle dbute par une activit de planification et s'achve par une valuation.

Une itration

C m r n en plus : o pe d la planification de l'itration et l'valuation de l'itration et quelques activits spcifiques

La figure 5.3 dcrit les lments gnriques de chaque enchanement d'activits d'une itration. Les itrations parcourent les cinq enchanements d'activits principaux, dbutent par une activit de planification et s'achvent par une valuation. Nous dcrivons, dans la troisime partie de l'ouvrage, quatre archtypes d'itration, un pour chaque phase du Processus unifi. Chaque type d'itration rutilise sa faon les descriptions des enchanements d'activits principaux. Quelle est donc la diffrence avec un classique modle en cascade ? Chaque enchanement d'activits principal est une collaboration entre un ensemble de travailleurs et d'artefacts. Mais on constate des chevauchements entre itrations. Des travailleurs et des artefacts peuvent, en effet, collaborer plusieurs enchanements d'activits principaux. Par exemple, l'ingnieur de composants participe trois enchanements d'activits : ceux de l'analyse, de la conception et de l'implmentation. Enfinde compte, l'enchanement des activits de l'itration se cre par la superposition d'un sous-ensemble choisi d'enchanements d'activits principaux, auquel s'ajoutent des lments supplmentaires comme la planification et l'valuation. Les premires itrations s'attachent la comprhension du problme et de la technologie. Dans la phase de cration, les itrations visent produire une tude de rentabilit , tandis que les itrations de la phase d'laboration ont pour objectif le dveloppement de l'architecture de rfrence. Enfin, les itrations de la phase de construction sont tout entires ddies la mise au point du produit par une srie de constructions au sein de chaque itration, jusqu' la ralisation d'un produit livrable aux utilisateurs. Malgr ces diffrences, chaque itration suit le mme modle, comme l'indique lafigure5.3.

5.4.2 Planifier les

itrations

S'il faut bien admettre une chose, c'est que le cycle de vie itratif rclame plus de planification et de rflexion que l'approche en cascade. Dans le modle en cascade, tout est planifi l'avance, souvent avant que les risques aient t rduits et l'architecture tablie. Les plans qui en rsultent reposent donc sur une grande part d'incertitude et ne sont gure fidles la ralit. L'approche itrative, en revanche, ne planifie pas tout le projet en dtail au cours de la phase de cration ; elle s'engage simplement sur les premires tapes. L'quipe du projet ne s'aventure pas planifier les phases de construction et de transition tant que n'a pas t mise en place une base factuelle dans la phase d'laboration. Il existe, bien entendu, un plan de travail pendant les deux premires phases, mais qui n'entre pas dans les dtails. En principe (sauf au tout dbut d'un projet), la planification prend en compte les rsultats des itrations prcdentes, le choix des cas d'utilisation pertinents pour l'itration suivante, le statut actuel des risques concernant l'itration venir, et l'tat de la dernire version des diffrents modles. Elle se conclut par la prparation de la version interne. On dispose donc, lafinde la phase d'laboration, d'une base permettant de planilici te reste du projet et d'avancer un plan dtaill pour chaque itration de la phase de cous traction. Le plan de la premire itration sera trs clair. Celui des itrations suivantes coin portera moins de dtails, sera sujet d'ventuelles modifications et reposera sur l'issue dei itrations prcdentes et les connaissances qui s'en seront dgages. De mme, on devra dis poser d'un plan de la phase de transition qui sera susceptible, toutefois, de changer la lueui de ce que rvleront les itrations de la phase de construction. Ce type de planification permet de mener un dveloppement itratif contrl.

1. Il est important de ne pas confondre enchanements d'activits et processus concurrents . Les enchanements d'activits sont des collaborations utiles pour la cration de descriptions. 1. Au cours de la phase de cration, une itration peut suivre une variante simplifie des enchanements d'activits pour l'tude de certains problmes technologiques prcis.

Le Processus u n i f i de d v e l o p p e m e n t
PARTIE I

logiciel

Un processus itratif et

incrmental
CHAPITRE 5 Wm

5.4.3 Squencer

les

itrations

Dans la nature, l'volution se droule sans plan pralable. Ce n'est pas le cas pour les itrations logicielles. En quelque sorte, les cas d'utilisation fixent un objectif, tandis que l'architecture impose une forme. Avec l'esprit cet objectif et cette forme, les dveloppeurs planifient la squence de production du dveloppement.

Les planificateurs tentent d'ordonner les itrations de faon tracer une voie directe entre itrations, les premires servant de base de connaissances aux suivantes. Les premires itrations du projet jettent une lumire nouvelle sur les besoins, les problmes, les risques et le domaine de la solution, tandis que les itrations ultrieures aboutissent des incrments successifs qui finissent par constituer la version externe, c'est--dire le produit livr au client. Le comble de la russite, pour les planificateurs, est de trouver une squence d'itrations qui permette d'aller constamment de l'avant, sans jamais avoir revenir aux rsultats d'une itration antrieure pour reprendre le modle en fonction d'informations livres par une itration plus tardive.
Itration 1

la fin d'une itration, l'ensemble des modles reprsentant le systme se trouve dans un tat particulier. Cet tat, ou tat d'avancement, est appel rfrence. Chaque modle a atteint une rfrence ; chaque lment de modle essentiel se trouve dans un tat de rfrence. Par exemple, le modle des cas d'utilisation contient, la fin de chaque itration, un ensemble de cas d'utilisation qui refltent le degr de ralisation des besoins. Certains de ces cas d'utilisation sont mens leur terme, tandis que d'autres ne sont que partiellement pris en compte. Dans le mme temps, le modle de conception a atteint un tat de rfrence cohrent avec celui du modle des cas d'utilisation. Les sous-systmes, interfaces et ivali sations de cas d'utilisation du modle de conception se trouvent galement dans des tats de rfrence cohrents les uns avec les autres. Travailler efficacement avec plusieurs rfrences au sein d'un mme projet ncessite de veiller prserver la cohrence et la compatibilit des versions de tous les artefacts d'une rfrence. On ne peut que souligner, dans le cadre d'un dveloppement itratif, l'importance cruciale de l'utilisation d'outils de gestion de conligu ration efficaces.
1

^ Besoins^ Analyse^ Conceptio^lmplement^ T ss ^ al

Itration 2

un point quelconque de la squence d'itrations, certains sous-systmes arrivent maturit : ils contiennent toutes les fonctions prescrites, et ont t implments et tests. D'autres ne sont que partiellement constitus, tandis que d'autres encore restent vides, mme s'ils disposent des bouchons (stubs) ncessaires leur fonctionnement et leur intgration avec d'autres sous-systmes. En somme, et pour tre plus prcis, un incrment est la diffrence entre deux rfrences successives.

Hgure 5.4 1rs itrations fuitrourent les i m hatnements d'activits, de la < capture des besoins aux tests.

^ Bs i s eon

Analyse^ ConcepliQ^Implment^ T ss ^ et
Itration 3

Bs i s eon

A aye ^Conceptio^lmplnien^ T ss ^ nl s el

Comme nous l'avons dj indiqu, l'architecture de rfrence se met en place au cours de la phase d'laboration. On identifie les cas d'utilisation ayant une influence notable sur l'architecture, puis on les ralise sous forme de collaborations. C'est ainsi que sont identifis la plupart des sous-systmes et interfaces, tout au moins ceux qui sont intressants sur le plan de l'architecture. Une fois qu'on les a identifis, i l convient d'toffer ces sous-systmes et interfaces, c'est--dire d'crire le code permettant de les implmenter. Cette tche est, en partie, effectue avant la livraison de l'architecture de rfrence et se poursuit tout au long des enchanements d'activits, mais principalement au cours des itrations de la phase de construction. L'approche de la phase de transition s'accompagne d'une amlioration de la cohrence interne des modles et de leur cohrence mutuelle. Les incrments naissent de l'toffement progressif des modles, jusqu' l'intgration de l'incrment final qui donne lieu au systme tel qu'il est livr.

Les itrations peuvent se chevaucher dans le sens o une itration dbute alors que la prcdente est sur le point de s'achever, comme le montre la figure 5.4. La planification et le travail d'une itration peuvent dbuter alors mme que se termine l'itration prcdente et que l'on prpare la version qui en rsultera. I l ne faut pas, cependant, que ces chevauchements aillent trop loin, car une itration constitue toujours le fondement de l'itration suivante. N'oubliez pas qu'une itration s'achve lorsque les dveloppeurs ont termin ce qu'ils avaient faire ; le logiciel cr par l'itration est intgr et peut tre livr sous forme de version interne.

5.6 Itrations dans le cycle de vie

Chacune des quatre phases se conclut par un jalon majeur, comme l'illustre la figure 5.5 111 cration : objectifs du cycle de vie laboration : architecture du cycle de vie

L'ordre dans lequel sont prvues les itrations dpend largement de facteurs techniques. Nanmoins, l'objectif majeur est d'chelonner le travail de sorte que les dcisions les plus importantes, c'est--dire celles concernant les nouvelles technologies, les cas d'utilisation et l'architecture, soient prises trs tt.

5.5 Une itration se traduit par un incrment

Un incrment est la diffrence entre la version interne d'une itration et la version interne de l'itration suivante.

1. Tous les cas d'utilisation n'ayant pas besoin d'tre conus, le terme cohrent ne se rfre qu' ceux qui sont en cours de conception.

Lo Processus u n i f i de d v e l o p p e m e n t logiciel

Un processus i t r a t i f et i n c r m e n t a l mm

r. nil I construction : capacit oprationnelle initiale transition : livraison du produit L'objectif de chaque jalon majeur est de s'assurer que les modles des diffrents enchanements d'activits voluent de faon quilibre sur l'ensemble du cycle de vie du produit. Par quilibre , nous entendons que les dcisions essentielles influant sur ces modles et celles concernant les risques, les cas d'utilisation et l'architecture doivent tre prises au dbut du cycle de vie. Sur ces bases, le travail peut ensuite se poursuivre et s'enrichir d'un degr croissant de dtails avec un niveau de qualit suprieur.
Jalons

dploiement, d'implmentation et des tests. Cet incrment est ensuite intgr au rsultat de l'itration prcdente pour crer une nouvelle version des modles. Comme nous l'avons indiqu dans les sections prcdentes, les jalons mineurs sont l'occasion, pour responsables et dveloppeurs, de dterminer la faon de passer aux itrations suivantes. En revanche, les jalons majeurs, qui clturent chaque phase, reprsentent le moment o les responsables prennent la dcision cruciale d'accorder ou non leur feu vert et de dfinir le planning, le budget et les exigences.

Jalon des objectifs du cycle de vie Cration

Jalon de l'architecture du cycle de vie laboration

Jalon de capacit oprationnelle Initiale Construction

Jalon de livraison du produit Transition

Un jalon mineur (au moment de la livraison d'une version interne, lafind'une itration) est une tape prvue vers un jalon majeur marquant la conclusion d'une phase. La principale diffrence qui oppose un jalon majeur un jalon mineur se situe au niveau de l'organisation. Les dveloppeurs traitent les risques de faon itrative et construisent des artefacts logiciels jusqu' ce qu'ils atteignent le jalon majeur. chaque jalon majeur, les responsables valuent le travail accompli par les dveloppeurs. Le passage d'un jalon majeur reprsente donc une importante dcision de gestion et suppose un engagement financier pour la phase suivante (au moins) selon ce qui est prvu. On peut envisager ces jalons majeurs comme les points de convergence des domaines technique et de gestion.

lter.1

Iter. 2

iter. #n-1

iter. #n

Ces divisions aident les responsables et les autres intervenants concerns valuer le travail effectu dans les phases peu coteuses de cration et d'laboration, avant de s'engager dans la phase de construction, beaucoup plus onreuse. On peut, grosso modo, dcouper un projet de dveloppement logiciel en deux grandes parties : d'un ct, les phases de cration et d'laboration, de l'autre, les phases de construction et de transition. Les phases de cration et d'laboration sont consacres la ralisation de l'tude de rentabilit, la rduction des risques les plus importants, la cration de l'architecture de rfrence et la planification plus prcise du reste du projet. Ce travail est effectu par une quipe restreinte, avec un faible budget. Puis, le projet passe la phase de construction, dont l'objectif est de raliser des conomies d'chelle. Le nombre de personnes impliques dans le projet augmente. Ensemble, elles mettent au point la grande masse des fonctions du systme, qu'elles dveloppent partir de l'architecture de rfrence cre pendant la phase d'laboration. On rutilise autant que possible les logiciels existants.

Figure 5.5 Agrgation des itrations de chaque phase aboutissant aux jalons majeurs, au cours desquels sont prises les principales dcisions stratgiques.

Les principaux objectifs de la phase de cration consistent dfinir la porte et le rle du produit, rduire les risques les plus srieux et prparer une premire tude de rentabilit dmontrant la viabilit commerciale du projet. En d'autres termes, i l s'agit d'tablir les objectifs du cycle de vie du projet. Les principaux objectifs de la phase d'laboration consistent crer l'architecture de rfrence, saisir l'essentiel des besoins et rduire les risques de moindre gravit, c'est--dire tablir l'architecture du cycle de vie. On est en mesure, l'issue de cette phase, d'estimer les cots, de prvoir le calendrier du dveloppement et de planifier en dtail la phase de construction. I l devient possible, ce stade, de faire une offre. Les principaux objectifs de la phase de construction consistent dvelopper le systme complet et s'assurer que le produit peut commencer tre utilis par les clients, c'est-dire qu'il a atteint une capacit oprationnelle initiale. Les principaux objectifs de la phase de transition consistent s'assurer que l'on dispose d'un produit prt tre livr l'ensemble des utilisateurs, qui sont forms ce moment-l l'utilisation du logiciel. Chaque phase comporte aussi des jalons de moindre importance (ou mineurs ), prcisment des critres applicables chacune des itrations. Chaque itration produit des rsultats : des artefacts de modle. Lafinde chaque itration ajoute, par consquent, un nouvel incrment au modle des cas d'utilisation, aux modles d'analyse, de conception, de

Si toutes les itrations parcourent tous les enchanements d'activits des besoins, de l'analyse, de la conception, de l'implmentation et des tests, chacune insiste sur diffrents points selon les phases abordes, comme l'illustre la figure 5.6. Au cours des phases de cration et d'laboration, les efforts se portent principalement sur l'expression des besoins, ainsi que sur l'analyse et la conception prliminaires, tandis que l'on insiste surtout, dans les phases de construction et de transition, sur la conception dtaille, l'implmentation et les tests. Bien que cela n'apparaisse pas sur la figure 5.6, la gestion de projet et la mise au point de l'environnement du projet occupent une part importante des premires phases.

mm
u l m

Le Processus u n i f i de d v e l o p p e m e n t logiciel
i-M H H

Un processus i t r a t i f et i n c r m e n t a l
CHAPITRE 5

Phases
lf \ se ,/,(/,/. ent, selonles ,i. i,liions, de la , uplure des

Enchanements d'activits principaux

In iiiin.t aux tests en

IHiuuml pur l'analyse, lu , mu rption et I impli'menlalion.

Dans la phase d'laboration, la zone sombre, qui indique le niveau d'accomplissement du travail, augmente de faon substantielle. Pourtant, l'issue de cette phase, alors que l'quipe a formul environ 80% des cas d'utilisation (U) et une partie du modle de conception (C), moins de 10% de ces lments ont t construits dans le systme et se traduisent par des fonctions implmentes (I) et testes (T). Les modles des cas d'utilisation et de dploiement doivent avoir atteint ce niveau d'avancement l'issue de la phase d'laboration. Sinon, on ne connatra pas suffisamment les besoins et les pr-conditions de l'implmentation (y compris en matire d'architecture) pour planifier avec prcision la phase de construction.
1

La phase de construction voit le quasi-achvement des enchanements d'activits U, A, C, D, I et T, ce qui n'est gure surprenant puisque le critre de sortie de cette phase est une impie mentation complte du systme pouvant tre transmise aux utilisateurs. I l sera toujours possible ensuite, lorsque le systme passera en mode oprationnel dans la phase de transition, de l'optimiser et de lui apporter quelques corrections mineures.

Itrations

5.8 Les itrations remettent en question l'organisation

Les quipes de dveloppement logiciel souvent ne rsistent pas la tentation de passer directement l'criture de lignes de code, facilement quantifiables par les chefs de projet. Elles ont aussi tendance faire obstruction au changement, qui ralentit la production de code. Enfin, elles ne cherchent gure rutiliser le produit d'analyses, de conceptions ou de codes antrieurs, car seul le code frachement crit est pris en compte par les responsables. Le passage un dveloppement itratif remet en question les pratiques en vigueur dans ces services. Il exige un changement d'attitude. L'attention du service doit, en effet, se dtourner du nombre de lignes de code pour se porter sur la rduction des risques et la cration de fonctions architecturales de rfrence. Les chefs de projet doivent, quant eux, poser un regard neuf sur ce qui doit tre mesur, et dmontrer, par leurs actions, qu'ils mesurent la progression en termes de traitement des risques, de prparation des cas d'utilisation et de ralisation sous forme de composants. Sinon, les dveloppeurs ne tarderont pas revenir ce qui leur valait encouragements et flicitations : la production de lignes de code. L'adoption de l'approche itrative et incrmentale s'accompagne de quelques consquences majeures : pour raliser l'tude de rentabilit dans la phase de cration, le service se concentre sur la rduction des risques et la dmonstration de la viabilit technique du projet ; pour soumettre une offre rentable lafinde la phase d'laboration, le service doit connatre les lments dont il est charg d'effectuer la construction (reprsente par l'architecture de rfrence plus les besoins) et s'assurer qu'ils ne dissimulent aucun risque

r , .7 Les modles v o l u e n t partir des itrations

Incrment par incrment, les itrations construisent les modles qui en rsultent. Chaque itration enrichit les modles l'un aprs l'autre, en en parcourant tous les enchanements d'activits. Comme l'indique le diagramme de la figure 5.7, certains de ces modles, tel que le modle des cas d'utilisation, focalisent en grande partie l'attention dans les premires phases, tandis que d'autres, tel que le modle d'implmentation, sont l'objet d'une tude plus approfondie dans la phase de construction. Dans la phase de cration, l'quipe pourra, par exemple, crer les parties des modles ncessaires la prise en charge d'un prototype de mise l'preuve du concept, c'est--dire les principaux lments du modle des cas d'utilisation (U), du modle d'analyse (A) et du modle de conception (C), ainsi qu'une partie des modles de dploiement (D), d'implmentation (I) et de tests (T). ce stade, l'essentiel de l'implmentation est encore l'tat prparatoire. Comme on le voit sur la figure 5.7, i l reste encore beaucoup faire.
figure 5.7

Cration

laboration

| Construction |

Transition

UAC D I T U AC D I T

m
Conception Dveloppement

i , un, tassement des modles se miui mil tout au long de chacune des h,,:, i / a phase de construction .,. heve par un ensemble (presque) i de modles, qui devront i. .Hun,uns tre optimiss dans la . de transition, lors du muent sur les postes des utilisateurs.

I. Dans le chapitre 4, nous avons indiqu que les modles des cas d'utilisation et d'analyse avaient atteint, la fin de la phase d'laboration, un niveau de ralisation plus faible que ne le montre lafigure5.7. Ce dcalage s'explique par le fait que, dans le chapitre 4, nous nous tions exclusivement intress l'architecture sans prendre en compte le reste (en l'occurrence, la ncessit d'avoir une comprhension plus aigu des cas d'utilisation pour tablir une tude de rentabilit).

fi.M

OHKUS

u n i f i de d v e l o p p e m e n t logiciel

1 in exemple, des facteurs incertains, susceptibles d'alourdir les budgets et de rallonger 1 tel dlais) ; pour rduire les cots, viter les anomalies et raccourcir les dlais de mise sur le march, Il service doit employer des composants rutilisables (manation des premiers dveloppements de l'architecture fonds sur l'tude du domaine auquel ressortit le systme propos) ; | nu viter les retards de livraison, les dpassements de budget et les produits de mauvaise qualit, il est ncessaire de faire le sale boulot en premier ; pour viter de fabriquer un produit dj dpass la livraison, on ne peut plus s'obstiner n i user tout changement. L'approche itrative par phases permet d'intgrer les i hangements de faon progressive tout au long du processus de dveloppement.

Partie

II

L e s

e n c h a n e m e n t s p r i n c i p a u x

d ' a c t i v i t s

Chapitre 6 Chapitre 7

i i dveloppement itratif et incrmental ne rclame pas seulement une nouvelle faon de l'an les projets, mais aussi des outils prenant en charge cette nouvelle approche. I l est pratiqunnenl impossible de grer tous les artefacts d'un systme soumis en permanence des changements concomitants chaque construction et chaque itration sans le secours I . mi ils appropris. Les services qui adoptent ce mode de dveloppement ont besoin d'outils prenant en charge les diffrents enchanements d'activits, et d'autres assurant la gestion de . onflguration et le contrle de version.

Expression des besoins : de la vision aux besoins Expression des besoins sous forme de cas d'utilisation Analyse Conception Implmentation Tests

6.9 Rfrences
1
2

Chapitre 8 Chapitre 9 Chapitre 10 Chapitre 11

HARRY BOEHM, "Anchoring the software process," IEEE Software, July 1996, pp. 73-82.
PETER F. DRUCKER, Management: Tasks, Responsibilities, Practices, New York:

Harper & Row, 1973. 3 BARRY W . BOEHM, "A spiral model of software development and enhancement," Computer, May 1988, pp. 61-72. (Reprinted in Barry W . Boehm, Tutorial: Software Risk Management, IEEE Computer Society Press, Los Alamitos, CA, 1989.) CAPERS JONES, Assessment and Control of Software Risks, Upper Saddle River, NJ: Prentice-Hall, 1993. WALKER ROYCE, "TRW'S Ada process model for incrmental development of large software Systems," Proceedings, 12th International Confrence on Software
Engineering, 1990, pp. 2-11.

4 5

Maintenant que nous avons compris les notions lmentaires qui soustendent les pratiques essentielles du Processus unifi, nous allons dcrire en dtail chacun des enchanements d'activits. La troisime partie traitera des itrations et des phases. Dans la deuxime partie, les enchanements d'activits principaux font l'objet de chapitres distincts : les chapitres 6 et 7 traitent des besoins, le chapitre 8 de l'analyse, le chapitre 9 de la conception, le chapitre 10 de l'implmentation et le chapitre 11 des tests. Le terme enchanement d'activits principal est une abstraction, dcrite en dtail dans le chapitre 5. Nous nous attachons, au cours des itrations, au dploiement concret de ces enchanements d'activits, thme auquel est consacre la troisime partie. Le fait d'voquer sparment les enchanements d'activits principaux, comme nous nous apprtons le faire, peut tre trompeur pour le lecteur ; nous tenons dissiper toute confusion ventuelle. Premirement, en dcrivant les enchanements d'activits principaux l'un

aprs l'autre, nous donnons l'impression que le processus global de dveloppement logiciel ne traverse cette squence d'enchanements d'activits qu'une seule fois entre le dbut et la fin du projet. Le lecteur risque de rester sur l'ide que les enchanements d'activits principaux constituent un processus sens unique se droulant une fois pour toutes, comme le vieux processus en cascade. Deuximement, un lecteur non prpar pourrait dduire de ces pages que chaque enchanement d'activits principal est une tape monolithique du processus.

6
Expression des besoins : de la vision aux besoins
Pendant des gnrations, certaines tribus amrindiennes ont construit un type de pirogue, appel dugout , littralement creus dans un tronc d'arbre . On commenait, pour construire ces pirogues, par rechercher un arbre de plus d'un mtre de diamtre, dj tomb proximit du cours d'eau. Puis, on allumait tout prs un feu et l'on dispersait le charbon de bois brlant sur le tronc. Le bois ainsi carbonis tait plus facile vider avec des outils de pierre. Aprs plusieurs jours passs sculpter le tronc, le cano tait prt et mis l'eau dans une zone peu profonde. Le plus souvent, la premire bauche ne faisait que se retourner sur elle-mme. I l fallait donc parfaire l'ouvrage avec de lourds outils de pierre jusqu' ce que le bateau ne chavire plus lorsqu'on se penchait pour retirer un poisson de l'eau. C'est alors, et alors seulement, que le bateau tait considr comme termin. Ce savoir s'est transmis de gnration en gnration, au point de s'inscrire dans le subconscient des constructeurs. Lorsqu'une tribu de dveloppeurs logiciels entend l'appel du dveloppement d'un nouveau systme, elle se trouve confronte une situation totalement diffrente. Premirement, les dveloppeurs ne sont pas les futurs utilisateurs du systme. Ils n'obtiendront pas de retours immdiats sur le comportement de leur pirogue . Deuximement, les besoins et les contraintes du systme n'ont pas imprgn les couches profondes de leur subconscient par un usage continu du produit depuis l'enfance. Ils devront, au contraire, dcouvrir par eux-mmes ce qui est ncessaire. Nous nommons cet acte de dcouverte expression ou capture des besoins. I l s'agit du processus de mise au jour, le plus souvent dans des circonstances difficiles, de ce qui doit tre construit. En fait, cette tche est tellement dlicate qu'il n'est encore pas rare de voir des quipes de projet commencer l'criture du code (ce qui est relativement simple), avant d'avoir clairement tabli ce qu'est suppos faire le code (ce qui est nettement plus compliqu).

Aucune de ces deux impressions n'est exacte. La description des enchanements d'activits principaux sous forme de chapitres spars n'obit qu' un objectif strictement pdagogique : ce choix formel nous permet de traiter fond l'intgralit de chaque enchanement d'activits. En ce qui concerne la premire interprtation (le rapprochement avec le dveloppement en cascade), i l est vrai que l'on traverse les cinq enchanements d'activits de faon squentielle, mais ce parcours se produit chaque itration, et non pas une seule fois pour tout le projet. Par exemple, si l'on a sept itrations sur quatre phases, on parcourra vraisemblablement sept fois chaque enchanement d'activits. I l convient, nanmoins de nuancer ce propos pour reconnatre que l'on n'utilisera peut-tre pas les cinq enchanements d'activits au dbut de la phase de cration. I l est probable, en effet, que l'on n'aille pas jusqu'aux derniers enchanements d'activits, tels que l'implmentation et les tests, au cours des premires itrations. Le principe est clair : le parcours des enchanements d'activits est soumis aux particularits de chaque itration. Pour ce qui est de la seconde interprtation (l'tape monolithique), nous dcrivons, en effet, chaque enchanement d'activits principal indpendamment des autres enchanements d'activits. Mais ces enchanements dialoguent les uns avec les autres en produisant des artefacts et en utilisant ceux produits par les autres. Nous avons essay, dans cette partie, de simplifier un peu chaque enchanement d'activits en nous concentrant sur ses activits fondamentales, l encore pour des raisons pdagogiques. Nous n'abordons pas les allers-retours entre ces activits et celles des autres enchanements d'activits. Cet change est, bien sr, essentiel un processus de dveloppement logiciel itratif et sera voqu en dtail dans la troisime partie. Tout en travaillant sur une conception particulire, un dveloppeur peut, par exemple, juger souhaitable d'aller et venir entre les enchanements d'activits d'analyse et de conception. La troisime partie illustre l'association de ces divers enchanements, dcrits sparment dans les pages suivantes, au sein d'un projet rel. Ainsi, un ensemble limit d'enchanements d'activits pourra suffire dans les premires phases, tandis que l'ensemble complet des enchanements d'activits sera indispensable la phase de construction.

nehainements d ' a c t i v i t s principaux

i m III II

Expression des besoins : de la vision aux besoins mm

cTipnvWmm Mme en faisant preuve de perspicacit, l'expression des besoins reste difficile et l'industrie cherche depuis longtemps un processus la fois efficace et systmatique pour y parvenir. C'est ce thme qui fait l'objet de ce chapitre et du suivant.

Pourquoi l'expression des besoins est-elle dlicate ?

6.2

Objectif de l'enchanement

d'activits

des besoins

l . . professionnels du dveloppement logiciel construisent, en gnral, des systmes pour .1. tiers : les utilisateurs du logiciel, et non pour eux-mmes. Bah , avaient coutume de . lamer les dveloppeurs, les utilisateurs doivent savoir ce qu'il leur faut . Mais i l iiiin d'avoir, quelques reprises, tent de recueillir les exigences auprs des utilisateurs I u u u savoir qu'ils se rvlent bien souvent une source d'informations trs imparfaite. I > bord, parce qu'un systme a en gnral de nombreux utilisateurs (ou types d'utilisateurs) i l que, si chacun sait ventuellement ce qu'il lui faut, personne n'a une vision d'ensemble. I iiMiilc, parce que ces utilisateurs ignorent par quels moyens le fonctionnement global du i, nie peut tre amlior. La plupart d'entre eux ne savent pas quels aspects de leur travail i u 1 M - I I I cire dvolus un logiciel. Pour tre tout fait franc, il est assez courant que les uti1 II Meurs ne sachent pas quels sont les besoins, ni comment les exprimer de faon prcise.

Le principal objectif de l'enchanement d'activits des besoins est d'orienter le dveloppement en direction du systme le plus appropri. La satisfaction de cet objectif suppose de dcrire les exigences qui psent sur le systme (c'est--dire des conditions ou des moyens que doit respecter le systme) avec suffisamment de prcision pour parvenir un accord entre le client (y compris les utilisateurs) et les dveloppeurs sur ce que doit faire ou ne pas faire le systme. Le dfi qui se pose l est que le client, que l'on peut supposer a priori non spcialiste de l'informatique, doit tre capable de lire et de comprendre les rsultats de la capture des besoins. I l convient donc d'employer le langage du client pour dcrire ces rsultats et d'tre particulirement vigilant lorsqu'on y introduira formalisme et structure, ainsi que les dtails sur le fonctionnement interne du systme. Les rsultats de l'enchanement d'activits aident aussi le chef de projet planifier les itrations et les versions destines au client (ces questions sont traites dans la troisime partie).

plus, ces

6.3

Prsentation

gnrale

de l'expression des besoins

I ,'ipproche traditionnelle, face ce problme, consistait confier des intermdiaires, les m ilvsles, le soin de tirer de chaque utilisateur une liste de besoins, en esprant qu'ils parI lendl aienl dgager une vision d'ensemble et mettre au point une spcification complte, lnlrli- cl cohrente de ces besoins. En gnral, les analystes consignaient ces exigences dans . h . documents quifinissaientpar compter des centaines, voire des milliers, de pages. Mais i l i absurde d'imaginer un seul instant que l'esprit humain puisse parvenir une liste cohi i n i c cl pertinente de milliers d'exigences en se disant : alors, le systme devra... . En spcifications de besoins ne se transformaient pas facilement en spcifications de et d'implmentation.
mu option

i. Ii m. avec l'aide des analystes, les utilisateurs ne parvenaient pas totalement comprendre i c que devait faire le systme avant que celui-ci ne soit pratiquement achev. mesure qu'avanaient les projets et que les utilisateurs, intermdiaires et dveloppeurs eux-mmes , icnaient entrevoir l'allure gnrale du systme et mieux apprhender les vritables lu-soins, les suggestions de changement pleuvaient. Nombre de ces changements taient, d'ailleurs, souhaitables, mais leur implmentation avait un grave retentissement sur les dlai) cl les cots.

Chaque projet logiciel est unique. Cette singularit s'explique par la diversit des types de systme, des clients, de l'organisation du dveloppement, des technologies, etc. De mme, l'expression des besoins repose sur diffrents points de dpart. On commencera, dans certains cas, par laborer un modle du mtier, ou bien on exploitera un modle de ce type en cours d'laboration par une autre socit (voir la section 6.6.1, Qu'est-ce qu'un modle du mtier ? ). Dans d'autres cas, le logiciel sera un systme embarqu ne prenant pas directement en charge un mtier spcifique. On pourra aussi ne disposer, comme entre, que d'un simple modle objet, tel qu'un modle du domaine (voir la section 6.5.1, Qu'est-ce qu'un modle du domaine ? ). I l arrivera aussi que le client ait tabli une spcification complte et dtaille des besoins ne reposant pas sur un modle objet, mais qui servira de base de ngociation aux futures modifications. On rencontrera, l'oppos, des clients n'ayant qu'une ide trs vague de ce que doit tre leur systme, dont l'ide manera parfois d'une simple dclaration d'intention des responsables suprieurs. Entre ces extrmes, toutes sortes de variations sont possibles. Nous avons choisi, comme point de dpart, le cas d'une ide vague et prsentons maintenant l'exemple qui traversera tout le livre. liMUM Le Consortium interbancaire envisage la cration d'un systme informatique Le Consortium interbancaire, institution financire fictive, se trouve confront des changements majeurs suscits par la drgulation, un nouveau type de concurrence et des prestations innovantes rendues possibles par le World Wide Web. Le Consortium envisage de dvelopper de nouvelles applications pour prendre rapidement en charge des marchs finan-

Pendant toutes ces annes, nous nous sommes berc d'illusions en pensant que les utilisateurs savaient quels taient leurs besoins et qu'il nous suffisait de les interroger. Certes, les systmes dvelopps sont censs rendre service aux utilisateurs et c'est bien de ces derniers que l'on peut recueillir des informations sur les interactions entre utilisateurs. Mais i l est encore plus important que les systmes remplissent la mission qui a motiv leur consn notion. Le systme doit, par exemple, apporter une valeur spcifique l'entreprise utilisaIrice ainsi qu' ses clients. Il est souvent difficile d'identifier ou de comprendre la vritable nature de cette valeur, et parfois impossible de mettre au point le systme susceptible de la prendre en charge. Pire, dans le contexte d'un monde rel en perptuelle volution, i l y a de fortes chances pour que cette valeur insaisissable change au cours du projet : l'entreprise elle-mme risque de changer, la technologie disponible pour la construction du systme risque de changer, les ressources (personnel, budget) dgages pour le projet risquent de changer, etc.

e n c h a n e m e n t s d ' a c t i v i t s principaux

Expression des besoins : de la vision aux besoins Wgf

ciers en pleine volution, dont elle a confi la mise au point sa filiale de dveloppement logiciel, Interbank Software.

un tat d'avancement (par exemple : propos, approuv, intgr ou valid) : une estimation du cot d'implmentation (en termes de types de ressources et d'heureshommes) ; un niveau de priorit (par exemple : essentiel, important ou secondaire) ; enfin, un niveau de risque associ l'implmentation de la fonction (par exemple : majeur, significatif ou ordinaire ; voir le chapitre 5). Ces valeurs de planification permettent, en conjonction avec d'autres aspects (abords au chapitre 12), d'estimer la taille du projet et de dcider de la faon de le scinder en une squence d'itrations. Les niveaux de priorit et de risque associs une fonction servent, par exemple, dterminer dans quelle itration mettre en uvre la fonction (comme l'explique la troisime partie). Par ailleurs, lorsque sera prvue l'implmentation d'une fonction, on pourra tablir une relation de traabilit entre cette fonction et des cas d'utilisation ou des exigences supplmentaires (thme abord d'ici peu). Comprendre le contexte du systme - Parmi les personnes impliques dans le dveloppement d'un logiciel, nombreux sont les spcialistes de questions strictement informatiques. Il est pourtant ncessaire, pour apprhender les vritables besoins et construire le systme appropri, que les principaux dveloppeurs (l'architecte en particulier, et certains des analystes seniors) aient une relle comprhension du contexte dans lequel se dploiera le systme.

Interbank Software a dcid de concevoir le Systme de facturation et de rglement en collaboration avec quelques-uns de ses principaux clients bancaires. Le systme utilisera l'Internet pour l'envoi des commandes, des factures et des rglements entre vendeurs et acheteurs. La banque souhaite, par la mise au point de ce systme, attirer de nouveaux clients en proposant des frais de traitement des rglements trs faibles. Elle veut galement rduire ses frais salariaux en traitant les demandes de rglements automatiquement par l'Internet plutt que manuellement par des guichetiers. L'objectif des vendeurs et des acheteurs est de rduire les cots, la paperasserie et le temps de traitement. Par exemple, il ne sera plus ncessaire d'envoyer les commandes ou les factures par courrier. Le rglement des factures sera pris en charge par les systmes informatiques de l'acheteur et du vendeur, qui bnficieront en outre d'une meilleure visibilit du statut de leurs factures et rglements. i ventualit de points de dpart aussi diffrents qu'une dclaration d'intention assez vague . i une spcification des besoins suggre que l'analyste doit tre capable d'adapter chaque Situation son approche de l'expression des besoins. Et comme les risques induits diffrent en fonction de ces points de dpart, i l faut donc qu'il choisisse l'approche qui permettra au mieux de rduire ces risques. La rduction des risques est traite en dtail dans la troisime partie. I n dpit de ces diffrences, certaines tapes restent valables dans la plupart des cas, ce qui u..u autorise proposer un archtype d'enchanement d'activits. Celui-ci comprend les tapes suivantes, qui, en ralit, ne sont pas sparables : recenser les besoins potentiels ; comprendre le contexte du systme ; apprhender les besoins fonctionnels ; apprhender les besoins non fonctionnels. I .es paragraphes suivants dcrivent brivement ces tapes. Recenser les besoins potentiels - Au cours de la vie d'un systme, clients, utilisateurs, analystes et dveloppeurs avancent des ides susceptibles de rvler de vritables besoins. On dresse alors une liste de ces suggestions, que l'on pourra considrer comme un ensemble d'exigences potentielles implmenter ou non dans une version future du systme. Cette liste de fonctions (ou de caractristiques) augmente avec l'ajout de nouveaux lments et s'allge mesure que ces fonctions sont retenues comme besoins et transformes en d'autres artefacts, comme les cas d'utilisation. Elle ne sert, en fait, qu' planifier le travail. Chaque caractristique porte un nom court et s'assortit d'une brve explication ou dfinition comportant suffisamment d'informations pour permettre l'vocation prcise de cette fonction lors de la planification du produit. Elle s'accompagne, en outre, d'un ensemble de valeurs issues du suivi de projet pouvant comprendre les lments suivants :

Il existe au moins deux approches pour exprimer le contexte d'un systme sous une forme utilisable par les dveloppeurs logiciels : la modlisation du domaine et la modlisation du mtier. Un modle du domaine dcrit, en les reliant les uns aux autres, les concepts essentiels du contexte sous forme d'objets du domaine. Une fois identifis et nomms, ces objets permettent d'arrter un glossaire qui favorisera la communication entre les diverses personnes travaillant sur le systme. Ces objets faciliteront, ensuite, l'identification de certaines des classes au cours de l'analyse et de la conception du systme. Comme vous le verrez, on peut dfinir un modle du mtier comme un sur-ensemble d'un modle du domaine, comprenant plus que les simples objets du domaine. L'objectif de la modlisation du mtier est de dcrire les processus, existants ou perus, afin de les comprendre. C'est la seule partie de l'ingnierie du mtier que nous utiliserons dans cet ouvrage [3]. Nous nous bornerons, pour l'instant, dire que l'ingnierie du mtier est trs proche de la modlisation du mtier, mais qu'elle vise en plus amliorer les processus mtier de l'entreprise. En modlisant le mtier, les analystes en apprennent beaucoup sur le contexte du systme logiciel, qu'ils dcrivent dans un modle du mtier. Celui-ci spcifie quels sont les processus mtier qui devront tre pris en charge par le systme. Outre l'identification des objets du mtier ou du domaine impliqus dans l'activit professionnelle, la modlisation du mtier tablit galement les comptences requises par chaque processus : les travailleurs, leurs responsabilits et les tches qu'ils effectueront. Cette connaissance est, bien entendu, cruciale pour l'identification des cas d'utilisation, comme nous le verrons un peu plus loin. En fait,

Los e n c h a n e m e n t s d ' a c t i v i t s principaux

l:\HII~l II

_ _ _ _ _

Expression des besoins : de la vision aux besoins

CHAPITRES _

cette approche systmatise au plus haut point le processus de capture des besoins pour les applications professionnelles [3]. Ensemble, l'architecte et le chef de projet dcident s'il y a lieu d'laborer un modle du domaine qui servira de base la prparation d'un modle complet du mtier, ou si aucun de ces deux modles ne serafinalementtabli. Apprhender les besoins fonctionnels - L'approche permettant d'identifier directement les besoins du systme s'appuie sur les cas d'utilisation (traits en dtail dans le chapitre 7). Ces derniers expriment les besoins fonctionnels et non fonctionnels propres chacun d'entre eux. Rappelons brivement par quels moyens les cas d'utilisation favorisent l'apprhension des vritables besoins du systme. Chaque utilisateur demande au systme de lui rendre service d'une faon ou d'une autre, c'est--dire d'excuter certains cas d'utilisation. Pour l'utilisateur, un cas d'utilisation reprsente une faon d'utiliser le systme. Par consquent, s'ils peuvent dcrire tous les cas d'utilisation exigs par les utilisateurs, les analystes sauront exactement ce que doit faire le systme. Nous avons donc dit que chaque cas d'utilisation reprsente une faon d'utiliser le systme (par exemple, d'assister un utilisateur pendant le droulement d'un processus mtier). Or, chaque utilisateur a besoin de plusieurs cas d'utilisation pour dsigner les diffrentes faons dont i l emploiera le systme. I l est donc indispensable, pour dgager les cas d'utilisation exigs de la part du systme, notamment ceux permettant l'exercice mme de l'activit et ceux que les utilisateurs estiment ncessaires leur propre confort , de connatre fond les besoins des utilisateurs et du client. I l faut, pour cela, comprendre le contexte du systme, interroger les utilisateurs, dbattre des diverses propositions, etc.

RHfflH

Exigences particulires du cas d'utilisation Rgler la facture

Exigences te performances

Lorsqu'un acheteur met une facture pour rglement, le systme doit rpondre par une vrification de la requte en 1 seconde maximum dans 90% des cas. Le dlai de vrification ne doit jamais excder 10 secondes, sauf si la connexion est interrompue (auquel cas l'utilisateur doit en tre inform). Certaines exigences non fonctionnelles renvoient des lments du monde rel, comme lei comptes d'un systme bancaire. Ces exigences peuvent, dans un premier temps, tre intgres l'objet du mtier ou du domaine concern dans le modle dcrivant le contexte du systme. Puis, une fois que les cas d'utilisation et les concepts sur lesquels elles agissent ont t dtermins, ces exigences non fonctionnelles sont relies aux concepts. Par concepts , nous entendons les termes informels d'un glossaire servant aux descriptions des cas d'utilisation (voir le chapitre 7) ou, de faon plus formelle, les classes d'un modle d'analyse (voir le chapitre 8). Pour plus de simplicit, nous adoptons dans ce chapitre la premire hypothse, c'est--dire que ces exigences sont relies aux concepts du glossaire. Enfin, certaines exigences non fonctionnelles sont plus gnriques et ne peuvent tre relies un cas d'utilisation en particulier, ni une classe spcifique du monde rel. Elles doivent donc tre gres sparment, dans une liste d'exigences supplmentaires (Annexe C). Rsum - Pour apprhender efficacement les besoins, les analystes doivent recourir un ensemble de techniques et d'artefacts qui leur permettront de se faire une ide claire du systme et de passer aux enchanements d'activits suivants. Nous dsignons collectivement ces artefacts sous le nom d'ensemble des exigences. La spcification classique des besoins est donc dsormais remplace par un ensemble d'artefacts comprenant le modle des cas d'utilisation et les exigences supplmentaires. Les artefacts ncessaires la dfinition du contexte du systme sont les modles du mtier et du domaine, comme l'illustre la
figure 6.1. (Notez que les cas d'utilisation tionnels spcifiques aux cas d'utilisation.)
Figure 6.1

En complment des cas d'utilisation, les analystes doivent galement indiquer l'apparence gnrale qu'aura l'interface utilisateur une fois les cas d'utilisation excuts. Le meilleur moyen d'laborer cette spcification de l'interface utilisateur consiste en esquisser plusieurs versions spcifiant les informations transfrer, discuter de ces propositions avec les utilisateurs et crer des visualisations concrtes ou des prototypes que ces derniers pourront tester.

contiennent

galement

les besoins

non fonc-

Travail effectuer

Artefacts obtenus

Recenser les besoins potentiels Comprendre le contexte du systme Apprhender les besoins fonctionnels Apprhender les besoins non fonctionnels

Liste des fonctions Modle du mtier ou du domaine Modle des cas d'utilisation Exigences supplmentaires ou cas d'utilisation individuels (pour les besoins spcifiques aux cas d'utilisation) Dfinit une spcification tradltlonnnollo des besoins

Apprhender les besoins non fonctionnels - Les besoins non fonctionnels spcifient les proprits du systmes, notamment les contraintes d'environnement et d'implmentation, les performances, les dpendances de plate-forme, la capacit de maintenance, l'extensibilit et la fiabilit. D'une manire gnrale, tout ce qui se termine par ilit . La fiabilit renvoie aux caractristiques telles que la disponibilit, la prcision, l'intervalle entre deux pannes, le nombre moyen d'anomalies pour 1 000 lignes de code (KLOC) et par classe. Les exigences de performances imposent aux besoins fonctionnels certaines conditions telles que la vitesse, le dbit, le temps de rponse et l'utilisation de la mmoire. Elles ne sont, en gnral, pertinentes que pour certains cas d'utilisation et doivent donc tre lies (en tant que valeurs marques) aux cas d'utilisation concerns (Annexe A). Cela signifie, en pratique, que ces exigences seront dcrites dans le contexte appropri, c'est--dire dans la description du cas d'utilisation (ventuellement dans une section part, nomme Exigences particulires ).

L'ensemble de tous les besoins se compose des diffrents artefacts indiqus dans la colonne de droite, tandis que le travail effectuer influe sur un ou plusieurs de ces artefacts.

Etant donn les changements constants auxquels sont soumis les besoins, i l faut absolument disposer d'un moyen de les actualiser de faon contrle. Ce moyen nous est offert par les itrations, dont chacune refltera un certain nombre de modifications de l'ensemble des exi-

L e s e n c h a n e m e n t s d ' a c t i v i t s principaux
PARTIE II Figure 6.2

Expression des besoins : de la vision aux besoins

CHAPITRE 6

Phases
x,

la capture des Enchanements besoins s'effectue d ' a c t i v i t s principaux principalement au ^

Cration , Elaboration ,

Construction

, Transition

gences. Le nombre de ces modifications baissera mesure que l'on avancera dans la phase de construction et que les besoins se stabiliseront. Nous reviendrons plus en dtail l-dessus dans la section 6.4, avant de dcrire le contexte du systme sous forme de modle du domaine (section 6.5) ou de modle du mtier (section 6.6). Puis, nous traiterons des exigences supplmentaires dans la section 6.7. L'expression des besoins sous forme de cas d'utilisation est un sujet bien plus vaste, sur lequel nous reviendrons dans le chapitre 7.

cours des phases

de cration et d'laboration.

| Besoins
A n

.,
y s e

4 Rle des besoins dans le cycle de vie du logiciel

Le modle des cas d'utilisation s'labore sur plusieurs incrments de dveloppement, chaque itration apportant de nouveaux cas d'utilisation ou dtaillant les cas d'utilisation existants. La figure 6.2 illustre la faon dont l'enchanement d'activits de l'expression des besoins et les artefacts qui en rsultent adoptent des formes diverses au cours des diffrentes phases et de leurs itrations (voir le chapitre 12). Pendant la phase de cration, les analystes identifient la plupart des cas d'utilisation afin de dlimiter le systme et de cibler le projet, et dtaillent les plus importants d'entre eux (moins de 10%).

Conception Implmentation Tests

Itrations

iter. #1

Iter. #2

iter. iter. iter. #n #n+1 # + n2

Itrations

Iter. # m

Iter. # + m1

6.5 C o m p r h e n s i o n du contexte du s y s t m e l'aide d'un modle du domaine

6.5.1 Qu'est-ce qu'un modle du domaine ?

Pendant la phase d'laboration, les analystes mettent au jour la plupart des besoins restants afin de permettre aux dveloppeurs d'estimer l'effort de dveloppement ncessaire. L'objectif est d'avoir apprhend environ 80% des besoins et dcrit la plupart des cas d'utilisation la fin de cette phase. (Notez que seuls 5 10% de ces cas d'utilisation doivent, ce stade, tre implments dans l'architecture de rfrence.) Le reste des besoins est formul (et implment) au cours de la phase de construction. La phase de transition ne saisit pratiquement aucun besoin, moins que certains d'entre eux n'aient fait l'objet de changements.

Un modle du domaine saisit les types d'objets les plus importants dans le contexte du systme. Les objets du domaine reprsentent les choses qui existent ou les vnements qui se produisent dans l'environnement au sein duquel fonctionne le systme [2, 5]. On trouvera un grand nombre de ces objets ou (pour utiliser une terminologie plus prcise) de ces classes du domaine dans la spcification des besoins ou en interviewant les experts du domaine. Les classes du domaine se prsentent gnralement sous trois formes : les objets mtier reprsentant les lments mis en uvre dans une activit professionnelle, tels que les commandes, les comptes ou les contrats ; les objets et concepts du monde rel dont un systme doit garder la trace, tels que les avions ennemis, les missiles et les trajectoires ; les vnements s'tant produits ou devant se produire, tels que l'arrive, le dpart d'un avion, ou la pause djeuner. Le modle du domaine est dcrit dans les diagrammes UML (en particulier dans les diagrammes de classes). Ces diagrammes illustrent, pour les clients, les utilisateurs, les rviseurs et les autres dveloppeurs, les classes du domaine et la faon dont elles sont lies par des relations d'association.

m mu i ..n n n c h a n e m e n t s d ' a c t i v i t s principaux

k M i:\nill II

Expression des besoins : de la vision aux besoins

CHAPITRE 6

Les classes du domaine Commande, Facture, Article et Compte Le systme utilisera l'Internet pour envoyer les commandes, factures et rglements entre acheteurs et vendeurs. Il assistera l'acheteur dans l'tablissement des commandes et le vendeur dans l'valuation des commandes et l'expdition des factures, puis il aidera l'acheteur valider les factures et effectuer les rglements de son propre compte vers le compte du vendeur. Une commande est l'acte par lequel un acheteur demande au vendeur de lui fournir un certain nombre d'articles. Chaque article occupe une ligne de la commande. Une commande a des attributs tels qu'une date d'mission et une adresse de livraison. Voir le diagramme de la figure 3.6. Une facture est la demande de rglement envoye par un vendeur un acheteur en rponse une commande de marchandises ou de services. Une facture a des attributs tels qu'un montant, une date d'mission et une date limite de rglement, et peut constituer la demande de rglement de plusieurs commandes. Une facture est rgle par le virement du montant appropri du compte de l'acheteur celui du vendeur. Un compte a des attributs tels qu'un solde et un titulaire. L'attribut titulaire identifie la personne possdant le compte.
lluiiinU.3 lUnninmnie i lusses issu modle tltt saisissant dumume, de d'un

Notation UML
Les classes sont reprsentes par des rectangles, les attributs figurent dans la partie infrieure des rectangles de classe, et les associations sont dsignes par tes lignes reliant les rectangles de classe). Le texte plac au bout d'un chemin d'association explique le rle d'une classe par rapport une autre, c'est--dire le rle de l'association. La multiplicit (les chiffres et toiles figurant au bout d'un chemin d'association) indique le nombre d'objets de la classe situe cette extrmit qui sont lis un objet situ l'autre extrmit. Par exemple, l'association reliant les classes Facture et Commande dans la figure 6.3 affiche une multiplicit de 1..* dcorant l'extrmit Commande. Ce qui signifie que chaque objet Facture peut constituer une requte de rglement pour un ou plusieurs objets Commande, comme l'indique le. rle d'association payable (Annexe A).

6.5.2 laboration

d'un modle

du domaine

La modlisation du domaine est gnralement effectue en ateliers, par des analystes du domaine utilisant UML et d'autres langages de modlisation pour la documentation des rsultats. Pour former une quipe vraiment efficace, ces ateliers doivent associer experts du domaine et personnes comptentes en matire de modlisation.

Commande

Article

date d'mission adresse de livraison

W 1..'

I, \ iiHriyi/.v les
bu importants du
i imtrxle i vstme. du

description description photo photo prix prix

L'objet de la modlisation du domaine est de comprendre et de dcrire les classes essentielles dans le contexte du domaine. Les domaines de taille modeste ncessiteront, en moyenne, entre 10 et 50 de ces classes, mais ce nombre pourra tre nettement plus lev pour des domaines plus vastes.

1..*

payable vendeur
1

Facture

Acheteur solde titulaire

Les centaines d'autres classes candidates qu'auront pu dcouvrir les analystes pour le domaine seront conserves sous forme de dfinitions dans un glossaire ; sinon, le modle du domaine deviendrait trop important et ncessiterait plus d'efforts qu'il ne convient ce stade du processus. Parfois, notamment pour des domaines professionnels trs limits, i l ne sera pas ncessaire de mettre au point un modle objet pour le domaine. Un glossaire pourra suffire. Le glossaire et le modle du domaine offrent aux utilisateurs, aux clients, aux dveloppeurs et aux autres intervenants un vocabulaire commun, indispensable au partage des connaissances. L o rgne la confusion, i l est difficile, voire impossible d'effectuer un vritable travail d'ingnierie. Et la construction d'un systme logiciel, quelles qu'en soient les dimensions, exige la fusion des langages utiliss par les divers participants en un seul et mme langage cohrent. Enfin, un mot d'avertissement sur la modlisation du domaine. Il est parfois plus simple de commencer la modlisation des parties internes d'un systme en ne se proccupant pas du contexte [7]. Il arrive, par exemple, que certains objets du domaine aient une reprsentation directe dans le systme, et que les analystes du domaine tombent dans le pige qui consiste spcifier les dtails de cette reprsentation. Il est primordial, dans des cas comme celui-ci, de garder l'esprit que l'objectif de la modlisation du domaine est de contribuer une

montant montant date d'mission date d'mission date limite de rglement date limite de rglement

Compte
1

Los e n c h a n e m e n t s d ' a c t i v i t s principaux PARTIE II

Expression des besoins : de la vision aux besoins

wm

cTATnmWWm

meilleure comprhension du contexte du systme et, par l-mme, des besoins du systme mesure qu'ils mergent de ce contexte. En d'autres termes, la modlisation du domaine doit favoriser la comprhension du problme qu'est cens rsoudre le systme par rapport son contexte. La solution qu'apporte le systme ce problme sera traite dans les enchanements d'activits d'analyse, de conception et d'implmentation (voir les chapitres 8, 9 et 10).

6.6.1 Qu'est-ce qu'un modle

du mtier ?

8.5.3 Utilisation du modle

du domaine

D'abord, un modle des cas d'utilisation mtier dcrit les processus mtier d'une entreprise l'aide de cas d'utilisation mtier et d'acteurs mtier qui correspondent respectivement aux processus mtier et aux clients. Tout comme le modle des cas d'utilisation d'un systme logiciel, le modle des cas d'utilisation mtier prsente un systme (ici, le systme mtier) du point de vue de son utilisation et indique la faon dont il rend service ses utilisateurs (ici, ses clients et partenaires) [3, 4, 6].

Les classes du domaine et le glossaire se rvlent utiles au moment de l'laboration du modle des cas d'utilisation et du modle d'analyse :

Bfflfll

Cas d'utilisation mtier L'exemple du Consortium interbancaire offre un cas d'utilisation mtier impliquant l'envoi de commandes, de factures et de rglements entre un acheteur et un vendeur: Ventes : de la commande la l ivraison. Dans ce cas d'utilisation mtier, un acheteur sait ce qu'il veut acheter et qui il veut l'acheter. Dans la squence suivante, le Consortium interbancaire agit, pour ce cas d'utilisation, comme courtier mettant en relation l'acheteur et le vendeur et fournissant des sous-programmes srs pour le rglement des factures : 5. 6. 7. 8. L'acheteur commande les marchandises ou les services. Le vendeur livre les marchandises ou effectue la prestation. Le vendeur facture l'acheteur. L'acheteur paie.

lors de la description des cas d'utilisation et de la conception de l'interface utilisateur, sujet sur lequel nous reviendrons au chapitre 7 ; pour proposer des classes internes au systme pendant l'analyse, thme qui sera trait au chapitre 8. Il existe, toutefois, un moyen encore plus systmatique d'identifier les cas d'utilisation et de imuver les classes d'un systme: l'laboration d'un modle du mtier. Comme nous le verrons, un modle du domaine est un cas particulier d'un modle du mtier plus complet. I A mise au point d'un modle du mtier constitue, par consquent, une alternative puissante au dveloppement d'un modle du domaine.

6.6 C o m p r h e n s i o n du contexte du s y s t m e l'aide d'un modle du mtier

Dans ce contexte, l'acheteur et le vendeur sont les acteurs mtier du Consortium interbancaire et utilisent les cas d'utilisation mtier que procure le Consortium. Une entreprise fournit normalement un grand nombre de cas d'utilisation mtier. Le Consortium interbancaire ne fait pas exception cette gnralit. Nous allons dcrire ici deux de ces cas d'utilisation dans le seul but de dterminer le contexte appropri. En revanche, nous ne traiterons pas des autres processus. Dans le cas d'utilisation Gestion des prts : de la demande au dblocage des fonds, un client de la banque soumet une demande de prt au Consortium interbancaire et reoit les fonds de la banque. Le client de la banque reprsente le client gnrique. L'acheteur et le vendeur sont des types plus spcifiques de clients. Le cas d'utilisation mtier Virer, retirer et dposer de l'argent permet un client de la banque d'effectuer des virements entre comptes, de retirer ou dposer de l'argent. Ce cas d'utilisation permet galement un client de dfinir de futurs virements automatiques. Le modle des cas d'utilisation est dcrit par les diagrammes de cas d'utilisation (voir les chapitres 4 et 7). Un modle objet mtier est un modle interne du mtier. I l dcrit la faon dont chaque cas d'utilisation du mtier est ralis par un groupe de travailleurs utilisant un ensemble d'entits

I .a modlisation du mtier est une technique permettant de comprendre les processus mtier d'une entreprise. Mais qu'en est-il lorsqu'on travaille sur un systme n'ayant rien voir avec ce que la plupart d'entre nous considrent comme un mtier ? Par exemple, comment procder au dveloppement d'un stimulateur cardiaque, d'un systme de freinage anti-verrouillage, d'un contrleur de camra ou d'un systme de tlcommunications ? Dans de tels cas, on peut galement modliser le systme englobant le systme logiciel qu'il s'agit de dvelopper. Ce systme (une partie du corps humain, une partie d'une voiture, la camra, le commutateur) constitue le systme mtier du systme logiciel intgr. I l prend part aux cas d'utilisation du systme de plus haut niveau qu'il convient d'esquisser brivement. L'objectif tant d'identifier les cas d'utilisation du logiciel et les entits mtier pertinentes devant tre prises en charge par ce logiciel, i l suffit de modliser les lments strictement ncessaires la comprhension du contexte. Cette activit se traduit par un modle du domaine issu de la comprhension du fonctionnement du systme mtier qui l'englobe. La modlisation du mtier est prise en charge par deux types de modles UML : le modle des cas d'utilisation et le modle objet [6]. L'un et l'autre sont dfinis dans l'extension d'UML spcifique au mtier.

ymn
mmmM

L e s e n c h a n e m e n t s d ' a c t i v i t s principaux
PARTIE II

Expression des besoins : de la vision aux besoins

CHAPITRE 6

mtier et d'units de travail. Chaque ralisation de cas d'utilisation mtier peut tre montre sous forme de diagrammes d'interactions (voir les chapitres 4 et 9) et de diagrammes d'activits (tels que les diagrammes d'enchanements d'activits des chapitres 7 11). Une entit mtier reprsente une chose, telle qu'une facture, laquelle accdent les travailleurs, qu'il peuvent inspecter, manipuler, produire ou utiliser dans un cas d'utilisation mtier. Une unit de travail est un ensemble de telles entits formant un tout reconnaissable pour un utilisateur final.

Figure 6.4 Acheteur, Vendeur et Gestionnaire de rglements participent au cas d'utilisation mtier Ventes : de la commande la livraison. Le Gestionnaire de rglements vire l'argent d'un compte un autre, selon les indications de la Facture.

Les entits mtier et les units de travail permettent de reprsenter les mmes types de concepts que les classes du domaine, telles que Commande, Article, Facture et Compte. On pourrait donc laborer un diagramme des entits mtier trs proche de la figure 6.3. On ajouterait ensuite d'autres diagrammes, tels que la figure 6.4, pour dcrire les travailleurs, leurs interactions et la faon dont ils utilisent les entits mtier et les units de travail. Chaque travailleur, chaque entit mtier et chaque unit de travail peut prendre part la ralisation de plusieurs cas d'utilisation mtier. Il est trs probable, par exemple, que la classe Compte participera aux ralisations des trois cas d'utilisation mtier suivants : dans Gestion des prts : de la demande au dblocage des fonds, le montant du prt sera vers sur un compte ; dans Virer, retirer et dposer de l'argent : l'argent est tir d'un compte, dpos sur un compte ou vir d'un compte l'autre ; le cas d'utilisation Ventes : de la commande la 1 i vrai son implique un virement du compte de l'acheteur sur le compte du vendeur. fifflH Le cas d'utilisation mtier Ventes : de la commande la livraison Le cas d'utilisation Ventes : de la commande la l i v r a i son se droule selon les tapes suivantes (voir la figure 6.4) :

L'acheteur et le vendeur utilisent le travailleur gestionnaire (automatis) de rglements parce qu'il leur rend service tous les deux : au vendeur, en adressant la facture l'acheteur et en gardant la trace des factures impayes ; l'acheteur, en simplifiant les rglements et en offrant une meilleure visibilit et disponibilit du rglement des factures.

6.6.2 laboration

d'un modle

du

mtier

L'laboration d'un modle du mtier s'articule donc selon deux tapes : 1. les personnes charges de la modlisation mtier doivent d'abord dresser un modle des cas d'utilisation mtier identifiant les acteurs du mtier et les cas d'utilisation mtier auxquels ils prennent part ; 2. il faut ensuite mettre au point un modle objet mtier intgrant les travailleurs, les entits mtier et les units de travail qui, ensemble, ralisent les cas d'utilisation mtier. Les rgles du mtier et toute autre rglementation s'appliquant en la matire sont associes ces diffrents objets. Le but est de crer des travailleurs, des entits mtier et des units de travail ralisant au mieux les cas d'utilisation mtier, c'est--dire rapidement, prcisment et moindre frais.

1. Un acheteur commande des marchandises ou des services en contactant le vendeur. 2. Le vendeur envoie une facture l'acheteur par l'intermdiaire du gestionnaire de rglements. 3. Le vendeur livre les marchandises l'acheteur ou effectue la prestation de service. 4. L'acheteur paie par l'intermdiaire du gestionnaire de rglements, ce qui implique le virement du montant du compte de l'acheteur sur le compte du vendeur. Le gestionnaire de rglements est un employ de la banque contribuant aux tapes 2 et 4. Ces tches peuvent tre automatises par un systme d'information.

La modlisation du mtier et la modlisation du domaine se ressemblent sous bien des aspects. On peut, en fait, envisager la modlisation du domaine comme une variante simplifie de la modlisation du mtier, ne s'attachant qu'aux choses , c'est--dire aux classes du domaine ou aux entits mtier, ncessaires aux travailleurs. Les classes du domaine et les entits mtier tant, par consquent, des concepts trs semblables, nous utilisons indiffremment ces deux termes.
1

Quelques diffrences majeures sparent, toutefois, la modlisation du mtier de la modlisation du domaine, qui plaident nettement en faveur d'une modlisation du mtier plus complte : Les classes du domaine sont issues de la base de connaissances de quelques experts du domaine ou ventuellement des connaissances (par exemple, les autres classes du domaine, les spcifications des besoins, etc.) provenant de systmes semblables au 1. Un modle du domaine tant une variante simplifie du modle du mtier, nous ne citons que ce dernier parmi les entres des enchanements d'activits principaux ultrieurs, tels qu'ils sont prsents dans les chapitres 7 11.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins : de la vision aux besoins

CHAPITRE 6

systme en cours de dveloppement. Pour trouver les entits mlici, en revanche, on pari des clients du mtier, puis on identifie les cas d'utilisation mtier, d'o se dgagent enfin les entits. Dans l'approche de la modlisation du mtier, chaque entit doit tre justifie par sa participation un cas d'utilisation mtier. Ces deux approches aboutissent gnralement des ensembles diffrents de classes, d'associations, d'attributs et d'oprations. L'approche de la modlisation du domaine permet de faire remonter les classes l'exprience des experts du domaine, tandis que l'approche de la modlisation du mtier attribue la ncessit de chaque lment du modle aux clients eux-mmes. Les classes du domaine ont des attributs, mais gnralement peu ou pas d'oprations. I l n'en va pas de mme pour les entits mtier. L'approche de la modlisation du mtier identifie non seulement les entits, mais les travailleurs qui prennent part la ralisation des cas d'utilisation mtier impliquant ces entits. Cette approche permet, en outre, de dterminer l'usage que font les travailleurs de ces entits travers les oprations que chacune d'entre elles doit fournir. En ce qui concerne les entits elles-mmes, ces oprations proviendront galement des clients, dont la trace restera identifiable.

Utilisation de l'approche de la modlisation mtier pour dcrire le Processus unifi (premire partie)
L'approche de la modlisation mtier prsente pour la modlisation de la socit cliente est fondamentalement la mme que celle choisie dans ces pages pour la description du Processus unifi de gnie logiciel. Nous utilisons donc, pour cela, l'extension d'UML spcifique au mtier (voir le chapitre 2). Outre un soubassement thorique solide, celte extension prsente une grande utilit pratique et constitue une sorte d'auto-amorage ou de travail de rflexion : elle expose les forces et les faiblesses de cette approche. Le Processus unifi est donc un cas d'utilisation mtier de l'activit de dveloppement logiciel. Au sein de cette activit, le processus s'organise ou, comme nous le disons, se ralise travers une squence d'enchanements d'activits lis les uns aux autres l'expression des besoins (objet de ce chapitre et du chapitre 7), l'analyse (chapitre 8), la conception (chapitre 9), l'implmentation (chapitre 10) et les tests (chapitre 11). Chaque enchanement d'activits constitue la ralisation d'une partie du cas d'utilisation mtier Processus unifi, dcrit en termes : de travailleurs, tels que l'analyste systme et les spcificateurs de cas d'utilisation ; d'entits mtier (ou, selon notre terminologie, d'artefacts), telles que les cas d'utilisation ou les cas de test ; d'units de travail (qui sont galement des artefacts), telles que le modle des cas d'utilisation et la description de l'architecture. Les travailleurs, entits mtier et units de travail du Processus unifi sont galement dcrits dans les diagrammes de classes UML, avec les principales relations les associant les uns aux autres. (Suite de l'encadr au chapitre 7.)

Les travailleurs recenss par la modlisation mtier servent de point de dpart la mise au jour d'un premier groupe d'acteurs et de cas d'utilisation pour le systme d'information construire. Ce procd permet de faire remonter chaque cas d'utilisation du systme d'information aux clients, par le biais des travailleurs et des cas d'utilisation mtier. Nous reviendrons plus en dtail l-dessus au chapitre 7. I l est possible, partir de chaque cas d'utilisation, de remonter jusqu'aux composants mettant en uvre le systme, comme le dcrit le chapitre 3. On peut donc en conclure que l'association de la modlisation mtier et de l'approche du gnie logiciel propose par le Processus unifi permet de suivre la trace des besoins du client travers les processus, les travailleurs et les cas d'utilisation mtier, jusqu'au code logiciel. Nanmoins, la seule utilisation d'un modle du domaine n'offre pas de traabilit directe entre ce modle et les cas d'utilisation du systme.

6.6.3 Identification des cas d'utilisation partir d'un du mtier

modle

L'utilisation, comme entre, d'un modle du mtier offre une technique systmatique pour la cration d'un modle des cas d'utilisation provisoire. L'analyste identifie d'abord un acteur pour chaque travailleur et chaque acteur mtier (c'est--dire chaque client) destin devenir un utilisateur du systme d'information.
1

RflfflH

L'acteur Acheteur L'acheteur utilise le Systme de facturation et de rglement pour commander des marchandises ou des services et pour rgler les factures. L'acheteur est donc la fois un client et un acteur, car il utilise le systme pour effectuer ses commandes et ses rglements par le biais de deux cas d'utilisation : Commander des marchandises ou des services et Rgler les factures.

r c : ^ t r

acteur pour dsigner un acteur du

> -

co

n f u

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins : de la vision aux besoins

CHAPITRE 6

Chaque travailleur (et acteur mtier) destin devenir un utilisateur du systme d'information doit tre pris en charge par celui-ci. I l faut, pour cela, s'arrter sur chaque travailleur, un par un, et identifier chaque fois toutes les ralisations de cas d'utilisation mtier auxquelles i l participera. Le travailleur joue un rle dans chaque ralisation, tout comme une classe. Une fois que l'on a trouv tous les rles d'un travailleur ou d'un acteur mtier, c'est--dire un rle par ralisation de cas d'utilisation mtier, on peut passer aux cas d'utilisation des acteurs systme. Chaque travailleur et chaque acteur du mtier correspond un acteur du systme d'information. Pour chaque rle d'un travailleur ou d'un acteur mtier, l'acteur systme correspondant aura besoin d'un cas d'utilisation.

6.7 Exigences s u p p l m e n t a i r e s
Les exigences supplmentaires comprennent principalement les exigences non fonctionnelles qui ne peuvent tre associes un cas d'utilisation particulier, chacune influant, au contraire, sur plusieurs cas d'utilisation ou n'ayant d'impact sur aucun d'entre eux. Les besoins en matire de performances, d'interfaces et de conception physique en sont des exemples, de mme que les contraintes d'architecture, de conception ou d'implmentation [1]. L'apprhension de ces exigences supplmentaires s'apparente la spcification tradi tionnelle des besoins, puisque les exigences sont regroupes sous forme de liste. On les utilise ensuite au cours de l'analyse et de la conception, en association avec le modle les cas d'utilisation. Une exigence d'interface spcifie l'interface d'un article externe avec laquelle un systme doit dialoguer ou exprime des contraintes de formats, des obligations temporelles ou d'autres facteurs pertinents dans ce type d'interaction. Une exigence physique prcise les caractristiques physiques que doit prsenter un systme, telles que le type de matriel, la forme, la taille ou le poids. Ce type d'exigence peut permettre, par exemple, de reprsenter les exigences matrielles telles que la configuration du rseau physique ncessaire. MHH Exigences de plate-forme matrielle
Serveurs

Le moyen le plus direct d'identifier un ensemble possible de cas d'utilisation consiste donc crer un cas d'utilisation pour l'acteur correspondant chaque rle de chaque travailleur et de chaque acteur mtier. Si bien que l'on aura, pour chaque cas d'utilisation mtier, un cas d'utilisation par travailleur et par acteur mtier. Aux analystes, ensuite, de dtailler et d'adapter ces propositions de cas d'utilisation. Les analystes doivent galement dcider, parmi les tches des travailleurs ou des acteurs mtier, quelles sont celles qui seront automatises par les systmes d'information (en tant que cas d'utilisation) et rorganiser les cas d'utilisation afin qu'ils rpondent mieux aux besoins des acteurs. Notez que toutes les tches ne sont pas susceptibles d'tre automatises. REKH Identification des cas d'utilisation partir d'un modle du mtier

SUN SPARC 20 ou PC Pentium

Clients

Pour reprendre l'exemple prcdent, on pourrait suggrer un cas d'utilisation nomm Achat de marchandises ou de services, qui prendrait en charge l'acteur Acheteur lorsqu'il se comporte en acteur mtier dans le cas d'utilisation mtier Ventes : de la commande la 1 i vrai son. Une analyse plus pousse laisse apparatre que le cas d'utilisation Achat de marchandises ou de services serait mieux ralis par plusieurs cas d'utilisation distincts, tels que Commander des marchandises ou des servi ces et Rgler la facture. La raison d'une telle scission est qu'un acheteur ne souhaitera pas excuter un cas d'utilisation Achat de marchandises ou de servi ces en une seule squence ininterrompue d'actions. Il prfrera attendre la livraison des marchandises ou la ralisation de la prestation avant de procder au rglement de la facture. C'est pourquoi la squence de rglement est prsente sous la forme d'un cas d'utilisation part, Rgi er la facture, qui sera excut une fois les marchandises livres.

PC (quips au minimum de processeurs Intel 486) ou Sun Sparc 5 Une contrainte de conception influe sur la conception d'un systme. I l peut s'agir de contraintes d'extensibilit ou de capacit de maintenance, ou encore de contraintes concernant la rutilisation de systmes existants ou de certaines parties de ces systmes. Une contrainte d'implmentation spcifie ou impose le code ou la construction d'un systme. Les exemples en sont multiples : standards exigs, directives et langages d'implmentation, politiques d'intgrit des bases de donnes, limites des ressources et environnements de fonctionnement. BfflgH Contraintes de format de fichiers La version 1.2 du Systme de facturation et de rglement prendra en charge les noms de fichier longs. Contraintes de plate-forme logicielle
Logiciel systme

Nous avons vu, dans les pages prcdentes, comment modliser le contexte d'un systme l'aide d'un modle du domaine ou d'un modle du mtier. Puis, nous avons dcouvert comment driver un modle des cas d'utilisation d'un modle du mtier, c'est--dire un modle des cas d'utilisation regroupant tous les besoins fonctionnels d'un systme, ainsi que la plupart des exigences non fonctionnelles. Certaines de ces exigences, ne pouvant tre associes un cas d'utilisation particulier, sont appeles exigences supplmentaires.

Systmes d'exploitation des clients : Windows NT 4.0, Windows 95 ou Solaris 2.6 Systmes d'exploitation des serveurs : Windows NT 4.0 ou Solaris 2.6

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins : de la vision aux besoins

CHAPITRE 6

145

Logiciel de navigation sur Internet

IVAR JACOBSON, "Business process reengineering with object technology " Obiect
Magazine, May 1994.
J

Netscape Communicator 4.0 ou Microsoft Internet Explorer 4.0 ces exigences, s'en ajoutent bien souvent d'autres, comme les exigences lgales et rglementaires. Blffll Autres exigences
Scurit

JAMES RUMBAUGH, M . BLAHA, W. PREMERLANI, F. EDDY, W. LORENSEN

Object-

Oriented Modeling and Design, Englewood Cliffs, NJ: Prentice Hall, 1 9 9 L OMG Unified Modeling Language Spcification. Object Management Group Framtngham, MA, 1998. Internet: www.omg.org.
A L A N M . DAVIS, Software Requirements: Objects, Functions, and States, Englewood

La transmission doit tre sre, c'est--dire que seules les personnes autorises doivent pouvoir accder aux informations. Les seules personnes autorises sont le client de la banque titulaire des comptes et les acteurs administrateurs de systme.
Disponibilit

Cliffs, N J : Prentice Hall, 1993.

Le Systme de facturation et de rglement ne doit pas tre indisponible plus d'une heure par mois.
Facilit d'apprentissage

Le temps d'apprentissage (par le biais d'instructions pas pas fournies par le systme) permettant de soumettre des commandes simples et de rgler des factures simples ne doit pas excder 10 minutes pour 90% des acheteurs. Une commande simple est une commande ne comportant qu'un seul article. Une facture simple est une facture correspondant au rglement d'une seule commande.

6.8 R s u m
ce stade, nous sommes parvenus une bonne comprhension de l'expression des besoins. Nous avons dcouvert en quoi les modles du mtier et du domaine contribuent la dfinition du contexte du systme et de quelle faon les cas d'utilisation pouvaient tre drivs d'un modle du mtier. Nous avons vu que les cas d'utilisation servaient l'expression des besoins, sujet sur lequel nous revenons dans le chapitre suivant. Les chapitres qui suivent montreront en quoi les cas d'utilisation et les exigences supplmentaires aident analyser le systme, en crer l'architecture, le concevoir, l'implmenter et le tester, de faon satisfaire aux exigences des clients.

6.9 R f r e n c e s
1 2 I E E E Std 610.12.1990. IVAR JACOBSON, MAGNUS CHRISTERSON, PATRIK JONSSON, and GUNNAR VERGAARD, Object-Oriented Software Engineering: A Use-Case-Driven Approach,

Reading, MA: Addison-Wesley, 1992 (Revised fourth printing, 1993).

3 IVAR JACOBSON, M A R I A ERICSSON, and AGNETA JACOBSON, The Object Advantage: Business Process Reengineering with Object Technology, Reading, MA: Addison-

Wesley, 1994.

7
Expression des besoins sous forme de cas d'utilisation
7.1 Introduction
Le principal objectif de l'expression des besoins est l'laboration d'un modle du systme construire. L'emploi des cas d'utilisation constitue un excellent moyen de procder la cration de ce modle, car les besoins fonctionnels sont naturellement structurs comme des cas d'utilisation. Par ailleurs, la plupart des besoins non fonctionnels tant spcifiques un cas d'utilisation unique, ils sont galement traits dans le cadre prcis de ce cas d'utilisation. Les autres besoins non fonctionnels, ceux qui sont communs une partie ou la totalit des cas d'utilisation, sont consigns dans un document part et dsigns sous le nom d'exigences supplmentaires. Ces exigences ont t dcrites au chapitre 6 et ne seront pas rexamines avant leur intervention dans les enchanements d'activits de l'analyse, de la conception, de l'implmentation et des tests. Les cas d'utilisation offrent un moyen la fois systmatique et intuitif de saisir les besoins fonctionnels sous l'angle particulier de l'intrt qu'ils prsentent pour chaque utilisateur ou chaque systme externe. Le recours aux cas d'utilisation oblige les analystes rflchi] a l'identit des utilisateurs et aux besoins professionnels, gnraux ou spcifiques une mission, qu'il faut satisfaire. Toutefois, comme nous l'avons indiqu au chapitre 4, les cas d'utilisation n'auraient sans doute pas emport l'adhsion gnrale si leur intrt s'arrtait l. Le rle essentiel qu'ils jouent dans le pilotage du travail de dveloppement a largement contribu leur intgration au sein des principales approches de l'ingnierie logiciellecontemporaine [8]. Dans ce chapitre, nous allons approfondir notre comprhension des cas d'utilisation et des acteurs et prciser les dfinitions avances au chapitre 3. La description de l'enchanement d'activits des besoins s'articulera autour de trois axes (nous procderons de mme pour les autres enchanements d'activits dans les chapitres 8 11) :

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins sous forme de cas d'utilisation

CHAPITRE 7

les artefacts crs dans l'enchanement d'activits des besoins ; les travailleurs prenant part cet enchanement d'activits ; une vision plus dtaille de chaque activit de l'enchanement d'expression des besoins. Nous allons, pour commencer, examiner les travailleurs et artefacts qu'illustre la figure 7.1

O
O

O
O
Archltoctu

Spcificateur de cas d'utilisation

responsable de

Concepteur d'interface utilisateur

responsable de

Figure 7.1 Travailleurs et artefacts impliqus dans l'expression des besoins sous forme de cas d'utilisation.

roN|><iM'.,ibl.i il..

Approche de la modlisation mtier utilise pour dcrire le Processus unifi (deuxime partie)

Modle des cas d'utilisation

Prototype Cas d'utilisation d'interface utilisateur

Description do l'archltocHiia

7.2 Artefacts
Le principal artefact participant de l'expression des besoins est le modle des cas d'utlU sation, qui regroupe tous les cas d'utilisation et les acteurs, auquel peuvent ventuellement s'ajouter d'autres types d'artefacts tels que les prototypes d'interface utilisateur. Dj sommairement prsents au chapitre 3, ces artefacts reoivent ici des dfinitions plus prcises, concordant avec celles livres dans [12]. Nous en assouplirons ensuite le formalisme pour montrer l'application relle de ces constructions dans le Processus unifi. Ces dfinitions permettent d'tablir des fondations solides, mais i l n'est pas obligatoire de respecter un tel formalisme dans la pratique. Nous les intgrons ici pour les raisons suivantes : i l peut tre important de les connatre lors de la description formelle de certains cas d'utilisation, comme l'emploi de diagrammes d'activits ou d'tats-transitions, particulirement apprciables pour les cas d'utilisation comportant de nombreux tats, eux-mmes relis par des transitions complexes ; elles facilitent l'identification des cas d'utilisation adquats et la cohrence de leur description. En fait, mme si vous choisissez de ne pas utiliser le formalisme propos lors de la description, par exemple, des acteurs ou des cas d'utilisation, i l est bon de l'avoir l'esprit afin de produire un rsultat complet et cohrent ; i l faut aussi pouvoir expliquer les constructions acteur et cas d'utilisation par rapport d'autres constructions UML.

Nous identifions ici les travailleurs et artefacts prenant part chaque enchanement d'activits. Un travailleur reprsente une fonction pouvant tre attribue une personne ou une quipe et spcifie les responsabilits et capacits que celle-ci suppose (voir galement la section 2.1.3). Artefact est un terme gnrique dsignant tout type de description ou d'information susceptible d'tre cr, produit, modifi ou encore utilis par les travailleurs dans le cadre de leur travail sur le systme. Il peut s'agir d'un modle, d'un lment de modle ou d'un document. Dans l'enchanement d'activits des besoins, par exemple, les artefacts se limitent essentiellement au modle des cas d'utilisation et aux cas d'utilisation qui le composent. Notez que dans le modle du mtier du Processus unifi, un artefact est une entit mtier ou une unit de travail. Chaque travailleur a la responsabilit d'un ensemble d'artefacts, comme le montrent les diagrammes en reliant, par une association nomme responsable de, un travailleur aux artefacts leur correspondant (voir, par exemple, la figure 7.1). Afin de renforcer l'intuitivit de ces diagrammes, nous utilisons des symboles spciaux pour la plupart des artefacts : les artefacts reprsentant des documents sont dsigns par un symbole de document, tandis que les modles ou lments de modles s'affichent avec le symbole UML qui les identifie. Remarquez que pour pouvoir utiliser ces symboles spciaux dans le modle du mtier du Processus unifi, nous introduisons des strotypes de documents, de modles et d'lments de modle. Chacun de ces strotypes est un sous-type des strotypes e n t i t mtier ou unit de t r a v a i l . Nous dcrivons les modalits de la collaboration des travailleurs un enchanement d'activits en insistant sur la faon dont le point de vue se dplace de travailleur en travailleur et en expliquant la manire dont ils utilisent les artefacts pour mener bien leurs diffrentes activits (voir galement la section 2.4.2). C'est dans ce contexte que nous allons aussi examiner plus prcisment chaque activit. Une activit est une tche qu'effectue un travailleur pendant l'enchanement d'activits, c'est--dire l'excution de l'une des oprations lies au travailleur.

7.2.1 Artefact : modle

des cas d'utilisation

Le modle des cas d'utilisation permet de parvenir un accord entre le client et les dveloppeurs sur les besoins [6], c'est--dire sur les conditions que le systme doit respecter et les possibilits qu'il doit offrir. Ce modle sert de contrat et fournit les entres principales pour l'analyse, la conception et les tests. Un modle des cas d'utilisation est un modle d'un systme contenant les acteurs, les cas d'utilisation et les relations qu'ils entretiennent les uns avec les autres (voir lafigure7.2).

I nu e n c h a n e m e n t s d ' a c t i v i t s principaux Al II II
II

Expression des besoins s o u s forme de c a s d'utilisation

CHAPITRE 7 '

Hum t.2 i
.i.l,-des cas
IM

1
r~l+ fi

Figure 7.3 L'acteur Acheteur.

non cl son /,

Modledes cas d'utilisation

Systmedes cas d'utilisation . Un acteur joue un rle diffrent dans chaque cas d'utilisation auquel i l collabore. chaque fois qu'un utilisateur particulier (un humain ou un autre systme) dialogue avec le systme, c'est l'instance correspondante de l'acteur qui joue ce rle. Une instance d'un acteur esl donc un utilisateur spcifique dialoguant avec le systme. Toute entit obissant la dfi nition d'un acteur peut agir en tant qu'instance de cet acteur.

\'Hir des cas d utilisation lr)itfMille le tagr de niveau suprieur

Acteur

Cas d'utilisation

7.2.3 Cas d'utilisation

Chaque usage que les acteurs font du systme est reprsent par un cas d'utilisation. Les cas d'utilisation sont des parcelles de fonctionnalits qu'offre le systme afin de produire un rsultat satisfaisant pour ses acteurs. De faon plus stricte, un cas d'utilisation spcifie une squence d'actions (accompagne des autres squences possibles) que le systme pcul effectuer en dialoguant avec les acteurs du systme. Un cas d'utilisation constitue donc une spcification, en ce qu'il dfinit le comportement d' lments dynamiques, en l'occurrence les instances de cas d'utilisation. fifflfl Le cas d'utilisation Retirer de l'argent Nous avons dcrit, au chapitre 3, le cas d'utilisation Retirer de l'argent, qui permet des instances de l'acteur Cl i ent de la banque de retirer de l'argent par l'intermdiaire d'un guichet automatique de banques (GAB) (figure 7.4).
Figure 7.4 Cas d'utilisation Retirer de l'argent.

I .c modle des cas d'utilisation pouvant s'toffer au point d'tre difficile digrer en une Seule fois, il faut trouver un moyen de l'apprhender morceau par morceau. UML permet de prsenter ce modle sous forme de diagrammes faisant apparatre les acteurs et les cas d'utilisation de diffrents points de vue et selon des intentions diversifies. Notez galement que si le modle des cas d'utilisation est important, c'est--dire s'il contient un grand nombre de cas d'utilisation et/ou d'acteurs, i l peut tre utile d'y introduire des paquetages afin d'en grer la taille. Il s'agit l d'une extension plus ou moins triviale du modle des cas d'utilisation, qui n'est pas traite dans cet ouvrage.

7.2.2

Artefact : acteur

O
Retirer de l'argent

Le modle des cas d'utilisation dcrit le rle que joue le systme pour chaque type d'utilisaleur, reprsent par un ou plusieurs acteurs. Chaque systme externe avec lequel dialogue le systme est galement reprsent par un ou plusieurs acteurs. Sont considres comme externes au systme toutes les units autonomes, telles que les horloges. Les acteurs reprsentent par consquent les parties extrieures au systme qui collaborent avec celui-ci. Une fois que l'on a identifi tous les acteurs d'un systme, on a identifi l'environnement externe du systme. Comme l'explique le chapitre 6, les acteurs correspondent souvent aux travailleurs (ou acteurs mtier) d'une entreprise. N'oubliez pas que chaque rle (d'un travailleur) dfinit ce que fait ce travailleur au sein d'un processus mtier spcifique. On peut ensuite utiliser les diffrents rles que peut jouer un travailleur pour driver (ou gnrer, si l'on dispose des outils appropris) les rles que jouera l'acteur systme correspondant. Puis, comme le suggre le chapitre 6, on fournit chaque travailleur un cas d'utilisation du systme pour chacun de ses rles. Ce cas d'utilisation prsente un intrt pour l'acteur lorsqu'il incarne le rle du travailleur. Acteur Le Systme de facturation et de rglement dinterbankdialogue avec un type d'utilisateur qui emploiera le systme pour commander des marchandises, confirmer des commandes, rgler des factures, etc. Ce type d'utilisateur est ensuite reprsent par l'acteur Acheteur (figure 7.3).

Le cas d'utilisation Reti rer de l'argent indique les possibles instances de ce cas d'utilisation, c'est--dire les diffrentes faons dont il peut tre lgitimement excut par le systme et l'interaction ncessaire avec les instances de l'acteur impliqu. Imaginons qu'une personne du nom de Patrick saisisse son code Secret, 1234, choisisse de retirer 300 francs et obtienne le montant demand. Le systme effectue alors l'une des instances du cas d'utilisation. Si, en revanche, Patrick saisit le mme code secret, demande 400 francs puis rcupre l'argent, le systme excute une autre instance du cas d'utilisation. On obtient F excution d'une troisime instance du cas d'utilisation si Patrick demande retirer 700 francs et que le systme rejette cette demande en raison d'un solde insuffisant ou d'un code secret incorrect ; ainsi de suite. Dans la terminologie UML, un cas d'utilisation est un classificateur, ce qui signifie qu'il esl dot d'oprations et d'attributs. Une description de cas d'utilisation peut donc comprendre des diagrammes d'tats-transitions, d'activits, de collaboration et de squence (pour de plus amples dtails, voir l'annexe A, Prsentation gnrale d'UML ).

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins s o u s forme de cas d'utilisation^

CHAPITRE 7

Les diagrammes d'tats-transitions spcifient le cycle de vie des instances de cas d'utilisation sous forme d'tats et de transitions entre ces tats. Chaque transition est une squence d'actions. Les diagrammes d'activits reprsentent plus prcisment ce cycle de vie en dcrivant galement la squence d'actions se produisant entre deux transitions. Enfin, les diagrammes de collaboration et de squence servent dcrire l'interaction ayant lieu, par exemple, entre une instance d'acteur typique et une instance de cas d'utilisation typique. En pratique, i l n'est pas ncessaire d'tre aussi formel pour la reprsentation des cas d'utilisation, comme nous le dirons dans la section 7.4.3, Dtailler un cas d'utilisation . Le fait d'avoir en tte cette comprhension plus prcise des cas d'utilisation peut toutefois se rvler utile lors de la structuration des descriptions de cas d'utilisation. Une instance de cas d'utilisation est l'excution d'un cas d'utilisation. En d'autres termes, c'est ce qu'effectue le systme lorsqu'il obit un cas d'utilisation . Lorsqu'une instance de cas d'utilisation est excute, elle dialogue avec les instances des acteurs et effectue la squence d'actions dcrite par le cas d'utilisation sous la forme d'un diagramme d'tatstransitions ou d'activits. Cette squence constitue l'un des chemins possibles du cas d'utilisation. De nombreux chemins peuvent tre emprunts, dont beaucoup sont trs proches les uns des autres. Ce sont les solutions de rechange la squence d'actions du cas d'utilisation. Un tel chemin pourrait se drouler de la faon suivante : 1. 2. 3. L'instance de cas d'utilisation est lance et place en tat de dbut. Elle est invoque par un message externe manant d'un acteur.

autres conflits potentiels (tels que le partage d'objets) entre diffrentes instances de cas d'utilisation. Les instances de cas d'utilisation sont envisages comme tant atomiques : chacune est excute de faon complte ou pas du tout, sans aucune interfrence avec d'autres instances du cas d'utilisation. Le comportement de chaque cas d'utilisation peut donc tre interprt indpendamment des autres cas d'utilisation, ce qui simplifie considri blement la modlisation des cas d'utilisation. Le fait de considrer que les cas d'utilisation sont atomiques n'a rien voir avec la prsence ventuelle d'un gestionnaire de transaiItioni sous-jacent aux cas d'utilisation, qui serait charg de rgler les conflits. Il ne s'agit ici que de s'assurer que le modle des cas d'utilisation est lisible et comprhensible. Il faut nanmoins admettre que l'on risque d'tre confront certains problmes d'interfl rences entre les diffrentes utilisations d'un systme. La rsolution de ces problmes ne pourra pas tre prise en charge par la modlisation des cas d'utilisation, mais sera diffre aux phases d'analyse et de conception (dcrites respectivement dans les chapitres 8 et 9), ou les cas d'utilisation seront raliss sous forme de collaborations entre classes et/ou sou tmes. Par exemple, le modle d'analyse permet de dcrire trs clairement la faon dont une seule classe peut participer plusieurs ralisations de cas d'utilisation et le moyen de rsoudre les problmes d'interfrences qui risquent d'en rsulter.

Modlisation
s

de vastes

systmes

ans cet ouvrage, nous allons insister sur la modlisation d'un seul et mme systme Ma, dans bien des cas, les systmes dvelopper sont plus vastes coZses enTait
tmes
63 S y S t m 6 S

Elle passe un autre tat en effectuant une autre squence d'actions pouvant contenir des calculs internes, la slection d'un chemin et l'mission de messages ( l'intention d'un acteur). Elle attend (dans ce nouvel tat) un autre message externe d'un acteur. Elle est (de nouveau) invoque par un message, et ainsi de suite. Ce cycle peut se poursuivre sur de nombreux tats avant qu'il ne soit misfinau cas d'utilisation.

'
N

U S

d S i 9 n 0 n S

C S t y p e

d e

s o u s

l e

"m*

J X ? * . ?

4. 5.

C'est le plus souvent une instance d'acteur qui invoque une instance de cas d'utilisation, comme nous l'avons dcrit plus haut, mais ce peut aussi tre un vnement interne au systme, comme le dclenchement d'une horloge rgle cet effet (si l'horloge est considre comme interne au systme). Les cas d'utilisation, comme tous les classificateurs, ont des attributs qui reprsentent les valeurs qu'utilise et que manipule une instance de cas d'utilisation pendant l'excution de son cas d'utilisation. Ces valeurs sont locales l'instance du cas d'utilisation, c'est--dire qu'elles ne peuvent tre utilises par d'autres instances de cas d'utilisation. Par exemple, le cas d'utilisation Retirer de l'argent pourrait tre dot d'attributs tels que code secret, compte et montant retirer.

L'un des plus grands systmes au monde Le plus grand systme jamais construit par des humains compte prs d'un milliard d'utilisateurs : il s'agit du rseau mondial de tlcommunications. Lorsque vous tlphonez, par exemple, de San Francisco Stockholm, votre appel passe sans doute par une vingtaine de systmes de commutation locaux et internationaux, de systmes de liaison par satellite, de systmes de transmission, etc. Le dveloppement de chacun de ces types de systme a cot environ 1 000 annes-homme, investissement dont l'aspect logiciel reprsente une part essentielle. Le plus incroyable est que, dans la plupart des cas, cela fonctionne ! tant donn la complexit du projet et la diversit des personnes, des entreprises et des pays impliqus, comment est-ce possible ? La principale explication tient la standardisation de l'ensemble des interfaces du rseau (c'est-dire de l'architecture du rseau) par un seul et mme organisme : l'ITU (International Tlcommunications Union). L'ITU a spcifi les interfaces entre tous les types de nuds du rseau et dfini prcisment la smantique utilise par ces interfaces.

Les instances de cas d'utilisation n'exercent pas d'interaction avec d'autres instances de cas d'utilisation. Le seul type d'interactions figurant dans le modle des cas d'utilisation relie les instances d'acteurs aux instances de cas d'utilisation [10]. I l faut, en effet, que le modle des cas d'utilisation reste simple et intuitif afin de susciter des discussions fructueuses, et qui ne se perdent pas dans les dtails, avec les utilisateurs finals et les autres intervenants. I l n'est pas question de se proccuper des interfaces entre cas d'utilisation, de la concurrence et des

(suite page suivante)

Les e n c h a n e m e n t s d ' a c t i v i t s principaux rMIIIC II

Expression des besoins sous forme de c a s d'utilisation

CHAPITRE 7

tionnelles devant tre gres dans les enchanements d'activits ultrieurs comme ceux d'analyse, de conception et d'implmentation. Nous donnons des exemples d'exigences particulires lies un cas d'utilisation dans la section 7.4.3, Activit : dtailler un cas d'utilisation .

7.2.4 Artefact : description de l'architecture (vue du modle des cas d'utilisation)

La description de l'architecture contient une vue architecturale du modle des ras il'uiili sation qui prsente les cas d'utilisation significatifs sur ce plan (figure 7.5).
Figure 7.5 Description de l'architecture.

Description de l'architecture
vue architecturale

La construction de systmes de systmes s'appuie sur des techniques semblables celles qui ont servi laborer le rseau de tlcommunications mondial [9]. L'ensemble du systme est d'abord spcifi avec ses cas d'utilisation et conu sous forme de collaborations entre sous-systmes. La somme des cas d'utilisation du systme global est ensuite dtaille en cas d'utilisation des sous-systmes collaborant, eux-mmes relis par l'intermdiaire d'interfaces. La dfinition prcise de ces interfaces permet de faire dvelopper indpendamment chaque sous-systme (comme un systme part entire) par une organisation part. UML prend en charge ce type d'architecture et il est possible d'tendre le Processus unifi pour mettre au point de tels systmes [13]. En fait, les cas d'utilisation permettent de spcifier non seulement des systmes, mais aussi des entits plus modestes, telles que des sous-systmes ou des classes. Un soussystme, ou une classe, peut alors comprendre deux parties dcrivant chacune un point de vue diffrent : une spcification et une implmentation. La spcification dcrit en termes de cas d'utilisation ce que produit le sous-systme ou la classe pour son environnement, tandis que la partie implmentation en prsente la structure interne, qui permettra de raliser la spcification. Cet environnement se compose gnralement d'autres sous-systmes et classes. Mais si l'on veut le traiter de faon anonyme, on peut galement le faire reprsenter par ses acteurs. Le choix de cette approche s'impose lorsque l'on veut traiter un sous-systme comme un systme part entire, par exemple : lorsque l'on veut dvelopper le sous-systme l'aide d'une technologie diffrente de celle utilise pour les autres sous-systmes. Cette possibilit existe condition que les cas d'utilisation appropris soient proposs et que les interfaces spcifies soient prises en charge ; lorsque l'on souhaite grer le sous-systme sparment des autres sous-systmes, ventuellement sur des sites gographiquement disperss.

Modle des cas d'utilisation La vue architecturale du modle des cas d'utilisation doit inclure les cas d'utilisation dcrivant des fonctionnalits stratgiques ou impliquant certaines exigences fondamentales qui doivent tre prises en charge au dbut du cycle de vie du logiciel. Cette vue architecturale sert d'entre lors de la dfinition de l'ordre de priorit des cas d'utilisation dvelopper (c'est--dire analyser, concevoir et implmenter) au sein d'une itration. Ce sujet est trait plus prcisment dans les premire et troisime parties de l'ouvrage (voir le chapitre 4, section 4.3, et le chapitre 12, section 12.6). Les ralisations correspondantes des cas d'utilisation se trouveront en principe dans les vues architecturales des modles d'analyse et de conception (voir le chapitre 4, section 4.5, le chapitre 8, section 8.4.5, et le chapitre 9, section 9.3.6).

7.2.5 Artefact : glossaire

Un glossaire permet de dfinir les termes qu'utilisent les analystes (et les autres dve loppeurs) pour dcrire le systme, et de parvenir ainsi un consensus entre dveloppeurs NUI la dfinition des divers concepts et notions, tout en limitant les risques de malentendu. On peut, en gnral, driver un glossaire d'un modle du mtier ou d'un modle du domaine, mais son moindre formalisme (il ne comprend ni classes, ni relations explicites) en fait Un outil plus facile mettre jour et plus intuitif pour l'change de points de vue avec II parties externes telles que les utilisateurs et les clients. De plus, un glossaire sera souvent

7.2.3.1 Flot d ' v n e m e n t s I ,c Ilot d'vnements de chaque cas d'utilisation peut tre exprim sous forme de description textuelle de la squence d'actions du cas d'utilisation. Il indique ce que fait le systme et la faon dont il dialogue avec les acteurs lors de l'excution de ce cas d'utilisation. I )u point de vue de la gestion, une description de flot d'vnements comprend un ensemble de squences d'actions susceptibles d'tre modifies, rvises, conues, implmentes et lestes ensemble, et de faire l'objet d'une mme section ou sous-section du manuel de l'utilisateur. Nous donnerons quelques exemples de descriptions de flots d'vnements lies des cas il'utilisation dans la section 7.4.3, Activit : dtailler un cas d'utilisation . 7.2.3.2 Exigences particulires Les exigences particulires se prsentent sous forme de description textuelle regroupant toutes les exigences pesant sur un cas d'utilisation. I l s'agit avant tout d'exigences non fonc-

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

^ ^ ^ ^ ^
CHAPITRE 7

Figure 7.6 Responsabilits d'un analyste systme au moment

plus cibl sur le systme construire que sur le conlexle le ce systme, contrairement au modle du mtier ou du domaine.

.2.6 Artefact : prototype d'interface utilisateur

a
/

de l'expression des besoins sous forme de cas d'utilisation.

Analyste systme

responsable de

I ~

Les prototypes d'interface utilisateur contribuent, au cours de l'expression des besoins, faciliter la comprhension et la spcification des interactions entre les acteurs humains et le systme. Ces prototypes ne contribuent pas seulement la mise au point d'une meilleure interface utilisateur ; ils aident aussi mieux apprhender les cas d'utilisation. D'autres artefacts, tels que des modles d'interfaces utilisateur et des esquisses d'cran, peuvent galement tre utiliss lors de la spcification de l'interface utilisateur. Consultez [2, 4, 6, 10, 11, 12] pour de plus amples informations sur les acteurs et les cas d'utilisation, et [14] sur la conception d'interfaces utilisateur.

Modle des cas d'utilisation

Glossaire

.3 Les travailleurs
Nous avons dcrit, un peu plus haut dans ce chapitre, les artefacts produits au cours de la modlisation des cas d'utilisation. L'tape suivante nous conduit maintenant examiner les travailleurs chargs de ces artefacts.

Bien qu'il ait la charge du modle des cas d'utilisation et des acteurs que contient celui ci, l'analyste systme n'est pas responsable de chaque cas d'utilisation en particulier II s'agit lit d'une responsabilit part, confie au travailleur spcificateur de cas d'utilisation (section 7.3.2). L'analyste systme dirige, cependant, la modlisation et coordonne l'expression des besoins. Il y a un analyste systme par systme. Nanmoins, la pratique montre que ce travailleur est gnralement pris en charge par une quipe comprenant un grand nombre d'analystes (rpartis en ateliers, par exemple).

7.3.2 Travailleur : spcificateur

de cas d'utilisation

La plupart du temps, la tche qui consiste formuler les besoins ne peut tre accomplie par une seule personne. L'analyste systme s'entoure donc d'autres travailleurs, chacun tant responsable de la description dtaille d'un ou de plusieurs cas d'utilisation. On appelle ces travailleurs spcificateurs de cas d'utilisation (figure 7.7).
Figure 7.7 Responsabilits d'un de cas spcificateur d'utilisation O

O Spcificateur de cas d'utilisation

au moment de l'expression des besoins sous forme de cas d'utilisation.

Comme nous l'avons vu au chapitre 2, un travailleur est un poste auquel peut tre affecte une personne relle . Chaque travailleur s'accompagne d'une description des responsabilits qui lui sont attribues et du comportement qui en est attendu. Travailleur n'est pas synonyme d'individu ; une personne peut tre affecte plusieurs travailleurs au cours d'un projet. De mme, un travailleur ne correspond pas un titre ou un poste particulier dans une entreprise ; mais c'est une autre question. On peut dire, en fait, qu'un travailleur correspond au versant abstrait d'un humain ayant certaines capacits ncessaires un cas d'utilisation mtier, en l'occurrence le Processus unifi d'ingnierie logicielle. Dans le cadre de l'affectation du personnel un projet, un travailleur reprsente les connaissances et les capacits dont une personne doit disposer pour incarner ce travailleur sur le projet. On peut identifier trois types de travailleurs prenant part la modlisation des cas d'utilisation, chacun ayant un ventail diffrent de comptences et de responsabilits : l'analyste systme, le spcificateur de cas d'utilisation et le concepteur d'interface utilisateur. Tous ces travailleurs seront dsigns collectivement sous le nom d' analystes dans cet ouvrage. D'autres travailleurs qui interviennent galement, comme les rviseurs, ne seront pas voqus ici.

responsable de

'.3.1 Travailleur : analyste

systme

Cas d'utilisation

l -

L'analyste systme a la responsabilit de l'ensemble des besoins modliss en tant que cas d'utilisation, y compris des besoins fonctionnels et non fonctionnels spcifiques un cas d'utilisation. L'analyste systme est charg de dlimiter le systme, d'identifier les acteurs et les cas d'utilisation et de s'assurer que le modle des cas d'utilisation est la fois complet et cohrent. Pour le respect de cette cohrence, l'analyste systme peut avoir recours un glossaire, qui permettra de fixer les termes, notions et concepts employs dans le projet une fois les besoins exprims. La figure 7.6 illustre les responsabilits qu'assume l'analyste systme.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins sous forme de c a s d'utilisation

CHAPITRE 7

7.3.3 Travailleur : concepteur d'interface utilisateur

7.4 E n c h a n e m e n t d'activits
Aprs avoir dcrit, dans la section prcdente, l'enchanement des activits permettant la prise en compte des besoins en termes statiques, nous allons dsormais en prsenter le comportement dynamique sous forme de diagramme d'activits (figure 7.10).
Figure 7.10 ... ^ ...

Les concepteurs d'interface utilisateur faonnent' l'aspect visuel de l'interface utilisateur. Cette tche peut ncessiter la cration de prototypes d'interface utilisateur pour certains cas d'utilisation, en gnral d'un prototype par acteur (figure 7.8). I l convient donc de laisser chaque concepteur d'interface utilisateur dessiner l'interface utilisateur d'un ou plusieurs acteurs.
I Igure7.8

O
D

O O
Analyste Analyste systme O

Responsabilits
Jim concepteur il interface

Concepteur d'Interface utilisateur

responsable de

Identifier les acteurs et les cas d'utilisation

Structurer le modle des cas d'utilisation

utilisateur au

/ /
1
/

Enchanement d'activits d'expression des besoins sous forme de cas d'utilisation, avec les travailleurs y prenant part et leurs activits.

a
Architecte O

moment de l'expression des besoins sous forme de eus d'utilisation.

1
Q
Prototype d'interface utilisateur

Assigner un ordre de priorit aux cas d'utilisation

^

n
Spcificateur de cas d'utilisation O Concepteur d'interface utilisateur

Dtailler un cas d'utilisation

7 34 Travailleur : architecte
L'architecte prend part l'enchanement d'activits des besoins pour dcrire la vue architecturale du modle des cas d'utilisation (figure 7.9).
Figure 7.9

Prototyper l'interface utilisateur

Responsabilits
.l'un architecte au moment de {'expression des besoins sous forme de cas d'utilisation.

O
Architecte
responsable de

vue architecturale Modle des cas d'utilisation

Description de l'architecture

La vue architecturale du modle des cas d'utilisation est une entre ^portante fication des itrations, comme le dcrit la section 7.4.2, Activtt: defimr un ordre de priorit pour les cas d'utilisation .
V

Le diagramme matrialise la rpartition des activits entre les divers intervenants grce des traves pareilles des couloirs de natation. Chaque activit (reprsente par un engrenage) est ainsi place dans la mme zone que le travailleur charg de l'effectuer. L'excution de ces activits conduit la cration, puis la modification de divers artefacts. Nous dcrivons cet enchanement comme une squence d'activits ordonnes de sorte que chacune d'entre elles produise un rsultat qui servira de point de dpart l'activit suivante. Le diagramme d'activits ne prsente toutefois qu'un flux logique. Dans la ralit, i l n'est pas indispensable de mener ces activits de faon squentielle du moment que l'on parvient un rsultat final quivalent . On pourrait, par exemple, commencer par identifier certains cas d'utilisation (l'activit Identifier les acteurs et les cas d'utilisation),puis concevoir l'interface utilisateur (l'activit Crer le prototype de l'interface u t i l isateur), pour s'apercevoir finalement qu'il convient d'ajouter un autre cas d'utilisation (d'o un retour l'activit Identifier les acteurs et les cas d'util isation, ce qui rompt la squence strictement dfinie), et ainsi de suite. Une activit peut ainsi tre reprise plusieurs fois, chacun de ces passages n'aboutissant qu' la ralisation partielle de l'activit. I l est par exemple possible que le retour sur l'activit Identifier les acteurs et les cas d'util isation ne permette l'identification que d'un seul cas d'utilisation. Les chemins conduisant d'une activit une autre se bornent par consquent illustrer la squence logique des activits en utilisant les rsultats issus d'une activit termine comme point de dpart de l'excution d'une autre activit.

de conception et d'implmentation.

I o e n c h a n e m e n t s d ' a c t i v i t s principaux
Mm un n

Expression des besoins sous forme de cas d'utilisation

CHAPITRE 7

de ses utilisateurs et d'autres analystes prenant part aux ateliers de modlisation dirigs par l'analyste systme.
Figure 7.11

Entres et rsultats de l'identification des acteurs et des cas d'utilisation.

n
Modle du mtier [ou modle du domaine] Analyste systme

>
Exigences supplmentaires -v Identifier les acteurs et les cas d'utilisation

Modle des cas d'utilisation [esquisse]

Dans un premier temps, l'analyste systme (une personne entoure d'une quipe d'analystes) effectue l'activit Identifier les acteurs et les cas d'utilisation pour laborer une premire version d'un modle des cas d'utilisation dont les acteurs et les cas d'utilisation sont identifis. I l doit ensuite s'assurer que le modle des cas d'utilisation en cours de dveloppement prend en compte les besoins l'origine de l'enchanement d'activits, c'est-dire la liste des fonctionnalits et le modle du domaine ou du mtier. Puis le ou les architectes doivent identifier les cas d'utilisation significatifs sur le plan architectural afin de permettre l'tablissement d'un ordre de priorit des cas d'utilisation (et, ventuellement, d'autres besoins) dans l'itration en cours. En partant de ces lments, les spcificateurs de cas d'utilisation (diffrentes personnes) dcrivent tous les cas d'utilisation identifis comme prioritaires. peu prs en mme temps, les concepteurs des interfaces utilisateur (diffrentes personnes) se fondent sur ces descriptions pour suggrer des interfaces utilisateur appropries pour chaque acteur. Enfin, l'analyste systme remanie le modle des cas d'utilisation pour le rendre aussi comprhensible que possible en tablissant des gnralisations entre cas d'utilisation. (Les gnralisations induites par l'activit Structurer le modle des cas d'util i sati on sont brivement justifies.) U s rsultats de la premire itration mene sur cet enchanement d'activits constituent une premire version du modle des cas d'utilisation, des cas d'utilisation eux-mmes et de tout prototype d'interface utilisateur associe. Les itrations suivantes produiront, leur tour, de nouvelles versions de ces artefacts. Gardez l'esprit que tous les artefacts seront finaliss et amliors de faon incrmentale, au fil des itrations.

Liste des fonctionnalits

Glossaire

Il arrive que l'on dispose d'un modle du mtier comme point de dpart. Cette opportunit permet l'quipe de crer, de faon plus ou moins automatique , une premire esquisse du modle des cas d'utilisation. I l faudra, dans d'autres cas, se fonder sur un modle du domaine ou encore se contenter d'une bauche trs sommaire ou d'une spcification dtaille des besoins comprenant les fonctions gnrales exiges de la part du systme. Enfin, l'quipe d'analyse pourra se voir remettre une liste d'exigences supplmentaires n'ayant pu tre alloues des cas d'utilisation individuels. Pour en savoir plus sur ces diffrents artefacts fournis comme points de dpart, consultez le chapitre 6. Cette activit se dcompose en quatre tapes : identifier les acteurs ; identifier les cas d'utilisation ; dcrire brivement chacun des cas d'utilisation ; dcrire de faon globale le modle des cas d'utilisation (cette tape comprend galement l'laboration d'un glossaire).

Les diverses activits lies la modlisation des cas d'utilisation revtent des formes diffrentes selon les phases du projet (voir la section 6.4). Par exemple, en se livrant l'activit Identifier les acteurs et les cas d'util isation au cours de la phase de cration, l'analyste systme dtectera un grand nombre de nouveaux acteurs et cas d'utilisation. En revanche, lorsqu'il excutera cette mme activit au cours de la phase de construction, i l n'apportera que des modifications mineures l'ensemble des acteurs et des cas d'utilisation, comme la cration de nouveaux diagrammes refltant le modle des cas d'utilisation selon un point de vue spcifique. Nous dcrirons plus loin ces activits telles qu'elles apparaissent typiquement dans une itration de la phase d'laboration.

7.4.1 Activit

: identifier les acteurs et les cas d'utilisation

L'identification des acteurs et des cas d'utilisation permet : de dlimiter le systme par rapport son environnement ; de faire apparatre les personnes et les lments (acteurs) interagissant avec le systme, ainsi que les fonctionnalits (cas d'utilisation) attendues de la part du systme ; de saisir et de dfinir dans un glossaire les termes essentiels la cration de descriptions dtailles des fonctionnalits du systme (par exemple, les cas d'utilisation). Cette identification est l'activit cruciale pour une apprhension exacte et fidle des besoins. C'est pourquoi elle est confie l'analyste systme (figure 7.11). Celui-ci ne peut toutefois effectuer cette tche seul. I l lui faut des lments fournis par une quipe constitue du client,
1

Il n'est pas ncessaire de respecter un ordre particulier pour l'excution de ces tapes, qui sont d'ailleurs souvent concomitantes. Les diagrammes de cas d'utilisation pourront, par exemple, tre actualiss chaque fois qu'un nouvel acteur ou qu'un nouveau cas d'utilisation sera identifi. Cette activit aboutit une nouvelle version du modle des cas d'utilisation, enrichie d'acteurs et de cas d'utilisation indits ou modifis. Ce modle doit donner lieu une des1. I l s'agit ici, en ralit, de la personne agissant en tant qu'analyste systme . S'il est un peu maladroit, la longue, de faire une distinction entre la personne relle et le travailleur qu'elle incarne, la description s'en trouve nanmoins clarifie. Nous adoptons la m m e approche pour tous les autres travailleurs v o q u s .

 A
M

L e s e n c h a n e m e n t s d ' a c t i v i t s principaux
PARTIE II

Expression des besoins s o u s forme de c a s d'utilisation mm

cription superficielle sous forme de texte et de diagrammes n'entraiil pas dans le dtail des cas d'utilisation, qui fera l'objet de l'activit suivante : D t a i l l e r un cas d'utilisation. La figure 7.12 illustre un diagramme de ce type (remani par plusieurs itrations). Une description plus prcise en sera donne plus loin.
figure 7.12 Cat d'utilisation Systme de turation et de M tlement prenant en t barge le cas i utilisation mtier ites : de la . nmande la livraison. Le rle d'initiateur, .

respect de ce critre permettra de ne retenir que les acteurs pertinents et d'carter ceux qui ne sont que pur produit de notre imagination. Deuximement, le chevauchement entre les rles que jouent les instances des diffrents acteurs par rapport au systme doit tre limit au strict minimum. I l n'est pas question de conserver plusieurs acteurs ayant peu prs le mme rle. Si c'est le cas, i l faut essayer soit de regrouper ces rles en un ensemble unique pris en charge par un seul acteur, soit de trouver un autre acteur plus gnral auquel sont attribus les rles communs ces diffrents acteurs. Ce nouvel acteur peut ensuite tre spcialis l'aide de gnralisations. Par exemple, Acheteur et Vendeur seront des spcialisa tions de l'acteur Cl ient de la banque. I l n'est pas rare, au dbut, de dterminer un nombre trop important d'acteurs dont les tches se recoupent largement. I l faut souvent plusieurs runions avant de parvenir un ensemble correct et stable d'acteurs et de gnralisations. L'analyste systme baptise les acteurs et dcrit brivement leurs diffrents rles ainsi que l'utilisation que chacun fait du systme. I l est important d'attribuer aux acteurs des noms vocateurs, qui vhiculeront la signification souhaite. La courte description qui accompagne chaque acteur doit permettre d'en dlimiter les besoins et les responsabilits. Bfflfij Les acteurs Acheteur, Vendeur et Systme de comptabilit
Acheteur

tach aux lociations, indique quel acteur est " rtgtne du cas ililisation.

Il

Un Acheteur reprsente une personne charge d'acheter des biens ou des services comme le dcrit le cas d'utilisation mtier Ventes : de la commande la livraison. Il peut s'agir d'un particulier (c'est--dire non employ par une socit) ou d'un membre d'une entreprise. L'Acheteur de biens et de services a besoin du Systme de facturation et de rgl ement pour passer les commandes et rgler les factures.
Vendeur

Un Vendeur reprsente une personne charge de vendre et de livrer des biens ou des services. Le Vendeur utilise le systme pour vrifier s'il y a de nouvelles commandes et pour envoyer des confirmations de commande, des factures et des relances. Envoyer des relances 7.4.1.1 Identifier les acteurs La tche consistant identifier les acteurs dpend largement du point de dpart. Lorsqu'il existe un modle du mtier, l'identification des acteurs est directe. L'analyste systme peut suggrer la prsence d'un acteur par employ de l'entreprise, et d'un acteur par acteur mtier (c'est--dire chaque client de l'entreprise) devant utiliser le systme d'informations (voir galement le chapitre 6, section 6.6.3). Sinon, avec ou sans modle du domaine, l'analyste systme identifie les utilisateurs avec l'aide du client et tente de les rpartir en diffrentes catgories reprsentant les acteurs. Dans l'un et l'autre cas, i l faut dterminer les acteurs figurant les systmes externes et ceux qui dsignent les personnes charges de maintenir ou de faire fonctionner le systme. Deux critres se rvlent utiles pour la mise au jour des acteurs potentiels : d'abord, i l doit tre possible d'identifier au moins un utilisateur susceptible d'incarner l'acteur propos. Le
Systme de comptabilit

Le Systme de facturation et de rglement envoie les justificatifs des transactions au Systme de comptabilit. Cette tape donne lieu une nouvelle version du modle des cas d'utilisation, dote d'un ensemble d'acteurs actualis et d'une brve description de chacun d'entre eux. Ces acteurs sommairement dcrits peuvent alors servir de point de dpart l'identification des cas d'un lisation. 7.4.1.2 Identifier les c a s d'utilisation Lorsque l'on part d'un modle du mtier, on identifie les acteurs et les cas d'utilisation selon la procdure dcrite au chapitre 6, dans la section 6.6.3, Identification des cas d'utilisation partir d'un modle du mtier . On suggre un cas d'utilisation pour chaque rle de chaque travailleur qui prendra part la ralisation d'un cas d'utilisation et se servira du systme d'information. Sinon, l'analyste systme peut identifier les cas d'utilisation par le biais

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins sous forme de c a s d'utilisation np CHATh^Tum

BfflH

Porte du cas d'utilisation Rgler la facture Le Systme de facturation et de rglement propose un cas d'utilisation appel Rgi er la facture, qui permet un acheteur de programmer le rglement de marchandises commandes et reues. Le cas d'utilisation Rgler la facture effectue ensuite le paiement la date prvue. Le cas d'utilisation Rgi er la facture comprend la fois la planification et l'excution d'un rglement. Si l'on divisait ce cas d'utilisation en deux parties, l'une pour la planification, l'autre pour l'excution du paiement, Planifier le rg 1 ement n'apporterait aucune valeur en soi. Cette valeur ne s'ajouterait qu'au moment du rglement de la facture (stade auquel on n'a pas se proccuper des relances que l'on reoit).

d'ateliers runissant le client et ses utilisateurs. Il examine les acleurs un \r.n un cl propose des candidats pour les cas d'utilisation de chaque acteur. La conduite d'entretiens et la cration de story-boards peuvent aider dterminer les cas d'utilisation ncessaires ; voir [16]. L'acteur aura le plus souvent besoin de cas d'utilisation pour prendre en charge les tches consistant crer, modifier, suivre, supprimer ou tudier les objets mtier, tels que Commandes et Comptes, intervenant dans les cas d'utilisation mtier. Il est possible, galement, que l'acteur informe le systme de certains vnements externes ou, l'inverse, que l'acteur ait besoin d'tre inform par le systme de la survenue d'un vnement donn, tel que l'arrive chance d'une facture. I l se peut aussi que d'autres acteurs assurent le dmarrage, l'interruption ou la maintenance du systme. Certains des candidats ne deviendront pas eux-mmes des cas d'utilisation mais feront partie d'autres cas d'utilisation. N'oubliez pas que le but est de crer des cas d'utilisation faciles modifier, rviser, tester et grer en tant qu'units individuelles. Le choix du nom de chaque cas d'utilisation doit nous amener rflchir la squence d'actions susceptible de satisfaire aux attentes de l'acteur. Les noms de cas d'utilisation commencent souvent par un verbe et doivent reflter la nature de l'interaction entre l'acteur et le systme. Dans notre exemple, nous avons utilis des cas d'utilisation tels que Rgi er 1 a facture et Commander des marchandises ou des services. Il est parfois difficile de dfinir la porte d'un cas d'utilisation. Une squence d'interactions entre l'utilisateur et le systme peut tre spcifie par un ou plusieurs cas d'utilisation que l'acteur invoque les uns aprs les autres. Pour dterminer si un cas d'utilisation candidat doit finalement devenir un cas d'utilisation part entire, il faut se demander s'il est autonome ou s'il fait systmatiquement suite un autre cas d'utilisation. N'oubliez pas que les cas d'utilisation doivent rendre service leurs acteurs (voir la section 7.2.3, Cas d'utilisation ). Pour tre plus prcis, un cas d'utilisation doit livrer un rsultat observable et satisfaisant aux attentes d'un acteur particulier. Ce conseil pragmatique peut aider dlimiter au mieux la porte du cas d'utilisation. Notez que deux expressions cls, rsultat satisfaisant et acteur particulier, constituent des critres utiles pour l'identification des cas d'utilisation :

En ce qui concerne les acteurs, il faut souvent restructurer et rvaluer plusieurs fois les cas d'utilisation identifis au dbut avant que le modle des cas d'utilisation ne se stabilise. Comme nous l'avons voqu au chapitre 4, les cas d'utilisation et l'architecture d'un systme s'chafaudent au fil des itrations. Une fois que l'on dispose d'une architecture, i l convient d'y adapter les cas d'utilisation nouvellement identifis. I l faut alors modifier les cas d'utilisation qui ne s'intgrent pas l'architecture choisie (il peut galement tre ncessaire de rformer l'architecture pour amliorer la production de nouveaux cas d'utilisation). Par exemple, le dbut de la spcification d'un cas d'utilisation peut avoir tabl sur un certain type d'interaction avec l'utilisateur. Une fois que l'on se sera dcid pour un cadre gnrique d'IHM, i l faudra peut-tre modifier les cas d'utilisation en consquence, mais ces adaptations sont gnralement trs limites. Il arrive toutefois que des modifications plus radicales soient ncessaires. L'analyste systme peut suggrer un moyen de surveiller la charge d'un systme en spcifiant un simulateur agissant comme un acteur important, c'est--dire un acteur exigeant du systme des cas d'utilisation. Cette option permet de mesurer les temps de rponses et autres exigences de performances. On peut aussi mesurer le temps d'immobilisation des cas d'utilisation dans les files d'attente internes du systme. Ces deux approches peuvent livrer des rsultats similaires, mais le cot de leur implmentation risque de varier considrablement en fonction de l'architecture existante. I l est possible que l'analyste systme soit amen rengocier les exigences (cas d'utilisation, etc.) avec le client, afin de s'orienter vers un systme plus simple implmenter et maintenir. Le client aura, lui aussi, tout y gagner et obtiendra peut-tre des fonctionnalits de meilleure qualit, plus tt que prvu et un moindre cot. 7.4.1.3 Dcrire brivement chaque c a s d'utilisation Pendant l'identification des cas d'utilisation, les analystes griffonnent parfois quelques mots d'explication pour chaque cas d'utilisation ou bien se contentent de noter leurs noms. Ils dcrivent ensuite brivement chaque cas d'utilisation, d'abord en quelques phrases en rsumant les actions, puis travers une description pas pas de ce que le systme a besoin de faire lors des interactions avec ses acteurs.

Rsultat satisfaisant : chaque cas d'utilisation excut avec succs doit apporter une certaine valeur l'utilisateur et lui permettre d'atteindre un objectif [3]. Dans certains cas, l'acteur souhaite payer cette valeur. Remarquez qu'une instance de cas d'utilisation, telle qu'un appel tlphonique, peut impliquer plusieurs acteurs. Le critre du rsultat observable et satisfaisant doit alors s'appliquer l'acteur qui est l'origine du cas d'utilisation. Ce critre de rsultat satisfaisant permet d'carter les cas d'utilisation dont la porte serait trop limite. Acteur particulier : l'identification de cas d'utilisation satisfaisants pour des utilisateurs individuels rels permet de conserver les cas d'utilisation dans des proportions raisonnables.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins sous forme de c a s d'utilisation

CHAPITRE 7

167

IfflfflB

Description initiale du cas d'utilisation Rgler la facture

Brve description

Description d'ensemble La description d'ensemble du modle des cas d'utilisation du Systme de facturation et de rgl ement (voir la figure 7.12) pourrait ressembler ce qui suit. Nous y avons intgr des commentaires numrots, qui sont dvelopps la fin de l'exemple.

Le cas d'utilisation Rgi er la facture permet un Acheteur de programmer le rglement des factures, puis effectue le paiement la date prvue.
Description pas pas initiale

Pralablement au dclenchement de ce cas d'utilisation, l'Acheteur a reu une facture (dlivre par un autre cas d'utilisation appel Facturer l'acheteur) et les marchandises ou services commands. Ensuite : 1. L'Acheteur tudie la facture rgler et vrifie qu'elle correspond la commande d'origine. 2. L'Acheteur programme le rglement de la facture par la banque. 3. Lorsque la date d'chance arrive, le systme vrifie que le compte de l'Ache teu r est provisionn. Si c'est le cas, la transaction est effectue. Jusqu' prsent, nous avons dcrit brivement les acteurs et les cas d'utilisation. Mais i l ne suffit pas de dcrire et de comprendre chaque cas d'utilisation isolment. Il faut aussi en avoir une vision d'ensemble, expliquer les relations liant les cas d'utilisation aux acteurs et la faon dont ils constituent le modle des cas d'utilisation. 7.4.1.4 Dcrire le m o d l e des c a s d'utilisation comme un tout L'laboration de diagrammes et de descriptions permet d'expliquer le modle des cas d'utilisation comme un tout et d'examiner de plus prs les relations que les cas d'utilisation entretiennent entre eux d'une part, avec les acteurs d'autre part.

L'acheteur Utilise le cas d'Utilisation Commandei: des marchandises ou des servi ces pour rechercher les articles commands et leur prix, pour compiler une commande, puis la soumettre. ce moment-l, peut-tre, ou plus tard, les marchandises ou les services sont livrs l'acheteur, accompagns d'une facture. L'acheteur active le cas d'utilisation Rgler la facture pour approuver la facture reue et programmer une demande de paiement. Lorsque la date prvue arrive, le cas d'utilisation Rgler la facture vire automatiquement le montant concern du compte de l'acheteut celui du vendeur, (commentaire 1) En plus, le cas d'utilisation Rgler la facture est tendu parle cas d'utilisation Payer des agios si le compte prsente un dcouvert, (commentaire 21 Abordons maintenant la faon dont le vendeur peut utiliser le systme. Il peut examiner les commandes reues, suggrer d'ventuelles modifications et confirmer les commandes l'aide du cas d'utilisation confirmer la commande. La confirmation d'une commande sera suivie de la livraison des marchandises ou de l'excution des services (ceci est effectu en dehors du Systme de facturation et de rglement et ne figure pas dans notre exemple de modle des cas d'utilisation). Puis, une fois que les marchandises ou les services ont t livrs, le vendeur facture l'acheteur par l'intermdiaire du cas d'utilisation Facturer l'acheteur. Lors de la facturation, le vendeur peut appliquer un taux de dcompte et choisir de regrouper plusieurs factures en une seule. Si l'acheteur n'a pas pay la date prvue, le vendeur en est inform et peut utiliser le cas d'utilisation Envoyer des relances. Le systme pourrait envoyer automatiquement des relances, mais nous avons opt pour une solution qui donne au vendeur la possibilit de vrifier les relances avant qu'elles ne soient expdies, pour viter d'importuner les clients. (commentaire 3} Commentaires

Aucune rgle stricte n'impose ce qui doit figurer dans un diagramme. Il convient plutt de slectionner l'ensemble de diagrammes qui dcriront le systme le plus clairement. Par exemple, on peut tracer des diagrammes pour montrer les cas d'utilisation participant un cas d'utilisation mtier (voir la figure 7.12) ou pour illustrer les cas d'utilisation excuts par un acteur. La mise au point d'un glossaire offre un moyen pratique de rester cohrent lors de la description parallle de plusieurs cas d'utilisation. Les termes que contient ce glossaire peuvent tre issus de classes (dont la trace reste identifiable) d'un modle du domaine ou d'un modle du mtier (dcrits au chapitre 6). Il n'est pas ncessaire que le modle des cas d'utilisation soit un modle plat, comme celui dcrit ici. I l peut galement se structurer sous forme de groupes de cas d'utilisation, appels paquetages de cas d'utilisation [12]. Cette tape aboutit galement une description d'ensemble du modle des cas d'utilisation, qui prsente le modle comme un tout. Cette description expose les interactions entre acteurs et cas d'utilisation et les relations entre cas d'utilisation. Dans la reprsentation que livre UML du modle des cas d'utilisation, la description d'ensemble est une valeur marque du modle lui-mme (voir annexe A, section A. 1.2).

1. Souvenez-vous que le modle des cas d'utilisation est plus qu'une simple liste de cas d'utilisation : il dcrit aussi les gnralisations entre ces cas d'utilisation. Par exemple, la squence d'actions ncessaire aux transactions de paiement du cas d'utilisation R g l e r la f a c t u r e peut tre partage par de nombreux cas d'utilisation (mme si seule une gnralisation apparat dans la figure 7.12). Ce partage peut tre reprsent par un cas d'utilisation spar, appel E f f e c t u e r l a t r a n s a c t i on, qui sera rutilis par plusieurs cas d'utilisation, tels que Rgi er la f a c t u r e , par le biais de gnralisations. La gnralisation implique que la squence d'actions dcrite dans le cas d'utilisation Effectuer l a t r a n s a c t i o n est insre dans la squence dcrite dans Rgi er 1 a f a c t u r e . Lorsque le systme excutera une instance du cas d'utilisation Rgi e r la f actu r.e, celle-ci suivra galement le comportement dcrit dans Effectuer l a t r a n s a c t i o n .

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins sous forme de c a s d'utilisation

CHAPITRE 7

puisse commencer. Un vendeur ne pourrait donc pas laisser plusieurs commandes initiales en suspens (tape 1 ), en attendant le renvoi d'une proposition de commande de rechange (tape 2 de l'exemple). Ces quatre tapes pourraient, videmment, faire l'objet de quatre cas d'utilisation diffrents, mais les nuances entre une commande initiale et une commande dfinitive sont si minces qu'il est parfaitement possible de les exprimer comme de simples variations du cas d'utilisation Commander des marchandises ou des services. Aprs tout, l'ide est de contenir l'ensemble des cas d'utilisation dans des proportions matrisables. Un nombre trop important de cas d'utilisation compromet la lisibilit du modle des cas d'utilisation et le rend difficilement utilisable comme entre pour l'analyse et la conception. De la mme faon, la suggestion d'une commande de rechange (tape 2) suppose la confirmation d'une partie de la commande et la proposition d'une solution de remplacement pour une autre partie de cette commande, tandis que la confirmation d'une commande (tape 4) implique la confirmation de la commande en bloc. Ces deux tapes peuvent tre exprimes par un cas d'utilisation unique, Conf i rmer la commande, qui permettra au vendeur la fois de confirmer une partie de la commande et de proposer des marchandises de rechange. Il y aura donc un cas d'utilisation, appel Commander des marchandises ou des services, qui fournira les services correspondant aux tapes 1 et 3, et un autre cas d'utilisation, appel Confirmer la commande, qui correspondra aux tapes 2 et 4. Lorsque la vision d'ensemble du modle des cas d'utilisation est prte, les personnes extrieures l'quipe de dveloppement (c'est--dire les utilisateurs et les clients) sont invites approuver ce modle en le rvisant de faon informelle en vue de dterminer : si tous les besoins fonctionnels ont bien t exprims sous forme de cas d'utilisation ; si la squence d'actions de chaque cas d'utilisation est correcte, complte et comprhensible ; si des cas d'utilisation sans vritable intrt ont t identifis. I l convient, dans ce cas, de les rexaminer.

2. Au moment o le systme excute une instance du cas d'utilisation R g l e r la f a c t u r e , la squence peut tre tendue pour intgrer la squence d'actions du cas d'utilisation Payer des agios. Nous avons mentionn, en passant, les relations de gnralisation et d'extension pour montrer qu'il est possible de structurer le modle des cas d'utilisation pour faciliter la spcification et la comprhension de l'ensemble complet des exigences fonctionnelles ; pour plus d'informations, voir [7]. 3. Envoyer des relances est un exemple de cas d'utilisation qui simplifie les chemins correctifs des cas d'utilisation mtier. Ces chemins correctifs contribuent remettre le processus sur les rails en vue d'viter, par exemple, qu'un lger souci dans l'interaction avec un client ne devienne un rel problme. Les acteurs ont donc galement besoin de cas d'utilisation (ou de cas d'utilisation de rechange) capables de les aider corriger les dviations des chemins de processus. Ce type de cas d'utilisation reprsente souvent une part importante des responsabilits du systme complet permettant de traiter les nombreux carts possibles. Discussion Il existe plusieurs mthodes pour laborer un modle des cas d'utilisation ; cet exemple illustre seulement l'une d'elles. Examinons maintenant les compromis consentis. Que se passerait-il si l'acheteur pouvait consulter sur Internet le catalogue des marchandises ou des services disponibles, puis passer une commande et obtenir une confirmation immdiate ? Serait-il encore ncessaire de disposer d'un cas d'utilisation Conf i rmer la commande ? La rponse est non, puisque la confirmation directe de la commande serait incluse dans le cas d'utilisation Commander des marchandises ou des services. Dans cet exemple, toutefois, nous sommes partis du principe qu'une fois qu'une commande est analyse, soit elle est confirme, soit le vendeur suggre une autre possibilit. Le vendeur peut par exemple proposer un autre ensemble de marchandises tout aussi utiles, mais moins chres ou livrables plus rapidement. La squence relle d'actions effectues au passage d'une commande pourra, dans ce cas, comprendre plusieurs tapes dans lesquelles le vendeur suggrera une commande diffrente et en demandera la confirmation, comme ci-dessous :

1. 2. 3. 4.

Un acheteur passe une commande initiale. Le vendeur renvoie l'acheteur une proposition de commande de rechange. L'acheteur passe une commande dfinitive. Le vendeur envoie l'acheteur une confirmation de commande.

7.4.2 Activit : dfinir d'utilisation

un ordre de priorit

pour les cas

Ces tapes sont prisesen charge par deux cas d'utilisation: Commander des marchandises ou des servi ces et Confirmer la commande. Pourquoi n'utilise-t-on pas quatre cas d'utilisation diffrents, ou au contraire un seul ? Voyons d'abord pour quelle raison ces tapes ne seront pas dcrites par un seul et mme cas d'utilisation : il n'est pas question d'obliger le vendeur et l'acheteur dialoguer en temps rel. Il vaut mieux qu'ils puissent se soumettre mutuellement des requtes sans avoir s'attendre, ni se synchroniser. On peut imaginer qu'un vendeur souhaitera recueillir plusieurs nouvelles commandes mises par diffrents acheteurs, prendre le temps de les analyser et les confirmer toutes en mme temps. Ceci ne serait pas possible si les quatre tapes ne formaient qu'un seul cas d'utilisation, chaque cas d'utilisation tant considr comme atomique et devant toujours tre achev avant qu'un autre

L'objectif de cette activit est de produire des entres pour dfinir l'ordre de priorit des cas d'utilisation afin de dterminer ceux qu'il faut dvelopper (c'est--dire analyser, concevoir, implmenter, etc.) ds les premires itrations et ceux qui peuvent attendre des itrations plus tardives (figure 7.13).

I n n c h a n e m e n t s d ' a c t i v i t s principaux
l'AIIIII II

Expression des besoins sous forme de cas d'utilisation H P

If* 7.13
icsullal i df/lnillon lie de de

7
Modle des " cas d'utilisation [esquisse] Architecte

priorit

En prenant comme point de dpart le modle des cas d'utilisation et les diagrammes de cas d'utilisation qui lui sont associs, les spcificateurs de cas d'utilisation peuvent maintenant dcrire chaque cas d'utilisation en dtail. Ils enrichissent la description tape par tape de chaque cas d'utilisation et crent une spcification dtaille de la squence d'actions. Dans cette section, nous verrons : comment structurer la description de faon spcifier tous les chemins possibles du cas d'utilisation ; ce qui doit figurer dans une description de cas d'utilisation ; comment formaliser une description de cas d'utilisation lorsque c'est ncessaire.

Exigences supplmentaires

,,-7Dfinir l'ordre de priorit des cas d'utilisation

Description de l'architecture [vue du modle des cas d'utilisation]

Les rsultats sont exprims sous la forme d'une vue architecturale du modle des cas d'utilisation. Cette vue est ensuite examine en compagnie du chef de projet et sert d'entre la planification des dveloppements mener au cours de chaque itration. Notez que cette planification doit galement prendre en considration d'autres aspects non techniques du systme dvelopper (voir le chapitre 12, section 12.4.2).

Figure 7.15 Un cas d'utilisation peut tre envisag comme ayant un tat de dpart (rectangle arrondi l'extrme gauche), des tats intermdiaires (rectangles arrondis suivants), un tat de fin (dernier rectangle arrondi l'extrme droite) et des transitions d'un tat un autre.

I
i

La vue architecturale du modle des cas d'utilisation doit dpeindre les cas d'utilisation pertinents sur le plan architectural. Pour plus de dtails, reportez-vous la section 7.2.4, Artefact : description de l'architecture (vue du modle des cas d'utilisation) .

Chaque spcificateur de cas d'utilisation a besoin de travailler en collaboration troite avec les vritables utilisateurs de ces cas d'utilisation. I l doit les interviewer, ventuellement prendre note de leur vision des cas d'utilisation, discuter avec eux de diverses propositions et leur demander de rviser les descriptions des cas d'utilisation. Cette activit s'achve par la description dtaille de chaque cas d'utilisation sous forme de texte et de diagrammes. 7.4.3.1 Structurer la description du c a s d'utilisation

.4.3 Activit r.

: dtailler

un cas d'utilisation

Le principal objectif recherch, lorsque l'on dtaille chaque cas d'utilisation, est de dcrire le flot d'vnements qui le constitue, en prcisant les modalits de dbut et defindu cas d'utilisation ainsi que ses interactions avec les acteurs (figure 7.14). O

n
Modle des cas d'utilisation [esquisse]

|ure7.14 nes et rsultat |i la description I, faillie de chaque \

Spcificateur de cas d'utilisation

Nous avons mentionn le fait qu'un cas d'utilisation dfinit les tats que sont susceptibles de traverser les instances de cas d'utilisation et les possibles transactions entre ces tats (voir la figure 7.15). Chaque transaction de ce type constitue une squence d'actions effectue par une instance de cas d'utilisation lorsqu'elle est dclenche par un vnement tel qu'un message.

Exigences supplmentaires

" > # * .--7 Dtailler un cas d'utilisation

->o

Cas d'utilisation [dtaill]

Le graphe des transitions d'tats illustr par la figure 7.15 risque de devenir trs complexe ; or, i l nous faut dcrire les possibilits de transitions d'tats (les squences d'actions) de manire simple et prcise. Une technique prouve consiste choisir un chemin de base complet (indiqu par les flches rectilignes de la figure 7.15) de l'tat de dpart l'tat de fin et consacrer ce chemin une section de la description. On peut ensuite dcrire, dans une section part, chacun des autres chemins (indiqus par les flches courbes) comme une solution de rechange ou un cart par rapport ce chemin de base. I l arrive, toutefois, que ces chemins de rechange ou dviations soient assez mineurs pour que leur explication figure en ligne , dans la description mme du chemin de base. C'est le bon sens qui dictera la conduite adopter. Rappelez-vous simplement que l'objectif est d'aboutir une description

L e s e n c h a n e m e n t s d ' a c t i v i t s principaux
PARTIE II

Expression des besoins s o u s forme de c a s d'utilisation mm

QHprTkTJmm paiement est effectue la date programme. Au cours de la transaction, le montant est vir depuis le compte de l'acheteur sur celui du vendeur, comme le dcrit le cas d'utilisation abstrait E f f e c t u e r la t r a n s a c t i o n (utilis par R g l e r la f a c t u r e ) . L'acheteur et le vendeur sont ensuite informs du rsultat de la transaction. La banque facture des frais pour la transaction, qui sont prlevs par le systme sur le compte de l'acheteur. 4. L'instance du cas d'utilisation se termine.

prcise, mais parfaitement lisible. Quelle que soit la technique choisie, i l faut dcrire toutes les possibilits, sinon on ne peut considrer le cas d'utilisation comme tant spcifi. Les solutions de rechange, dviations ou exceptions par rapport au chemin de base peuvent trouver diverses origines : l'acteur peut choisir de prendre des chemins diffrents au fil du cas d'utilisation. Pendant le cas d'utilisation Rgi er 1 a facture, par exemple, l'acteur peut dcider de rgler une facture ou de la rejeter ; si plusieurs acteurs sont impliqus dans un cas d'utilisation, il est probable que les actions de l'un de ces acteurs influeront sur le chemin d'actions des autres acteurs ; le systme peut dtecter des entres errones de la part de l'acteur ;

Chemins de rechange Dans l'tape 2, l'acheteur peut, la place, demander au systme de renvoyer un rejet de facture au vendeur. Dans l'tape 3, s'il n'y a pas assez d'argent sur le compte, le cas d'utilisation annulera le rglement et en avertira l'acheteur. Post-condition : l'instance du cas d'utilisation se termine une fois que la facture a t paye ou que son rglement a t annul et qu'aucune somme d'argent n'a t vire. tant donn que les cas d'utilisation doivent tre compris aussi bien par les clients et les utilisateurs que par les dveloppeurs, i l faut absolument qu'ils soient rdigs en franais courant, comme l'illustre notre exemple. Que faut-il inclure dans une description de cas d'utilisation ? - Une description de cas d'utilisation doit dfinir : l'tat de dbut (voir la figure 7.15) comme prcondition ; les modalits et le moment de ce dbut (c'est--dire la premire action effectuer ; tape 1); l'ordre (s'il y en a un) dans lequel les actions doivent se drouler. Ici, l'ordre est dfini par la squence numrote (tapes 1 4) ; les modalits et le moment defindu cas d'utilisation (tape 4) ; les possibles tats de fin (voir la figure 7.15) comme postcondition ; les chemins d'excution qui ne sont pas autoriss. La note de l'tape 2 voque un chemin impossible : payer deux fois une facture. C'est un chemin que ne peut pas emprunter l'utilisateur ; les descriptions des chemins de rechangefigurantdans la description du chemin de base. L'ensemble de l'tape 3 reprsente une action qui n'est excute que si le compte esl suffisamment provisionn ; les descriptions des chemins de rechange issus de la description du chemin de base (tape 5) ; les interactions et les changes entre le systme et les acteurs et entre les acteurs euxmmes (tapes 2 et 3). Exemples typiques de ces interactions : lorsque l'acheteur dcide de programmer le paiement de la facture l'tape 2 et lorsque l'acheteur et le vendeur

i l est possible que certaines ressources systme fonctionnent mal et empchent le systme de faire son travail correctement. Le chemin de base choisi doit tre un chemin normal , c'est--dire un chemin peru par les utilisateurs comme tant la fois le plus courant et le plus satisfaisant pour l'acteur. Ce chemin de base comprendra, en gnral, peu d'exceptions et de particularits auxquelles le systme n'est gure habitu faire face. B U Chemins du cas d'utilisation Rgler la facture Remarquez l'volution du texte par rapport au premier jet, rdig plus haut dans ce chapitre, lorsqu'on ne disposait que d'une bauche de description des cas d'utilisation (voir la section 7.4.1.3, Dcrire brivement chaque cas d'utilisation ). Ce changement reflte les dtails ajouts peu peu aux cas d'utilisation au cours de leur modlisation. Il y a de fortes chances, nanmoins, pour que les descriptions relles de cas d'utilisation soient plus volumineuses et traitent un plus grand nombre de chemins. Pr-condition : l'acheteur a reu les marchandises ou les services commands et au moins une facture de la part du systme. L'acheteur envisage maintenant de planifier le rglement de la ou des factures. Flot d'vnements Chemin de base 1. L'acheteur invoque le cas d'utilisation en commenant parcourir les factures reues par le systme. Celui-ci vrifie que le contenu de chaque facture correspond aux confirmations de commandes reues prcdemment (dans le cadre du cas d'utilisation Con f i rmer la commande) et livre le rsultat de cette vrification l'acheteur. La confirmation de commande dcrit les articles qui vont tre livrs, la date et le lieu de livraison, ainsi que le prix des articles. 2. L'acheteur dcide de planifier le rglement d'une facture par la banque et le systme gnre une demande de rglement permettant de virer la somme sur le compte du vendeur. Notez qu'un acheteur ne peut pas programmer deux fois le paiement d'une mme facture. 3. Plus tard, si le compte de l'acheteur est suffisamment provisionn, une transaction de

i es e n c h a n e m e n t s d ' a c t i v i t s principaux
PARTIE II

Expression des besoins sous forme de c a s d'utilisation

CHAPITRE 7

sont informs des rsultats de cette transaction l'tape 3. En d'autres termes, nous avons dcrit la squence d'actions du cas d'utilisation, les modalits d'invocation de ces actions par les acteurs et la faon dont leur excution se traduit par des requtes aux acteurs ; l'usage des objets, valeurs et ressources du systme (tape 3). En d'autres termes, nous avons dcrit la squence d'actions d'un cas d'utilisation et assign des valeurs aux attributs du cas d'utilisation. Exemples typiques : lorsque le montant est vir depuis le compte de l'acheteur sur celui du vendeur dans l'tape 3, mais aussi l'usage des factures et des confirmations de commande dans l'tape 1. Notez qu'il faut explicitement dcrire ce que font, d'une part, le systme (les actions qu'il excute) et, d'autre part, l'acteur. I l faut pouvoir sparer les responsabilits du systme de celles des acteurs, sinon la description des cas d'utilisation manquera de prcision et ne pourra servir de spcification du systme. Par exemple, il est crit, dans l'tape 1, que le systme vrifie que le contenu de chaque facture correspond aux confirmations de commandes reues prcdemment et, dans l'tape 3, que les frais sont prlevs par le systme sur le compte de l'acheteur . Les attributs d'un cas d'utilisation peuvent inspirer l'identification plus tardive des classes et des attributs, lors de l'analyse et de la conception : on pourra, par exemple, suggrer la cration d'une classe de conception appele Facture, drive de l'attribut facture d'un cas d'utilisation. L'analyse et la conception doivent prendre en compte le fait que certains objets participeront plusieurs cas d'utilisation, fait qu'il n'est pas ncessaire de considrer dans le modle des cas d'utilisation. On s'efforcera (comme l'voque la section 7.2.3, Cas d'utilisation ) de prserver la simplicit du modle des cas d'utilisation en interdisant les interactions entre instances de cas d'utilisation et en empchant chaque instance d'accder aux attributs de ses homologues. Pour l'instant, nous avons essentiellement parl des besoins fonctionnels et des moyens de les reprsenter sous forme de cas d'utilisation ; mais i l nous faut galement spcifier les exigences non fonctionnelles. La plupart des exigences non fonctionnelles sont lies un cas d'utilisation en particulier, comme celles indiquant la vitesse, la disponibilit, la prcision, les temps de rponse et de rcupration, ou l'usage de la mmoire. C'est en fonction de ces exigences que le systme doit effectuer un cas d'utilisation donn. Elles sont associes en tant qu'exigences particulires (valeurs marques en UML) au cas d'utilisation en question, et peuvent tre documentes dans une section part de la description du cas d'utilisation. RflfflH

l'architecture, cette spcification doit tre effectue ds les premires itrations, dans la phase d'laboration. Les descriptions de cas d'utilisation sont termines lorsqu'elles sont juges comprhensibles, correctes (elles expriment les vritables besoins), compltes (elles dcrivent tous les chemins possibles) et cohrentes. L'organisation de runions de rvision, la fin de l'tape d'expression des besoins, permet aux analystes, aux utilisateurs et aux clients d'valuer ces descriptions. Seuls les clients et les utilisateurs sont en mesure de vrifier la pertinence des cas d'utilisation. 7.4.3.2 Formaliser les descriptions de c a s d'utilisation La figure 7.15 illustre la faon dont les transitions font passer les instances des cas d'utilisation d'un tat l'autre. Souvent, comme lorsque le cas d'utilisation ne prsente que quelques tats, i l n'est pas indispensable de dcrire explicitement chaque tat. On peut choisir, la place, d'utiliser le style employ dans l'exemple Rgler la facture. Il n'est toutefois pas inutile de garder l'esprit l'image de la machine tats lorsqu'on dcrit un cas d'utilisation, au moins pour s'assurer que tous les cas possibles sont envisags. Mais il arrive, comme dans les systmes temps rels complexes, que les cas d'utilisation prsentent un tel degr de complexit qu'il soit indispensable de recourir une technique de description plus structure. L'interaction entre les acteurs et les cas d'utilisation pourra, par exemple, traverser un tel nombre d'tats et de transitions qu'il sera pratiquement impossible de prserver la cohrence de la description textuelle des cas d'utilisation. Il sera alors utile de disposer d'une technique de modlisation visuelle pour dcrire ces cas d'utilisation. Ces techniques peuvent aider l'analyste systme mieux comprendre les cas d'utilisation : les diagrammes d'tats-transitions d'UML peuvent tre utiliss pour dcrire les tats du cas d'utilisation, ainsi que les transitions entre tats ; voir la figure 7.16 ; les diagrammes d'activits peuvent tre utiliss pour dcrire plus en dtail les transitions entre tats sous forme de squences d'actions. On peut envisager les diagrammes d'activits comme une forme gnralise des diagrammes tats transitions (state transition diagrams) de SDL [15], technique prouve et largement utilise dans le secteur des tlcommunications ; les diagrammes d'interaction peuvent tre utiliss pour dcrire la faon dont une instance de cas d'utilisation dialogue avec une instance d'acteur. Ce type de diagramme montre ensuite le cas d'utilisation et l'acteur ou les acteurs y prenant part. Pour obtenir des explications sur les diagrammes d'tats-transitions, d'interaction et d'acti vits, voir [2, 11, 12, 17]. BfflH

Exigence particulire de performances Lorsqu'un acheteur envoie une facture au rglement, le systme doit rpondre par une vrification de la requte en 1 seconde maximum dans 90 % des cas. Le temps de vrification ne doit jamais dpasser 10 secondes, sauf en cas d'interruption de la connexion (qui doit tre notifie l'utilisateur).

Si le systme dialogue avec un autre systme quelconque (acteur non humain), i l faut spcifier cette interaction (par exemple, en se rfrant un protocole de communication standard). La ralisation de la communication entre systmes ayant un retentissement sur

Utilisation des diagrammes d'tats-transitions pour dcrire les cas d'utilisation La figure 7.16 montre un diagramme d'tats-transitions pour le cas d'utilisation Rgi er 1 a facture. Le point noir situ au sommet du diagramme indique le dbut du cas d'utilisation. C'est l que commence la machine tats et c'est partir de l qu'est instancie une instance du cas d'utilisation. La flche partant du point noir indique l'tat dans lequel passe la machine tats lorsqu'elle est instancie dans le premier tat, ici, Expl orati on (browsing). Les tats sont reprsents sous forme de rectangles arrondis, et les transitions entre tats par des flches reliant un tat un autre.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins sous forme de cas d'utilisation

CHAPITRE 7

1
R g u r e 7.16 'iagramme , ^tats-transitions pour le cas d'utilisation Rgler i facture montrant F quelle faon une ' instance de ce cas d'utilisation -"averse plusieurs

D'abord, l'utilisateur parcourt (browses) les factures (cf. l'tape 1 de l'exemple Rgi er 1 a facture prcdent), puis dcide de programmer (cf. tape 2) ou de rejeter (cf. tape 5) une facture. Le cas d'utilisation passe de l'tat Facture pour rglement Facture paye lorsque la facture programme est rgle la date convenue (cf. tape 3). Le cas d'utilisation prend fin (la fin est symbolise par le point noir entour d'un cercle) immdiatement aprs avoir atteint l'tat Facture paye ou Facture annule.

diagrammes de cas d'utilisation, des descriptions d'ensemble du modle des cas d'utilisation et des descriptions dtailles pour chaque cas d'utilisation. Il nous faut maintenant concevoir des interfaces utilisateur permettant l'utilisateur d'excuter les cas d'utilisation. Nous allons procder par tapes. Nous commencerons par les cas d'utilisation et tenterons de discerner ce qui est exig de la part des interfaces utilisateur pour rendre les cas d'utilisation effectifs pour chaque acteur. I l s'agit donc de procder la conception de l'interface utilisateur logique. On cre ensuite la conception de l'interface uii lisateur physique et l'on dveloppe des prototypes illustrant la faon dont les utilisateurs peuvent employer le systme pour excuter les cas d'utilisation [1]. Le fait de comment N par spcifier ce qui est ncessaire avant de dcider de la faon dont l'interface utilisaient sera ralise oblige bien comprendre les besoins avant de chercher les satisfaire 111.

Exploration programmer Facture pour rglement payer la date prvue Facture paye Facture annule

Le rsultat final de cette activit se compose d'un ensemble d'esquisses et de proloi\i d'interfaces utilisateur spcifiant l'apparence gnrale des interfaces utilisateurs destines aux principaux acteurs. O

ats ( rectangles . rrondis) par une srie de transitions entre tats lches).

Figure 7.17 Entres et rsultat du prototypage de l'interface utilisateur.

Modle des cas^ d'utilisation [esquisse] Exigences supplmentaires

Concepteur de l'interface utilisateur

O-"
Cas d'utilisation [dcrit]

Prototyper rf l'interface utilisateur

Prototype de l'interface utilisateur

Notez que ces diagrammes, utiliss dans un contexte de cas d'utilisation, risquent de s'toffer et de se complexifer un point qui en compromet la lisibilit et la clart. Un seul cas d'utilisation peut en effet impliquer de nombreux tats difficiles nommer de faon significative, problme particulirement dlicat si des intervenants autres que des dveloppeurs logiciels sont amens lire ces diagrammes. En plus, l'laboration de diagrammes dtaills et la prservation de leur cohrence avec les autres modles du systme finissent par revenir cher. Nous vous recommandons, d'une faon gnrale, d'utiliser avec prcaution ce type de diagrammes et de vous limiter le plus souvent des descriptions purement textuelles (c'est-dire des descriptions de flots d'vnements). Dans bien des cas toutefois, descriptions textuelles et diagrammes se complteront avantageusement.

7.4.4.1

Crer une conception de l'interface utilisateur logique

.4.4 Activit

: prototyper l'interface utilisateur

L'objectif de cette activit est de construire un prototype de l'interface utilisateur (voir la figure 7.17).
1.

Pour dialoguer avec le systme, les acteurs utilisent et manipulent des lments d'interface utilisateur reprsentant des attributs (des cas d'utilisation). I l s'agit souvent de termes issus du glossaire (par exemple, solde du compte, date d'chance ou t i t u l a i r e du compte). Ces lments se prsentent aux acteurs, qui les manipulent en les slectionnant, en les faisan) glisser ou en leur parlant, sous forme d'icnes, d'lments de liste, de dossiers ou d'objets d'une carte en 2 D . Le concepteur de l'interface utilisateur spcifie ces lments un pal Ml pour chaque acteur, en parcourant tous les cas d'utilisation auxquels peut accder l'acteur et en identifiant chaque fois les lments propres l'interface utilisateur. Un mme lment d'interface utilisateur peut participer de nombreux cas d'utilisation , en jouant un rle dans
1

De la m m e manire que lorsqu'une classe participe plusieurs collaborations pour raliser diffrents cas

ma

A ce stade, l'analyste systme a mis au point un modle des cas d'utilisation spcifiant l'identit des utilisateurs et l'usage qu'ils feront du systme, lments prsents travers des

d'utilisation, elle joue un rle dans chacune de ces collaborations.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins sous forme de cas d'utilisation

CHAPITRE 7

chacun d'entre eux. L'lment d'interface utilisateur doit donc tre conu pour assurer tous ces rles. Pour chaque acteur, i l convient de rpondre aux questions suivantes : Quels sont les lments d'interface utilisateur ncessaires l'excution du cas d'utilisation ? Quels doivent tre leurs liens ? Comment seront-ils utiliss dans les diffrents cas d'utilisation ? Quelle doit tre leur apparence ? Comment doivent-ils tre manipuls ? Pour dterminer les lments d'interface utilisateur ncessaires chaque cas d'utilisation accessible l'acteur, on peut se poser les questions suivantes : . Parmi les classes du domaine, les entits mtier et les units de travail, lesquelles sont susceptibles de constituer des lments d'interface utilisateur pour le cas d'utilisation ? Quels lments d'interface utilisateur l'acteur va-t-il utiliser ? Quelles sont les actions que peut invoquer l'acteur et les dcisions qu'il peut prendre ? De quelles indications l'acteur a-t-il besoin pour invoquer chaque action du cas d'utilisation ? Quelles informations l'acteur doit-il fournir au systme ? Quelles informations le systme doit-il fournir l'acteur ? Quelles sont les valeurs moyennes de tous les paramtres d'entre et de sortie ? Par exemple, combien de factures un acteur traitera-t-il normalement au cours d'une session, et quelle est la moyenne des soldes des comptes ? I l nous faut des estimations approximatives destines optimiser l'interface utilisateur graphique (mme s'il est impratif de prvoir une marge assez importante).

(comme l'indique l'association compte acheteur, drive de l'association de classes du domaine acheteur du chapitre 6). Le compte forme donc un autre aspect de l'interface utilisateur. Le solde du compte et son volution prvisible dans le temps au rythme du rglement des factures sont indiqus dans la figure 7.18 par l'attribut compte et par l'association facture rgi er reliant les lments d'interface utilisateur Compte et Facture.
Compte

Figure 7.18 lments de l'interface pour Facture et Compte, avec quelques-uns de leurs attributs.

solde prvu dans le temps (affect par le rglement des factures) A compte de l'acheteur V
Facture

facture rgler

date d'chance montant payer compte de destination

BfflHH
"

lments d'interface utilisateur employs par le cas d'utilisation Rgler la facture En nous appuyant sur le cas d'utilisation Rgi er la facture, nous allons maintenant illustrer la recherche des lments d'interface utilisateur ncessaires l'acteur pour travailler sur cran, ainsi que les indications dont il pourra avoir besoin au cours de sa tche.

Il est assez pratique de reprsenter les lments d'interface utilisateur sous forme de Post-it (comme l'indique la figure 7.18), de les coller sur un tableau blanc et de les agencer de faon esquisser l'apparence de l'interface utilisateur. Vient ensuite le moment de dcrire la faon dont les acteurs peuvent utiliser ces lments dans leur exploitation des cas d'utilisation. L'avantage d'utiliser des Post-it est de se limiter au volume suffisant de donnes. Et le fait que, par nature, ils ne sont pas permanents (il est facile de les dplacer ou de s'en dbarrasser) encourage les utilisateurs proposer les changements qu'ils estiment ncessaires. Les concepteurs de l'interface utilisateur peuvent donc s'assurer que chaque cas d'utilisation est bien accessible par le biais de ses lments d'interface utilisateur. Mais i l faut aussi veiller ce que l'ensemble complet des cas d'utilisation accessibles l'acteur prsente une interface utilisateur bien intgre, facile utiliser et cohrente. Jusqu' prsent, nous n'avons examin que ce que les acteurs exigent de l'interface utilisateur. I l nous faut maintenant tudier la faon dont l'interface utilisateur physique peut rpondre cette demande. 7.4.4.2 Crer une conception et un prototype de l'interface utilisateur physique Les concepteurs de l'interface utilisateur prparent d'abord des esquisses de la constellation des lments qui formeront des interfaces satisfaisantes pour les utilisateurs. Puis ils ajoutent les lments supplmentaires qui permettront d'agencer les divers lments d'interface en
1. Pour plus de formalisme, on peut envisager ce type de Post-it comme un strotype de classe au sein d ' U M L . I l n'appartient pas, toutefois, au prsent ouvrage de s'attarder sur un m o d l e (objet) formel des lments d'interface utilisateur.

L'acteur va certainement exploiter des lments d'interface utilisateur tels que des factures (issues d'une classe du domaine ou d'une entit mtier). Facture est, par consquent, un lment d'interface utilisateur, comme l'illustre la figure 7.18. Notez que les factures ont une date d'chance, un montant rgler et un compte de destination. Tous ces attributs sont ncessaires l'acteur et lui permettent de dcider s'il faut ou non payer la facture. Au moment de dcider s'il convient ou non de rgler la facture, l'acteur peut dsirer jeter un il au solde du compte, afin d'viter les dcouverts. Voil un exemple des indications dont peut avoir besoin un acteur. L'interface utilisateur doit donc afficher les factures en fonction de leur date d'chance, et montrer l'impact qu'aura leur rglement sur le solde du compte

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins sous forme de c a s d'utilisation M B CwprmFyBl

vue de constituer des interfaces compltes. Parmi ces lments supplmentaires peuvent se glisser des conteneurs d'lments d'interface utilisateur (par exemple, les dossiers), des fentres, des outils et des commandes ; voir la figure 7.19. Ces esquisses peuvent tre labores aprs (ou en parallle avec) les Post-it crs pendant la conception de l'interface utilisateur logique.

MHH

Conception et prototype de l'interface utilisateur physique

Modlisation

des cas d'utilisation essentiels

Le concepteur d'interface utilisateur esquisse la conception physique suivante de l'volution visuelle du solde du compte en fonction des rglements de factures. Les factures sont reprsentes par des trapzes blancs, qui vont entamer le solde du compte au moment de leur chance. Le concepteur d'interface utilisateur a choisi une forme trapzodale non seulement parce que sa largeur la rend bien visible, mais aussi parce qu'elle prsente une pointe qui poi met d'indiquer le moment prcis du rglement. Les factures programmes pour le rglonient. telles que la facture du loyer, vont provoquer une baisse du solde du compte leur date d'chance, comme l'illustre la figure 7.19. Paralllement, le dessin montre l'augmentation du solde lors, par exemple, du virement de la paie. Cette figure reprsente galement les ciiin mandes d'interface utilisateur telles que les boutons de dfilement et de zoom. Figure 7.19
Suggestion d'interface utilisateur pour les lments d'interface Compte et Facture. L'interface montre la faon dont le rglement de factures et la rception de dpts se traduisent par des baisses ou des hausses du solde du compte. Les boutons de dfilement gauche et droit permettent de parcourir la fentre du temps dans laquelle l'acteur peut tudier le solde de son compte. Les boutons de zoom avant et arrire modifient l'chelle du diagramme.

Les descriptions dtailles des cas d'utilisation constituent un excellent point de dpart pour la conception de l'interface utilisateur, parfois mme un peu trop parfait. En effet, le problme est que ces descriptions contiennent souvent des dcisions implicites sur les interfaces utilisateur, qui risquent ensuite de contraindre les concepteurs d'interface utilisateur lorsqu'ils suggreront des interfaces adaptes aux cas d'utilisation. Or, pour crer la meilleure interface utilisateur possible pour les cas d'utilisation, il faut tout prix viter cet cueil. Par exemple, le cas d'utilisation Rgler la facture commence par la phrase suivante : Lacheteur invoque le cas d'utilisation en commenant par parcourir les factures reues... . Une telle description risque d'garer le concepteur en l'incitant crer une interface utilisateur comprenant une liste des factures reues que l'acteur pourra parcourir. Mais ce n'est pas forcment le meilleur moyen d'examiner les factures reues. Les acheteurs prfrent peut-tre parcourir les factures d'une faon moins triviale: par exemple par le biais d'icnes classes horizontalement en fonction de la date de rglement et verticalement en fonction du montant payer. Larry Constantine propose un remde au problme des dcisions implicites aux interfaces utilisateur [14]. Il suggre que les spcificateurs de cas d'utilisation rdigent d'abord des descriptions allges des cas d'utilisation (les cas d'utilisation essentiels) ne contenant aucune dcision implicite de ce type. L'exemple prcdent pourrait alors tre reformul de la faon suivante : L'acheteur invoque le cas d'utilisation Rgi er l a facture en commenant tudier les factures reues... Les concepteurs d'interfaces utilisateur pourront alors employer ces cas d'utilisation essentiels comme entres pour la cration de l'interface utilisateur sans tre assujettis des dcisions implicites quelles qu'elles soient. Cet exemple propose une illustration nave de ce que peut entraner la rduction d'une description de cas d'utilisation sa substantifique moelle. En ralit, il ne suffit pas de remplacer un mot pour en arriver l. Mais l'important est d'viter de prendre des dcisions prmatures dans les domaines suivants : la technique utiliser pour prsenter un lment d'interface utilisateur, comme l'utilisation d'une liste ou d'un champ de texte ; la squence d'entres de l'acteur, comme la saisie d'un attribut avant un autre ; les dispositifs ncessaires aux entres et aux sorties, comme l'utilisation de la souris pour slectionner un lment ou de l'cran pour prsenter quelque chose. Ensuite, si c'est ncessaire, les spcificateurs de cas d'utilisation peuvent effectuer une seconde passe dans les descriptions de cas d'utilisation afin d'ajouter les dtails ngligs dans les descriptions allant l'essentiel.

Nous voil donc prts btir des prototypes excutables pour les principales constellations d'lments d'interface utilisateur. On pourra utiliser, cet effet, un outil de prototypage rapide. Il peut y avoir plusieurs prototypes, par exemple un par acteur, afin de vrifier que chaque acteur peut excuter les cas d'utilisation dont i l a besoin. L'effort consacr au prototypage doit tre proportionnel la valeur de retour attendue. On ne dveloppe des prototypes d'IHM excutables que s'il y a beaucoup gagner en termes de valeur d'utilisabilit (par exemple, un prototype pour les acteurs les plus importants), et l'on se contente d'esquisses sur papier dans les autres cas. La validation de l'interface utilisateur travers la rvision des prototypes et des esquisses trs tt dans le dveloppement vite de nombreuses erreurs dont la correction tardive risquerait de coter cher. Les prototypes permettent galement de rvler des omissions dans

L e s e n c h a n e m e n t s d ' a c t i v i t s principaux
PARTIE II

J W ! ? Q * ^ i r * ^ c ^

CHAPh^mTmmY

les descriptions de cas d'utilisation et d'y remdier avant que les cas d'utilisation n'entrent en phase de conception. Les rviseurs doivent vrifier que chaque interface utilisateur : permet l'acteur une navigation approprie ; offre une apparence et un fonctionnement cohrents, par exemple un agencement par onglets et des touches de raccourcis ; se conforme aux standards pertinents, notamment en ce qui concerne les couleurs, la taille des boutons et le placement des barres d'outils. Notez que l'implmentation de la vritable interface utilisateur (par opposition au prototype dvelopp ici) se construit en parallle avec le reste du systme, c'est--dire pendant les enchanements d'activits d'analyse, de conception et d'implmentation. Le prototype d'interface utilisateur mis au point ici fonctionnera donc comme une spcification de l'interface utilisateur qui sera ralise en termes de composants de qualit de production.

relation de gnralisation d'un cas d'utilisation A vers un cas d'utilisation R * mstance du cas d'utiltsation A prsentera aussi le c o r a ^ Z ^ T Z T** O

Figure 7.20 Entres et rsultat de l'identification des gnralisations dans le modle des cas d'utilisation.

Modle des cas'', d'utilisation [esquisse] Exigences supplmentaires

Analyste systme

7.4.5 Activit

: structurer le modle

des cas d'utilisation

Cas d'utilisation [dcrit]

o-

" Structurer s7 le modle des cas d'utilisation

Modle des cas d'utilisation [structur]

Le modle des cas d'utilisation est structur afin de : dgager les descriptions (de cas d'utilisation) gnrales et partages de fonctionnalits qui pourront tre utilises par des descriptions (de cas d'utilisation) plus spcifiques ; extraire des descriptions (de cas d'utilisation) supplmentaires ou facultatives de fonctionnalits qui tendront des descriptions (de cas d'utilisation) plus spcifiques.

Gnralisation entre cas d'utilisation Revenez la figure 7.12, un peu plus haut dans ce chapitre, dans laquelle le cas d'utilisation Rgler la facture est gnralis par le cas d'utilisation Effectuer la r r a n s a c t n o S squence aecnte dans Effectuer la transaction (figure 7.21).

Avant de procder cette activit, l'analyste systme a identifi les acteurs et les cas d'utilisation, qu'il a dcrits sous forme de diagrammes, et prsent le modle des cas d'utilisation comme un tout, tandis que les spcificateurs de cas d'utilisation ont rdig une description dtaille de chaque cas d'utilisation. ce stade, l'analyste systme peut restructurer l'ensemble des cas d'utilisation afin de le rendre plus comprhensible et plus simple utiliser (voir la figure 7.20). I l doit rechercher les comportements partags et les extensions. 7.4.5.1 Identifier les descriptions p a r t a g e s de fonctionnalits

Figure 7.21 Relation de gnralisation entre les cas d'utilisation Rgler la facture et Effectuer la transaction.

Payer la facture

Tout en identifiant et en dcrivant brivement les actions de chaque cas d'utilisation, il faut aussi rechercher les actions compltes ou partielles communes ou partages par plusieurs cas d'utilisation. Afin de limiter les redondances, ce partage doit tre extrait et dcrit sous la forme d'un cas d'utilisation part susceptible d'tre ensuite rutilis par les cas d'utilisation originaux. Cette relation de rutilisation est indique l'aide d'une gnralisation (appele relation d'utilisation dans [7]). La gnralisation entre cas d'utilisation est une sorte d'hritage, puisque les instances des cas d'utilisation gnraliss peuvent excuter tout le comportement dcrit dans le cas d'utilisation de gnralisation. En d'autres termes, une

Effectuer la transaction On emploie la gnralisation pour simplifier l'exploitation et la comprhension du modle des cas d'utilisation et pour rutiliser des cas d'utilisation semi-manufacturs lors de l'assemblage des cas d'utilisation complets exigs par les clients. Ces cas d'utilisation complets sont appels cas d'utilisation concrets. Ils sont lancs par un acteur et leurs instances forment une squence complte d'actions effectues par le systme. Les cas d'utilisation semi-manufacturs n'existent que pour tre rutiliss par d'autres cas d'utilisation et sont appels cas d'utilisation abstraits. En lui-mme, un cas d'utilisation abstrait ne sera pas instanci ; mais une instance de cas d'utilisation concret prsentera galement le comportement spcifi par le cas d'utilisation abstrait qu'elle (r)utilisera. Pour plus de clart, nous appelons cette instance le cas d'utilisation rel que peroivent les acteurs lors de leur interaction avec le systme.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des b e s o i n s s o u s j o n r m ^
CHAPITRE 7

Cas d'utilisation rels On peut conceptualiser un cas d'utilisation rel , comme le montre la figure 7.22, lorsque Rgler la facture est gnralis par Effectuer la transaction. facture est tendu par le cas d'utilisation Pawr des aoios. La souence dnions d*,*.

Rgler la facture + Effectuer la transaction

Vendeur B

I Igure 7.22 instance du cas d'utilisation rel form par les cas utilisation Rgler la facture et ffectuer la transaction, telle que ".a peroivent les instances d'acteur Acheteur A et Vendeur B.

Acheteur

Rgler la facture t>

attend

Figure 7.23 Relation d'extension entre les cas d'utilisation Rgler la facture et Payer des agios.

Effectuer la transaction

Payer des agios

Ce cas d'utilisation rel est le rsultat de l'application de la gnralisation aux deux cas d'utilisation, le concret et l'abstrait. Il reprsente le comportement de l'instance du cas d'utilisation que peroit un acteur dialoguant avec le systme. Si le modle contenait un plus grand nombre de cas d'utilisation concrets gnraliss par le cas d'utilisation Effectuer 1 a transacti on, il y aurait plus de cas d'utilisation rels, dont les spcifications prsenteraient des chevauchements, ces chevauchements tant ce que le cas d'utilisation Effectuer 1 a transaction spcifie.

Notez que la relation d'extension permet d'approfondir la discussion sur la perception qu'ont acteurs des cas d'utilisation. En appliquant la relation d'extension du cas d'ut o e nTraisoarFffPct ? ' (c'est--direRgi la fac g neral se par Effectuer 1 a transaction, on obtient un autre cas d'utilisation rel issu de la fusion de ces trois cas d'utilisation (figure 7.24).
0 8 d U t i l i S a t i n e r

Remarquez que cet exemple ne dit pas toute la vrit, puisqu'un autre cas d'utilisation (Pay e r des agi os) tend le cas d'utilisation Rgler la facture et donne ainsi lieu d'autres cas d'utilisation rels. Nous nous intressons cette question dans la section suivante. 7.4.5.2 Identifier les descriptions s u p p l m e n t a i r e s et facultatives de fonctionnalits L'autre relation entre cas d'utilisation est la relation d'extension [7]. Cette relation modlise les lments ajouts la squence d'actions d'un cas d'utilisation. Une extension se comporte comme un lment que l'on ajouterait la description d'origine d'un cas d'utilisation. En d'autres termes, une relation d'extension reliant un cas d'utilisation A un cas d'utilisation B indique qu'une instance du cas d'utilisation B peut intgrer (sous des conditions spcifiques prcises dans l'extension) le comportement dfini par A. Un comportement spcifi par plusieurs extensions d'un mme cas d'utilisation cible peut se produire au sein d'une instance unique de ce cas d'utilisation. La relation d'extension comprend la fois la condition cette extension et la rfrence du point d'extension, c'est--dire de l'emplacement auquel les ajouts peuvent tre effectus, dans le cas d'utilisation cible. Ds qu'une instance d'un cas d'utilisation (cible) atteint le point d'extension auquel se rfre une relation d'extension, la condition de la relation est value. Si la condition ncessaire est remplie, la squence suivie par l'instance du cas d'utilisation est tendue pour accueillir la squence du cas d'utilisation d'extension. EMU Relation d'extension entre cas d'utilisation Reprenez la figure 7.12 de ce chapitre et l'exemple donn dans la section 7.4.1.4, Dcrire le modle des cas d'utilisation comme un tout , dans lequel le cas d'utilisation Rgi er la

Figure 7.24

Instance du cas d'utilisation rel form par les cas d'utilisation Rgler la facture et Effectuer la transaction tendus par le cas d'utilisation Payer des agios, telle que la peroivent les instances d'acteur Acheteur A et Vendeur B.

Acheteur A

Rgler la facture -t Effectuer la transaction + Payer des agios ~

VendeurB

On peut dire que les cas d'utilisation rels, qui sont des cas d'utilisation part entire, sont le fruit de l'application des relations de gnralisation et d'extension aux cas d'utilisation du modle. Les cas d'utilisation rels sont ceux qui fournissent des rsultats aux utilisateurs. Les critres dterminant un bon cas d'utilisation, dicts dans la section 7.4.1, Acli\ identifier les acteurs et les cas d'utilisation (un cas d'utilisation livre un rsultat observable et satisfaisant pour un acteur particulier), ne valent donc que pour les cas d'utilisation rels Les cas d'utilisation concrets ne doivent pas dcrire de comportement (significatif) partag par d'autres cas d'utilisation concrets. Les cas d'utilisation abstraits facilitent la specifl cation des cas d'utilisation concrets en offrant un comportement partag, rutilisable- I c: cas d'utilisation d'extension spcifient un comportement supplmentaire pour les autres I M d'utilisation, sans se soucier du caractre facultatif ou obligatoire de ce comportement. Pour clarifier les relations de gnralisation et d'extension, nous avons donc introduit la notion de cas d'utilisation rel. Une fois que les cas d'utilisation concrets, abstraits et d'extension ont t identifis, i l suffit de les associer pour obtenir des cas d'utilisation rels. Cependant, lorsqu'on commence modliser un nouveau systme, on procde gnralement

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Expression des besoins sous forme de cas d'utilisation KM

de faon inverse : on part des cas d'utilisation rels et l'on identifie les comportements partags, qui sparent les cas d'utilisation concrets des cas d'utilisation abstraits, puis les comportements supplmentaires, que l'on traite comme des extensions des autres cas d'utilisation. Reportez-vous [ 7 ] pour dcouvrir un traitement plus approfondi des gnralisations (galement appeles relations d'utilisation) et des relations d'extension et pour savoir quand utiliser chacune de ces relations. 7.4.5.3 Identifier d'autres relations entre c a s d'utilisation Il existe d'autres relations entre cas d'utilisation, comme la relation d'inclusion [12]. Pour simplifier, on peut imaginer cette relation comme une relation d'extension inverse fournissant un cas d'utilisation des extensions explicites et sans condition. Par ailleurs, lors de l'inclusion d'un cas d'utilisation, la squence de comportement et les attributs du cas d'utilisation inclus sont encapsuls et ne peuvent tre ni modifis, ni atteints. Seul le rsultat (ou la fonction) du cas d'utilisation inclus peut tre exploit ; c'est l que rside la diffrence par rapport l'utilisation de la relation de gnralisation. Mais cet ouvrage ne s'attardera pas sur ces relations. Nous nous contenterons de ces quelques avertissements :

ensemble de diagrammes et une description dtaille de chaque cas d'utilisation rendent compte du modle des cas d'utilisation ; d'un ensemble d'esquisses et de prototypes d'interface utilisateur pour chaque acteur reprsentant la conception des interfaces utilisateur ; d'une spcification des exigences supplmentaires pour les exigences gnriques et non spcifiques un cas d'utilisation en particulier. Ce rsultat constitue un excellent point de dpart pour les enchanements d'activit! suivants : analyse, conception, implmentation et tests. Les cas d'utilisation dirigeront le dveloppement travers ces enchanements d'activits, d'itration en itration. Nous identi fierons, pour chaque cas d'utilisation du modle des cas d'utilisation, une ralisation comi pondante dans les phases d'analyse et de conception et un ensemble de cas de lesl dans In phase de tests. Les cas d'utilisation tabliront donc un lien transparent entre les diffrentl enchanements d'activits. Dans le chapitre 8, nous passons l'tape suivante de notre ensemble d'enchanements d'activits - l'analyse-, au cours de laquelle nous exprimerons les cas d'utilisation sous forme d'objets en vue d'accder une meilleure comprhension des besoins et des exigences et de prparer les phases de conception et d'implmentation du systme.

7.6

Rfrences
1
2

la structure des cas d'utilisation et de leurs relations doit reflter autant que possible les cas d'utilisation rels (comme nous l'avons vu prcdemment). Plus cette structure diverge des cas d'utilisation rels, plus i l sera difficile de comprendre les cas d'utilisation et leurs objectifs, non seulement pour les parties externes telles que les utilisateurs et les clients, mais aussi pour les dveloppeurs eux-mmes ;

AHLQVIST STEFAN et JONSSON PATRIK, Techniques for systematics design of

graphical user interfaces based on use cases , Proceedings User Guide, Reading, MA, Addison-Wesley, 1998. 3
4

OOPSLA 96.
Language

GRADY BOOCH, JAMES RUMBAUGH et IVAR JACOBSON, Unified Modeling

ALISTAIR COCKBURN, Structuring use cases with goals , Report on Analysis and
Design (ROAD), 1997.
IVAR JACOBSON, MAGNUS CHRISTERSON, PATRIK JONSSON et GUNNAR VERGAARD,

chaque cas d'utilisation individuel doit tre trait comme un artefact indpendant. Quelqu'un (un spcificateur de cas d'utilisation) doit avoir la responsabilit de le dcrire ; et i l faut, dans les enchanements d'activits ultrieurs (analyse et conception), que le cas d'utilisation soit ralis par des ralisations spares (comme nous le verrons aux chapitres 8 et 9). Les cas d'utilisation ne doivent donc tre ni trop sommaires, ni trop nombreux, car ils mobiliseraient une charge de gestion disproportionne ;

Object-Oriented Software Engineering: A Use-Case-Driven Addison-Wesley, 1992 (quatrime dition rvise, 1993).
5

Approach, Reading, MA,

Advantage:

IVAR JACOBSON, M A R I A ERICSSON et AGNETA JACOBSON, The Object

vitez de procder une dcomposition fonctionnelle des cas d'utilisation dans le modle des cas d'utilisation. I l sera bien plus efficace d'affiner chaque cas d'utilisation dans le modle d'analyse, car, comme nous le verrons au chapitre 8, les fonctionnalits dfinies par les cas d'utilisation seront plutt dcomposes, selon un mode orient objet, comme des collaborations d'objets d'analyse conceptuels. Cette dcomposition permettra, si ncessaire, une comprhension approfondie des besoins et des exigences.

Business Process Reengineering Wesley, 1994. 6

with Object Technology, Reading, M A , Addison-

7.5 R s u m de l'enchanement d'activits des besoins

Dans ce chapitre et le prcdent, nous avons dcrit le moyen de formuler les besoins et les exigences d'un systme sous la forme : d'un modle du mtier ou d'un modle du domaine afin de dfinir le contexte du systme ; d'un modle des cas d'utilisation exprimant les besoins fonctionnels et les exigences non fonctionnelles spcifiques des cas d'utilisation prcis. Une description gnrale, un

IVAR JACOBSON, Basic use case modeling , Report on Analisys and Design ROAD 1(2), juillet-aot 1994. IVAR JACOBSON, Basic use case modeling (continued) , Report on Analisys and Design ROAD 1(3), septembre-octobre 1994.
IVAR JACOBSON et MAGNUS CHRISTERSON, A growing consensus on use cases ,

7
8

Journal of Object-Oriented
9

Programming,

mars-avril 1995.
Systems ,

I . JACOBSON, K. PALMQVIST et S. DYRHAGE, Systems of interconnected Report on Analysis and Design (ROAD), mai-juin 1995.

Les e n c h a n e m e n t s d'activits principaux

PARTIE II ~~

10

Ni

IVAR JACOBSrj Modeling with use cases-Formalizing use-case modeling , Journal of Object-Ori i Programming, juin 1995.
mte( A U G H I V

11 12

Language

JAMES R U M B T AR JACOBSON et GRADY BOOCH, Unified Modeling Rfrence M Q ; Reading, MA, Addison-Wesley, 1998.
m ;

OMG Unified Modeling Language Spcification, Object Management Group, Framingham, A, 1998. Internet : www.omg.org.
M N>

13 14

IVAR JACOBSO MARTIN GRISS et PATRIK JONSSON, Software Reuse: Architecture, Process and O nization for Business Success, Reading, MA, Addison-Wesley, 1997.
rga

L. L. CONSTANTIME ET L. A. D . LOCKWOOD, Software for Use: A Practical Guide to the Models at^ Methods of Usage-Centered Design, Reading, MA, Addison-Wesley, 1999. CCITT, Speci Geneva, 1988
flcation a n Q

15 16 17

Description Language (SDL), Recommendation Z. 100, Design, New York, John Wiley & Sons, 1995.

Analyse
8.1 Introduction
Comme son nom l'indique, l'enchanement d'activits de l'analyse se consacre l'analyse des besoins dcrits dans l'expression des besoins, en les affinant et en les structurant. L'objectif est d'accder une comprhension plus aigu des besoins et des exigences et d'en livrer une description facile entretenir, favorisant la structuration de l'ensemble du systme, y compris de son architecture. Avant d'examiner ce que cela suppose, revenons quelques instants sur les rsultats de l'expression des besoins. Rappelez-vous que la rgle numro un en matire d'expression des besoins est d'utiliser le langage du client (voir la section 6.2). Or, comme nous l'avons indiqu au chapitre 7, nous estimons que les cas d'utilisation constituent un excellent soubassement ce langage commun. Mais, mme si nous parvenons un accord avec le client sur ce que le systme doit faire, i l est fort probable que des problmes non rsolus au sujet des besoins et des exigences du systme subsistent. C'est le prix payer pour l'utilisation du langage, certes intuitif, mais imprcis, du client au cours du recueil des besoins. Afin de mettre en lumire ces problmes non rsolus concernant les besoins et les exigences du systme, souvenez-vous que, pour communiquer efficacement les fonctions du systme au client, les cas d'utilisation doivent prsenter les caractristiques nonces ci-dessous. 5. Les cas d'utilisation doivent autant que possible rester indpendants les uns des autre! Il faut, pour cela, viter de se perdre dans les dtails quant aux interfrences, la concurrence et aux conflits entre cas d'utilisation lorsque, par exemple, ils sont en concurrence pour l'utilisation de ressources partages internes au systme (voir la section 7.2.3). Par exemple, les cas d'utilisation Dpt et Retrait accdent tous deux au mme compte utilisateur. Ou alors, i l se produit un conflit si un acteur associe des CM d'utilisation aboutissant un comportement indsirable, comme lorsqu'un abonne au tlphone utilise un cas d'utilisation Commander un r v e i l par tlphone suivi d'un cas d'utilisation Transfert d'appels entrants pour commander un rveil tlphonique pour

JOHN CARRO^ Scenario-Based

e t

D A V I D HAREI_ MlCHAL POLITI, Modeling Reactive Systems with Statecharts: The STATEMATE\pproach, New York, McGraw-Hill, 1998.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Analyse
CHAPITRE 8

un autre abonn. Les questions d'interfrence, de concurrence et de conflits entre cas d'utilisation peuvent donc avoir t laisses en suspens lois de l'expression des besoins.

Tableau 8.1 : Brve comparaison des modles des cas d'utilisation et d'analyse.
M o d l e des c a s d'utilisation M o d l e d'analyse

Formul dans le langage du client. Vue externe du systme. Structur par les cas d'utilisation ; donne une structure la vue externe. Sert principalement de contrat entre le client et les dveloppeurs sur ce que le systme doit faire et ne doit pas faire. Susceptible de contenir des redondances, des incohrences, etc., parmi les besoins et exigences. Exprime les caractristiques du systme, y compris les caractristiques significatives sur le plan architectural. Dfinit les cas d'utilisation, qui sont ensuite analyss plus prcisment dans le modle , d'analyse.

Formul dans le langage du dvelop- peur. Vue interne du systme. Structur par les classes et les paquetages strotyps ; donne une structure la vue interne. Sert principalement aux dveloppeurs pour comprendre la forme que doit revtir le systmo, c'est--dire sa conception et son implmentation. Ne doit contenir aucune redondance, incohrence, etc., parmi les besoins et exigences. Esquisse la ralisation des caractristiques dans le systme, y compris les caractristiques significatives sur le plan architectural ; sert de premier brouillon du systme. Dfinit les ralisations de cas d'utilisation, chacune reprsentant l'analyse d'un cas d'utilisation du modle des cas d'utilisation.

6. Les cas d'utilisation doivent tre dcrits dans le langage du client. Il s'agit essentiellement d'utiliser la langue naturelle dans les descriptions de cas d'utilisation et d'tre particulirement vigilant dans l'utilisation de notations plus formelles telles que les diagrammes d'tats-transitions, d'activits et d'interaction (voir la section 7.4.3.2). Mais l'utilisation exclusive de la langue naturelle entrane une perte de puissance d'expression ; un grand nombre de questions qui auraient pu tre prcises l'aide de notations plus formelles risquent de demeurer non rsolues, ou au mieux vaguement dcrites, dans la formulation des besoins. 7. Chaque cas d'utilisation doit tre structur de faon constituer une spcification complte et intuitive des fonctionnalits. I l faut, pour y parvenir, s tructurer les cas d'utilisation (et de ce fait, l^s besoins et les exigences) de telle sorte qu'ils refltent de faon intuitive les cas d'utilisation rels fournis par le systme. I l convient de ne pas les rpartir en cas d'utilisation limits, abstraits et non intuitifs dans l'objectif, par exemple, d'liminer les redondances. Bien que cette option soit possible, il faut parvenir un compromis raisonnable entre clart et volutivit des descriptions de cas d'utilisation (voir la section 7.4.5.3). Par consquent, i l est fort possible que les problmes de redondances parmi les besoins ayant fait l'objet d'une description aient t laisss de ct. Le premier objectif de l'analyse est donc de rsoudre ces problmes rests en suspens en procdant une analyse plus approfondie des besoins et des exigences, avec une nouveaut notable (par rapport au recueil des besoins) : on peut dsormais utiliser le langage des dveloppeurs pour en dcrire les rsultats. Cette possibilit permet ainsi de mieux cerner les aspects internes du systme et de rsoudre les questions concernant les interfrences entre cas d'utilisation et les autres cueils mentionns dans la premire caractristique de la liste ci-dessus. On peut galement, au cours de l'analyse, utiliser un langage plus formel pour mettre le doigt sur les dtails concernant les exigences du systme (deuxime caractristique de la liste ci-dessus). C'est ce que nous entendons par raffinement des exigences . Plus encore, l'analyse permet de structurer les besoins et les exigences de telle sorte que leur comprhension, leur prparation, leur modification, leur rutilisation et, d'une manire gnrale, leur maintenance en soient facilites (troisime caractristique de la liste cidessus). Cette structure (fonde sur les classes et les paquetages d'analyse) est orthogonale la structure fournie par les besoins (fonde sur les cas d'utilisation). Une parfaite traabilit relie nanmoins ces diffrentes structures, si bien que l'on peut remonter diffrentes descriptions - diffrents niveaux de dtails - de la mme exigence et prserver facilement la cohrence entre descriptions. En fait, cette traabilit transparente est dfinie entre les cas d'utilisation du modle des cas d'utilisation et les ralisations des cas d'utilisation du modle d'analyse ; nous tudierons en dtail cette question plus loin dans ce chapitre (voir aussi le tableau 8.1).

Enfinde compte, la structure des besoins fournie par l'analyse constitue galement une base fondamentale pour modeler le systme comme un tout (avec son architecture) ; ceci parce que l'on souhaite envisager le systme comme un tout maintenable, et non se contenter d'en dcrire les besoins et les exigences. Nous allons prsenter, dans ce chapitre, une explication plus dtaille de ce que nous entendons par analyse et par raffinement et structuration des exigences. Nous commencerons par positionner rapidement l'analyse (section 8.2), puis dcrirons son rle au coins des diffrentes phases du cycle de vie du logiciel (section 8.3). Ensuite, nous prsenterons les artefacts (section 8.4) et les travailleurs (section 8.5) prenant part l'analyse ( v o n la figure 8.1). Enfin, nous dcrirons l'enchanement d'activits de l'analyse (section 8.6).

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Analyse

gure 8.1 travailleurs et QrttfCtS impliqus lions l'analyse.

Architecte
responsable de

O O

O Ingnieur de composants
responsable de

Ingnieur de cas d'utilisation

responsable de

meworks) prfabriques, systmes existants, etc. Par souci de rentabilit, on parviendra une meilleure architecture en modifiant la structure du modle d'analyse au moment de passer au modle de conception et de faonner le systme.

/
Modle d'analyse

I Ralisation-analyse des cas d'utilisation

Description de l'architecture

8.2.1 Pourquoi l'analyse n'est ni la conception, ni l'implmentation...

Classe d'analyse

Paquetage d'analyse

~.2 L'analyse en bref

Le langage employ dans l'analyse repose sur un modle objet conceptuel, appel modle d'analyse. Ce modle d'analyse aide prciser les besoins et les exigences selon les lignes de force mentionnes plus haut (section 8.1) et permet d'envisager les aspects internes du systme, sans omettre les ressources internes partages. En fait, dans le modle d'analyse, une ressource interne peut tre reprsente sous forme d'objet, tel le compte client auquel accdent les cas d'utilisation Dpt et Retrait. Le modle d'analyse offre en outre une plus grande puissance d'expression et un formalisme plus pouss, comme l'illustrent les diagrammes d'interaction, qui permettent de dcrire les aspects dynamiques du systme. Comme nous l'avons mentionn plus haut (section 8.1), le modle d'analyse aide aussi hirarchiser les exigences et fournit une structure particulirement axe sur la maintenance, comme la capacit de raction aux changements des exigences et la rutilisabilit. (Nous discuterons, plus loin dans ce chapitre, des principes susceptibles d'accrotre la ractivit du modle d'analyse aux changements et qui lui permettront de contenir des lments rutilisables.) Cette structure n'est pas seulement utile pour la maintenance des exigences en tant que telle, mais elle sert galement d'entre aux activits de conception et d'implmentation (telles que nous les dcrivons dans les chapitres 9 et 10). On s'efforce de prserver cette structure mesure que l'on faonne le systme et que l'on dcide de sa conception et de son implmentation. A partir de l, le modle d'analyse peut tre vu comme un premier jet du modle de conception, bien qu'il soit un modle part entire. En prservant la structure du modle d'analyse lors de la conception, on obtiendra un systme dont la maintenance globale sera aise : i l saura ragir aux modifications des exigences et contiendra des lments susceptibles d'tre rutiliss dans la construction de systmes proches. Ici, il convient toutefois de noter que le modle d'analyse reste quelque peu vasif et omet de rsoudre certains problmes et de grer certaines exigences qu'il vaut mieux, selon nous, diffrer la conception et l'implmentation (annexe C ; voir galement la section 8.2.1). I l est possible, pour cette raison, que la structure fournie par le modle d'analyse ne soit pas toujours conserve et ncessite quelques ngociations et compromis lors de la conception et de l'implmentation, comme nous le verrons dans les chapitres 9 et 10. La raison pour laquelle cette injonction de conserver la structure ne tient pas toujours dans la pratique rside dans le fait que la conception exige de prendre en considration la plate-forme d'implmentation : langage de programmation, systmes d'exploitation, infrastructures (fra-

ce stade, vous vous demandez peut-tre pourquoi on n'analyse pas directement les besoin! et les exigences au moment de la conception et de l'implmentation du systme. Noire rponse cette question est la suivante : la conception et l'implmentation reprsentent tel lement plus que l'analyse (raffinement et structuration des besoins), qu'une sparation des proccupations nous semble indispensable. Pendant la conception, il nous faut modeler le systme et en dfinir la forme, y compris son architecture. Une forme qui devra prendre en compte toutes les exigences imposes au systme. Une forme qui comprendra les compo sants fichiers compils et intgrs sous forme de versions excutables du systme. Une forme qui, avec un peu de chance, pourra tre maintenue pendant longtemps. Une forme capable de rsister la pression du temps, du changement et des volutions. Une forme, enfin, qui gardera toute son intgrit. La conception commande donc de prendre des dcisions sur la manire dont le systme devra grer, par exemple, les exigences de performances et de distribution et de rpondre des questions telles que comment optimiser cette procdure afin que son excution ne dpasse pas 5 millisecondes ? ou comment dployer ce code sur ce noeud de rseau sans surcharger le trafic rseau ? Et il y aura bien d'autres problmes du mme ordre traiter en conception : trouver le moyen d'exploiter efficacement les composants acquis, tels que les bases de donnes et les ORB, et de les intgrer dans l'architecture du systme ; utiliser correctement le langage de programmation ; etc. Nous ne dresserons pas ici une liste exhaustive de toutes les autres questions survenant au cours de la conception et de l'implmentation, mais nous y reviendrons dans les chapitres 9 et 10. Nous esprons avoir t parfaitement clairs, c'est--dire vous avoir convaincu que la conception et l'implmentation ne se bornent pas - loin de l - une analyse approfondie et structure des besoins ; la conception et l'implmentation s'attachent faonner le systme de sorte qu'il satisfasse toutes les exigences, y compris aux exigences non fonctionnelles, qui lui sont imposes. Pour vous donner une ide des omissions du modle d'analyse par rapport au modle de conception, sachez que l'on constate frquemment un ratio de 1 5 entre les lments qui les constituent. partir de ce constat, nous estimons qu'il est indispensable, avant de dbuter la conception et l'implmentation, d'avoir une vision prcise et dtaille des besoins et des exigences. d mi < le client ne se proccupe pas un seul instant (dans la plupart des cas). Par ailleurs, si l'on dispose d'une structure des besoins pouvant servir d'entre au faonnage du systme, c'est encore mieux. Et cela, c'est l'analyse qui le permet. En clair, la conduite de l'analyse tablit une sparation des proccupations qui prpare et simplifie les activits ultrieures de conception et d'implmentation en dlimitant les pro blmes rsoudre et les dcisions prendre pendant ces activits. Cette sparation des problmes permet en outre aux dveloppeurs d' attaquer la falaise ds le dbut du dveloppement et d'viter la paralysie qui risque de survenir si l'on essaie de rsoudre trop

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Analyse ||B
CHAPITRE 8 m

de problmes la fois. Sans compter les problmes qui n'ont peut-tre pas t rsolus du tout en raison d'une formulation trop vague et d'une mauvaise comprhension de certains besoins et exigences !

Jf.2.2 Objectif de l'analyse :

rsum

milliers de sous-systmes de service). A partir de l, nous avons introduit un modle d'analyse afin de parvenir une meilleure comprhension du systme dj dvelopp. L e directeur informatique rsume ainsi l'exprience que vit aujourd'hui sa socit : grce au modle d'analyse, nous pouvons dsormais former des architectes systme en deux uns au heu de cinq . Pour un systme de moindre envergure, cette priode de formation se mesurerait en mois plutt qu'en annes, mais les proportions resteraient identiques.

Comme nous l'avons expliqu plus haut, l'analyse des besoins et des exigences sous la forme d'un modle d'analyse est importante pour plusieurs raisons : un modle d'analyse livre une spcification plus prcise des besoins que celle issue des rsultats de l'expression dts besoins, y compris du modle des cas d'utilisation ; un modle d'analyse s'crit dans le langage des dveloppeurs et peut, par consquent, introduire un plus grand formalisme et servir de base une rflexion sur les mcanismes internes du systme ; un modle d'analyse structure les besoins et les exigences sous une forme qui en facilite la comprhension, la prparation, la modification et, d'une manire gnrale, la maintenance ; un modle d'analyse peut tre envisag comme une premire bauche du modle de conception (bien qu'il soit un modle part entire), et constitue ainsi une entre essentielle pour l'laboration du systme, pendant les activits de conception et d'implmentation. Ceci s'explique par le fait que le systme doit pouvoir tre actualis en tant que tout et ne pas se rduire une simple description des besoins.

Certaines parties du systme prsentent des conceptions et/ou des implmentations de rechange. Par exemple, les systmes stratgiques tels que les systmes de contrle ai ieu ou ferroviaire peuvent se composer de plusieurs programmes diffrents calculant de faon concurrente les mmes oprations, et seule la convergence des rsultats de ces divei ses sources de calcul pourra permettre l'excution d'une manuvre d'importance. Aulie exemple : admettons qu'un client veuille que plusieurs diteurs (ou sous-traitants) fournissent des logiciels sur diffrents sites : i l voudra que ces SSII concurrentes lui soumettent des propositions partir de la mme spcification. C'est le cas, en gnral, lorsqu'une partie du systme est implment plus d'une fois par l'usage de diffrentes technologies telles que des langages de programmation ou des composants s'excutant sur diffrentes plates-formes. Le modle d'analyse peut alors offrir une vue conceptuelle, prcise et unifie de ces diffrentes implmentations. Dans ce cas, i l est vident que le modle d'analyse doit tre maintenu tout au long du cycle de vie du systme.

Quand employer l'analyse : exemples concrets

En complment de ce qui vient d'tre dit, nous proposons quelques exemples plus concrets des moments o l'emploi de l'analyse s'impose et de la manire d'exploiter ses rsultats (c'est--dire le modle d'analyse).

Le systme est bti partir d'un systme existant complexe. L'ingnierie de ce systme existant, ou tout au moins d'une partie de ce systme, peut tre dcrite sous la forme d'un modle d'analyse, afin de permettre aux dveloppeurs de le comprendre sans avoir se plonger dans les dtails de sa conception et de son implmentation, et de construire le nouveau systme en se servant de l'ancien comme d'une brique de base rutilisable. Une ringnierie complte de la conception et de l'implmentation d'un tel systme existant serait non seulement trs complexe et coteuse, mais finalement de peu de secours, surtout si le systme en question n'a pas besoin d'tre modifi ou repose sur des technologies obsoltes.

Effectuer l'analyse sparment, au lieu de la considrer comme faisant partie de la conception et de l'implmentation, permet d'analyser moindre frais une grande partie du systme. On peut ensuite utiliser son rsultat pour planifier le travail ultrieur de conception et d'implmentation ; parexemple, sous forme d'incrments successifs dont chacun prendra seulement en charge la conception et l'implmentation d'une petite partie du systme ; ou encore sous forme d'incrments concurrents, ventuellement conus et implments par des quipes de dveloppement gographiquement disperses. L'identification et la planification risquent d'tre plus compliques sans les rsultats de l'analyse. L'analyse offre une vision d'ensemble du systme qu'il serait peut-tre plus difficile d'obtenir en tudiant les rsultats de la conception ou de l'implmentation, vu qu'un grand nombre de dtails ont alors t introduits (rappelez-vous le ratio de 1 5 voqu dans la section 8.2.1). Ce type de prsentation gnrale peut se rvler trs prcieuse pour ceux qui dcouvrent le systme ou pour les dveloppeurs qui en assurent la maintenance d'une manire gnrale. Par exemple, une socit a mis au point, selon des principes semblables ceux dcrits dans les chapitres 3 et 4, un vaste systme (comportant des

8.3 Rle de l'analyse dans le cycle de vie du logiciel

L'analyse constitue le point de convergence des premires itrations de la phase d'laboration (voir la figure 8.2). Elle contribue la mise en place d'une architecture saine et stable et favorise une comprhension approfondie des besoins et des exigences. Plus tard, la lin de la phase d'laboration et au cours de la construction, une fois que l'architecture esl stable et que les besoins sont parfaitement compris, l'objectif se dplace vers la conception et l'implmentation.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Analyse
CHAPITRE

rfHyB
m m m

8 ~ r

Phases
Enchanements d ' a c t i v i t s principaux
Besoins

Igure 8.2 '.m/ de onvergence If I analyse.

Cration , laboration , i i

Construction

relativement directe un systme rpondant ces exigences. L encore, nous sommes quelque peu sceptique Transition
s

r
| Analyse
Conception

Pour choisir entre les deux premires variantes, i l convient d'valuer les avantages que pr*" sente la conservation du modle d'analyse par rapport au cot de sa mise jour sur plusicii" itrations et gnrations. I l nous faut, par consquent, effectuer le meilleur compromis ent " cot et avantages et dcider s'il est prfrable d'interrompre la mise jour du mode d'analyse (peut-tre ds la fin de la phase d'laboration) ou s'il vaut mieux en poursuiv" l'actualisation pendant le reste de la dure de vie du systme.
1

Implmentation

1 6

Itrations lier. prliminaires #1

Iter. #2

Iter. Iter. Iter. #n # + #n+2 n1

Itrations

iter. # m

iter. # + m1

Nous admettons que la troisime variante permet d'viter non seulement le cot de lu min jour du modle d'analyse, mais aussi celui de l'introduction mme de ce modle (Ici que temps et les ressources ncessaires pour former les dveloppeurs - e t leur | K - I I I M I I " d'acqurir de l'exprience - l'utilisation de ce modle). I l nous semble nanmoins, comn nous l'avons fait remarquer plus haut, que les avantages que confre l'emploi d'un mode d'analyse, au moins au dbut, l'emportent largement sur le cot de son introduction. Cet ' variante doit donc tre rserve aux trs rares cas o le systme dvelopper est extrf ' mement simple.

Si chaque projet doit se conformer au propos et l'objectif de l'analyse, la faon d'envisager et d'employer celle-ci peut varier d'un projet l'autre. Nous identifions trois variantes principales de cette vision de l'analyse : 1. Le projet utilise le modle d'analyse (comme nous le verrons en dtail plus loin dans ce chapitre) pour dcrire les rsultats de l'analyse et veille sa cohrence tout au long du cycle de vie du logiciel. Cette mise jour peut tre effectue continment, travers chaque itration du projet, afin de procurer certains des avantages suggrs dans la section 8.2.3.

Figure 8.3 Le modle d'analyse est une hirarchie de paquetages d'analyse Modle d'analyse contenant des classes d'analyse et des ralisations de cas d'utilisation.

Systme d'analyse

2. Le projet utilise le modle d'analyse pour dcrire les rsultats de l'analyse, mais i l envisage ce modle comme un outil transitoire et intermdiaire, essentiellement ax sur la phase d'laboration. Par la suite, lorsque la conception et l'implmentation trouvent leur vitesse de croisire, au cours de la phase de construction, on abandonne la mise jour du modle d'analyse. Toutes les questions d'analyse encore en suspens sont alors rsolues dans le cadre du travail de conception, directement dans le modle de conception qui en rsulte (sur lequel nous nous attarderons au chapitre 9).

Classe d'analyse

Ralisatlon-analys' de cas d'utlllsatior"

86

8.4 Artefacts 8.4.1 Artefact : modle d'analyse

3. Le projet n'utilise pas du tout le modle d'analyse pour dcrire les rsultats de l'analyse, mais place l'analyse des besoins et des exigences soit dans l'expression des besoins, soit dans la conception. La premire solution rclamera un plus grand formalisme dans le modle des cas d'utilisation. Le choix d'une telle option peut se justifier si le client est capable de comprendre les rsultats, ce qui nous semble tre rarement le cas. La seconde solution compliquera le travail de conception, comme nous l'avons expliqu dans la section 8.2.1. Cette option peut toutefois se dfendre, par exemple si les besoins sont trs simples et/ou parfaitement connus, si la forme du systme (y compris son architecture) est facile identifier, ou si les dveloppeurs ont une comprhension intuitive mais fidle des besoins et qu'ils sont capables de construire de manire

Nous avons prsent le modle d'analyse au dbut de la section 8.2. Comme l ' i l l u s i u - I ' figure 8.3, la structure qu'impose ce modle est dfinie par une hirarchie. Le modle d'analyse est reprsent par un systme d'analyse indiquant le paquetage d i niveau suprieur du modle. L'utilisation d'autres paquetages d'analyse permet e i i s u i h " d'amnager le modle en parties plus grables, reprsentant des abstractions de s o u . ivi"' tmes, voire des couches compltes de la conception du systme. Les classes d'analy| constituent des abstractions de classes et ventuellement de sous-systmes de la concepttOT
0

Analyse
CHAPITRE 8

TJM Les e n c h a n e m e n t s d ' a c t i v i t s principaux * i M ruillEll

du systme. Dans le modle d'analyse, les cas d'utilisation sont ralises par des classes d'analyse et les objets qu'elles comportent. Ces ralisations sont reprsentes par des collaborations dans le modle d'analyse et signales par l'expression ralisation-analyse de cas d'utilisation. Les artefacts du modle d'analyse sont abords en dtail dans les sections 8.4.2 8.4.5.

Figure 8.4 Attributs et soustypes (c'est--dire strotypes) essentiels d'une classe d'analyse.

Q
Classe d'analyse responsabilits attributs relations exigences particulires

8.4.2 Artefact : classe d'analyse

Une classe d'analyse reprsente une abstraction d'une ou de plusieurs classes et/ou sous-systmes dans la conception du systme. Cette abstraction possde les caractristiques suivantes :

une classe d'analyse se concentre sur les besoins fonctionnels et renvoie la prise en compte des exigences non fonctionnelles aux activits postrieures de conception et d'implmentation en les dsignant comme exigences particulires de la classe. Cette sparation rend les classes d'analyse plus videntes dans le contexte du domaine du problme, plus conceptuelles et souvent d'une granularit plus large que leurs quivalents en conception et en implmentation ; une classe d'analyse dfinit ou fournit rarement une interface en termes d'oprations et de signatures. Son comportement est, en revanche, dfini par des responsabilits un niveau plus lev, moins formel. Une responsabilit est une description textuelle d'un sousensemble cohrent du comportement dfini par une classe ;

Classe de contrle Ces trois strotypes sont standardiss dans UML et aident les dveloppeurs rpartir les proccupations entre les diffrentes classes [3]. Chaque strotype dispose de son propre symbole, comme l'illustre la figure 8.5.

une classe d'analyse dfinit des attributs, bien que ceux-ci demeurent galement un niveau assez lev. Ces attributs sont souvent de type conceptuel et reconnaissable partir du domaine du problme, tandis que ceux des classes de conception et d'implmentation prsentent souvent des types issus de langages de programmation. I l est assez courant, en outre, que les attributs identifis au cours de l'analyse se transforment en classes au cours de la conception et de l'implmentation ;

Figure 8.5 UML fournit trois strotypes de classes standard, que nous utilisons dans l'analyse.

Compte Alt. 2:
entit

Interface guichet
frontire

Interface guichet

une classe d'analyse est implique dans des relations, mme si celles-ci sont plus conceptuelles que leurs homologues de conception et d'implmentation. Par exemple, la navigabilit entre associations compte assez peu pour l'analyse, alors qu'elle est essentielle dans la conception. De mme, les gnralisations peuvent tre utilises dans l'analyse, mais i l peut trs bien tre impossible de s'en servir dans la conception si elles ne sont pas prises en charge par le langage de programmation ;

8.4.2.1

C l a s s e s frontires

On utilise une classe frontire pour modliser l'interaction entre le systme et ses aelems (c'est--dire entre les utilisateurs et les systmes externes). L'interaction implique souvent la rception (et la prsentation) d'informations et de requtes de la part (et en direction) des utilisateurs et des systmes externes. Les classes frontires modlisent les parties du systme qui dpendent de ses acteurs, ce qui implique qu'elles clarifient et recueillent les exigences pesant sur les frontires du systme Ainsi, la modification d'une interface utilisateur ou d'une interface de communication H cantonne gnralement une ou plusieurs classes frontires. Les classes frontires reprsentent souvent des abstractions de fentres, de formulaires, df volets, d'interfaces de communication, d'interfaces d'imprimantes, de capteurs, de terminaux et d'API (ventuellement non orientes objet). Cependant, ces classes frontires

les classes d'analyse appartiennent toujours l'un de ces trois strotypes de base : f r o n t i r e , contrle ou e n t i t (voir la figure 8.4). Le fait que chaque strotype implique une smantique particulire (dcrite brivement) donne une mthode puissante et cohrente d'identification et de description des classes d'analyse et contribue la cration d'un modle objet et d'une architecture robustes. I l est cependant beaucoup plus difficile de dfinir des strotypes de classes de conception et d'implmentation d'une faon aussi claire et intuitive. Parce qu'elles grent les exigences non fonctionnelles, ces classes existent dans un contexte propre au domaine de la solution et sont souvent dcrites par une syntaxe de langage de programmation et des technologies comparables de bas niveau.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Analyse
CHAPITRE 8

La classe entit Facture La classe entit suivante, appele Facture, permet de reprsenter les factures. Cette classe est associe la classe frontire lu Demande de rglement, grce laquelle l'utilisateur parcourt et manipule les factures (voir la figure 8.7).
Figure 8.7
IU Demande de rglement

doivent demeurer un niveau relativement lev et conceptuel et, par exemple, viter de se perdre dans les composants des interfaces utilisateur. Notez qu'il est largement suffisant que les classes frontires dcrivent le produit de l'interaction (c'est--dire les informations et requtes changes entre le systme et ses acteurs). Elles n'ont pas besoin de dcrire la ralisation physique de l'interaction, puisque cet aspect est pris en compte par les activits ultrieures de conception et d'implmentation. Chaque classe frontire doit tre lie au moins un acteur, et vice versa.

Classe frontire de l'interface utilisateur Demande de rglement La classe frontire iu Demande de rglement permet de prendre en charge l'interaction entre l'acteur Acheteur et le cas d'utilisation Rgler la facture (figure 8.6).
Figure 8.6
IU Classe frontire Demande de rglement.

Classe entit Facture et sa relation avec la classe frontire IU Demande de rglement.

parcourt

S
Acheteur

*0
IU Demande de rglement

Q
Facture

8.4.2.3 Classes de contrle

Les classes de contrle reprsentent la coordination, le squencement, les transactions et le contrle d'autres objets. Elles servent souvent encapsuler le contrle associ un cas d'utilisation spcifique. Elles permettent aussi de reprsenter des drivations et des calculs complexes, tels que la logique mtier, ne pouvant tre lis aucune information spcifique et durable stocke par le systme (une classe entit spcifique). La dynamique du systme est modlise par les classes de contrle, puisque celles-ci grent et coordonnent les actions et les flots de contrle principaux, et dlguent le travail d'autres objets (les objets frontires et entits). Notez que les classes de contrle n'encapsulent pas les questions lies aux interactions avec les acteurs, pas plus qu'elles n'encapsulent celles lies aux informations durables, persistantes gres par le systme, encapsules respectivement par les classes frontires et les classes entits. Les classes de contrle, de leur ct, encapsulent, et par consquent isolent, les modifications du contrle, de la coordination, du squencement, des transactions et, parfois, de la logique mtier complexe impliquant plusieurs autres objets. EMU Classe de contrle chancier Pour affiner l'exemple prcdent, nous introduisons une classe de contrle appele lehMu cier, charge de la coordination entre iu Demande de rglement et Facture; voir la figure 8.8.
Figure 8.8

iu Demande de rglement permet un utilisateur de parcourir les factures payer, de contrler chaque facture en dtail, puis de demander au systme de rgler une facture (en en programmant le rglement), iu Demande de rglement permet galement l'utilisateur de rejeter une facture que l'acheteur ne souhaite pas payer. Nous donnerons, ensuite, des exemples de la manire dont cette classe frontire est lie l' intrieur du systme, c'est--dire aux classes de contrle et aux classes entits.

8.4.2.2 Classes entits

Une classe entit sert modliser les informations de longue dure et souvent de nature persistante. Ce type de classe modlise les informations et le comportement associ d'un phnomne ou d'un concept tel qu'un individu, un objet ou un vnement du monde rel. Dans la plupart des cas, les classes entits sont directement drives de la classe entit mtier (ou de la classe du domaine) correspondante du modle objet mtier (ou du modle du domaine). Une diffrence essentielle oppose toutefois les classes entits et les classes entits mtier : les premires reprsentent des objets grs par le systme envisag, tandis que les secondes renvoient des objets du mtier (et du domaine du problme) en gnral. Les classes entits fournissent donc une reprsentation des informations utile aux dveloppeurs lors de la conception et de l'implmentation du systme, y compris en ce qui concerne la prise en charge de la persistance. Ce n'est pas exactement le cas des classes entits mtier (ou classes du domaine), qui dcrivent plutt le contexte du systme et expriment par consquent des informations qui ne sont absolument pas gres par le systme. Un objet entit n'est pas ncessairement passif et peut avoir un comportement complexe selon les informations qu'il reprsente. Ces objets isolent les modifications des informations qu'ils incarnent. Les classes entits font souvent apparatre une structure de donnes logique et contribuent une meilleure comprhension des informations dont le systme dpend.

Introduction de la classe chancier et de ses relations avec les classes frontires et entits.

Acheteur

IU Demande de rglement

programmer la facture '

chancier

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Analyse
CHAPITRE 8

chancier accepte une demande de rglement, telle qu'une requte de paiement d'une facture, et une date laquelle la facture doit tre rgle. Ensuite, lorsque la facture arrive chance, chanci er effectue le paiement en demandant un transfert de la somme entre les comptes voulus.

8.4.3.1 Diagrammes de classes

8.4.3 Artefact : ralisation-analyse

de cas d'utilisation

Une classe d'analyse et les objets qu'elle comporte participent en gnral plusieurs r a l i s a tions de cas d'utilisation, alors qu'un certain nombre de responsabilits, d'attributs et d'aSSO dations ne sont souvent pertinents que dans une seule de ces ralisations. Il est donc important, pendant l'analyse, de coordonner toutes les exigences que sont susceptibles d'avoir diffrentes ralisations de cas d'utilisation sur une classe et ses objets, ("esl pourquoi on associe les diagrammes de classes aux ralisations de cas d'utilisation en mon trant les classes qui y prennent part et leurs relations (voir la figure 8.11).
Figure 8.11 Diagramme de classes pour une ralisation du cas Rgler d'utilisation la facture.

Une ralisation-analyse de cas d'utilisation est une collaboration au sein du modle d'analyse dcrivant la faon dont un cas d'utilisation donn est ralis et excut en termes de classes d'analyse et d'interactions entre les objets qu'elles contiennent. Une ralisation de cas d'utilisation offre donc une traabilit directe vers un cas d'utilisation spcifique dans le modle des cas d'utilisation (figure 8.9).
C a s d'utilisation M o d l e d'analyse

Figure 8.9 // existe une traabilit entre une ralisationanalyse de cas d'utilisation du modle d'analyse et un cas d'utilisation du modle des cas d'utilisation.

M o d l e des cas d'utilisation

o -

Ralisation-analyse de cas d'utilisation

Acheteur

Echancier

Une ralisation de cas d'utilisation prsente une description textuelle des flots d'vnements, des diagrammes de classes qui dcrivent ses classes d'analyse, et des diagrammes d'interaction illustrant la ralisation d'un flot ou d'un scnario particulier du cas d'utilisation en termes d'interactions entre objets d'analyse (voir la figure 8.10). De mme, tant donn qu'une ralisation de cas d'utilisation est dcrite ici l'aide des classes d'analyse et des objets que renferment celles-ci, elle s'intresse naturellement aux exigences fonctionnelles. Elle peut donc, tout comme les classes d'analyse elles-mmes, reporter la prise en charge des exigences non fonctionnelles aux activits de conception et d'implmentation en les dsignant comme exigences particulires de la ralisation en question.
Figure 8.10
l'ttncipaux attributs associations utilisation mi,tlv.se ,1 de cas et d'une

8.4.3.2 Diagrammes d'interaction

Ralisation-analyse de cas d'utilisation

La squence d'actions d'un cas d'utilisation dbute lorsqu'un acteur invoque ce cas d'utilisation en envoyant une forme quelconque de message au systme. Si, dans ces pages, nous considrons l' intrieur du systme, c'est un objet frontire qui recevra ce message adress par l'acteur. L'objet frontire envoie son tour un message un autre objet, de sorte que les objets concerns dialoguent pour raliser le cas d'utilisation. Nous prfrons, dans l'analyse, traduire ce phnomne par des diagrammes de collaboration puisque notre propos est avant tout d'identifier les exigences et les responsabilits des objets et non de dterminer des squences dtailles et chronologiques d'interactions (auquel cas nous utiliserions plutt des diagrammes de squence). A l'aide de diagrammes de collaboration, nous illustrons l'interaction entre objets en I niant des liens entre ces objets et en associant des messages ces liens. Le nom d'un message doil voquer l'intention de l'objet appelant lors de l'interaction avec l'objet invoqu. IfMfl Diagramme de collaboration montrant la ralisation d'un cas d'utilisation La figure 8.12 montre un diagramme de collaboration ralisant la premire partie du cas et'utilisation Rgler la facture.

Utilisation.

flot d ' v n e m e n t s - a n a i y s e diagrammes de classes diagrammes d'interaction exigences particulires

participante

Classe d'analyse

L e s e n c h a n e m e n t s d ' a c t i v i t s principaux a l PARTIE II

Analyse CHAPITRE 8

iure8.12
Diagramme de . ollaborationpour ic ralisation du v tl'utilisation fier la facture. 3: Contrler la facture 1: Parcourir les factures 6: Programmer la facture pour rglement

L'acheteur parcourt les factures gres par le systme afin de trouver celles reues (1,2) par l'iu Demande de rglement. L'IU Demande de rglement Utilise le Gestionnaire de commandes pour vrifier les factures par rapport aux confirmations de commande concernes (3,4,5), avant de prsenter la liste des factures l'acheteur. Les implications de cette vrification dpendent des rgles mtier que met en uvre la socit de l'acheteur : il peut s'agir, par exemple, de comparer le prix, la date de livraison et le contenu de la facture par rapport la confirmation de commande. L'objet Gestionnaire de commandes s'appuie surces rgles mtier pour dterminer les questions (illustres pai lus messages Obtenir 4, 5) poser aux Objets Confirmation de commande et Facture pour analyser les rponses. Toute facture suspecte est, d'une faon ou d'une autre, si gnale l'attention de l'acheteur par l'intermdiaire de l'iu Demande de rgl emn t, ventuellement par l'usage d'une couleur diffrente destine la mettre en relief. L'acheteur slectionne une facture l'aide de l'iu Demande de rglement utniipiu gramme le rglement (6). L'iu Demande de rglement demande Ti-u-iu:nu-i,-i de programmer le rglement de la facture (7). L'chancier cre ensuite une demanda du rglement (8). L'iu Demande de rglement fait alors passer la facture en tat programm (9). L'chancier gramme). dclenche le rglement la date d'chance (ceci n'apparat pas sur le dia-

En ce qui concerne la cration et l'achvement des objets d'analyse au sein d'une ralisation de cas d'utilisation, diffrents objets ont diffrents cycles de vie (annexe C) : un objet frontire n'a pas besoin d'tre spcifique une ralisation de cas d'utilisation s'il doit par exemple apparatre dans une fentre et participer plusieurs instances du cas d'utilisation. I l est courant, toutefois, que ce type d'objet soit cr et prennefinau cours d'une mme ralisation de cas d'utilisation ; la plupart du temps, un objet entit n'est pas spcifique une ralisation de cas d'utilisation. I l sera plutt durable et participera plusieurs ralisations de cas d'utilisation avant de prendrefin; les classes de contrle encapsulent souvent le contrle li un cas d'utilisation spcifique, ce qui implique qu'un objet de contrle est cr au dmarrage du cas d'utilisation et prend fin l'issue du cas d'utilisation. I l y'a nanmoins des exceptions : lorsqu'un objet de contrle participe plusieurs ralisations de cas d'utilisation, lorsque plusieurs objets de contrle (issus de diffrentes classes de contrle) participent une seule ralisation de cas d'utilisation, et enfin lorsqu'une ralisation de cas d'utilisation ne ncessite aucun objet de contrle.
8.4.3.3 Flot d ' v n e m e n t s - a n a l y s e

Il est intressant de comparer cette description avec le flot d'vnements du cas d'utilisation tel qu'il a t dcrit dans le chapitre 7, section 7.2.3.1. La description du chapitre 7 expose le comportement du cas d'utilisation vu de l'extrieur, tandis que la description ci-dessus s'attache montrer la ralisation du cas d'utilisation par le systme en termes de collaborations entre objets (logiques). 8.4.3.4 E x i g e n c e s particulires

Les exigences particulires sont des descriptions textuelles regroupant toutes les exigences non fonctionnelles qui affectent une ralisation de cas d'utilisation. Certaines de ces exigences avaient dj t formules d'une manire ou d'une autre pendant l'enchanement d'activits des besoins (tel qu'il est dcrit dans les chapitres 6 et 7), et sont simplement transformes en ralisations-analyse de cas d'utilisation. I l se peut toutefois que des exigences nouvelles ou drives apparaissent au cours du travail d'analyse.
BMflj Exigences particulires pour la ralisation d'un cas d'utilisation Voici un exemple d'exigences particulires pour une ralisation du cas d'utilisation mi ici i <i

facture : lorsque l'acheteur demande voir les factures reues, leur apparition l'cran ne doit pas pinn dre plus d'une demi-seconde ; le rglement des factures doit utiliser le standard SET.

Les diagrammes, en particulier ceux de collaboration, d'une ralisation de cas d'utilisation sont parfois difficiles lire ; i l peut donc tre utile d'ajouter un texte explicatif. Ce texte doit tre rdig en termes d'objet, notamment d'objets de contrle, qui dialoguent pour excuter le cas d'utilisation. I l ne doit toutefois mentionner aucun des attributs, des responsabilits et des associations des objets, qu'il serait difficile d'actualiser en raison de leurs frquentes modifications.
BfflH Flot d ' v n e m e n t s - a n a l y s e expliquant un diagramme de collaboration La description textuelle suivante vient complter le diagramme de collaboration montr dans l'exemple prcdent (voir la figure 8.12) :

tiNlnninonts d ' a c t i v i t s principaux

Analyse
CHAPITRE 8

pjj
Mm

<t

irf.ici

: p a q u e t a g e

d ' a n a l y s e

8.4.4.1 P a q u e t a g e s d e s e r v i c e

ii|in-iages d'analyse offrent un moyen d'organiser les artefacts du modle d'anilyie en labis. Un paquetage d'analyse peut se composer de classes d'analyse, de icalisa M d'utilisation et d'autres paquetages d'analyse (de faon rcurslve), Voir la Ut H 1.1.

Outre les cas d'utilisation qu'il fournit ses acteurs, chaque systme procure ses clients un ensemble de services. Un client acquiert ainsi une combinaison adapte de services afin d'offrir ses utilisateurs les cas d'utilisation ncessaires l'excution de leur mission. Un cas d'utilisation spcifie une squence d'actions : le processus est dclench par un acteur, se poursuit par les interactions entre l'acteur et le systme, et enfin s'achve et s'interrompt aprs avoir renvoy une valeur l'acteur. En gnral, les cas d'utilisation n'existent pas isolment. Par exemple, le cas d'utilisation Facturer l'acheteur part de l'hypothse qu'un autre cas d'utilisation a cr une facture et que l'adresse tic l'ai lirinn et les autres donnes concernant le client sont accessibles. Un service reprsente un ensemble cohrent d'actions fonctionnellement lies un paquetage de fonctionnalits - employ par plusieurs cas d'utilisation. Le client d'un systme achte gnralement un assortiment de services afin de proposera ses utilisai, m tous les cas d'utilisation dont ils ont besoin. Un service est indivisible au sens o le systme doit le fournir intgralement ou pas du tout. Les cas d'utilisation sont destins aux utilisateurs, les services s'adressent aux clients. Les cas d'utilisation chevauchent les services, c'est--dire qu'un cas d'utilisation a besoin d'actions issues de plusieurs services.

Paquetage d'analyse

Classe d'analyse

Ralisation-analyse de cas d'utilisation

Dans le Processus unifi, le concept de service est pris en charge par les paquetages de service. Ceux-ci sont utiliss un niveau infrieur de la hirarchie (de contenance) des paquetages d'analyse pour structurer le systme en fonction des services qu'il fournit. Quelques remarques s'imposent propos des paquetages de service : un paquetage de service contient un ensemble de classes fonctionnellement lies ; un paquetage de service est indivisible : chaque client en acquiert soit toutes les classes, soit aucune ; un ou plusieurs paquetages de service peuvent prendre part la ralisation d'un cas d'utilisation, et i l n'est pas rare qu'un paquetage spcifique participe plusieurs ralisations de cas d'utilisation ; un paquetage de service prsente gnralement des dpendances trs limites vis--vis des autres paquetages de service ; un paquetage de service ne prsente gnralement de pertinence que pour une poigne d'acteurs ; une fois conues et implmentes, les fonctionnalits dfinies par un paquetage de service peuvent tre gres comme des units livres sparment. Un paquetage de service pi-ut ainsi reprsenter des fonctionnalits additionnelles du systme. Lorsqu'un paquetage de service est exclu, i l en va de mme pour chaque cas d'utilisation dont la ralisation implique son intervention ; les paquetages de service peuvent tre mutuellement exclusifs ou reprsenter divers aspects ou variantes du mme service. Par exemple, vrification d'orthographe pour le franais de France et vrification d'orthographe pour le franais de Belgique peuvent tre deux paquetages de service fournis par un mme systme ;

ii |t ici ges d'analyse doivent tre cohrents (c'est--dire que leur contenu doit tre forI h) et faiblement coupls (leurs dpendances mutuelles doivent tre rduites le plus Hulble). i H itii'luges peuvent, en outre, prsenter les caractristiques suivantes : i iquetages d'analyse peuvent marquer une sparation des questions d'analyse. Par r in pie, il est possible, dans un vaste systme, que certains paquetages d'analyse soient > llltilyss sparment ou paralllement par des dveloppeurs ayant des connaissances dans ili domaines diffrents ; i mquetages d'analyse doivent provenir des besoins fonctionnels et du domaine du problme (c'est--dire l'application ou le mtier), et tre identifiables par les personnes ii.sant le domaine. Ils ne doivent pas s'appuyer sur les exigences non fonctionnelles, m le domaine de la solution ; i i fort probable que les paquetages d'analyse deviendront, ou seront rpartis entre, des systmes des deux couches suprieures d'applications du modle de conception. i ertains cas, un paquetage d'analyse pourra mme reflter toute une couche de m suprieur du modle de conception.

nti d ' a c t i v i t s principaux

Analyse
CHAPITRE 8

8.4.5 (vue

Artefact d u

: description d'analyse)

d e

l'architecture

m o d l e

! i-i|',rs de service constituent une entre essentielle pour les activits ultl I II un MU. . | ii H m cl d'implmentation, en ce qu'ils contribuent la structuration dei modles l'iion cl d'implmentation sous forme de sous-systmes de service. Ils cxai cnl, m. H lui. une influence majeure sur la dcomposition du systme en composants M'cutables.

La description de l'architecture contient une vue architecturale du modle d'analyse (annexe C) et en dcrit les artefacts significatifs sur le plan architectural (figure 8.14).
Figure 8.14
La description de l'architecture contient une vue architecturale du modle d'analyse. Description de l'architecture vue architecturale

'

m M H m du systme en fonction des services qu'il fournit prpare la voie la possiIilier les services un par un, puisque ces changements ont de grandes chances ilisi's dans le paquetage de service correspondant. Ce qui donne un systme i|. il.lt- le s'adapter au changement. H dans la section 8.6.1.1 une mthode d'identification des paquetages de in. .les exemples de ces paquetages.

Modle d'analyse

pu l H le d'agencement courant des artefacts du modle d'analyse reste dict par H .1. paquetages d'analyse ordinaires, comme l'explique la section prcdente. I l uilili iiiiiirlbis indispensable d'introduire ici un strotype paquetage de service i iiiniqiii'i explicitement les paquetages reprsentant des services. I l est particulii..H.mi. dans les systmes d'envergure (contenant de nombreux paquetages), de un I.H ilement la distinction entre les diffrents types de paquetages. De plus, cette M in- l'utilisation et l'exploitation des strotypes au sein d'UML. u

On considre gnralement comme significatifs sur le plan architectural les artefacts du modle d'analyse suivants : la dcomposition du modle d'analyse en paquetages d'analyse avec leurs dpendances. Cette dcomposition influe souvent sur les sous-systmes des couches suprieures au cours de la conception et de l'implmentation et prsente donc un intrt pour l'architecture en gnral ;

. le service sont rutilisables - Comme nous l'avons vu dans la section prcI.I. h |im|iii'lages de service prsentent un certain nombre de caractristiques fort sduih II. que leur cohrence (annexe C), leur indivisibilit, leur faible couplage, leur FMIMIII M'I'IUT, cl ainsi de suite. Ces qualits font de la plupart des paquetages de service i .r i la rutilisation, la fois l'intrieur d'un mme systme et entre systmes I un moins) lis. De faon plus spcifique, i l y a des chances pour que les paquetages | - n ns sont centrs autour d'une ou plusieurs classes entits (voir la ^ ^ H | , 2 . 2 ) soient rutilisables dans diffrents systmes prenant en charge le mme m le infime domaine. Le fait que les classes entits drivent de classes entits mtier i. .lu domaine fait de ces classes entits et des services qui leurs sont lis des canI

les classes d'analyse cls telles que les classes entits qui encapsulent un phnomne majeur du domaine du problme ; les classes frontires qui encapsulent des interfaces de communication et les mcanismes d'interfaces utilisateur essentiels ; les classes de contrle qui encapsulent d'importantes squences large couverture (c'est--dire celles qui coordonnent les ralisations de cas d'utilisation significatives) ; enfin, les classes d'analyse gnrales et centrales qui entretiennent de nombreuses relations avec d'autres classes d'analyse. I l est d'ordinaire suffisant de considrer une classe abstraite, et non ses sous-classes, comme tant significative sur le plan architectural ; les ralisations de cas d'utilisation qui ralisent certaines fonctionnalits importantes et stratgiques ; celles qui impliquent un grand nombre de classes d'analyse et, par l mme, ont une large couverture et peuvent traverser plusieurs paquetages d'analyse ; ou celles qui s'attachent un cas d'utilisation important devant tre dvelopp tt dans le cycle de vie du logiciel, et par consquent susceptible de figurer dans la vue architecturale du modle des cas d'utilisation (annexe C).

i i lu n utilisation dans l'ensemble du mtier ou du domaine et dans la plupart des syspicnant en charge, et non pas uniquement dans un systme spcifique. Les ijiii i.i).. ilr service et les services eux-mmes sont orthogonaux aux cas d'utilisation dans m paquetage de service peut tre employ dans plusieurs ralisations de cas d'utiiitti 'rentes. Ceci est particulirement vrai lorsque le paquetage de service rside | | mit' couche gnrale comportant des fonctionnalits communes et partages (voir la d I I ) . Un paquetage de ce type est ensuite susceptible d'tre rutilis dans plu| | ipplii .liions (configurations) diffrentes du systme, chacune d'entre elles fournissant . i lisaiion dont la ralisation ncessite le paquetage de service. On peut remonter i.ijvs de service aux sous-systmes de services de la conception (voir la I I ) et aux composants d'implmentation (voir la section 10.3.2). Ces compo ...i u'iililisables pour les mmes raisons que les paquetages de service le sont. ii i.igcs de service se rvlent par consquent notre principal outil de rutilisation i analyse et influent la fois sur la conception et l'implmentation du systme, pour i ' ii donner lieu des composants rutilisables.

Les e n c h a n e m e n t s d'activits PARTIE II

principaux

Analyse CHAPITRE

J
B.5 8.5.1

8 Jmm

T r a v a i l l e u r s

Travailleur

architecte

Notez que l'ingnieur de cas d'utilisation n'est pas responsable des classes d'analyse et des relations employes dans la ralisation du cas d'utilisation. Ces responsabilits-l sont du ressort de l'ingnieur de composants (voir la section 8.5.3). Comme nous le verrons dans le chapitre suivant, l'ingnieur de cas d'utilisation est galement charg de la conception des ralisations de cas d'utilisation. Le fait que l'analyse et la conception du cas d'utilisation soient confies la mme personne garantit une transit parfaitement fluide.
Figure 8.16 O

Responsabilits d'un ingnieur de cas d'utilisation pendant l'analyse.

Ingnieur de 'utilisation
s

Pendant l'enchanement d'activits de l'analyse, l'arehilei i. . i i. jiunsnlile III I 'p.iiicdu modle d'analyse dans son ensemble et doit s'assurei de son cxw lititdi .1. su . ohieni c cl de sa lisibilit (voir la figure 8.15). Pour de vastes systmes i omplcxes i es responsabilits peuvent exiger, aprs quelques itrations, une maintenance supplmentaire . d est possibltque le travail impliqu devienne assez routinier. L'architecte peut alors dlguer celle lche un autre travailleur, tel qu'un ingnieur de composants de liant niveau (voir la section 8.5.3), mais i l gardera la responsabilit de ce qui a de l'importance sur le plan architectural, c'est--dire de la description de l'architecture. Le travailleur auquel aura t dlgue une partie du travail sera charg du paquetage de niveau suprieur du modle d'analyse, qui doit tre conforme la description de l'architecture. Le modle d'analyse est jug correct lorsqu'il ralise les fonctionnalits dcrites dans le modle des cas d'utilisation, et celles-l seulement.

responsable de I Ralisation-analyse de cas d'utilisation

L'architecte est galement responsable de l'architecture du modle d'analyse, c'est--dire de l'existence de ses parties significatives sur le plan architectural telles que la vue architecturale de ce modle les dpeint. Rappelez-vous que cette vue fait partie de la description de l'architecture du systme. Remarquez que l'architecte n'est pas responsable du dveloppement et de la maintenance permanents des divers artefacts du modle d'analyse, qui sont la charge des ingnieurs de cas d'utilisation et de composants concerns (voir les sections 8.5.2 et 8.5.3). qure8.15
Responsabilits I architecte mdant Vanalyse. de

8.5.3

Travailleur

: i n g n i e u r

d e

c o m p o s a n t s

L'ingnieur de composants dfinit les responsabilits, attributs, relations et exigences particulires d'une ou de plusieurs classes d'analyse, dont i l assure galement la maintenance. I l fait en sorte que chaque classe d'analyse satisfasse aux exigences que font peser sur elle les ralisations de cas d'utilisation auxquelles elle participe (voir la figure 8.17).

Q
f~j Architecte y \^ responsable de

L'ingnieur de composants veille galement au respect de l'intgrit d'un ou de plusieurs paquetages d'analyse, en s'assurant que leur contenu (par exemple, les classes et leurs relations) est juste et que leurs dpendances par rapport aux autres paquetages d'analyse sont correctes et minimales.

vue architecturale Modle d'analyse Description de l'architecture

. 5 . 2 Travailleur

: i n g n i e u r

d e c a s

d'utilisation

Il peut tre intressant qu'un ingnieur de composants cumule la responsabilit d'un paquetage d'analyse et celle des classes d'analyse qu'il contient. Par ailleurs, s'il existe une correspondance directe entre un paquetage d'analyse et les sous-systmes de conception correspondants (voir la section 8.4.4), l'ingnieur de composants doit aussi tre responsable de ces sous-systmes et exploiter les connaissances acquises au cours de l'analyse effectue lors de la conception et de l'implmentation du paquetage d'analyse. En l'absence d'une telle correspondance, d'autres ingnieurs de composants peuvent prendre part a la emi ception et l'implmentation du paquetage d'analyse.

Un ingnieur de cas d'utilisation est responsable de l'intgrit d'une ou de plusieurs ralisations de cas d'utilisation et doit s'assurer que celles-ci satisfont aux exigences qui leur sont imposes (voir la figure 8.16). Une ralisation de cas d'utilisation doit raliser de faon adquate le comportement du cas d'utilisation correspondant dans le modle des cas d'utilisation, et uniquement ce comportement. I l faut, dans ce cadre, s'assurer que toutes les descriptions textuelles et tous les diagrammes dcrivant cette ralisation sont lisibles et remplissent leur mission.

^
mmt

L e s e n c h a n e m e n t s d ' a c t i v i t s principaux
PARTIE II

Analyse
CHAPITRE 8

Figure 8.17
Responsabilits l'ingnieur composants rendant l'analyse. de de

Ingnieur de composants responsable de

8.6.1

A c t i v i t

: a n a l y s e

architecturale

Le propos de l'analyse architecturale est de tracer les contours du modle d'analyse et de l'architecture en identifiant les paquetages d'analyse, les classes d'analyse manifestes et les exigences particulires communes (voir la figure 8.19).
Figure 8.19
Entres et rsultat Modle des ** cas d'utilisation

O
D
Paquetage d'analyse [esquisse]

Classe d'analyse

de l'analyse architecturale.

Paquetage d'analyse

3.6

E n c h a n e m e n t

d ' a c t i v i t s

Exigences supplmentaires

Aprs avoir dcrit le travail d'analyse en termes statiques, nous allons maintenant utiliser un diagramme d'activits pour rflchir son comportement dynamique (voir la figure 8.18).

Modle du mtier [ou modle du domaine]

Analyse ^architecturale

- > Analyse architecturale Classe d'analyse [esquisse]

Description de l'architecture [vue du modle des Architecte]

Description de l'architecture [vue du modle d'analyse]

Ce sont les architectes qui amorcent la cration du modle d'analyse (tel qu'il est dfini plus haut dans ce chapitre) en commenant par identifier les principaux paquetages d'analyse, les classes entits manifestes et les exigences communes. Puis les ingnieurs de cas d'utilisation ralisent chaque cas d'utilisation l'aide des classes d'analyse qui y prennent part, en formulant les exigences comportementales de chacune de ces classes. Ces exigences sont, leur tour, spcifies par des ingnieurs de composants et intgres chaque classe par la cration de responsabilits, d'attributs et de relations cohrents pour chaque classe. Pendant l'analyse, l'architecte identifie en permanence de nouveaux paquetages, classes d'analyse et exigences communes, mesure qu'volue le modle d'analyse, tandis que les ingnieurs de composants responsables de chacun des paquetages d'analyse prcisent et actualisent ces paquetages.
igure 8.18
nchanement d'activits dans l'analyse, avec les availleurs y renant part et veurs activits.

8.6.1.1 Identifier l e s p a q u e t a g e s d ' a n a l y s e

O
a Architecte Analyse architecturale
s

Les paquetages d'analyse permettent d'agencer le modle d'analyse en parties plus modestes et plus facilement grables. Ils sont identifis soit ds le dbut comme un moyen de rpartir le travail d'analyse, soit au cours de l'volution du modle d'analyse, lorsque celui-ci devient une structure imposante qu'il faut dcomposer.

o
Ingnieur de cas d'utilisation

Jfcjfc
Analyser un cas

Une premire identification des paquetages d'analyse s'effectue naturellement partir des besoins fonctionnels et du domaine du problme, c'est--dire de l'application ou du mtier considrs. Puisque les besoins fonctionnels sont exprims sous forme de cas d'utilisation, il existe un moyen direct d'identifier les paquetages d'analyse, qui consiste tout simplement attribuer l'essentiel d'un certain nombre de cas d'utilisation un paquetage en particulier puis raliser la fonctionnalit correspondante au sein de ce paquetage. On peut considra comme approprie l' affectation un paquetage spcifique des cas d'utilisation suivants les cas d'utilisation ncessaires la prise en charge d'un processus mtier prcis
Analyser une classe Analyser un paquetage

O
O Ingnieur de composants

les cas d'utilisation ncessaires la prise en charge d'un acteur particulier du .\u les cas d'utilisation lis par des gnralisations et des relations d'extension. Ces ensembles de cas d'utilisation sont cohrents dans le sens o les cas d'utilisation se spcialisent ou s'tendent les uns les autres. Des paquetages de ce type localiseront respectivement les modifications d'un pTOCMSUN mtier, les volutions du comportement d'un acteur et les changements intervenus dans un ensemble de cas d'utilisation troitement lis. Cette approche se contente de faciliter l'ai le*

I o e n c h a n e m e n t s d ' a c t i v i t s principaux
uim
II

Analyse
CHAPITRE 8

lation initiale des cas d'utilisation des paquetages. Les . as .1 nuit ...n . <>> lement pas locaux un seul paquetage, mais en traversent pllll l( Ul I O i.m l n w i u n q u e t l'analyse progresse et que les cas d'utilisation soin raliss ions li le i nllnhoriilions entre classes, ventuellement situes dans diffrents pai|uei:i|'i'. une stiiu line de paquetages plus sophistique se met en place.
BfflH Identification des paquetages d'analyse Cet exemple illustre la faon dont Interbank Software pourtail idcnliltiii cet tains de ses paquetages d'analyse partir du modle des cas d'utilisation. Les cas d'utilisation R g 1er i a face

consiste extraire la classe partage, la placer dans un paquetage lui appartenant en propre ou juste en dehors des autres paquetages, puis faire dpendre les autres paquetages de ce paquetage ou de cette classe plus gnraux. Il y a de fortes chances pour que ces classes partages reprsentant des chevauchements soient des classes entits dont on peut attribuer l'origine des classes du domaine ou ii des classes entits mtier. Il est donc utile d'tudier les classes du domaine ou les classes eniii. mtier si elles sont partages et de dgager des paquetages d'analyse gnraux ds le dbut de l'analyse.
fjMH Identification des paquetages d'analyse g n r a u x Cet exemple illustre la faon dont Interbank Software pourrait identifier les paquetaqt::; d'aiu lyse gnraux partir du modle du domaine. Chacune des classes du domaine 11 i < < i la banque et Compte reprsente des entits importantes et complexes du monde rel. Interbank se rend compte que ces classes exigent une prise en charge par le systme d'information plus sophistique et qu'elles sont partages par d'autres paquetages d'analyse plus spcifiques. Interbank cre donc des paquetages spars, Gestion des comptes et Gest Ion des clients de la banque, pour chaque classe (voir la figure 8.21). Figure 8.21
Compte

ture, Envoyer une relance et Facturer l'acheteur sont tous impliqus dans le mme
processus mtier, Ventes : de la c m a d la 1 i vrai son. Ils peuvent donc tre fournis o mn e par le mme paquetage d'analyse. Mais Interbank Software doit livrer ce systme diffrents clients ayant diffrents types de besoins. Certains de ces clients se serviront du systme seulement en tant qu'acheteurs, d'autres uniquement en tant que vendeurs, d'autres enfin cumuleront ces deux aspects. Interbank Software choisit par consquent de sparer la ralisation des cas d'utilisation dont le vendeur a besoin de celle des cas d'utilisation qui ne sont utiles qu' l'acheteur. Nous voyons, ici, que l'hypothse initiale d'un paquetage d'analyse unique pour le processus mtier Ventes : de l a commande l a l i v r a i son a t adapte afin de rpondre aux l'acheexigences des clients. Il en rsulte deux paquetages d'analyse pouvant tre livrs sparment aux clients en fonction de leurs besoins : G e s t i o n des f a c t u r e s par t e u r et G e s t i o n des f a c t u r e s par o 8.20
liraiion des /uelages thilvsc partir %s isation.
Paquetages d'analyse Rgler la facture Facturer l'acheteur Envoyer une relance

Client de la banque

A partir du m o d l e du domaine

le

vendeur (voir la figure 8.20).

Identification de paquetages d'analyse gnraux partir des classes du domaine.

1 7
Gestion des comptes Gestion des clients de la banque

Paquetages d'analyse

Remarquez que les paquetages Gestion des comptes et Gestion des clients de la banque
contiendront probablement de nombreuses classes d'analyse, notamment des classes de contrle et des classes frontires lies respectivement la gestion des comptes et la gestion des clients de la banque. Il est ainsi fort improbable que ces paquetages ne renferment que peu de classes entits permettant de remonter aux classes du domaine correspondant!!!!. Notez que d'autres cas d'utilisation prennent galement en charge le processus mtier Ventes : de l a commande l a 1 i v r a i son, mais nous avons choisi de les ignorer pour plus de simplicit.
Gestion des factures par l'acheteur Gestion des factures par le vendeur

Identification des paquetages

de service

Gestion des chevauchements entre paquetages d'analyse - Il n'est pas rare de rencontrer des chevauchements entre les paquetages tels qu'ils ont t identifis dans la section prcdente. On trouvera un exemple de ce type de chevauchement lorsque plusieurs paquetages ont besoin de partager la mme classe d'analyse. Une rponse efficace ce problme

L'identification des paquetages de service appropris intervient souvent vers la lin du travail d'analyse, une fois que les besoins fonctionnels sont compris et que la plupart des classes d'analyse existent. Les classes d'analyse figurant dans le mme paquetage de service COnbi buent toutes au mme service. Lors de l'identification des paquetages de service, i l convient d'effectuer les dmarches dcrites ci-dessous.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux / 'ARTIE II

Analyse CHAPITRE 8

Identifiez un paquetage de service pour chaque service facullntil < V paquetage constituera une unit d'agencement.
^^fflj Paquetages de service facultatifs La plupart des vendeurs qui utilisent le systme Interbank rclament un service d'envoi de relances. Ce service est dcrit dans le cas d'utilisation (facultatif) Envoyer une r e l a nce. Certains souhaitent que des relances soient envoyes automatiquement ds que la date d'chance d'une facture est dpasse, tandis que d'autres prfrent tre d'abord informs et choisir ensuite d'envoyer ou non une relance. Cette variabilit est reprsente par deux paquetages de service facultatifs et mutuellement exclusifs : Re 1 a n c e s a u t o ma t i q u e s envoie directement des relances, alors que Re l a n c e s m a n u e l l e s avertit d'abord le vendeur, qui dcide ensuite s'il faut contacter l'acheteur ; voir la figure 8.22. Ces deux paquetages de service sont contenus dans le paquetage G e s t i o n des factures par le vendeur. Si un vendeur ne dsire aucune prise en charge des relances, ni l'un ni l'autre de ces paquetages ne lui seront livrs avec le systme.

Identification des paquetages de service encapsulant des classes fonctionnellement lies Le paquetage Gestion des comptes comprend un paquetage de service gnral appel C m o p tes, qui permet d'accder aux comptes pour des activits telles que le transfert d'argent et l'extraction d'historiques des transactions. Ce paquetage contient galement un paquetage de service appel Ri sques, consacr l'estimation des risques associs un compte particulier Ces diffrents paquetages de service sont communs et utiliss par plusieurs ralisations du cas d'utilisation. Voir la figure 8.23. Gestion des comptes paquetage de service Comptes <paquetage de service Risques

Compte Historique du compte

Figure 8.23 Paquetages de service Comptes et Risques, encapsulant chacun des classes fonctionnellement lies.

Transferts du compte

Risques

Estimation des risques

** are 8.22 filetages de t'ire Relances im.'iinitit/ues et

'i. I,IIII es

Envoyer une relance <l Gestion des factures par le vendeur 'paquetage de service | Relances automatiques paquetage de service Relances manuelles

A Dfinition des d p e n d a n c e s entre paquetages d'analyse - I l faut dfinir les dpendances entre paquetages de service si leurs contenus respectifs entretiennent des relations. La direction de la dpendance doit tre la mme que la direction (de navigabilit) de la relation. L'objectif est de mettre au point des paquetages relativement indpendants et faiblement coupls, mais ayant une forte cohsion interne. Les caractristiques de faible couplage et de forte cohsion facilitent la maintenance des paquetages, puisque le fait de modifier certaines classes d'un paquetage affectera essentiellement les classes du paquetage lui-mme. I l est donc recommand de tenter de rduire le nombre de relations entre classes de diffrents paquetages afin de limiter les dpendances entre paquetages. Pour clarifier les dpendances, i l peut tre utile de dcouper le modle d'analyse en couches, en plaant les paquetages spcifiques l'application dans une couche de haut niveau et les paquetages plus gnraux dans une couche infrieure. La distinction entre fonctionnalits spcifiques et fonctionnalits gnrales devient alors plus vidente.
D p e n d a n c e s et couches de paquetages d'analyse Le paquetage Gesti on des comptes contient plusieurs classes, telles que compt tiii'iitllisitni des classes issues d'autres paquetages. La classe Compte est, par exemple, utilise dans lus

UMlles, situs I le paquetage h\lion des tu tinvs par le 'leur.

Identifiez un paquetage de service pour chaque service qui pourrait tre rendu facultatif, mme si tous les clients le demandent. tant donn que les paquetages de service contiennent des classes fonctionnellement lies, vous obtiendrez ainsi une structure de paquetages localisant la plupart des changements dans des paquetages de service individuels. On peut galement formuler ce critre de la faon suivante : identifiez un paquetage de service pour chaque service fourni par des classes fonctionnellement lies. Une classe A peut tre considre comme fonctionnellement lie une classe B lorsque : un changement intervenant dans A a de fortes chances de ncessiter un changement dans B ; la suppression de A rend B superflu ; les objets de A ont d'importantes interactions avec des objets de B, ventuellement par l'intermdiaire de diffrents messages.

paquetages Gestion des factures par l'acheteur et Gestion des facture:, par le veu
deur. Ces paquetages dpendent, par consquent, du paquetage Gestion des comptes (voir la figure 8.24).

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

Analyse
CHAPITRES Wm

PARTIE II
m 8.24
iitUinces et in

persistance ; distribution et concurrence ;

(Couche spcifique A l'application) Gestion des factures par le vendeur Gestion des factures par l'acheteur

|n

(te

Murs ulvse.

caractristiques de scurit ; tolrance aux pannes ; gestion des transactions.

Gestion des comptes

(Couche gnrale aux applications)

Ces couches seront ensuite affines et dtailles au cours de la conception et de l'implmentation, lorsque l'environnement d'implmentation et les exigences non fonctionnelles en gnral seront pris en considration.
8 . 6 . 1 . 2 Identification d e s c l a s s e s e n t i t s manifestes

L'architecte a la charge d'identifier les exigences particulires communes de sorte que les dveloppeurs puissent s'y rfrer comme des exigences particulires sur des ralisations de cas d'utilisation et des classes d'analyse dtermines. Dans certains cas, il esl impossible de dtecter l'avance ces exigences particulires, et i l faut attendre d'avoir explor les ralisa fions de cas d'utilisation et les classes d'analyse pour les mettre au jour. Note/, galement qu'il n'est pas rare qu'une classe ou qu'une ralisation de cas d'utilisation spcilie pliisirui s exigences particulires. Pour faciliter la conception et l'implmentation, les caractristiques essentielles le chaque exigence particulire commune doivent tre identifies.
IWjjHH Identification des caractristiques essentielles d'une exigence particulire Une exigence de persistance prsente les caractristiques suivantes : intervalle de taille : intervalle de taille des objets dont la persistance doit tre prserve ; volume : nombre d'objets dont la persistance doit tre prserve ; priode de persistance : priode de temps pendant laquelle la persistance d'un objet doit en principe tre prserve ; frquence de mise jour : frquence de mise jour des objets ; fiabilit : questions de fiabilit ; par exemple, dterminer si des objets doivent survivre un chec du logiciel ou du matriel.

La plupart du temps, i l est bien venu de dresser une proposition prliminaire des classes entits les plus importantes (de 10 20), partir des classes du domaine ou des entits mtier identifies au cours de la formulation des besoins. Cependant, la plupart des classes seront identifies au moment de la cration des ralisations de cas d'utilisation (lors de l'activit d'analyse des cas d'utilisation ; voir la section 8.6.2). Pour cette raison, i l convient de veiller ne pas identifier un trop grand nombre de classes ce stade et ne pas s'garer dans une fort de dtails superflus. Une premire bauche des classes significatives pour l'architecture devrait largement suffire (voir la section 8.4.5). On risque, sinon, d'avoir refaire une grande partie du travail lors de l'exploitation plus tardive des cas d'utilisation en vue d'identifier les classes entits vritablement indispensables, c'est--dire celles prenant part des ralisations de cas d'utilisation. Une classe entit ne participant aucune ralisation de cas d'utilisation est inutile. Les agrgations et associations entre classes du domaine dans le modle du domaine (ou entre entits mtier dans le modle du mtier) peuvent servir de base l'identification d'un ensemble prliminaire d'associations entre les classes entits correspondantes.
TOIfll Une classe entit identifie partir d'une classe du domaine Facture est une classe du domaine mentionne au chapitre 6, que nous utiliserons pour suggrer l'une des premires classes entits. Nous pouvons proposer, titre de point de dpart,
8.6.2

Les caractristiques de chaque exigence particulire sera ensuite qualifie pour chaque classe ou ralisation de cas d'utilisation faisant rfrence cette exigence particulire.
A c t i v i t : a n a l y s e r un c a s d'utilisation

les mmes attributs que pour la Classe Facture : montant, date d'mission et date limite
de rglement. Des associations seront galement dfinies entre les classes entits partir du modle du domaine, telles que l'association payable entre une C m a d et une Facture. o mn e 8.6.1.3 Identification d e s e x i g e n c e s p a r t i c u l i r e s communes

On procde l'analyse d'un cas d'utilisation (voir la figure 8.25) pour : identifier les classes d'analyse dont les objets sont ncessaires l'excution du Ilot d'vnements de ce cas d'utilisation ; rpartir le comportement du cas d'utilisation entre des objets d'analyse en interaction les uns avec les autres ; formuler des exigences particulires sur la ralisation du cas d'utilisation. L'analyse des cas d'utilisation est galement appele raffinement des cas d'utilisation Chaque cas d'utilisation est affin sous forme de collaboration entre classes d'analyse.

Une exigence particulire est une exigence surgissant au cours de l'analyse et qu'il est important de saisir afin de pouvoir la grer comme i l convient dans les activits ultrieures de conception et d'implmentation. I l s'agit par exemple de restrictions ou de contraintes dans les domaines suivants :

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

l'ARTIE II
Igure 8.25
titres et tir l'analyse rsultat d'un Modle des \ cas d'utilisation

Analyse
CHAPITRE 8

Mj
mm

<. .l'utilisation.

Ingnieur de cas d'utilisation

(annexe C) et de rduire le plus possible le nombre de fentres principales avec lesquelles chaque acteur aura besoin de dialoguer. Ces classes frontires centrales sont souvent considres comme des agrgats de classes frontires plus primitives. ,.-7
IIOIIIIMIIIOII ly.i-

Exigences supplmentaires

de cas d'utilisation
S

Modle du mtier [ou modle du domaine]

Analyser .-7 un cas d'utilisation

"A >

tAl V
S

Identifiez une classe frontire primitive pour chaque classe entit dtecte prcdemment Ces classes reprsentent les objets logiques avec lesquels l'acteur (humain) dialoguera a travers l'interface utilisateur, pendant l'excution du cas d'utilisation. Ces classes frontires primitives peuvent ensuite tre affines selon divers critres d'utilisabiliie et contribuer la naissance d'une bonne interface utilisateur.

Classe d'analyse [esquisse]

Description de l'architecture [vue du modle d'analyse]

Pour chaque acteur systme externe, identifiez une classe frontire centrale, dont voui ferez la reprsentante de l'interface de communication. Rappelez-vous qu'un aelein systme peut reprsenter n'importe quel lment logiciel ou dispositif matriel imprimantes, terminaux, dispositifs d'alarme, capteurs, etc., en interaction avec le systme en question. Si la communication systme est rpartie entre pln.su ni oJvMUX de protocoles, i l faudra peut-tre que le modle d'analyse ait la possibilit d'tabli] une distinction entre certains de ces niveaux. Si c'est le cas, identifiez des classes l'ronlires spares pour chaque niveau d'intrt. Identifiez une classe de contrle responsable de la gestion du contrle et de la coordination de la ralisation du cas d'utilisation, puis affinez cette classe en fonction des exigences du cas d'utilisation. Par exemple, dans certains cas, i l sera plus efficace d'encapsuler le contrle dans une classe frontire, en particulier si l'acteur assume une part importante de ce contrle ; i l ne sera alors pas ncessaire de faire appel une classe de contrle. Dans d'autres cas, en revanche, le contrle sera si complexe qu'il vaudra mieux l'encapsuler dans deux ou plusieurs classes de contrle ; la classe de contrle devra tre scinde. Au cours de cette tape, les classes d'analyse du modle d'analyse doivent, bien sr, tre prises en considration. Certaines sont susceptibles d'tre rutilises dans la ralisation de cas d'utilisation en cours, et plusieurs cas d'utilisation seront raliss presque simultanment, ce qui facilitera la dtection des classes d'analyse participant plusieurs ralisations de cas d'utilisation. Runissez les classes d'analyse participant la ralisation d'un cas d'utilisation dans un diagramme de classes, qui vous permettra de montrer les relations existant au sein de cette ralisation.
8 . 6 . 2 . 2 D e s c r i p t i o n d e s interactions e n t r e o b j e t s d ' a n a l y s e

8.6.2.1 Identification d e s c l a s s e s d ' a n a l y s e

Dans cette tape, on identifie les classes de contrle, les classes entits et les classes frontires ncessaires la ralisation du cas d'utilisation, et l'on en fait apparatre le nom, les responsabilits, les attributs et les relations. Les cas d'utilisation dcrits dans les besoins et les exigences ne sont pas toujours assez dtaills pour permettre l'identification des classes d'analyse. Les informations sur l'intrieur du systme prsentant gnralement peu d'intrt au moment de la formulation des besoins et des exigences, i l est possible qu'elles aient t ngliges. Pour identifier les classes d'analyse, i l faut, par consquent, prciser les descriptions des cas d'utilisation en ce qui concerne l'intrieur du systme. Ce surcrot de prcision doit figurer dans le flot d'vnements textuel, c'est--dire la description de l'analyse de la ralisation d'un cas d'utilisation. Les conseils et les principes noncs ci-dessous s'appliquent d'une faon gnrale l'identification des classes d'analyse. Identifiez les classes entits en tudiant en dtail la description du cas d'utilisation et tout modle du domaine existant, puis envisagez les informations ncessaires la ralisation du cas d'utilisation. Distinguez toutefois les informations qu'il est prfrable de formuler en tant qu'attributs (voir la section 8.6.3.2, Identification des attributs ) de celles qu'il vaut mieux relier des classes frontires ou des classes de contrle, et enfin de celles qui ne sont tout simplement pas ncessaires la ralisation du cas d'utilisation. Les informations rpondant ces critres ne doivent pas tre modlises en tant que classes entits. Identifiez une classe frontire centrale pour chaque acteur humain et faites en sorte que cette classe reprsente la fentre principale de l'interface utilisateur avec laquelle dialoguera l'acteur. Si l'acteur dialogue dj avec une classe frontire, envisagez de rutiliser cette classe afin d'assurer un bon niveau d'utilisation de l'interface utilisateur

Une fois que l'on dispose d'une bauche des classes d'analyse ncessaires la ralisai ion du cas d'utilisation, i l faut dcrire les interactions entre leurs objets d'analyse respei ni . < in utilise cette fin des diagrammes de collaboration qui contiennent les instances les ai teiu participants, les objets d'analyse et leurs liens. Si le cas d'utilisation comporte les Uni nu des sous-flots distincts, i l sera souvent prfrable de crer un diagramme de ciillahniaiiiui pour chacun de ces flots. La ralisation du cas d'utilisation n'en sera que plus claire et l elli option permettra d'extraire des diagrammes de collaboration reprsentant les inleiai i gnrales et rutilisables.

 o n c h a n e m e n t s d ' a c t i v i t s principaux

Analyse W CHAPITRE 8 Mm

nu II
EflfflH Exigences particulires sur une ralisation de cas d'utilisation

Parmi les exigences particulires imposes par la ralisation du cas d'utilisation Rgier la facture, citons les suivantes : la classe F a c t u r e doit tre persistante ; la classe G e s t i o n n a i r e de 10 000 transactions l'heure. commandes doit tre capable de grer

On cre un diagramme de collaboration en partant du dbut du flotdlll I I d'Utilisation pull en parcourant tout le flot tape par tape et en dterininani les intrrnt lions entre objets <l'analyse et instances d'acteur indispensables sa ralisai u m I es objets Irouvenl m gnral ualurellement leur place dans la squence d'interactions de la ralisai H m dei I I d'utilisation. On notera les remarques ci-dessous au sujet du diagramme de collaboration, Le cas d'utilisation est invoqu par un message adress par une instance d'acteur un objet frontire.

Lors de la formulation de ces exigences, rfrez-vous, si possible, aux exigences parti) u lires communes ayant pu tre identifies par l'architecte.
8.6.3 Activit : analyser une classe

Chaque classe d'analyse identifie dans l'tape prcdente doit possder au moins un objet d'analyse prenant part un diagramme de collaboration. Si tel n'est pas le cas, cela signifie que cette classe d'analyse est superflue, puisqu'elle ne participe aucune ralisation du cas d'utilisation.

L'objectif de l'analyse d'une classe (voir la figure 8.26) consiste : identifier et actualiser les responsabilits d'une classe d'analyse, partir du rle qu'elle joue dans les ralisations de cas d'utilisation ; identifier et actualiser les attributs et relations de la classe d'analyse ; formuler les exigences particulires pesant sur la ralisation de la classe d'analyse.
Figure 8.26 Entres et rsultat de l'analyse d'une classe. Ralisation -analyse de cas d'utilisation
,-"7

Les messages ne sont pas affects des oprations puisqu'on ne spcifie pas d'opration pour les classes d'analyse. En revanche, un message doit exprimer l'intention de l'objet appelant lors de son interaction avec l'objet invoqu. Cette intention constitue un embryon de responsabilit de l'objet rcepteur et peut mme devenir le nom de la responsabilit en question.

Il est souvent ncessaire que les liens figurant dans le diagramme soient des instances d'associations entre classes d'analyse. Soit ces associations existent dj, soit les liens dfinissent la ncessit de telles associations. Toutes les associations manifestes doivent tre esquisses ce moment-l et reprsentes dans le diagramme de classes concernant la ralisation du cas d'utilisation. La squence indique dans le diagramme ne doit pas tre le principal objet d'attention ; elle peut mme tre exclue si elle se rvle trop complique maintenir ou si elle provoque un clatement du diagramme. I l convient en revanche de s'intresser particulirement aux relations (liens) entre objets et aux besoins et exigences (tels qu'ils sont exprims dans les messages) sur chaque objet individuel. Le diagramme de collaboration doit prendre en compte toutes les relations du cas d'utilisation en cours de ralisation. Par exemple, si un cas d'utilisation A spcialise un cas d'utilisation B par le biais d'une relation de gnralisation, le diagramme de collaboration ralisant le cas d'utilisation A devra probablement faire rfrence la ralisation (par exemple, au diagramme de collaboration) du cas d'utilisation B. Il convient, dans certains cas, de complter les diagrammes de collaboration par des descriptions textuelles, notamment si un grand nombre de diagrammes ralisent le mme cas d'utilisation ou si certains diagrammes reprsentent des flots complexes. Ces descriptions textuelles doivent tre intgres au flot d'vnements-analyse de la ralisation du cas d'utilisation.
8.6.2.3 Expression des exigences particulires

O
D Ingnieur de composants

Analyser une classe

Classe d'analyse [complte]

Classe d'analyse [bauche] 8.6.3.1 Identification d e s responsabilits

Les responsabilits d'une classe peuvent tre identifies par l'association de tous les rles qu'elle joue dans les diffrentes ralisations de cas d'utilisation, que l'on recensera en tU diant les diagrammes de classes et d'interaction de ces diverses ralisations. N'oubliai p l i non plus, que les exigences de chaque ralisation de cas d'utilisation par rapport a < . classes font parfois l'objet d'une description textuelle, contenue dans le flot d'vnement analyse de la ralisation du cas d'utilisation.
fiflfflfl R l e s des classes Les objets Facture sont crs pendant le cas d'utilisation Facturer l'acheteur. Le vendeur excute ce cas d'utilisation pour demander un acheteur de rgler une commande (cre pendant le cas d'utilisation C m a d r des marchandises ou des services). Pendant l'excution o mn e

Nous allons, dans cette tape, formuler toutes les exigences, telles que les exigences non fonctionnelles, pesant sur une ralisation de cas d'utilisation identifie au cours de l'analyse et qui devront tre prises en compte pendant la conception et l'implmentation.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Analyse

tPf

cTiATrmcTmm
du cas d'utilisation, la facture est transmise l'acheteur, qui peut ensuit dckloi do la rylm ou non. Le paiement est effectu au cours du cas d'utilisation Rpg 1er i ,i facture, dans lequel l'objet chancier programme le rglement d'un objet Facture. La facture est ensuite rgle et l'ob-

les attributs des classes frontires dialoguant avec des acteurs humains reprsentent souvent des informations manipules par les acteurs, comme des champs de texte tiquets ; les attributs des classes frontires dialoguant avec des acteurs systme reprsentent souvent les proprits d'une interface de communication ; les classes de contrle sont rarement dotes d'attributs en raison de leur courte dure de vie. Il leur arrive toutefois d'en avoir ; ils reprsentent des valeurs accumules on drives au cours de la ralisation d'un cas d'utilisation ; les attributs formels ne sont pas forcment indispensables. Une simple explication d'une proprit gre par une classe d'analyse pourra suffire et figurer dans la description des responsabilits de la classe ; si une classe prsente des attributs trop nombreux ou trop complexes, elle peut tre illustre sous la forme d'un diagramme de classes spar ne montrant que le compartiment des attributs.
8.6.3.3 Identification d e s a s s o c i a t i o n s et d e s agrgations

jet Facture est sold.

Notez cependant que la mme instance de Facture participe la fois aux cas d'utilisation Fac-

turer l'acheteur et Rgler la facture. Il existe plusieurs moyens de synthtiser les responsabilits d'une classe. L'approche la plus simple consiste extraire les responsabilits de chaque rle, un par un, et ajouter les responsabilits ainsi dtectes ou modifier les responsabilits existantes partir d'une ralisation de cas d'utilisation la fois.
BlflfflH Responsabilits des classes La classe chancier possde les responsabilits suivantes : cration d'une demande de rglement; suivi des rglements programms et envoi d'une notification lors de l'excution ou de la suspension d'un rglement ; dclenchement du transfert d'argent la date d'chance ; notification d'une facture lors de son inscription l'chancier et une fois qu'elle a t rgle (c'est--dire acquitte). 8.6.3.2 Identification d e s attributs

Les attributs spcifient les proprits d'une classe d'analyse et sont souvent ncessits par les responsabilits d'une classe (telles qu'elles ont t voques ci-dessus). Lors de l'identification des attributs, i l n'est pas inutile de garder l'esprit les conseils et directives suivants : le nom d'un attribut doit tre un substantif [ 1 , 2 ] ;

Les objets d'analyse dialoguent les uns avec les autres par l'intermdiaire des liens figurant dans les diagrammes de collaboration. Ces liens sont souvent des instances des associations reliant les classes correspondantes. L'ingnieur de composants doit, par consquent, tudier les liens des diagrammes de collaboration afin de dterminer les associations ncessaires. Ces liens peuvent susciter le besoin de rfrences et d'agrgations entre objets. Le nombre de relations entre classes doit tre rduit le plus possible. I l ne s'agit pas, avant tout, de relations du monde rel devant tre modlises sous forme d'agrgations ou d'associations, mais de relations dont l'existence rpond aux exigences des diverses ralisations d'un cas d'utilisation. L'analyse ne doit pas s'attarder sur la modlisation des meilleurs chemins de recherche travers les agrgations ou les associations, qui sera mieux prise en charge par la conception et l'implmentation. L'ingnieur de composants dfinit galement la multiplicit des associations, les noms de rles, les associations rcursives, les rles ordonnancs, les rles qualifis et les associations n-aires (annexe A). Consultez galement les ouvrages [2, 3].
ISfflH Association entre classes d'analyse Une facture est une demande de paiement correspondant une ou plusieurs commandes (voir la figure 8.27). Cette relation est reprsente par une association de multiplicit I " (il y a toujours au moins une commande associe une facture) et par le nom de rle < MIIUV

souvenez-vous que les types d'attributs doivent tre conceptuels en analyse et, si possible, ne pas tre limits par l'environnement d'implmentation. Par exemple, montant conviendra pour l'analyse, tandis que son quivalent en conception pourra tre entier ; lorsque vous choisissez un type d'attribut, essayez d'en rutiliser un qui existe dj ; une mme instance d'attribut ne peut tre partage par plusieurs objets d'analyse. Si le besoin s'en fait sentir, l'attribut doit tre dfini dans sa propre classe ; si une classe d'analyse devient trop difficile comprendre en raison de ses attributs, on peut envisager de placer certains de ces attributs dans des classes part ; souvent, les attributs des classes entits coulent de source. Si une classe entit remonte une classe du domaine ou une classe entit mtier, les attributs de ces classes constituent des entres intressantes ;

rgler.

'Les e n c h a n e m e n t s d ' a c t i v i t s principaux

Analyse CHAPITRE 8

M/{ Mm

PARTIE II
0 8.27 8.6.3.5 Expression des exigences particulires

i-ji/rrure est la
lunule de '"lient d'une ou isieurs mandes.

Q commando h ri(|lcn

Nous allons, maintenant, procder l'expression de toutes les exigences d'une classe d'analyse identifies au cours de l'analyse mais appeles tre gres pendant la conception et l'implmentation (par exemple, les exigences non fonctionnelles). Veillez, pendant cette tape, tudier les exigences particulires de la ralisation de cas d'utilisation, qui peuvent comprendre des exigences (non fonctionnelles) supplmentaires pour la classe d'analyse.
BMH Expression des exigences particulires concernant une classe d'analyse On pourrait qualifier de la faon suivante les caractristiques des exigences de persistance concernant la classe Facture :

Facture

Il convient d'utiliser des agrgations lorsque les objets reprsentent :

intervalle de taille : de 2 24 kilo-octets par objet ; volume: jusqu' 100 000;

des concepts physiquement inclus les uns dans les autres, comme une voiture contient le conducteur et les passagers ; des concepts constitus les uns des autres, comme une voiture se compose d'un moteur et de roues ; des concepts formant une collection conceptuelle d'objets, comme une famille se compose d'un pre, d'une mre et des enfants.
8 . 6 . 3 . 4 Identification d e s gnralisations

frquence de mise jour : cration/suppression : 1 000 par jour ; mise jour : 30 mises jour l'heure ; lecture : 1 accs l'heure.

Lors de la formulation de ces exigences, rfrez-vous, si possible, aux exigences particulires communes ayant pu tre identifies par l'architecte.
8.6.4 Activit : analyser un paquetage

On utilise les gnralisations au cours de l'analyse pour dgager les comportements communs et partags entre diffrentes classes d'analyse. Ces gnralisations doivent demeurer un niveau lev et conceptuel, et leur principal objectif doit tre de faciliter la comprhension du modle d'analyse.
EfflH Identification des gnralisations

L'objectif de l'analyse d'un paquetage, comme le montre la figure 8.29, consiste : s'assurer que le paquetage d'analyse en question est aussi indpendant que possible des autres paquetages ; s'assurer que ce paquetage d'analyse remplit sa mission, qui est de raliser certaines classes du domaine ou certains cas d'utilisation ; dcrire les dpendances afin que les effets de futurs changements puissent tre estims.

Les Factures et les C m a d s ont des responsabilits semblables. Les unes et les autres sont o mn e des spcialisations d'un objet Transacti on commerci al e plus gnral ; voir la figure 8.28.

Iiro 8.28 rfiji!/ transaction f trciale

^j/i.vp les

Transaction commerciale

Voici quelques directives gnrales s'appliquant cette activit : dfinissez et actualisez les dpendances du paquetage envers les autres paquetages dont les classes lui sont associes ; assurez-vous que le paquetage contient les classes qui conviennent. Efforcez-vous de garantir la cohsion du paquetage en n'y incluant que les objets fonctionnellement lil

, i\ oinmande

Commande

limitez les dpendances envers d'autres paquetages. Envisagez de reloger dans ces paquetages les classes trop dpendantes des autres paquetages.

Au cours de la conception, les gnralisations seront ajustes afin qu'elles s'adaptent mieux l'environnement d'implmentation, par exemple au langage de programmation. I l est possible que certaines gnralisations disparaissent ; elles seront alors ralises par d'autres relations telles que des associations.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

J
I

Analyse
CHAPITRE 8

Wfj
WL

lire 8.29 Titres et ~iut'tage. rsultat II / analyse d'un Description de l'architecture [vue du modle d'analyse] Ingnieur de composants

individuels fournis par le systme et constituent un outil fondamental de prparation de la rutilisation pendant l'analyse.

Analyser un paquetage Paquetage d'analyse [esquisse]

Paquetage d'analyse [complet]

D p e n d a n c e s de paquetages

Des classes d'analyse, leurs responsabilits, attributs, relations et exigences particulires Chacune des classes de contrle, des classes entits et des classes frontires localisera les changements apports au comportement (strotyp) et aux informations qu'elles reprsentent. Une modification de l'interface utilisateur ou de l'interface de communication sera gnralement localise dans une ou plusieurs classes frontires ; unevolution des informations durables et souvent persistantes gres par le systme scia, an principe, localise dans une ou plusieurs classes entits ; enfin, un changement alle taul li contrle, la coordination, le squencement, les transactions et, parfois, la logique inein i complexe impliquant plusieurs objets (frontires et/ou entits) sera habitiiellenienl localis dans une ou plusieurs classes de contrle.

Le paquetage Gestion des factures par le vendeur contient une Classe Traitement des factures associe la classe Compte du paquetage Gestion des comptes, ce qui ncessite
une dpendance correspondante entre les paquetages (voir la figure 8.30).
Igurn 8.30 ttnrndances ssnires entre triages. Gestion des factures par le vendeur I Gestion des factures par le vendeur |

Les ralisations-analyse de cas d'utilisation, qui dcrivent la manire dont les cas d'utilisation sont prciss en termes de collaborations dans le modle d'analyse et leurs exigences particulires. Les ralisations de cas d'utilisation localiseront les changements dans les cas d'utilisation, car, si un cas d'utilisation volue, i l est probable que sa ralisation devra galement changer. La vue architecturale du modle d'analyse, avec ses lments significatifs sur le plan architectural. La vue architecturale (annexe C) localisera les changements dans l'architecture.

Traitement des factures

Gestion des comptes

Traitement des factures |

Gestion des comptes J

\ \

Comme nous allons le voir dans le chapitre suivant, le modle d'analyse est considr comme le principal document de travail des activits ultrieures de conception et d'implmentation. En utilisant le modle d'analyse dans ce but, on prserve autant que possible la structure qu'il dfinit tout en procdant la conception du systme par la prise en compte de la majeure partie des exigences non fonctionnelles et des autres contraintes lies l'environnement d'implmentation. Plus spcifiquement, le modle d'analyse aura sur le modle de conception le retentissement dcrit ci-dessous. Les paquetages d'analyse et de services auront, respectivement, une influence majeure sur les sous-systmes de conception et de services, dans les couches spcifiques l'application et gnrales toutes les applications. Dans bien des cas, une relation de traabilit un--un (isomorphe) liera les paquetages aux sous-systmes correspondants.

C ompte

R s u m

de

l ' a n a l y s e

L'enchanement d'activits de l'analyse (annexe C) aboutit la cration d'un modle d'analyse. I l s'agit d'un modle objet conceptuel qui analyse les besoins et les exigences en les affinant et en les structurant. Le modle d'analyse comprend les lments recenss cidessous. p Des paquetages d'analyse et de services, ainsi que leurs dpendances et leur contenu. Les paquetages d'analyse localisent les changements apports un processus mtier, au comportement d'un acteur ou un ensemble de cas d'utilisation troitement lis. De leur ct, les paquetages de service localisent les changements apports aux services

Les classes d'analyse serviront de spcifications pour la conception des classes I a conception de classes d'analyse issues de diffrents strotypes rclamera des comptences et des technologies diffrencies. Par exemple, la conception des classes entits ncessite souvent l'utilisation de bases de donnes, tandis que la conception de classes frontires exige plutt l'exploitation de technologies d'interfaces utilisaleui Toutefois, les classes d'analyse et leurs responsabilits, leurs attributs et leurs relations servent d'entre (logique) la cration des oprations, des attributs et des relations correspondants dans les classes de conception. De mme, la plupart des exigences particulires concernant une classe d'analyse seront prises en charge par les classes de

m e n c h a n e m e n t s d ' a c t i v i t s principaux
umi II

conception correspondantes lorsqu'il sera question, par exemple, de loi linoloyii de donnes ou d'interfaces utilisateur.

di hases

Les ralisations-analyse de cas d'utilisation poursuivent deux uh|ei nr. | paiw l . un de ces objectifs est d'aider la cration de spcifications plus prcises pont les i as d'utihsation. Au lieu de dtailler chaque cas d'utilisation dans le modle des, a-, d'utilisation par des diagrammes d'tats-transitions ou des diagrammes d'activits, la description de chaque cas d'utilisation sous forme de collaboration entre classes d'analyse produira une spcification formelle complte des exigences du systme I .es ralisations analyse de cas d'utilisation servent galement d'entres lors de la conception des cas d'utilisation. Elles facilitent l'identification des classes de conception devant participer aux ralisations-conception de cas d'utilisation correspondantes. Elles permettront galement une premire esquisse des interactions entre objets de conception. De mme, la plupart des exigences particulires exprimes sur une ralisation-analyse de cas d'utilisation seront gres par la ralisation-conception de cas d'utihsation correspondante lorsqu'il sera par exemple question de technologies de bases de donnes ou d'interfaces utilisateur.

La vue architecturale du modle d'analyse constitue une entre pour la cration de la vue architecturale du modle de conception. I l y a de fortes chances qu'une relation de traabiht unisse les lments des diffrentes vues (des diffrents modles), car la notion de pertinence architecturale a tendance se rpandre travers les modles par le biais de dpendances de traabiht.

9.1

Introduction

R f r e n c e s
1 I V A R JACOBSON, M A G N U S CHRISTERSON, P A T R I K JONSSON E T G U N N A R V E R G A A R D ,

Object-Oriented Software Engineering:

A Use-Case Driven Approach, Reading, MA,

Addison-Wesley, 1992 (quatrime dition rvise, 1993).

2 J. R U M B A U G H , M . B L A H A , W. P R E M E R L A N I , F. E D D Y E T W. L O R E N S E N , Object-

L'activit de conception consiste faonner le systme et lui donner une forme (et une architecture) rpondant tous les besoins et exigences (y compris les exigences non fonctionnelles et autres contraintes) formules son endroit. Base fondamentale de la conception, le modle d'analyse (voir le tableau 9.1) issu de l'analyse apporte une comprhension dtaille des besoins et des exigences. Mais surtout, i l impose au systme une structure qu'il faudra s'efforcer autant que possible de conserver lors de l'laboration du systme (voir le chapitre 8, section 8.2). Pour tre plus prcis, numrons les objectifs de la conception :

Oriented Modeling and Design, Englewood Cliffs, NJ, Prentice Hall, 1991. 3 OMG Unified Modeling Language Spcification, Object Management Group, Framingham, MA, 1998. Internet : www.omg.org.

acqurir une comprhension approfondie des questions concernant les exigences non fonctionnelles et les contraintes lies aux langages de programmation, la rutilisation des composants, aux systmes d'exploitation, aux technologies de distribution, de concurrence, de bases de donnes, d'interfaces utilisateur, de gestion des transactions, etc. ; constituer une base et un point de dpart aux activits subsquentes d'implmentation en formulant les exigences pesant sur chaque sous-systme individuel, sur les interfaces et sur les classes ; dcomposer le travail d'implmentation en portions plus grables, prises en charge pin plusieurs quipes de dveloppement, ventuellement en parallle. Celle possibilit se rvle utile dans les cas o la dcomposition ne peut se fonder sur les rsultats de l'expression des besoins (et du modle des cas d'utilisation) ou de l'analyse (et du moileli d'analyse). I l s'agit, par exemple, des cas o l'implmentation de ces rsultats ne peut in directe ; dterminer, trs tt dans le cycle de vie du logiciel, les principales interfaces entre soussystmes. Tout l'intrt de cette dmarche apparat lorsqu'il s'agit de rflchir

au e n c h a n e m e n t s d ' a c t i v i t s principaux AH III II

Conception CHAPITRE 9

l'architecture et d'utiliser les interfaces comme instruments de synchronisi diffrentes quipes de dveloppement ; visualiser et penser la conception l'aide d'une notation commune ;

les

Phases Enchanements d ' a c t i v i t s principaux Besoins

Figure 9.2 Point de convergence de la conception.

crer une abstraction transparente de l'implmentation du systme, au sens < m l'implmentation est un raffinement direct de la conception, que l'on se contente de muscler sans en modifier la structure. Ceci autorise l'usage de techniques telles que la gnration de code ou le round-trip engineering entre la conception et l'implmentation. Nous prsenterons, dans ce chapitre et dans les suivants, les moyens d'atteindre ces objectifs. Notre approche de l'enchanement d'activits de la conception est identique celle adopte pour l'enchanement d'activits de l'analyse (voir la figure 9.1).

y.1 Heurs et M impliqus , onception.

D Ingnieur de cas d'utilisation

responsable de

Itrations prliminaires

jter. #1

iter. #2

iter. #n

iter. #n+1

Iter. #n+2

Iter. Il m

Iter. #m+1

Itrations

Modle de dploiement

Description Ralisation-conception Classe Sous-systme de l'architecture de cas d'utilisation de conception de conception

Interface

9.3

A r t e f a c t s

9.3.1 R l e du de la c o n c e p t i o n d a n s le c y c l e de vie

Artefact

: modle

de

conception

logiciel

Le modle de conception est un modle objet dcrivant la ralisation physique des cas d'utilisation en s'attachant aux effets conjugus des exigences fonctionnelles et non fonctionnelles et des autres types de contraintes sur le systme en question. En outre, i l tient heu de vision abstraite de l'implmentation du systme et constitue par consquent une entre majeure pour les activits d'implmentation. Le modle de conception dfinit une hirarchie, comme l'illustre la figure 9.3. Enfin, le modle de conception est reprsent par un systme de conception illustrant le sous-systme de plus haut niveau du modle. L'utilisation d'autres sous-systmes offre ensuite un moyen de dcouper le modle de conception en parties plus grables. Les sous-systmes et les classes de conception constituent des abstractions (annexe C) des sous-systmes et des composants de l'implmentation du systme. Ces abstractions sont directes et reprsentent une correspondance simple entre la conception et rimplmcnlation Dans le modle de conception, les cas d'utilisation sont raliss par les classes de concept u m et leurs objets. Ces ralisations sont figures par des collaborations dans le model de cou ception et signales par l'expression ralisations-conception de cas d'utilisation. Note/ la distinction entre la ralisation-conception de cas d'utilisation et la ralisation-analyse de cas d'utilisation : la premire dcrit la ralisation du cas d'utilisation par des interactions entre objets de conception, tandis que la seconde la dcrit par des interactions entre objets d'analyse. Les artefacts du modle de conception sont prsents en dtail dans les sections qui suivent.

Durant les itrations de la fin de l'laboration et celles du dbut de la construction, la conception focalise toute l'attention (voir la figure 9.2). Elle contribue la mise en place d'une architecture saine et stable et cre un plan d'laboration et de construction pour le modle d'implmentation. Plus tard, au cours de la phase de construction, quand l'architecture est stable et les besoins parfaitement compris, l'attention se porte sur l'implmentation. Le modle de conception tant trs proche de l'implmentation, il est naturel de le conserver et de l'actualiser tout au long du cycle de vie du logiciel. Ceci se vrifie particulirement dans le cadre du round-trip engineering, o le modle de conception peut servir de visualisation l'implmentation et de support aux techniques de programmation graphique.

| e n c h a n e m e n t s d ' a c t i v i t s principaux

Conception
CHAPITRE 9 mm

tu :i
t'iii'ii est une H Itie de sous-

la classe en question. On peut ainsi diffrer les dcisions qui n'ont pas lieu d'tre tranches dans le modle de conception, par exemple celles concernant le codage de la classe.

NH de llillrIM M*
Hun, des iinti de cas iiiiim et des PS.

Modle de conception

Systme de conception

Sous-systme de conception

Une classe de conception se voit souvent attribuer un strotype ayant une correspondance transparente avec une construction du langage de programmation donn. Par exemple, une classe de conception d'une application Visual Basic pourra tre strotype en tant que module de classe , formulai re , contrle u t i l i s a t e u r , etc. Une classe de conception peut raliser, et par consquent fournir, des interfaces, si cell M justifie dans le langage de programmation. Par exemple, une classe de conception reprsentant une classe Java pourra fournir une interface.

Classe de conception

Ralisation-conception de cas d'utilisation

Interface

Artefact

: c l a s s e

d e

c o n c e p t i o n

Une classe de conception est une abstraction transparente d'une classe ou d'une construction quivalente de l'implmentation du systme (voir la figure 9.4). Le sens de la transparence de cette abstraction est expliqu ci-dessous. La spcification d'une classe de conception utilise le mme langage que le langage de programmation, si bien que les oprations, paramtres, attributs, types, etc., sont spcifis l'aide de la syntaxe du langage de programmation choisi.
Figure 9.4

Une classe de conception peut tre active, ce qui implique que les objets de celle classe maintiennent leur propre thread de contrle et s'excutent en mme temps que il ; objets actifs. Mais, en principe, les classes de conception ne sont pas actives : leurs objet! s'excutent dans l'espace d'adressage et sous le contrle d'un autre objet actif. L encore, la smantique dtaille exprimant ce fait dpend du langage de programmation cl des technologies de gestion de la concurrence et de la distribution utilises. Notez qu'une diffrence significative existe entre la smantique des classes actives de celle des autres classes. En vertu de cette diffrence, les classes actives pourraient tout aussi bien rsider dans leur propre modle de processus au lieu de figurer dans le modle de conception. Une telle rpartition convient dans les cas o les classes actives sont nombreuses et o leurs objets entretiennent des interactions complexes, par exemple dans certains systmes temps rel.
>
|zzj Classe de conception
r a l i s e r

La visibilit des attributs et des oprations d'une classe de conception est souvent prcise. Par exemple, l'usage des mots-cls public, protected ou private est frquent en C++.

Attributs cls et associations d'une classe de conception.

Interface

Les relations liant une classe de conception d'autres classes trouvent souvent une signification directe lors de l'implmentation de la classe. Par exemple, la gnralisation, ou tout strotype de gnralisation, emprunte une smantique correspondant la signification de la gnralisation (ou de l'hritage) dans le langage de programmation. Ce qui signifie qu'il existe souvent, entre les associations - ou les agrgations - et les variables (attributs) des classes de l'implmentation, une correspondance fournissant des rfrences entre objets.

relations mthodes exigences d'implmentation est active : {true, false}

Tableau 9.1 : Brve comparaison des modles d'analyse et de conception. [ M o d l e d'analyse M o d l e de conception

Les mthodes (c'est--dire les ralisations des oprations) d'une classe de conception prsentent des liens directs avec les mthodes correspondantes dans l'implmentation de la classe (c'est--dire le code). Si les mthodes sont spcifies en conception, elles le sont gnralement en langue naturelle ou en pseudo-code, et peuvent ainsi servir d'annotations l'implmentation des mthodes. C'est l'une des principales abstractions entre conception et implmentation, assez peu usite, cependant, puisque nous recommandons de confier au mme dveloppeur la conception et l'implmentation d'une classe (voir la section 9.4.3). Une classe de conception peut retarder la prise en compte de certaines exigences aux activits ultrieures d'implmentation en les qualifiant d'exigences d'implmentation sur

Modle conceptuel, car c'est une abstraction du systme qui vite les questions d'implmentation. Gnrique ia conception (applicable plusieurs conceptions).

Modle physique, puisque c'est un plan d'laboration et de construction de l'implmentation. Non gnrique, mais spcifique une implmentation.

I *< mu ii.niioments d ' a c t i v i t s principaux

Conception
CHAPITRE 9 mm

M o d l e d'analyse

M o d l e de conception

9.3.3

Artefact

: ralisation-conception

d e c a s

d'utilisation

Imis strotypes (conceptuels) de classe : de i ml rle , entit et frontire . Moins formel. Moins coteux dvelopper. l'un de couches. Dynamique (mais s'attache peu la squence). Irace les grandes lignes de la conception du systme, y compris de son architecture. ( merge principalement d'un vritable marathon entre les ateliers et les divers lieux de rflexion.

Autant de strotypes (physiques) de classe que le permet le langage d'implmentation. Plus formel. Plus coteux dvelopper (ratio de 5 1 par rapporta l'analyse). Nombreuses couches. Dynamique (mais s'intresse beaucoup la squence). Exprime la conception du systme, y compris de son architecture (une de ses vues). merge principalement de la programmation visuelle dans les environnements de round-trip engineering ; on effectue des allers-retours entre le modle de conception et le modle d'implmentation (dcrit dans le chapitre 10). Doit tre conserv tout au long du cycle de vie du logiciel. Faonne le systme tout en s'efforant de prserver autant que possible la structure dfinie par le modle d'analyse.
Figure 9.6

Une ralisation-conception de cas d'utilisation est une collaboration du modle de conception qui dcrit la ralisation et l'excution d'un cas d'utilisation spcifique par des classes de conception et les objets qui les composent. Une ralisation-conception de cas d'utilisation offre une traabilit directe avec une ralisation-analyse de cas d'utilisation issue du modle d'analyse (voir la figure 9.6). On peut donc faire remonter une ralisation conception de cas d'utilisation un cas d'utilisation dans le modle des cas d'utilisation pai le biais de la ralisation-analyse du cas d'utilisation.
Modle de conception

// existe des relations de traabilit entre les ralisations de cas d'utilisation des diffrents modles.

Modle d'analyse _ _. J c W Ralisation-analyse de cas d'utilisation

Ralisation-conception de cas d'utilisation

Risque de ne pas tre conserv tout au long du cycle de vie du logiciel. Dfinit une structure constituant une base essentielle pour la cration du systme (y compris pour la cration du modle de conception).
Classe de conception Facture

Dans les cas o le modle d'analyse ne sera pas conserv tout au long du cycle de vie du logiciel mais ne servira qu' crer une conception satisfaisante, i l n'y aura pas de ralisations-analyse de cas d'utilisation ; la dpendance de traabilit d'une ralisation-conception de cas d'utilisation mnera directement au cas d'utilisation dans le modle des cas d'utilisation. Une ralisation-conception de cas d'utilisation comporte une description textuelle de flot d'vnements, des diagrammes de classes dcrivant les classes de conception y participant et des diagrammes d'interaction dcrivant la ralisation d'un flot ou d'un scnario prcis du cas d'utilisation en termes d'interactions entre objets de conception (voir la figure 9.7). Si ncessaire, les diagrammes peuvent galement dcrire les sous-systmes et les interfaces impliqus dans la ralisation du cas d'utilisation (c'est--dire les sous-systmes contenant les classes de conception y prenant part).
Figure 9.7 ,'""""->
' Ralisation-conception de cas d'utilisation
, l o t

La figure 9.5 illustre la classe de conception Facture telle qu'elle a t labore en conception. L'attribut compte, suggr lors de l'analyse, a t transform en association avec une

classe Compte.
Facture compte crditer compte crditer 1 ^ ^ solde: Argent titulaire: TypeTitulaire titulaire: TypeTitulaire titulaire: TypeTitulaire montant: Argent date de rglement: Date date d'mission: Date +crer (montant: Argent, dateDeRglement: Date) remettre (acheteur: TypeAcheteur) ^-planifier (chance: Date) +solder() Compte

Attributs cls et . associations dune ralisationconception de cas d utilisation.

in 'u Facture t attributs et Unis et une iiu'ii reliant i n Facture Iris ( 'ompte.

d'vnements-conception diagrammes de classes diagrammes d'interaction exigences d'implmentation

larticipant

\t

Classe de conception

Sous-systme de conception

I ns e n c h a n e m e n t s d ' a c t i v i t s principaux

Conception mm
CHAPITRE 9 Mm

PARTIE II Une ralisation-conception de cas d'utilisation fournit une ruliNiillon physique de In rnli sation-analyse de cas d'utilisation laquelle elle csl lie pui une relation d, liaeiibllit, ci prend en compte la plupart des exigences non fonctionnelles (c'est a due des exigences pai ticulires) dfinies sur cette dernire. I l n'en reste pas moins qu'une n nli: aluni i onception de cas d'utilisation peut, tout comme les classes de conception, diffrer la prise en compte de certaines exigences aux activits d'implmentation en les qualifiant d'exigences d'impie mentation dans la ralisation.
9.3.3.1 Diagrammes de c l a s s e s 9.3.3.3 Flot d ' v n e m e n t s - c o n c e p t i o n

Les diagrammes dcrivant une ralisation de cas d'utilisation sont souvent difficiles dchiffrer, en particulier les diagrammes d'interaction. C'est pourquoi les flots d'vnements-conception, qui proposent une description textuelle clairant et compltant les dia grammes et leurs tiquettes, peuvent apporter un secours prcieux. Le texte doit voquer les objets qui dialoguent entre eux pour excuter le cas d'utilisation ou les sous-systmes IJUI \ prennent part. Cette description ne doit pas, cependant, faire mention des attributs, Opra tions ou associations des objets : elle en deviendrait difficile actualiser tant donne l < caractre changeant des attributs, oprations et associations des classes de conception Si des interfaces figurent dans les diagrammes, la description ne doit pas non plus en eilei les up, rations. L'adoption de cette approche permet de rduire au strict minimum la mv< u, d'actualiser la description du flot d'vnements-conception si les dlagl 61 de. m notamment les oprations apparaissant sur les messages des diagrammes d'inlcu viennent tre modifis. Les flots d'vnements-conception montrent tout leur intrt lorsqu'une mme ralisation de cas d'utilisation est dcrite par un grand nombre de diagrammes de squence ou lorsque certains diagrammes reprsentent des flots complexes. I l convient de noter les remarques suivantes : le flot d'vnements-conception d'une ralisation de cas d'utilisation n'tant pas local un diagramme de squence en particulier, on peut l'utiliser pour dcrire les relations qu'entretiennent plusieurs diagrammes ; les tiquettes (par exemple, les indications de contrainte ou les descriptions d'actions au cours d'une activation) d'un diagramme de squence ne sont pas locales ce diagramme. Toutefois, un trop grand nombre d'tiquettes risque de crer une certaine confusion. I l peut tre prfrable, dans ce cas, d'inclure le texte de certaines tiquettes dans le flot d'vnements-conception. Si l'on utilise la fois un flot d'vnements-conception et des tiquettes, i l faut qu'ils se compltent. Vous trouverez des exemples de description de flots d'vnements-conception dans la section 9.5.2.2.
9.3.3.4 Exigences d'implmentation

Une classe de conception et les objets qu'elle comporte - et, par consquent, le soussystme contenant la classe en question - participent souvent plusieurs ralisations de cas d'utilisation. I l se peut galement que certaines oprations, certains attributs et certaines associations d'une classe en particulier ne soient pertinents que pour une seule ralisation de cas d'utilisation. I l est donc important de coordonner toutes les exigences qu'imposent les diffrentes ralisations de cas d'utilisation sur une classe et ses objets, mais aussi sur le soussystme la contenant. On emploie cet effet des diagrammes de classes associs une ralisation de cas d'utilisation, montrant les classes les sous-systmes qui y participent et leurs relations. Ceci permet de garder la trace des lments prenant part une ralisation de cas d'utilisation. Vous trouverez des exemples de ces diagrammes de classes dans les sections 9.5.2.1 et 9.5.2.3.
9.3.3.2 D i a g r a m m e s d'interaction

La squence d'actions d'un cas d'utilisation dbute lorsqu'un acteur invoque celui-ci en adressant au systme un message sous une forme quelconque. Considrons l' intrieur du systme : un objet de conception recevra ce message de la part de l'acteur. Puis cet objet appellera un autre objet, afin que les objets impliqus dialoguent entre eux et excutent le cas d'utilisation. On prfrera, en conception, retracer cette interaction par le biais d'un diagramme de squence, puisque l'on s'attache avant tout dtecter les squences d'interactions dtailles et chronologiques. Dans certains cas, ces diagrammes de squence indiqueront en outre les sous-systmes qui prennent part la ralisation d'un cas d'utilisation et, ventuellement, les interfaces fournies (c'est--dire ralises) par ces sous-systmes. Cette option permet de concevoir les cas d'utilisation un niveau lev, avant de dvelopper la conception interne des sous-systmes participants ; elle est utile lorsqu'il s'agit, par exemple, d'identifier les interfaces des sous-systmes tt dans le cycle de vie du logiciel, avant que leur conception interne ne soit mise au point.

Les exigences d'implmentation sont prsentes sous la forme d'une description textuelle regroupant des exigences, notamment les exigences non fonctionnelles, pesant sut une n ali , sation de cas d'utilisation. I l s'agit l d'exigences qui sont exprimes en conception, mai' qui seront mieux prises en charge lors de l'implmentation. Certaines de ces exigences ont dj pu tre formules dans les enchanements d'activits prcdents ; il ne reste a loi s qu i les transformer en ralisation de cas d'utilisation. Mais i l arrive aussi que le ii.iv.nl de < mi ception en fasse apparatre de nouvelles. Vous trouverez des exemples d'exigences d'implmentation sur des ralisations CODI eption de cas d'utilisation dans la section 9.5.2.5.

Les diagrammes de squence reprsentent les interactions entre objets par des changes de messages entre les lignes de vie d'objets ou de sous-systmes. On parle de la rception d'un message par une ligne de vie de sous-systme pour signifier que c'est en fait un objet d'une classe contenue dans ce sous-systme qui reoit le message. De mme, lorsqu'un message est envoy depuis la ligne de vie d'un sous-systme, c'est en ralit un objet d'une classe contenue dans ce sous-systme qui l'envoie. Le nom d'un message doit indiquer une opration de l'objet invoqu ou d'une interface fournie (ralise) par l'objet. Vous trouverez des exemples de ce type de diagramme d'interaction dans la section 9.5.2.2.

I Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II
Figure 9.8

Conception J K V V B CHAPITRE 9 K U
conception

9.3.4

Artefact

: s o u s - s y s t m e

d e

Les sous-systmes de conception offrent un moyen d'agcnei i li ni im i .lu modle de conception en portions plus grables (voir la ligure ').). I In IOUI IVItfflC peut se composer de classes de conception, de ralisations de cas d'utilisalion, d'intrim es cl d'aunes sous systmes (de faon rcursive), mais il peut aussi fournir des Interfaces reprsentant If. loue tions qu'exportent celles-ci en termes d'oprations. Chaque sous-systme doit montrer de la cohsion : les lments qui le composent doivent tre fortement lis. I l faut aussi que les sous-systmes soient faiblement coupls : les dpendances qui les unissent leurs homologues ou leurs interfaces respectives doivent tre rduites au strict minimum. Ces sous-systmes de conception doivent, en outre, prsenter les caractristiques dcrites cidessous. Les sous-systmes peuvent reprsenter une segmentation des questions de conception. Par exemple, dans un vaste systme, certains sous-systmes pourront tre conus sparment, et ventuellement en parallle, par plusieurs quipes de dveloppement ayant diffrentes comptences de conception. Les deux couches suprieures de l'application et leurs sous-systmes dans le modle de conception ont souvent une traabilit directe avec des paquetages d'analyse et/ou des classes d'analyse. Les sous-systmes peuvent reprsenter des composants plus large granularit dans l'implmentation du systme ; c'est--dire que les composants fournissant plusieurs interfaces sont crs partir de plusieurs autres composants granularit plus fine, comme ceux qui spcifient les classes d'implmentation individuelles, et se manifestent sous forme d'excutables, de binaires ou d'entits semblables pouvant tre dploys sur diffrents nuds. Les sous-systmes peuvent reprsenter des produits logiciels rutiliss en les emballant (wrap) et accompagner la rflexion sur l'intgration de ce type de produits dans le modle de conception. Ces sous-systmes rsident dans les couches de middleware et de logiciel systme. Les sous-systmes peuvent reprsenter des systmes hrits en les emballant (totalement ou partiellement) et permettre l'intgration de systmes existants dans le modle de conception. La section 9.5.1.2 fournit de plus amples informations sur les sous-systmes et leur utilisation, et propose une mthode permettant de les identifier ainsi que leurs interfaces.

Contenu d'un soussystme et associations cls.

Classe de conception

Ralisation-conception de cas d'utilisation

Interfaco

9.3.4.1

S o u s - s y s t m e s de service

On utilise les sous-systmes de service un niveau infrieur de la hirarchie des sous sys tmes de conception pour la mme raison que l'on utilise les paquetages de service dans le modle d'analyse : afin de prparer les changements intervenant dans chaque service en localisant ces modifications au sous-systme de service correspondant. Pour revenir plus en dtail sur la notion de service, consultez la section 8.4.4.1 du chapitre 8. L'identification des sous-systmes de service repose sur les paquetages de service du modle d'analyse, auxquels ils sont gnralement lis par une traabilit un--un (isomorphe). Les sous-systmes de service sont donc plus rpandus dans les deux couches suprieures (la couche spcifique l'application et la couche gnrale aux applications), mais ils ont plus de problmes grer que leurs homologues paquetages de service, parce que : i l est possible que les sous-systmes de service aient besoin de fournir leurs services en termes d'interfaces et d'oprations ; les sous-systmes de service contiennent des classes de conception et non des classes d'analyse : ils traitent par consquent de nombreuses exigences non fonctionnelles et d'autres contraintes lies l'environnement d'implmentation. Ils ont donc tendance a contenir un plus grand nombre de classes que leurs homologues paquetages de service el il peut tre ncessaire de les dcomposer leur tour en sous-systmes (plus modestes ) pour en grer la taille ; un sous-systme de service conduit souvent un composant binaire ou excutable lin l'implmentation. Dans certains cas, i l faudra toutefois diviser ce sous systme, et le dploiement de chacune de ses parties sur diffrents nuds pourra implique! la ne.. Il d'un composant binaire ou excutable pour chaque nud. Il faudra peut tre a loi' dcomposer nouveau le sous-systme de service en sous-systmes (plus petits) alui qn< chacun encapsule la fonction dploye sur un nud spcifique. Vous trouverez des exemples de sous-systmes de service dans la section 9.5.1.2.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

Conception
CHAPITRE 9 ma

PARTIE II

9.3.6

Artefact d e

: description

d e

l'architecture

(vue

d u

m o d l e

I
- 3.5

c o n c e p t i o n )

La description de l'architecture contient une vue architecturale du modle de conception (annexe C), dont elle dcrit les artefacts significatifs sur le plan architectural (figure 9.10).
Figure 9.10 B,

Notez que l'on utilise encore, d'une manire gnrale, les . sysiim ,1, eiviee ordi naires pour agencer les artefacts du modle de conceptii m. couiinr l'voqui In si cl prc dente. Toutefois, nous introduisons ici un strotype > '.nie, syslinr l e M-I v h . pont indiquer explicitement que ces sous-systmes reprsentent d e s services Celte possibilit dvoile tout son intrt dans les systmes d'envergure (comprenant d e nombreux sous sys tmes) et permet de diffrencier facilement les divers types de sous systmes kappelczvous que le mme raisonnement vaut pour le strotype paquetage de service , Introduit au chapitre 8.
Artefact : interface

La description de , . l architecture contient une vue architecturale modle de conception. du

_ =l Description |. ecture
archit

vue architecturale

Les interfaces permettent de spcifier les oprations fournies par les classes et les sous-systmes de conception (voir la figure 9.9). luure 9.9
fgocUttions cls f interface.

Modle de conception

Les artefacts suivants sont normalement considrs comme significatifs architectural :

sur le plan

Sous-systme de conception

la dcomposition du modle de conception en sous-systmes, avec leurs interfaces et les dpendances les reliant. Cette dcomposition est particulirement significative pour l'architecture en gnral, puisque ce sont les sous-systmes et leurs interfaces qui chafaudent la structure fondamentale du systme ;

Une classe de conception fournissant une interface doit galement procurer les mthodes qui en raliseront les oprations. Un sous-systme fournissant une interface doit aussi contenir les classes de conception et les autres sous-systmes (de faon rcursive) qui fournissent cette interface. Les interfaces offrent un moyen de sparer la spcification des fonctions par des oprations de leur implmentation par des mthodes. Cette sparation libre chaque client dpendant, ou utilisateur, d'une interface donne de l'implmentation de cette interface. On peut, ds lors, remplacer l'implmentation spcifique d'une interface (une classe ou un sous-systme de conception) par une autre implmentation sans avoir modifier le client. La plupart des interfaces entre sous-systmes sont considres comme significatives sur le plan architectural parce qu'elles dfinissent les conditions d'interaction entre les sous-systmes. Dans certains cas, il est galement utile d'esquisser des interfaces stables trs tt dans le cycle de vie du logiciel, avant que les fonctions reprsentes ne soient implmentes par les sous-systmes. Ces interfaces peuvent alors tre considres comme des exigences par les quipes de dveloppement charges de concevoir les sous-systmes et servir d'instruments de synchronisation entre les diffrentes quipes susceptibles de travailler en parallle sur plusieurs sous-systmes [2]. La section 9.5.1.2 fournit de plus amples informations sur les interfaces et leur utilisation, et propose une mthode permettant de les identifier.

les classes de conception cls, comme celles que l'on peut faire remonter des classes d'analyse significatives sur le plan architectural, les classes actives et les classes de conception gnrales et centrales, celles qui reprsentent des mcanismes gnriques de conception et qui entretiennent de nombreuses relations avec les autres classes de conception. En principe, i l est suffisant de considrer comme importante sur le plan architectural une classe abstraite, en laissant de ct ses sous-classes, moins que cellesci ne manifestent un comportement intressant pour l'architecture, indpendamment de leur classe abstraite ;
1

les ralisations-conception de cas d'utilisation qui ralisent certaines fonctions importantes et stratgiques devant tre dveloppes tt dans le cycle de vie du logiciel, celles qui impliquent de nombreuses classes de conception et qui ont donc une larj'.c couverture englobant ventuellement plusieurs sous-systmes, ou enfin celles qui impliquent des classes de conception cls rpondant aux critres nonces prcdemment On trouvera, normalement, les cas d'utilisation correspondants dans lu vue a n i m e , lui il. du modle des cas d'utilisation et les ralisations-analyse de cas d'utilisation 01 dans la vue architecturale du modle d'analyse. Vous trouverez, dans les sections 9.5.1.2, 9.5.1.3 et 9.5.1.4, des exemples de ce qui i figurer dans la vue architecturale du modle de conception. 1. Si les classes actives devaient rsider dans leur propre modle de processus (comme nous l'avons liui rinwqui i plus haut), ellesfigureraientalors dans la vue architecturale du modle de processus.

es e n c h a n e m e n t s d ' a c t i v i t s principaux
'MIIIE II

Conception
CHAPITRE 9 HU

''Artefact

: m o d l e

d e

d p l o i e m e n t

9.3.8

Artefact d e

: d e s c r i p t i o n

d e

l'architecture

(vue

d u

m o d l e

d p l o i e m e n t )

Le modle de dploiement est un modle objet qui dcrit la distribution physique du systme en montrant la rpartition des fonctions sur les diffrents nuds de calcul du rseau (voir la figure 9.11). I l constitue une entre essentielle aux activits de conception et d'implmentation, puisque la distribution du systme a une influence majeure sur sa conception. ..'tu
'"le \ des de nuds. ment Modle de dploiement

La description de l'architecture contient une vue architecturale du modle de dploiement (annexe C), dont elle dcrit les artefacts significatifs sur le plan architectural (figure 9.12).
Figure 9.12
La description de ,, ... , l architecture contient une vue architecturale modle de dploiement. du

pu
Description de l'architecture vue architecturale

Nud

Modle de dploiement

On peut formuler les remarques suivantes propos du modle de dploiement : chaque nud reprsente une ressource de calcul, souvent un processeur ou une unit matrielle de ce type ; des relations entre les nuds reprsentent les moyens de communication qui les relient, tels qu'Internet, intranet, bus, etc. ; le modle de dploiement peut dcrire plusieurs configurations rseau diffrentes, y compris les configurations de test et de simulation ; Les fonctions (ou processus) d'un nud sont dfinies par les composants dploys sur ce nud ; le modle de dploiement lui-mme manifeste une correspondance entre l'architecture logicielle et l'architecture systme (le matriel). Vous trouverez des exemples de modle de dploiement dans la section 9.5.1.1.
9.4 Travailleurs

En raison de son importance, tous les aspects du modle de dploiement doivent apparatre dans la vue architecturale, y compris la rpartition des composants sur les nuds telle qu'on la trouve dans l'implmentation. La section 9.5.1.1 propose des exemples de ce qui peut figurer dans la vue architecturale du modle de dploiement.

9.4.1

Travailleur

a r c h i t e c t e

Pendant la conception, l'architecte est responsable de l'intgrit des modles de conception et de dploiement, et doit s'assurer que chacun de ces modles est correct, cohrent et lisible (voir la figure 9.13). Comme pour le modle d'analyse, i l est possible, dans le cas de systmes vastes et complexes, qu'un autre travailleur reprenne son compte la responsabilit du sous-systme de niveau suprieur du modle de conception (c'est--dire le systme de mu ception). Les modles sont jugs corrects lorsqu'ils ralisent les fonctions dcrites dans le modle des cas d'utilisation - e t uniquement celles-l - , les exigences supplmentaires et I. iim.l.l. d'analyse. L'architecte a galement la charge de l'architecture des modles de conception I I .1. dploiement, c'est--dire de l'existence de leurs parties significatives sur le plan au luie. tural telles qu'elles sont dcrites parles vues architecturales des modles. N'oublie/ pas qui ces vues font partie de la description de l'architecture du systme.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux PARTIE II

Conception CHAPITRE 9

ire 9.13 nmsabilits de

Figure 9.14 Responsabilits l'ingnieur cours de la conception. d'utilisation au de de cas

O D Ingnieur de cas d'utilisation I responsable de

architecte au Mrs de la
eption.

V
Ralisation-conception de cas d'utilisation

9.4.3 vue architecturale

Travailleur

: i n g n i e u r

d e

c o m p o s a n t s

Description de l'architecture Figure 9.15

L'ingnieur de composants dfinit et actualise les oprations, mthodes, attributs, relut s cl exigences d'implmentation d'une ou plusieurs classes de conception, cl s'assuic que chacune satisfait aux exigences formules son endroit partir des ralisations de cas d'un lisation auxquelles elle prend part (voir la figure 9.15). O

Responsabilits l'ingnieur composants cours de la conception. de au

de

Notez que l'architecte n'est pas charg du dveloppement continu et de l'actualisation des divers artefacts du modle de conception, qui sont du ressort des ingnieurs de cas d'utilisation et de composant concerns (voir les sections 9.4.2 et 9.4.3).
".2 Travailleur : i n g n i e u r d e c a s d'utilisation

Ingnieur de composants

Classe de conception

Sous-systme de conception

O Interface

_ m

L'ingnieur de cas d'utilisation veille l'intgrit d'une ou de plusieurs ralisations-conception de cas d'utilisation et s'assure que celles-ci satisfont aux exigences les concernant (voir la figure 9.14). Une ralisation-conception de cas d'utilisation doit raliser correctement le comportement de la ralisation-analyse de cas d'utilisation qui lui correspond dans le modle d'analyse - et uniquement ce comportement-ci - , ainsi que le comportement du cas d'utilisation correspondant dans le modle des cas d'utilisation. Ceci suppose de rendre parfaitement lisibles et conformes leur objectif la totalit des descriptions textuelles et des diagrammes dcrivant la ralisation de cas d'utilisation.

L'ingnieur de composants peut galement veiller l'intgrit d'un ou de plusieurs soussystmes, c'est--dire s'assurer que leur contenu (par exemple, des classes et leurs relations) est juste, que leurs dpendances vis--vis d'autres sous-systmes et/ou interfaces sont correctes et rduites au strict minimum, et enfin qu'ils ralisent correctement les interfaces qu'ils fournissent. Il sera bien venu, en gnral, de confier l'ingnieur de composants charg d'un sous systme la responsabilit des lments de modle que contient celui-ci. D'autre part, poui instaurer un dveloppement fluide et transparent, i l semble naturel que les artefacts du modle de conception (par exemple, les classes et les sous-systmes de conception) soient mens jusqu' l'enchanement d'activits de l'implmentation et implments pai le iiit'inc ingnieur de composants.

il

Notez que l'ingnieur de cas d'utilisation n'est pas charg des classes de conception, des sous-systmes, interfaces et relations employs dans la ralisation d'un cas d'utilisation, qui sont de la responsabilit de l'ingnieur de composants concern.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Conception
CHAPITRE

J
t.5

249

E n c h a n e m e n t d ' a c t i v i t s

les classes de conception significatives sur le plan architectural, telles que les classes actives ; les mcanismes de conception gnriques prenant en charge les exigences communes (par exemple, les exigences particulires de persistance, de distribution, de performances, etc.) telles qu'elles ont t formules au cours de l'analyse travers les classes d'analyse et les ralisations-analyse de cas d'utilisation.
Figure 9.17
Entres de la et rsultat Modle \ des cas d'utilisation "

Nous avons dcrit, prcdemment dans ce chapitre, le travail de eonceplion en lermel M.I tiques. Nous allons maintenant employer un diagramme d'activits pour eu ex; ci le comportement dynamique (voir la figure 9.16). O

Architecte

O
'Sous-systme [esquisse] Interface [esquisse]

conception

Figure 9.16 Enchanement activits de la meeption, avec 1rs travailleurs y prenant part et tirs activits.

Ingnieur de cas d'utilisation

architecturale.

Architecte

o
D Ingnieur de composants Concevoir un sous-systme

Exigences supplmentaires Conception , ^architecturale ' Modle d'analyse

Classe de conception [esquisse]

\e de dploiement [esquisse] Description de l'architecture [vue du m o d l e d'analyse]

1=6,

Description de l'architecture [vue des m o d l e s de conception et de dploiement]

Tout au long de cette activit, les architectes envisagent les diverses possibilits de rutilisation, comme la rutilisation partielle de systmes comparables ou de produits logiciels gnralistes. Les sous-systmes, interfaces et autres lments de conception qui en rsultent sont ensuite intgrs au modle de conception. L'architecte est galement charg de maintenir, d'affiner et d'actualiser la description de l'architecture et les vues architecturales des modles de conception et de dploiement.
9.5.1.1 Identification d e s n u d s et d e s c o n f i g u r a t i o n s r s e a u

La cration des modles de conception et de dploiement (tels qu'ils ont t dfinis plus haut dans ce chapitre) est mise en route par les architectes, qui esquissent les nuds du modle de dploiement et suggrent les principaux sous-systmes et leurs interfaces, les classes de conception importantes (y compris les classes actives) et les mcanismes de conception gnriques du modle de conception. Les ingnieurs de cas d'utilisation ralisent ensuite chaque cas d'utilisation sous forme de classes et/ou de sous-systmes de conception avec leurs interfaces. Les ralisations issues de cette phase expriment des exigences de comportement pour chaque classe ou chaque sous-systme prenant part aux ralisations de cas d'utilisation. Ces exigences sont ensuite spcifies par les ingnieurs de composants et intgres dans chaque classe, soit par la cration d'oprations, d'attributs et de relations cohrents sur chaque classe, soit par la cration d'oprations cohrentes sur chaque interface fournie par le soussystme. Tout au long de l'enchanement d'activits de la conception, les dveloppeurs identifieront des candidats la formation de nouveaux sous-systmes, interfaces, classes et mcanismes de conception gnriques mesure que le modle de conception voluera, tandis que les ingnieurs de composants responsables de chaque sous-systme affineront et actualiseront ces sous-systmes.
3.5.1 A c t i v i t : c o n c e p t i o n architecturale

La conception architecturale a pour objectif de tracer les grandes lignes des modles de conception et de dploiement et de leur architecture, en identifiant les lments suivants (voir la figure 9.17) : les nuds et leur configuration rseau ; les sous-systmes et leurs interfaces ;

Les configurations rseau physiques ont souvent un impact majeur sur l'architecture du logiciel et affectent les classes de conception ncessaires et la rpartition des fonctiona entre les nuds du rseau. I l est frquent que ces configurations suivent un modle il trois niveau-, distinguant les clients (les interactions avec les utilisateurs), les fonctions de bue de donni et la logique mtier/applicative sur trois couches indpendantes. Le schma Client IC simple n'est qu'un cas particulier de ce schma dans lequel la logique mtici/appln ai m place sur l'un des deux autres niveaux (celui des clients ou celui des base-, de donnes l Les configurations rseau traitent notamment des aspects numrs ci dessous Quels sont les nuds impliqus et quelles sont leurs capacits en puissance de liiiilcnu ni et en taille de mmoire ?

 a II

ii<-inents d ' a c t i v i t s principaux

Conception CHAPITRE 9

Quel type de connexions existe entre les nuds et

lin?

par quels protOCOlcjl COrflJnuniquaronl cation,

alors se dgager de l'volution progressive du modle de conception, lorsque le besoin d'clatement se fait sentir. Notez aussi que tous les sous-systmes ne sont pas dvelopps en interne par l'quipe du projet en cours ; certains d'entre eux pourront tre des produits rutiliss ou des systmes appartenant au patrimoine de l'entreprise. L'intgration, dans le modle de conception, de sous-systmes de ce type permet d'envisager et d'estimer les possibilits de rutilisation.
9.5.1.2.1. Identification des sous-systmes d'applications

Ouelles sont les caractristiques des connexions et des protocoles de coin telles que largeur de bande, disponibilit et qualit ?

\1 l-il un besoin de capacit de traitement redondante, de modes dgrads, de migration des processus, de cration de copie de secours des donnes, etc. ? I .11 minaissance des limites et des possibilits des nuds et de leurs connexions permettra i il. lulecte d'intgrer des technologies telles que les ORB (Object Request Brokers) ou les i \s de duplication des donnes, qui faciliteront la distribution du systme.
IHfflPJ Configuration rseau pour le s y s t m e interbancaire Le systme interbancaire s'excutera sur trois nuds serveurs et sur un certain nombre de nuds clients. Avant tout, il y a un nud serveur pour l'acheteur et un pour le vendeur, puisque les organisations auxquelles appartiennent l'acheteur et le vendeur ont chacune besoin d'un serveur central pour leurs objets et traitements mtier. Les utilisateurs finals accdent au systme par le biais de nuds clients, tels que le client Acheteur. Les nuds communiquent par le protocole TCP/IP sur l'Internet ou un intranet ; voir la figure 9.18. Il y a galement un troisime nud serveur, pour la banque elle-mme. C'est sur ce nud que le paiement des factures est rellement effectu (que l'argent est vir de compte compte).

Au cours de cette tape, nous allons identifier les sous-systmes de la couche spcifique a l'application et ceux de la couche gnrale aux applications (les deux couches supi leuiH I Voir la figure 9.19. Si l'analyse autorise une dcomposition satisfaisante en paquetages d'analyse, on unir., r i ces derniers autant que possible et on identifiera les sous-systmes correspondants dtni II modle de conception. Ceci est particulirement important lorsqu'on en arrive mis piiqui tages de service et permet l'identification de sous-systmes de service correspondants ne compromettant pas la structuration du systme en fonction des services qu'il In i Cependant, cette premire identification des sous-systmes sera lgrement amliore IU cours de la conception afin de prendre en compte les questions relatives la conception, il l'implmentation et au dploiement du systme ; nous voquerons ce point d'ici peu.
Couche spcifique l'application

de m four Serveur vendeur

Figure 9.19 Sous-systmes de la couche spcifique l'application et de la couche gnrale aux applications.

Couche gnrale aux applications

Internet \ Serveur banque

/

Couche de middleware Client vendeur

1Y

Couche de logiciel systme

Identification des s o u s - s y s t m e s de conception partir des paquetages d'analyse

( iiaque configuration rseau, y compris les configurations spciales destines aux tests et aux simulations, doit tre prsente dans un diagramme de dploiement indpendant. On peut ensuite commencer rflchir au moyen de rpartir les fonctions entre ces diverses configurations (voir la section 9.5.1.3).
9.5.1.2 Identification d e s s o u s - s y s t m e s et d e l e u r s i n t e r f a c e s

Les paquetages Gestion des factures par l'acheteur et Gestion des ciiiii|il.i". putiiiiil
tent d'identifier les sous-systmes correspondants dans le modle de conception (von la figure 9.20).

Les sous-systmes permettent d'agencer le modle de conception en portions grables. Ils peuvent tre identifis ds le dbut comme un moyen de rpartir le travail de conception, ou

M. ii.unements d ' a c t i v i t s principaux

Conception CHAPITRE 9 mm

n i/l'.V
m IMI.'.II, i ,i

M o d l e d'analyse paquetage d'analyseGestion des factures par l'acheteur .pnquotnuo il'niiiilyiio. Gestion des comptes

Lorsque les paquetages d'analyse (prcdents) ne refltent pas l'intgration d'un systme existant. I l est alors possible que la totalit, ou une partie, d'un systme existant soit emballe sous forme de sous-systme de conception part entire.

M o d l e de conception sous-systme de conception Gestion des factures par l'acheteur sous-systme de conception Gestion des comptes

Si les paquetages d'analyse (prcdents) n'ont pas t conus pour un dploiement direct sur les nuds. I l faudra sans doute alors que la dcomposition en sous-systmes rsolve certaines questions de dploiement en autorisant une nouvelle dcomposition en sous systmes (plus petits) qui seront affects chacun un nud individuel. Ces sous lyitml (plus petits) doivent ensuite tre perfectionns afin de rduire le plus possible le tralie rseau, etc.

Ifflfl

Raffinement des s o u s - s y s t m e s afin de prendre en compte les fonctions partages Interbank Software avait envisag d'implmenter tous les paquetages de service pour lu r glement des factures dans le sous-systme Gestion des factures par l'acheteur, auquel ils semblaient appartenir l'issue de l'analyse des cas d'utilisation lis la factuiatiun. Les dveloppeurs se sont ensuite rendu compte que plusieurs cas d'utilisation futurs tireraient un bnficie de la prsence d'un sous-systme de service gnral de paiement. Ils ont donc dcid d'attribuer cette fonction de rglement un sous-systme de service complet, appel Gestion de l ' c h a n c i e r . Ce qui signifie que le sous-systme Gestion des factures par l'acheteur utilise la fonction de planification des rglements depuis le sous-systme de service Gestion de l ' c h a n c i e r . Une fois que la facture arrive chance, le sous-systme Gestion de l ' c h a n c i e r utilise le sous-systme Gestion des comptes pour le virement effectif d'un compte l'autre. Voir la figure 9.22.

D'autre part, les paquetages de service Comptes et Risques figurant dans le paquetage Gestion des comptes du modle d'analyse permettent d'identifier les sous-systmes de service correspondants dans le modle de conception (voir la figure 9.21 ). 1,11 M o d l e d'analyse paquetage de service Comptes paquetage de service Risques paquetage d'analyse Gestion des comptes

mil m les Ifmrs de i t'iiiltt des thikr\ 0 ni Munis.

sous-systme de conception Gestion des comptes M o d l e de conception sous-systme de service Comptes sous-systme de service Risques

sous-systme de conception Gestion des factures par l'acheteur

Couche spcifique l'application

Couche gnrale aux applications sous-systme de service Gestion de l'chancier sous-systme de conception Gestion des comptes

Les cas dcrits ci-dessous exigent une amlioration de cette dcomposition initiale en soussystmes par rapport aux paquetages d'analyse (prcdents) du modle d'analyse.

Figure 9.22 La conception permet d'identifier le sous-systme de service Gestion de l'chancier, qui fournira un service gnral susceptible d'tre employ par plusieurs ralisations de cas d'utilisation.

Lorsqu'une partie du paquetage d'analyse (prcdent) correspond un sous-systme part entire (par exemple, s'il s'avre que cette partie peut tre partage et utilise par plusieurs autres sous-systmes).

Distribution d'un s o u s - s y s t m e sur diffrents

nuds

Le dploiement du sous-systme Gestion des factures par l'acheteur ncessite sa distribution sur plusieurs nuds. Pour ce faire, le sous-systme est, son tour, dcompos en trois sous-systmes : IU de l'acheteur, Gestion des demandes de rglement et Gest i o n des factures (voir la figure 9.23). Les composants crs partir de chacun de ces trois sous-systmes (plus petits) peuvent ensuite tre dploys respectivement sur les nuds Client acheteur, Serveur acheteur et Serveur vendeur.

Lorsque certaines parties du paquetage d'analyse (prcdent) sont ralises par des produits logiciels rutiliss. I l est possible, dans ce cas, que certaines fonctions soient affectes des sous-systmes de middleware ou de logiciel systme (voir la section 9.5.1.2). Lorsque les paquetages d'analyse (prcdents) ne refltent pas une rpartition approprie du travail.

wmm L e s e n c h a n e m e n t s d ' a c t i v i t s principaux mM rMiTIElI

Conception B j j CHAPITRE 9 Mm

Ngiire 9.23 \>>ii\ ./ i ompos de

sous-systme de conception Gestion des factures par l'acheteur sous-systme de conception Gestion des d m n e do reglomtinl e a ds Traitement des d m n e e ad de rglement Gestionnaire de c m a d s o mn o xsoun-systmo do conception' Il ni I.ii line .

dpendant possible de produits du commerce et de limiter, par l-mme, les risques lis leur utilisation en cas de changement, ou de garder la possibilit de choisir un autre diteur si ncessaire.

" rcursive en sous-systme de conception tivis nouveaux IU de l'acheteur WMJ systmes, afin -A prendre en de d m n e e ad i ompte le de rglement J. ploiement.

liiiltemi-nl dos IncluroH

Il existe un moyen de contrler les dpendances : i l suffit de traiter chaque produit logiciel acquis comme un sous-systme part ayant des interfaces explicites avec le reste du systme. Par exemple, si vous avez besoin d'un mcanisme de distribution transparente des objets, vous pouvez dfinir une interface stricte vis--vis d'un sous-systme qui ralisera i i mcanisme. Cette solution vous laissera la libert de choisir entre divers produits, puisque le cot d'actualisation du systme sera, de ce fait, parfaitement dlimit.
Bfflgfl Utilisation de Java lors de la construction de la couche de middleware Il est possible que plusieurs des implmentations de sous-systmes d'applications inlstis m point par Interbank Software s'excutent sur diffrents types de machines, pat exemple dm; PC et des stations de travail Unix, et soient par consquent amenes cooprai sut divin sur. plates-formes. Interbank Software a choisi d'implmenter cette interoprabilit a iaidi: du

Client acheteur

Serveur acheteur

Serveur vendeur

9.5.1.2.2.

Identification

des sous-systmes

de middleware

et de logiciel

systme

produits de middleware, en l'occurrence des paquetages Java AWT (Abstract Wiiidowiny Toolkit), RMI (Remote Method Invocation) et Applets. Ces paquetages Java sont reprsents sous forme de sous-systmes dans la figure 9.25. Ils sont btis sur la machine virtuelle Java, c'est--dire l'interprteur Java qui doit tre install pour qu'une machine puisse excuter du code Java. Dans nos exemples, nous utilisons un navigateur Internet pour charger les pages web qui vont chercher les applets. Au niveau le plus bas, Interbank Software construira au-dessus d'un logiciel systme tel que le protocole TCP/IP pour les communications par l'Internet (voir la figure 9.25). Le sous-systme Appf et Java est un middleware qui permet Interbank de crer des applets

Le middleware et le logiciel systme constituent le fondement d'un systme, car toutes les fonctions s'appuient sur des logiciels tels que les systmes d'exploitation, les systmes de gestion de base de donnes, les logiciels de communication, les technologies de distribution des objets, les kits de conception d'IHM et les technologies de gestion des transactions [3] (voir la figure 9.24). Le choix et l'intgration de produits logiciels acquis ou construits spcialement pour le projet se situent par consquent au cur des proccupations des phases de cration et d'laboration. L'architecte valide que les logiciels choisis conviennent l'architecture et qu'ils assurent une implmentation rentable du systme.

Couche spcifique l'application

Java. Chaque fentre d'interface utilisateur est conue l'aide de la classe Appl et Java et d'autres

fIV

classes d'interface utilisateur telles que Li sts, fournies par le sous-systme AWT. Le paqueCouche gnrale aux applications tage Java AWT (java.awt) est conu pour permettre la cration d'interfaces utilisateur indpendantes de toute plate-forme et comprend des classes telles que Fields, Scroilbars et Check Boxes. Couche de middleware Java RMI est un mcanisme de distribution des objets intgr dans les bibliothques de clas ses Java standard. Nous avons choisi RMI pour la distribution des objets afin de simplllitn lus exemples et d'viter d'associer plusieurs techniques et langages. Une solution COHUA un Ai Couche de logiciel systme tiveX/DCOM aurait tout aussi bien fait l'affaire.

I Iqure 9.24 Ifi sous-systmes des <ouches de middleware et de logiciel systme encapsulent les logiciels acquis.

Avertissement : l'acquisition des logiciels de middleware et du logiciel systme limite, voire invalide, la matrise de leur volution. I l est donc important de conserver une marge de manuvre raisonnable et d'viter de se retrouver pig et totalement dpendant d'un projet ou d'un diteur sur lequel le projet n'a que peu d'influence. Essayez d'tre le moins

I on e n c h a n e m e n t s d ' a c t i v i t s principaux

Conception
CHAPITRE 9

I mttlillrware Hf /munissent minimes |i.il, m

Java.applet

Figure 9.26 Java.awt

Couche spcifique l'application Gestion des factures par l'acheteur

Coin IH. .1.- nil.ML.wm,>

KjfMJ
Itpr minute s de

Dpendances et couches de certains des sous-systmes du systme interbancaire.

ffp plan-forme

Navigateur

Machine virtuelle Java

Gestion de l'chancier

Gestion des comptes

Couche gnrale aux application.

mmtlet jnrnt lu mise en " i , de lu \IHhiitnm des ii (invti.rmi).

Couche de logiciel systme Java.applet Navigateur

Couche do mtddluwmn

La figure 9.25 illustre la faon dont les services Java peuvent tre rpartis en sous-systmes dans la couche de middleware. Elle ne montre aucune dpendance entre sous-systmes (celles-ci sont prsentes dans la figure 9.26). Chaque sous-systme contient des classes conues pour tre utilises en association les unes avec les autres afin d'offrir certains services. De mme, les composants ActiveX (comme ceux prenant en charge les tableurs, le multimdia, le traitement d'images, la gestion de la scurit, la persistance, la distribution, les moteurs d'infrences, les traitements et la concurrence) peuvent galement tre reprsents sous forme de sous-systmes. Souvent, il est pratique de crer un sous-systme part pour les types de donnes ou les classes fondamentales standard que tous les autres sous-systmes peuvent importer et employer : par exemple, java.lang, qui fournit une grande partie des classes

Machine virtuelle Java

Couche de logiciel systmo

Mais lorsque les dpendances ont un impact sur l'architecture du systme, notamment lorsqu'elles traversent les couches, il est utile de les rendre explicites dans le modle de conception et de les dcrire dans des diagrammes de classes tels que celui de la figure 9.26. Les ingnieurs de cas d'utilisation, comme les ingnieurs de composants, peuvent ensuite se reporter ces diagrammes lors de la conception des cas d'utilisation, des classes et des sous-systmes.

de base de Java, telles que Boolean, Integer et Float.

9.5.1.2.3 Dfinition des dpendances entre sous-systmes 9.5.1.2.4.

Identification

des interfaces

de

sous-systme

Les dpendances entre sous-systmes doivent tre dfinies si les lments que contiennent ces sous-systmes entretiennent des relations. La direction de la dpendance doit tre la mme que la direction (de navigabilit) de la relation. Si les dpendances doivent tre traces avant que le contenu des sous-systmes ne soit connu, on considre que les dpendances entre paquetages d'analyse correspondent aux sous-systmes de conception. Il y a de fortes chances pour que ces dpendances soient identiques dans le modle de conception. Enfin, si l'on utilise des interfaces entre sous-systmes, les dpendances doivent relier ces interfaces et non les sous-systmes eux-mmes (voir le paragraphe Identification des interfaces de sous-systme ).
BlflfflH D p e n d a n c e s et couches La figure 9.26 illustre les sous-systmes du systme interbancaire et certaines de leurs dpendances (initiales)

Les interfaces que procure un sous-systme dfinissent les oprations accessibles depuis l' extrieur de ce sous-systme. Ces interfaces sont fournies soit par des classes, soit par d'autres sous-systmes (de faon rcursive) contenus dans le sous-systme en question. Pour jeter les bases des interfaces, et avant que le contenu des sous-systmes ne soit connu, on commence par prendre en considration les dpendances entre sous-systmes telles qu'elles ont t identifies dans l'tape prcdente (paragraphe Dfinition des dpen dances entre sous-systmes ). L'existence d'une dpendance dirige vers un soiis-sysiine ncessite en gnral que ce sous-systme fournisse une interface. D'aulrc pari, si l'on peui remonter un paquetage d'analyse partir de ce sous-systme, il esl possible que chaque classe d'analyse rfrence depuis l'extrieur du paquetage suppose une interface CWldidti fournie par le sous-systme (comme le montre l'exemple suivant).
Effijfl Identification d'interfaces candidates partir du m o d l e d'analyse Le paquetage de service Comptes contient une classe d'analyse nomme V i rcmcn t . m t re comptes, rfrence depuis l'extrieur du paquetage. On peut donc identifier une interface lui tiale, appele Vi rement s, fournie par le sous-systme de service Compte correspondant dan:; le modle de conception (voir la figure 9.27).

Notez que certaines de ces dpendances, en particulier celles des couches de middleware et de logiciel systme, peuvent tre plus ou moins implicites dans l'environnement d'implmentation (dans ce cas, Java).

luiinements d ' a c t i v i t s principaux

Conception CHAPITRE 9 mm

IB/

M o d l e d'analyse

paquetage d# Mrvlce ] Comptes | Virements Cmt o no entre comptes Historique des comptes

Classe rfrenant Virements entre comptes depuis l'extrieur implique une candidate M o d l e de conception o Virements

L'identification des interfaces des deux couches infrieures (c'est--dire les couches de middleware et de logiciel systme) est plus simple, car les sous-systmes de ces couches encapsulent des produits logiciels susceptibles de comporter des interfaces prdfinies sous une forme ou une autre.

sous-systme de service Comptes

Mais il ne suffit pas d'identifier les interfaces ; i l faut aussi dterminer les oprations quechaque interface doit dfinir. Pour ce faire, les cas d'utilisation sont conus sous forme de sous-systmes et d'interfaces de sous-systmes, comme le dcrivent les sections 9.5.2 i ,<i 9.5.2.4, dans l'activit de conception des cas d'utilisation. On peut, de la sorlc, Ibrniiilci des exigences sur les oprations qui doivent tre identifies par les interfaces. Les exi^ciu es issues des diverses ralisations de cas d'utilisation sont ensuite prises en compte et inlcen i pour chaque interface, comme le dcrit la section 9.5.4.2.
9.5.1.3 Identification d e s c l a s s e s d e c o n c e p t i o n s i g n i f i c a t i v e s s u r le plan a r c h i t e c t u r a l

En suivant cette approche, nous avons identifi les interfaces que montre la figure 9.28 dans les deux couches suprieures du modle de conception

sous-systme H O de conception DestinataireFacture Gestion des factures par l'acheteur

Couche spcifique l'application

Demande De Rglement Couche gnrale aux applications sous-systme - X O H de conception Virements Gestion des comptes

Il peut tre pratique d'identifier les classes de conception significatives sur le plan nullit, tural tt dans le cycle de vie du logiciel, afin d'amorcer le travail de conception, Mae. la plupart des classes de conception seront dtermines lorsque les classes seront conues dans l'activit de conception des classes, puis affines en fonction du rsultat de l'activit de conception des cas d'utilisation (voir les sections 9.5.2 et 9.5.3). C'est pourquoi les dveloppeurs doivent veiller ne pas identifier un trop grand nombre de classes ce stade et ne pas se noyer dans les dtails : en principe, une premire bauche des classes significatives sur le plan architectural devrait suffire (voir la section 9.3.6). Sinon, on s'expose au risque d'avoir refaire une grande partie du travail plus tard, au moment o les cas d'utilisation servent justifier les classes de conception (c'est--dire justifier les classes prenant part des ralisations de cas d'utilisation). Une classe de conception ne participant aucune ralisation de cas d'utilisation est inutile.
9.5.1.3.1. Identification des classes de conception partir des classes d'analyse

sous-systme de service Gestion de ('chancier

Le sous-systme Gestion des comptes fournit l'interface Virements pour le transfert d'argent entre comptes. Il s'agit de la mme interface que celle fournie par le sous-systme de service Comptes au sein du sous-systme Gesti on des comptes (voir l'exemple prcdent). Le sous-systme Gestion de l ' c h a n c i e r fournit l'interface DemandeDeRglement, qui permet de planifier les rglements. Enfin, le sous-systme Gestion des factures par l'acheteur fournit l'interface DestinataireFacture afin de recevoir de nouvelles factures mises par un vendeur. Cette interface est utilise dans le cas d'utilisation Facturer l'acheteur, qui prvoit l'expdition d'une nouvelle facture l'acheteur.

Certaines classes de conception peuvent, dans un premier temps, merger des classes d'analyse significatives sur le plan architectural dtectes au cours de l'analyse. De mme, les relations entre ces classes d'analyse peuvent servir l'identification d'un ensemble provisoire de relations entre les classes de conception correspondantes.
B M H Esquisse d'une classe de conception partir d'une classe d'analyse La classe de conception Facture est esquisse partir de la classe entit Facture du modle d'analyse (voir la figure 9.29). M o d l e d'analyse M o d l e de conception

Notez que les interfaces identifies ici permettent d'affiner les dpendances entres sous-syslenics, selon les termes voqus plus haut, dans le paragraphe Dfinition des dpendances intre sous-systmes , puisque les dpendances peuvent porter sur les interfaces et non sur les sous-systmes.

Figure 9.29 La classe de conception Facture est d'abord issue de la classe entit Facture.

Iiniiioments d ' a c t i v i t s principaux

Conception CHAPITRE 9

/ I l. Identification

des

classes

actives

C l a s s e s d'analyse

N u d s et leurs objets actifs

liilecte identifie galement les classes actives ncessaires au sysicmc en prenant en con ni les exigences de concurrence pesant sur le systme, telles que celles Indique! l I dnions

Gestionnaire stionna de commandes :omman Confirmation de commande

: Serveur acheteur > esquisse : Traitement des demandes dt rolwiwnl

i exigences de performances, de dbit et de disponibilit qu'expriment les diffrents MIS dans leur interaction avec le systme. Si, par exemple, un acteur particulier a de tintes exigences sur les temps de rponse, i l faudra peut-tre y consacrer un objet actif, ii ii re de prendre en compte les entres de l'acteur et de produire des sorties pour ce m me acteur : un objet qui ne sera pas suspendu simplement parce que d'autres objets sei ont trop chargs ( condition que la capacit du processeur et les ressources en mmoire le permettent). l . i distribution du systme sur des nuds. Les objets actifs ont besoin de prendre en charge la distribution sur plusieurs nuds diffrents qui pourra ncessiter au moins un ' ilijei actif par nud et des objets actifs spars pour assurer les communications entre i u ends. I iilui. d'autres exigences, comme celles pesant sur le dmarrage et l'interruption du terne, sur sa vivacit (liveliness), l'vitement des blocages et de la privation de ressources, la reconfiguration des nuds et la capacit des connexions.

Figure 9.30 Une classe active, Traitement des demandes de rglement, se dgage de l'tude des classes d'analyse Gestionnaire de commandes et Confirmation de commande et du nud Serveur acheteur. On dcide que, lorsque seront conues les classes d'analyse, les parties principales des classes de conception correspondantes seront affectes au nud Serveur acheteur. La classe Traitement des demandes de rglement est alors identifie pour encapsuler le thread de contrle de ces classes de conception sur le nud.

Une autre possibilit d'esquisser les classes actives consiste utiliser les sous systme! identifis plus tt et affecter tout un sous-systme un nud spcifique en identifiant une classe active l'intrieur de ce sous-systme (voir, plus haut, le paragraphe Identification des sous-systmes d'applications ). N'oubliez pas qu'il faudra peut-tre amliorer la dcomposition en sous-systmes pour que ce soit possible. Toute classe active reprsentant un processus est potentiellement candidate l'identification d'un composant excutable lors de l'implmentation. L'affectation des classes actives des nuds au cours de cette tape constitue donc une entre essentielle pour l'affectation des composants (excutables) des nuds au moment de l'implmentation. Par ailleurs, lorsque tout un sous-systme est affect un nud, il arrive frquemment que les lments qui le constituent contribuent ensemble la fabrication d'un composant (excutable) affect ce nud.
9 . 5 . 1 . 4 Identification d e s m c a n i s m e s gnriques de c o n c e p t i o n

i ti.n une des classes actives est bauche en prenant en considration le cycle de vie de ses Objet! actifs et la faon dont ceux-ci doivent communiquer, synchroniser et partager les Informations. Ces objets actifs sont ensuite affects aux nuds du modle de dploiement. I on de cette affectation, il convient de prendre en compte la capacit des nuds, notamment li un processeurs et la taille de leur mmoire, ainsi que les caractristiques des connexions, i u particulier leur largeur de bande et leur disponibilit. Une rgle lmentaire veut que le u .ilu rseau ait une influence substantielle sur les ressources de calcul (aussi bien matmiles que logicielles) requises par le systme et doive, par consquent, tre parfaitement I I mi rle. Ce qui peut avoir un retentissement majeur sur le modle de conception. Il est possible, pour commencer identifier les classes actives, d'utiliser comme entres les rsultats de l'analyse et le modle de dploiement, puis de relier les conceptions correspon I.mies des classes d'analyse (ou une partie de ces classes) des nuds par l'intermdiaire de classes actives.
Bfflfll Utilisation des classes d'analyse pour esquisser les classes actives Comme nous l'avons indiqu plus haut, le systme interbancaire doit tre rparti sur des nuds tels que Client acheteur, Serveur acheteur, Serveur banque, etc. Nous avons en outre identifi des classes d'analyse : lu Demande de r g l e m e n t , G e s t i o n n a i r e nant qu'un acheteur est intress par la fonction offerte par les classes d'analyse Confirmation de commande et Gestionnaire de commandes, mais que cette fonction a besoin de plus de puissance de calcul qu'un nud Cl ient acheteur ne peut lui en fournir. Les principales parties de ces deux classes d'analyse doivent tre affectes au nud Serveur acheteur et gres par une classe active spare ( r a i t e m e n t ment) sur ce mme nud. des demandes de rglede commandes, Confirmation de commande, Facture, etc. (voir la figure 9.30). Il apparat mainte-

Nous allons maintenant tudier les exigences communes, telles que les exigences particulires identifies au cours de l'analyse sur les ralisations-analyse de cas d'utilisation et les classes d'analyse, et dcider de la manire dont elles seront prises en charge en fonction des technologies de conception et d'implmentation disponibles. Il rsultera de cette opration un ensemble de mcanismes gnriques de conception qui pourront se prsenter sous loi nie de classes de conception, de collaborations ou mme de sous-systmes identiques ce que dcrit [1]. Les exigences prendre en charge concernent en gnral les questions : de persistance, de distribution transparente des objets, de caractristiques de scurit, de dtection des erreurs et de rcupration, de gestion des transactions.

m i c h a n e m e n t s d ' a c t i v i t s principaux

rAimi II

Conception
CHAPITRE 9

263

Utilisation d'une collaboration g n r i q u e dans plusieurs ralisations de cas d'utilisation Au cours de leur travail sur les cas d'utilisation et leurs ralisations, les architectes Identifiant un pattern dans lequel un objet Transaction commerciale, tel qu'une C m a d ou uni Fa o mn e ture, est cr par un acteur et envoy un autre acteur :

Dans certains cas, il arrive que ces mcanismes ne soicnl p u I m m d i a t e m e n t apparents mais qu'ils se dgagent de l'exploration des ralisations de cas d'utilisai ion cl des classes de conception. jjjgJJJI M c a n i s m e de conception pour la distribution transparente des objets Certains objets, tels que les objets Facture, doivent tre accessibles depuis plusieurs nuds et conus pour un systme distribu. Interbank Software dcide d'implmenter la distribution des objets en faisant de chaque classe distribue une sous-classe de la classe abstraite Java java.rmi .server.UnicastRemoteObject, qui prend en charge RMI (Remote Method Invocation) ; voir la figure 9.31. RMI est la technique utilise par Java pour parvenir aune distribution transparente des objets (c'est--dire que les objets sont distribus de telle sorte qu'un objet client n'ait pas savoir o rside l'objet appel).

lorsqu'un acheteur dcide de commander certaines marchandises ou certains swv ,nn vendeur, il invoque le cas d'utilisation C m a d r des marchandises ou des scrvln".. o mn e qui lui permet de rdiger et d'envoyer par courrier lectronique une commanda an vninlmii concern ; lorsqu'un vendeur dcide de facturer un acheteur, il invoque le cas d'utilisation I ,u u n i l'acheteur, qui envoie par courrier lectronique une facture l'acheteur cniicniii Il s'agit l d'un type de comportement courant, pouvant tre reprsent pat uni: ooHabninlion gnrique, comme le montre le diagramme de collaboration de la figure 9.32 1: envoyer transaction commerciale :IU de cration transactions commerciales

UnicastRemoteObject

rlUinn il :il li i /m vr destine ti ilmr doit tre M mm Iv/ic de H/NII iiMh'emuleObject.

7T

une classe distribue

: Expditeur

2: crer Transaction Commerciale,;) : Traitement par l'expditeur commerciale

BH3H

M c a n i s m e s de conception pour la persistance Certains objets, tels que les objets Facture et C m a d , doivent tre persistants. Interbank o mn e Software peut utiliser, pour cela, un systme de gestion de bases de donnes objet, un systme de gestion de bases de donnes relationnelles ou tout simplement des fichiers binaires. Le choix dpend de la faon dont on aura besoin d'accder aux objets et de les actualiser, et des possibilits d'implmentation et d'volution ultrieures. Une base de donnes relationnelle offrira gnralement de meilleures performances dans le cas de donnes tabulaires, tandis qu'une base de donnes objet sera mieux adapte aux structures complexes d'objets. Si les systmes de gestion de bases de donnes relationnelles montrent plus de maturit que les systmes de bases de donnes objet, il peut toutefois revenir plus cher de construire un systme l'aide d'un systme de gestion de bases de donnes relationnelles, puis de le mettre niveau plus tard avec une base de donnes objet (une fois que celle-ci aura atteint un niveau de maturit satisfaisant). Quelle que soit la solution retenue, elle sera documente par l'architecte en tant que mcanisme gnrique de conception pour la gestion des questions de persistance. Figure 9.32

4: recevoir Transaction Commerciale (stubTransaction Commerciale) 6: prsenterTransaction M 7: prsenter Commerciale : Traitement de prsentation transaction commerciale par le destinataire (stubTransaction Commerciale) des transactions commerciales

>

Diagramme de collaboration montrant une collaboration gnrique de prsenter des transactions commerciales.

permettant de crer, d'envoyer, de recen ,ii , i

Tout d'abord, l'IU de cration des transactions commerciales reoit de l'acteur I xpi di teur des informations servant d'entres la cration d'un objet Transaction C U in I O 1 e(1) (les chiffres entre parenthses renvoient ceux de la figure 9.32). L'in de 1 1 de transactions commerciales demande ensuite Traitement par l'expditeur do crer un objet Transaction commerciale (2). Traitement par l'expditeur demanda a la classe Transaction commerciale correspondante de crer une instance (3) I M 1 1 des factures soumet ensuite la rfrence de la Transaction commen iaie par le destinataire (4). Traitement par le destinataire peut alors interrogei la Transacti on commerci a 1 e pour obtenir de plus amples informations (5). Tra i tement pa r le destinataire envoie ensuite l'objetTransacti on commerci al e l'IU de prsentation des transactions commerciales (6), qui le prsentera l'acteur Destinataire (7). ni i ,i 1 minii 1

Ce dernier exemple illustre le fait que chaque mcanisme peut tre gr de plusieurs manires et que chacune des approches a ses avantages et ses inconvnients. Si aucun mcanisme ne suffit lui seul prendre en compte toutes les situations, i l peut tre ncessaire d'en fournir plusieurs et d'employer le plus appropri chaque situation. L'architecte doit galement identifier les collaborations gnriques pouvant servir de patterns et tre utilises par plusieurs ralisations de cas d'utilisation du modle de conception.

i j

< ne i i n n e m e n t s d ' a c t i v i t s principaux

Conception CHAPITRE 9 Wm

tMIIUlTl

Ensuite, lorsque, par exemple, le cas d'utilisation Facturer i \ heieut ost ifoillsn, chacun des classificateurs abstraits prenant part la collaboration gni iquii poulfttrusous typ par des classificateurs concrets, comme l'illustre la figure 9.33. La ralisation du cas d'utilisation Facturer l'acheteur n'a donc qu' faire rfrence la collaboration gnrique, mais elle n'a pas besoin de la dupliquer ou de la spcialiser tant que les oprations (virtuelles) sur les classificateurs abstraits sont ralises par des mthodes sur les classificateurs concrets qui les sous-typent.

dfinir les exigences pesant sur les oprations des classes de conception et/ou des soussystmes et leurs interfaces ; formuler les exigences d'implmentation pour le cas d'utilisation en question.
9.5.2.1 Identification d e s c l a s s e s de c o n c e p t i o n p a r t i c i p a n t e s

Dans cette tape, nous allons identifier les classes de conception ncessaires la ralisation du cas d'utilisation (voir la figure 9.34). I l convient de procder de la faon suivante.

mi

i ii

Expditeur

IU de cration des transactions commerciales

Traitement par l'expditeur

/\

Transaction commerciale

Traitement par le destinataire

IU de prsentation des transactions commerciales

i\

Destinataire

tudiez les classes d'analyse prenant part la ralisation-analyse du cas d'utilisation correspondante. Identifiez ensuite les classes de conception que l'on peut l'aire rcmonii i il ces classes d'analyse, telles qu'elles ont t cres par l'ingnieur de composant! Ion dl la conception des classes ou par l'architecte lors de la conception architecturale

^HMI | I tM1 MH* l

I lu i n l l * l l o n

II

IU de facturation

Traitement des factures

Facture

Traitement des demandes de rglement

IU de prsentation des factures

tudiez les exigences particulires de la ralisation-analyse du cas d'utilisation correspondante et identifiez les classes de conception ralisant ces exigences pailu ulli n Ces classes sont dtectes soit par l'architecte au cours de la conception archilei luiale (c'est--dire sous forme de mcanismes gnriques), soit par l'ingnieur de composant! au cours de la conception des classes. I l en rsulte que la classe ncessaire doit tre identifie et qu'un ingnieur de composants . doit s'en voir attribuer la responsabilit.

lu

i II lit meurs abstraits prenant part une collaboration gnrique participant une ralisation spcifique de cas d'utilisation.

sont sous-typs

par des

classificateurs

I .a mme approche vaut pour la ralisation du cas d'utilisation Commander des marchandises
nu des services.

S'il manque toujours une classe de conception ncessaire la conception d'un cas d'utilisation spcifique, l'ingnieur de cas d'utilisation doit en faire part aux architectes ou aux ingnieurs de composants. La classe requise doit tre identifie et un ingnieur de composants doit s'en voir attribuer la responsabilit. Runissez les classes de conception prenant part une ralisation de cas d'utilisation dans un diagramme de classes associ cette ralisation, qui exposera les relations employes dans la ralisation. O

Noie/, que l'utihsation de gnralisations n'est pas le seul moyen d'employer une collaboration gnrique. Les patterns, qui sont des collaborations paramtres (des classes paramii ces, par exemple), sont galement gnriques et peuvent tre employs par l'association de classes concrtes aux paramtres.

Modle des X cas d'utilisation Exigences supplmentaires D Modle d'analyse

F3

7 Ingnieur de cas d'utilisation

Ralisation-conception de cas d'utilisation

1,11 plupart des mcanismes gnriques doivent tre identifis et conus au cours de la phase d'laboration. En procdant avec attention, l'architecte pourra souvent laborer un ensemble de mcanismes capables de rsoudre les problmes de conception les plus complexes et de rendre assez simple et directe la ralisation d'une majorit de cas d'utilisation au cours de la phase de construction. Les mcanismes lis des produits logiciels sont des candidats naturels la couche de middleware. D'autres mcanismes trouveront plutt leur place dans la couche gnrale aux applications.
82 Activit : concevoir un c a s d'utilisation

' Classe de conception [esquisse] ^Concevoir -y un cas d'utilisation

Sous-systme [esquisse]

La conception d'un cas d'utilisation poursuit les objectifs suivants : identifier les classes de conception et/ou les sous-systmes dont les instances sont ncessaires au flot d'vnements du cas d'utilisation ; distribuer le comportement du cas d'utilisation aux objets de conception en interaction et/ ou aux sous-systmes participants ;

Figure 9.34 Entres et rsultat de la conception des cas d'utilisation. La ralisationanalyse de cas d'utilisation correspondante du modle d'analyse est un point de dpart essentiel pour cette activit.

Modle de conception , D " " Modle de dploiement

Interface [esquisse]

i on e n c h a n e m e n t s d ' a c t i v i t s principaux
JUII II

Conception
CHAPITRE 9

Classes participant la ralisation du cas d'utilisation Moulin la lacliuu La figure 9.35 montre un diagramme de classes dcrivant lis; i t e m , inniiaiil p.ul ,i la i fiait sation du cas d'utilisation Rgler la facture et les associations qui lus iHimil lis, mu::; aux autres.

naturellement leur place dans la squence d'interactions de la ralisation du cas d'utilisation. Quelques remarques s'imposent au sujet de ces diagrammes de squence : le cas d'utilisation est invoqu par un message adress par une instance d'acteur un objet de conception ; chaque classe de conception identifie lors de l'tape prcdente doit avoir au moins un objet de conception participant un diagramme de squence ;

:ir.

twi prenant
iKiilmn i/w cas

Gestionnaire de commandes

Confirmation de commando

Hiuion Rgler
lit liiir nvcc

msoeiations. flamme, les > tCllvtS ont ftnturt plus

IU de demande de rglement

les messages circulent entre les lignes de vie d'objets (annexe A) pour raliser le cas d'utilisation. Un message peut avoir un nom temporaire, qui deviendra le nom d'une opration ds que celle-ci aura t identifie par l'ingnieur de composants i espi nisalih 11 la classe de l'objet rcepteur ;
Traitement des factures

Traitement des demandes de rglement

la squence du diagramme doit mobiliser l'attention car la ralisation-concept ion di i | d'utilisation constitue la principale entre de l'implmentation du cas d'ulilisnlion I I esl important de comprendre l'ordre chronologique des changes de messages entre oh|els utilisez des tiquettes et les flots d'vnements-conception pour complta lei diagrammes de squence ;

Echancier Facture

Demande de rglement

Certaines classes actives, telles que Traitement des demandes de rglement ou Traitement des factures, garantissent l'excution du systme interbancaire en faisant passer les transactions commerciales entre les diffrents nuds d'un metteur un rcepteur, tout comme les factures sont transmises du vendeur l'acheteur. 9.5.2.2 Description d e s interactions entre objets d e conception

le diagramme de squence doit prendre en compte toutes les relations du cas d'utilisation en cours de ralisation. Par exemple, si un cas d'utilisation A spcialise le cas d'utilisation B par une relation de gnralisation, le diagramme de squence ralisant le cas d'utilisation A aura peut-tre besoin de se rfrer la ralisation (c'est--dire au diagramme de squence) du cas d'utilisation B. Notez qu'il est fort probable que des rfrences de ce type existent dans les ralisations-analyse de cas d'utilisation correspondantes.
R I S H Diagramme de s q u e n c e pour la p r e m i r e partie du cas d'utilisation Rgler la facture La figure 9.36 montre le diagramme de squence de la premire partie du cas d'utilisation Rgler la facture. La description du flot d'vnements-conception compltant ce diagramme de squence pourra tre rdige de la faon suivante :

Une fois que l'on dispose d'une esquisse des classes de conception ncessaires la ralisation du cas d'utilisation, i l faut dcrire les interactions entre les objets qu'elles renferment. ( )n utilise cettefindes diagrammes de squence contenant les instances des acteurs participants, les objets de conception et leurs changes de messages. Si les cas d'utilisation prsentent des flots ou des sous-flots distincts, i l peut tre intressant de crer un diagramme de squence pour chacun d'eux. La ralisation de cas d'utilisation gagnera en clart et i l sera possible d'en extraire des diagrammes de squence reprsentant des interactions gnrales et rutilisables.

L'acheteur utilise le systme, via TappletW de demande de rglement ef l'application irai

tement des demandes de rglement, pour parcourir les factures reues. Irai l.eitient. de. demandes de rglement Utilise le Gestionnaire de commandes pour v r i f i e r h". I.n tures par rapport aux confirmations de commande correspondantes, .iv.int que

l'IU de demande de rgl ement ne prsente la liste des factures l'acheteur. L'acheteur slectionne une facture par le biais de /'IU de demande de rglcnirni et en M
nifie le rglement, puis l'IU de demande de rglement transmet cette requte im

Pour dbuter cette tape, tudiez la ralisation-analyse de cas d'utilisation correspondante. ( )n peut en dgager une esquisse de la squence de messages ncessaire entre les objets de conception, mme s'il est probable qu'un grand nombre d'objets de conception supplmentaires auront t ajouts. Dans certains cas, on pourra mme transformer un diagramme de collaboration de la ralisation-analyse de cas d'utilisation en une premire esquisse du diagramme de squence correspondant. < )n cre un diagramme de squence en se plaant au dbut du flot du cas d'utilisation, puis en le parcourant tape par tape et en dterminant les interactions entre objets de conception et instances d'acteur ncessaires sa ralisation. Dans la plupart des cas, les objets trouvent

Traitement des demandes de rglement, qui demande licbander dprogrammai rglement de la facture. /.'chanci er cre ensuite une demande de rglement l'applii .itum
Traitement des demandes de rglement demande alors l'application Iniilrnienl des

factures de faire passer la facture l'tat Pour rgl ement.

i os e n c h a n e m e n t s d ' a c t i v i t s principaux r\li!ll II

Conception CHAPITRE 9 Wm2

des demande

Il s'agit, pour commencer, d'identifier les sous-systmes ncessaires la ralisation du cas d'utilisation.

parcourirQ

parcourlrFactures()

obtenir Infos

vrilierFacture

tudiez les classes d'analyse prenant part la ralisation-analyse de cas d'utilisation correspondante. Identifiez les paquetages d'analyse contenant ces classes d'analyse, s'il j en a. Identifiez ensuite les sous-systmes de conception pouvant remonter ces paquetages d'analyse.
.

: G et t n at i s o ni d cm ad s Exploration!) e o mni

o t nr a l r Q be iF cue obtenlrlnfosConflrmatlonQ ' Q tnrnoFf ue Pe li f s a^ j Q

planifier le r g l e m e n t de ta facture | planrfierRglemerrtffacture)

tudiez les exigences particulires de la ralisation-analyse de cas d'utilisation correspondante. Identifiez les classes de conception ralisant ces exigences partit Lllli P l s'il y en a. Identifiez ensuite les sous-systmes de conception contenant t es i la .. Runissez les sous-systmes participant une ralisation de cas d'utilisation dans Il I gramme de classes associ cette ralisation, que vous emploierez ensuite pOUl (aifl apps ratre les dpendances entre ces sous-systmes et les interfaces employe: ilau i i ralisation.

: Dmne e ad le rglement
dfmirtatDeLaFacture(PourRgiement} ^ I dfinlrtat(PourRglemenl}

juin 9.36 Oframme de squence lin lure.

des objets de conception excutant

une partie de la ralisation

du cas d'utilisation

Rgler

Il est fort probable que l'enrichissement des diagrammes d'interaction mettra au jour de nouveaux chemins possibles pour le cas d'utilisation. Ces chemins peuvent tre dcrits dans les tiquettes des diagrammes ou faire l'objet de diagrammes d'interaction qui leur seront ddis. En ajoutant des informations, l'ingnieur de cas d'utilisation dcouvrira souvent de nouvelles exceptions auxquelles personne n'avait pens lors de la formulation des besoins ou de l'analyse. I l peut s'agir, par exemple, des types d'exception suivants : gestion des dlais d'inactivit lorsque des nuds ou des connexions s'interrompent ; entres errones introduites par des acteurs humains ou machines ; messages d'erreur gnrs par le middleware, le logiciel systme ou le matriel.
9.5.2.3 Identification d e s s o u s - s y s t m e s p a r t i c i p a n t s et d e l e u r s i n t e r f a c e s

Figure 9.37 Les lignes de vie du diagramme du centre (a) reprsentent les soussystmes et montrent les i messages reus et envoys I par les sous-systmes. Les autres diagrammes (betc) reprsentent les conceptions internes des sous-systmes et montrent la faon dont ces messages (dans a) sont reus et envoys par les lments internes des sous-systmes. Le diagramme (a) peut tre conu avant (b et c).

S o u s - s y s t m e s et interfaces prenant part la ralisation du cas d'utilisation R g l e r la facture

Jusqu' prsent, nous avons conu les cas d'utilisation comme des collaborations entre diffrentes classes et les objets qu'elles comportent. Mais i l arrive qu'il soit plus adapt de concevoir un cas d'utilisation sous forme de sous-systmes y prenant part et/ou d'interfaces de sous-systmes. Par exemple, i l peut tre ncessaire, dans le cadre d'un dveloppement descendant, d'exprimer les exigences pesant sur les sous-systmes et leurs interfaces avant que leur contenu n'en soit dtermin. Dans d'autres cas, i l faudra pouvoir remplacer facilement un sous-systme et sa conception interne spcifique par un autre sous-systme dot d'une conception interne diffrente. On pourra alors dcrire une ralisation-conception de cas d'utilisation plusieurs niveaux de la hirarchie des sous-systmes (voir la figure 9.37).

La figure 9.38 montre un diagramme de classes comprenant les sous-systmes, les interfaces et leurs dpendances impliqus dans la premire partie du cas d'utilisation Wq i n i,i facture.

I o e n c h a n e m e n t s d ' a c t i v i t s principaux
l'Ai II II II

Conception
CHAPITRE 9 Wkm

,11 III mime le

9.5.3

Rglement

Activit

: concevoir

une classe

i,n.,

les

ns, les rl leurs

sous-systme de conception IU de l'acheteur

sous-systme de conception Gestion des demandes de rglement

>(. )

rnctum

lin l:lllll li|lllllll~ GIMIIIDII ilim Imliiiini

L'objectif de la conception d'une classe est de crer une classe de conception remplissant son rle dans les ralisations de cas d'utilisation et compte tenu des exigences non fonction nelles qui s'y appliquent (voir la figure 9.39). Ce qui implique d'actualiser non seulement la classe de conception elle-mme, mais galement : ses oprations ; ses attributs ; les relations auxquelles elle prend part ; ses mthodes (qui en ralisent les oprations) ; ses tats imposs ;

\t

sous-systme de conception Gestion de l'chancier Gestion de l'chancier

9.5.2.4

Description des interactions entre s o u s - s y s t m e s

ses dpendances par rapport des mcanismes gnriques de conception ; les exigences s'appliquant son implmentation ; la ralisation correcte des interfaces qu'elle doit fournir. Figure 9.39
Entres d'une et rsultat Ralisation-conception de cas d'utilisation v de la conception

Une fois que l'on dispose d'une esquisse des sous-systmes requis par la ralisation du cas d'utilisation, i l faut dcrire la manire dont les objets des classes qu'ils contiennent dialoguent au niveau des sous-systmes. On utilise pour cela des diagrammes de squence contenant les instances des acteurs participants, les sous-systmes et leurs changes de messages. L'approche adopte pour cette dmarche est semblable celle dcrite dans la section 9.5.2.2, avec, toutefois, les diffrences suivantes : les lignes de vie (annexe A) dans les diagrammes de squence dnotent des sous-systmes et non des objets de conception ; chaque sous-systme identifi dans la section 9.5.2.3 doit tre cit par au moins une ligne de vie dans un diagramme de squence ; si un message est affect une opration d'interface, il peut tre utile de qualifier ce message l'aide de l'interface fournissant l'opration. Cette qualification est ncessaire lorsqu'un sous-systme fournit plusieurs interfaces et qu'il est impratif de dterminer l'interface utilise dans le message. 9.5.2.5 Formulation des exigences d ' i m p l m e n t a t i o n

classe.

Ingnieur de composants

Classe de conception [esquisse]

Concevoir 77 une classe

Classe de conception [complte]

Interface [esquisse]

Q "
Classe d'analyse [complte]

I )ans cette tape, nous allons procder la formulation de toutes les exigences pesant sur une ralisation de cas d'utilisation, comme les exigences non fonctionnelles identifies en conception, mais qui devront tre gres par l'implmentation.
Bfflfl Exigences d ' i m p l m e n t a t i o n sur le cas d'utilisation Rgler la facture Voici un exemple d'exigence d'implmentation impose par la ralisation du cas d'utilisation Rgler la facture : Un objetde la classe (active) Traitement des demandes de r g l ement doit pouvoir prendre en compte 10 clients acheteurs diffrents sans qu'aucun d'entre eux soit victime du moindre retard de traitement.

9.5.3.1 b a u c h e d e la classe de conception La premire tape consiste esquisser une ou plusieurs classes de conception parfit des entres fournies par les classes d'analyse et/ou par les interfaces. Lorsqu'on dispose d'une interface comme entre, le plus simple est en gnral d'attribuer une classe de coin cpiion pour fournir cette interface. Si l'on dispose, en revanche, d'une ou plusieurs classes d'analyse comme entre, la mellmili utilise dpendra du strotype de la classe d'analyse : la conception des classes frontires dpend des technologies d'interface spcifiques utilises. Par exemple, les classes frontires conues en Visual Basic impliqueront des classes de conception strotypes en tant que formulai re ainsi que d'autres classes de

I o n c h a n e m e n t s d ' a c t i v i t s principaux t<MIIII II

Conception Mff CHAPITRE y Mm

conception reprsentant les contrles , ventuellcnicnl des coniioles AciivcX, dans l'interface utilisateur. Notez galement que certains outils rcents de conception d'interfaces utilisateur permettent de crer les interfaces de faon visuelle, directement l'cran, ce qui rend implicite la cration des classes de conception correspondantes. Tout prototype d'interface utilisateur existant constitue une entre essentielle pour cette tape ;

les responsabilits de toutes les classes d'analyse auxquelles la classe de conception remonte. Une responsabilit implique souvent une ou plusieurs oprations. En outre, si des entres et des sorties sont dcrites pour ces responsabilits, elles peuvent tre utilises comme premire esquisse des paramtres formels et des valeurs de rsultat des oprations ; les exigences particulires de toutes les classes d'analyse auxquelles la classe de conception remonte. Rappelez-vous que ces exigences doivent souvent tre pi i .es m compte dans le modle de conception, ventuellement par l'intgration d'un nui anisrni gnrique de conception ou d'une technologie telle qu'une technologie de base dedonnes ; la ou les interfaces que fournit la classe de conception, qui doit galement en lu oprations ; les ralisations-conception de cas d'utilisation auxquelles participe la classe i von lu section 9.5.2). Les oprations d'une classe de conception doivent prendre en charge tous les rles que < me | la classe dans les diffrentes ralisations de cas d'utilisation. On trouvera ces rles en pai courant les ralisations de cas d'utilisation et en allant voir si la classe et ses objets figurent dans les diagrammes et les descriptions de flots d'vnements-conception des ralisations.
jljJIJJIJ O p r a t i o n s de la classe Facture La classe Facture participe plusieurs ralisations de cas d'utilisation, comme celles des cas

la conception des classes entits reprsentant des informations persistantes (ou de classes ayant d'autres exigences de persistance) impose souvent de recourir une technologie de hase de donnes spcifique. I l peut s'agir, par exemple, de crer des classes de conception correspondant aux tables d'un modle de donnes relationnel. L'utilisation d'outils de modlisation actuellement disponibles permet d'automatiser en partie ce processus, bien que cette opration puisse se rvler assez dlicate. Elle peut ncessiter l'adoption d'une Stratgie de persistance, susceptible de faire surgir un grand nombre de problmes de conception, en particulier si l'on cherche tablir une correspondance entre un modle de donnes relationnel et un modle de conception orient objet. Ces problmes pourront ncessiter leur tour l'intervention d'autres travailleurs (des concepteurs de base de donnes, par exemple), d'activits (la conception de bases de donnes) et de modles (les modles de donnes) dans le processus de dveloppement. Ces cas dpassent le cadre de cet ouvrage ; la conception des classes de contrle est dlicate. Comme ces classes encapsulent les squences, la coordination des autres objets et, parfois, la pure logique mtier, i l faut prendre en considration les aspects dcrits ci-dessous.

I.

d'utilisation Rgler la facture, Envoyer des relances et Facturer l'acheteur. Chacune de ces ralisations lit ou modifie l'tat des objets Facture. Le cas d'utilisation Facturer

- Les problmes de distribution. Si la squence doit tre distribue et gre par plusieurs nuds du rseau, il faudra peut-tre plusieurs classes de conception sur diffrents nuds pour raliser la classe de contrle. - Les problmes de performances. I l n'est pas toujours justifi qu'une classe de contrle soit ralise par plusieurs classes de conception indpendantes. Elle pourra tout simplement tre ralise par les mmes classes de conception que celles qui ralisent certaines classes frontires et/ou entits proches. - Les problmes transactionnels. Les classes de contrles encapsulent frquemment des transactions. Les classes de conception leur correspondant doivent alors intgrer la technologie de gestion transactionnelle utilise. Les classes de conception identifies dans cette tape doivent se voir attribuer des dpendances de traabilit par rapport aux classes d'analyse correspondantes. I l faut absolument garder l'esprit les origines des classes de conception pendant leur raffinement au cours des tapes suivantes.
9 . 5 . 3 . 2 Identification d e s o p r a t i o n s

l'acheteur cre et soumet des Factures. Le cas d'utilisation Rgler la facture envoie
les F et u res au rglement, et ainsi de suite, si bien que chaque ralisation de cas d'utilisation a fait un usage diffrent des objets Facture. En d'autres termes, la classe Facture et ses objets jouent diffrents rles dans ces ralisations de cas d'utilisation. Les ingnieurs de composants avaient d'abord pens implmenter ces changements d'tat en une seule opration, appele dfinirtat, dont un paramtre indiquerait l'action dsire et l'tat cible (par exemple, dfi ni rtat ( PourRgl ement)). Mais ils ont finalement prfr implmenter des oprations explicites pour chacune des transitions d'tat. Ils ont galement dcid d'appliquer cette approche non seulement la classe Facture, mais aussi la classe Transacti on commerci al e, dont la classe Facture est un sous-type (voii la ligun: !) '10) I a classe Transacti on commerci al e prend donc en charge les oprations suivantes (iloul cita

cune modifie l'tat de la Transacti on commerciale) : Crer, Soumettre, l'Ianl 11er ni '.<> i
der. Ces oprations ne sont toutefois que des oprations virtuelles qui illinissitiil une signature. Les classes sous-types de la classe Transacti on c m e n i a le doiviml chacune o m dfinir une mthode concrte ralisant ces oprations.

Dans cette tape, nous allons identifier les oprations qui doivent tre fournies par la classe de conception et les dcrire dans la syntaxe du langage de programmation. La visibilit de chaque opration doit tre spcifie : par exemple, public, protected, private en C++. Les principales entres de cette tape sont les suivantes :

e n c h a n e m e n t s d ' a c t i v i t s principaux mu II

Conception Wff
CHAPITRE 9 WL

. . Il

Ml

< Facture,
rti lion

Transaction commerciale

lf n lii/c cl / Ml MM i/ll V//l'

i luirge. m

+crerO +soumettre() +planifier() +solder{) 7

Le nombre de relations entre classes doit tre rduit le plus possible. I l ne s'agit pas de modliser sous forme d'associations ou d'agrgations avant tout les relations du monde rel, mais plutt celles appeles rpondre aux exigences des diverses ralisations de cas d'utilisation. Notez galement que, tant donn que les questions de performances doivent tre gres pendant la conception, i l peut tre ncessaire de modliser des chemins de recherche optimaux travers les associations ou les agrgations. Rappelez-vous les conseils qui suivent lors de l'identification et du raffinement des assot la tions et des agrgations.

Facture

Considrez les associations ou les agrgations impliquant la ou les classes d'analyse correspondantes. Il arrive que ces relations (du modle d'analyse) entranent la Itl CSSltl d'une ou de plusieurs relations correspondantes (dans le modle de conception) impliquant la classe de conception.

I e comportement des objets de certaines classes dpend troitement de l'tat de l'objet. Ces 1 lasses sont mieux dcrites par des diagrammes d'tats-transitions (voir la section 9.5.3.7).
9.5.3.3 Identification d e s attributs

I );ms cette tape, nous allons identifier les attributs ncessaires la classe de conception et les dcrire dans la syntaxe du langage de programmation. Un attribut spcifie une proprit d'une classe de conception et sa prsence est souvent implique et ncessite par les oprations de la classe (telles qu'elles ont t dcrites dans la section prcdente). Les conseils suivants vous seront utiles lors de l'identification des attributs : prenez en considration les attributs de toutes les classes d'analyse auxquelles la classe de conception remonte. I l arrive que ces attributs fassent natre le besoin de crer un ou plusieurs attributs dans la classe de conception ; les types d'attributs disponibles sont limits par le langage de programmation ; lorsque vous choisissez un type d'attribut, essayez d'en rutiliser un qui existe dj ; une mme instance d'attribut ne peut tre partage par plusieurs objets de conception. Si cela est absolument ncessaire, l'attribut doit tre dfini en tant que classe part ; si une classe de conception devient difficilement comprhensible en raison de ses attributs, certains d'entre eux peuvent tre placs dans une classe part ;

Affinez la multiplicit des associations, les noms de rles, les classes d'association, li rles ordonns, les rles qualifis et les associations n-aires en fond ion des possibilits du langage de programmation choisi. Par exemple, les noms de rles sont susceptibles de devenir des attributs de la classe de conception lors de la gnration du code ; leur loi misera donc restreinte. Autre exemple : une classe d'association pourra devenir une nouvelle classe entre les deux autres classes (les classes d'origine), ce qui ncessitera de nouvelles associations dotes de la multiplicit approprie entre la classe d' association et les deux autres classes. Affinez la navigabilit des associations. Examinez les diagrammes d'interaction dans lesquels figure l'association en question. La direction des changes de messages entre objets de conception implique une navigabilit correspondante des associations entre les classes les contenant.
9.5.3.5 Identification d e s g n r a l i s a t i o n s

Les gnralisations doivent utiliser la smantique dfinie par le langage de programmation. Si celui-ci ne prend pas en charge la gnralisation (ou l'hritage), on peut utiliser la place des associations et/ou des agrgations pour assurer la dlgation (par exemple, l'envoi d'un message demandant l'excution d'une tche, l'excution de cette tche et la rception d'un message de confirmation depuis des objets de la classe la plus spcifique vers des objets de la classe la plus gnrique.
fijfljjflfl G n r a l i s a t i o n s dans le m o d l e de conception Les objets Facture et Commande changent d'tat de la mme faon et prennent en cltaign dus oprations similaires. Tous deux sont des spcialisations d'un objet ir,i n s .u 1 imi ci aie plus gnral (voir la figure 9.41).

si les attributs d'une classe sont trop nombreux ou trop complexes, ils peuvent tre prsents dans un diagramme de classes part ne montrant que le compartiment des attributs.
9.5.3.4 Identification d e s a s s o c i a t i o n s et d e s a g r g a t i o n s

mei

Les objets de conception dialoguent ensemble par le biais de diagrammes de squence. Ces interactions ncessitent souvent des associations entre les classes qu'elles relient. L'ingnieur de composants doit donc tudier les changes de messages dans les diagrammes de squence et dterminer les associations requises. On pourrait utiliser des instances d'association pour dtenir les rfrences d'autres objets et grouper les objets en agrgations pour l'change de messages.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux / -ARTIE II

Conception CHAPITRE 9

Figure 9.42 Diagramme d'tats-transitions pour la classe Facture.

Cre

j +soumettreO

^En attente j

(jure 9.41 mxsaction vmmcrciale U'iu'nilise Facture i i nimande. ^Irz que ces u'm'inlisations tintent galement 'ii \ modle imilvsi' entre les IIWI'.I d'analyse mrspondantes. 9.5.3.6 Description d e s m t h o d e s

+schedule() +planifier()

[dpassement : au-del de la dernire limite de rglement] Pour rglement j En retard J

Au cours de la conception, on peut utiliser des mthodes pour spcifier la faon dont les oprations seront ralises. Ces mthodes peuvent, par exemple, dfinir un algorithme et sont exprimes soit en langue naturelle, soit en pseudo-code, selon ce qui convient le mieux.

+solder{)

+solder() Solde

Nanmoins, la plupart des mthodes temporelles ne sont pas cres pendant la conception, mais au cours de l'implmentation, directement dans le langage de programmation. Tout simplement parce que c'est le mme ingnieur de composants qui doit concevoir et implmenter la classe, ce qui vite d'avoir transmettre des spcifications telles que les spcifications de mthode.

tat est Solde.

Une facture est cre lorsqu'un vendeur veut qu'un acheteur rgle une commande. La facture est ensuite soumise l'acheteur et son tat devient En attente. Lorsque l'acheteur dcide de payer, l'tat de la facture passe Pour r g l ement. Puis, si l'acheteur ne paie pas temps, l'tat de la facture passe devient En retard. Enfin, une fois la facture rgle, son

Notez que si l'outil de conception prend en charge une gnration de code fluide des mthodes sur les classes de conception, les mthodes peuvent tre spcifies directement dans l'outil de conception l'aide du langage de programmation. Mais ceci est ensuite considr comme une activit d'implmentation et n'est donc pas trait par la conception. Pour de plus amples dtails, reportez-vous au chapitre 10, plus particulirement la section 10.5.4, qui aborde l'activit d'implmentation des classes.
9.5.3.7 Description d e s t a t s

9.5.3.8 Gestion d e s exigences p a r t i c u l i r e s

Certains objets de conception sont pilots par l'tat dans lequel ils se trouvent : c'est ce dernier qui dtermine leur comportement lors de la rception d'un message. Dans de tels cas, i l est intressant d'employer un diagramme d'tats-transitions pour dcrire les diffrentes transitions de l'tat d'un objet de conception. Ce diagramme constitue ensuite une entre prcieuse pour l'implmentation de la classe de conception correspondante.
WUIJJU Diagramme d ' t a t s - t r a n s i t i o n s pour la classe Facture Les objets Facture changent d'tat mesure qu'ils sont crs, soumis, planifis et solds. Comme pourtous les objetsTransacti on commerci aie, ces changements d'tat suivent une squence stricte. Par exemple, une facture ne peut tre planifie avant d'avoir t soumise. Cette squence de changements d'tat peut tre dfinie par un diagramme d'tats-transitions, comme le montre la figure 9.42.

Les exigences qui n'ont pas t prises en compte dans les tapes prcdentes vont maintenant tre gres. cettefin,tudiez les exigences imposes par les ralisations de cas d'utilisation auxquelles la classe prend part et qui sont susceptibles de formuler des exigences (non fonctionnelles) pour la classe de conception. I l faut galement tudier les exigences particulires pesant sur toute classe d'analyse laquelle remonte la classe de conception. Ces exigences particulires devront souvent tre gres par la classe de conception.
lypfflH Emploi d'un m c a n i s m e de conception pour grer une exigence particulier!] Les objets Facture doivent tre accessibles partir de plusieurs nuds, a la lois depuis le Serveur acheteur et depuis le Serveur vendeur. Facture n'est pas une classe active, mais elle doit tre conue pour un systme distribu. Dans notre exemple, nous avons implment cette distribution des objets en faisant de la classe Facture une sous-classe de la classe abstraite java nomme java. rmi. server .Uni castRemoteObject, qui prend en charge RMI (Remote Method Invocation) (voir la figure 9.43). Notez que ce mcanisme de conception est identifi et dcrit par l'architecte dans l'activit de conception architecturale.

I e n c h a n e m e n t s d ' a c t i v i t s principaux

Conception CHAPITRE 9

II

UnicasIRomotoObJort

O O

fun u A3 i-i, i\ ki classe ilnivenl tre i "est pourquoi MI les sous-types de |/lMi iitlHrmoleObject.

Figure 9.44 Entres et rsultat de la conception d'un sous-systme.

Description de * l'architecture [vue du modle de conception]

Ingnieur de composants Sous-systmo [complet] Concevoir sous-systme Inlnrlm < [complotl

Pour la gestion de ces exigences, servez-vous si possible de tous les mcanismes gnriques de conception votre disposition, tels qu'ils ont t identifis par l'architecte.

Sous-systme [esquisse]

( 'cpcndant, i l peut tre plus adapt de retarder la gestion de certaines exigences jusqu' l'implmentation. Ces exigences doivent alors tre signales en tant qu'exigences d'implniciilation pour la classe de conception.
Exigence d ' i m p l m e n t a t i o n pour une classe active Voici un exemple d'exigence d'implmentation pour la classe Traitement des demandes de 9.5.4.2

Interface [esquisse]

O '

rglement.
Un objet de la classe doit pouvoir prendre en compte 10 clients acheteurs diffrents sans qu'aucun d'eux soit victime du moindre retard de traitement.

A c t u a l i s a t i o n d e s i n t e r f a c e s f o u r n i e s p a r le s o u s - s y s t m e

9 hA

Activit

: concevoir

un

sous-systme

I a conception d'un sous-systme poursuit les objectifs suivants (voir la figure 9.44) : s'assurer que le sous-systme est aussi indpendant que possible des autres sous-systmes cl/ou de leurs interfaces ; s'assurer que le sous-systme fournit les interfaces voulues ; s'assurer que le sous-systme remplit sa mission, c'est--dire qu'il offre une ralisation salisfaisante des oprations dfinies par les interfaces qu'il fournit.
9.5.4.1 Actualisation d e s d p e n d a n c e s entre s o u s - s y s t m e s

Les oprations dfinies par les interfaces que fournit un sous-systme doivent prendre en charge tous les rles que le sous-systme assume dans les diffrentes ralisations de cas d'utilisation. Mme si elles ont t esquisses par les architectes, i l est possible que ces interfaces rclament quelque raffinement de la part de l'ingnieur de composants, aufilde l'volution du modle de conception et de la conception des cas d'utilisation. N'oubliez pas qu'un sous-systme et ses interfaces peuvent tre employs dans diverses ralisations de cas d'utilisation par les ingnieurs de cas d'utilisation, ce qui impose de nouvelles exigences sur les interfaces (voir la section 9.5.2.4). L'approche adopte pour l'actualisation des interfaces et de leurs oprations est semblable celle utilise pour l'actualisation des classes de conception et de leurs oprations, dcrite dans la section 9.5.3.2.
9.5.4.3 A c t u a l i s a t i o n d u c o n t e n u d'un s o u s - s y s t m e

II est ncessaire de dfinir et d'actualiser les dpendances d'un sous-systme l'gard d'autres sous-systmes dont les lments possdent des associations originaires d'lments de ce sous-systme. Nanmoins, si ces autres sous-systmes fournissent des interfaces, les dpendances (relation d'utilisation) doivent plutt tre dclares par rapport ces interfaces. Il vaut mieux dpendre d'une interface que d'un sous-systme, car un sous-systme peut trs bien tre remplac par un autre dot d'une conception interne diffrente, alors qu'il ne sera pas forcment ncessaire de changer d'interface. Faites en sorte de rduire le plus possible les dpendances par rapport aux autres sous-syslemcs et/ou interfaces. Vous pouvez toujours envisager de dplacer les classes qui seraient trop dpendantes d'autres sous-systmes de ces sous-systmes.

On peut considrer qu'un sous-systme remplit sa fonction lorsqu'il offre une ralisation satisfaisante des oprations dfinies par les interfaces qu'il fournit. Mme s'il a t esquiss par les architectes, le contenu du sous-systme peut ncessiter quelque amlioration de la part de l'ingnieur de composants, mesure qu'volue le modle de conception. Certaines questions d'ordre gnral doivent tre prises en considration : pour chaque interface fournie par le sous-systme, des classes de conception ou d'autTM sous-systmes au sein de ce sous-systme doivent galement fournir l'intrim e en question ; pour clarifier la faon dont la conception interne d'un sous-systme ralise ses intrim. ou ses cas d'utilisation, on peut crer des collaborations entre lments contenus dans ce sous-systme. Ceci permet de justifier les lments contenus dans le sous-systme.

i iniinements d ' a c t i v i t s principaux m II

Conception
CHAPITRE 9

Classe de conception fournissant une interface dans un sous s y s t m e Le sous-systme Gestion des factures par l'acheteur fournit l'intiiilace i .n i m > I in gnieur de composants responsable de ce sous-systme dcide de laisser la classe i ai t u n raliser cette interface (voir la figure 9.45). On aurait aussi bien pu faire raliser l'interface pai une quelconque autre classe de conception, puis utiliser la classe Facture.

La vue architecturale du modle de conception, avec ses lments significatifs sur le plan architectural. Comme nous l'avons indiqu plus haut, les lments du modle d'analyse significatifs sur le plan architectural servent de spcification lors de l'bauche des lments du modle de conception significatifs sur le plan architectural. La conception se traduit galement par le modle de dploiement, qui dcrit toutes les conli gurations rseau sur lesquelles le systme doit tre distribu. Le modle de conception com prend les lments suivants : les nuds, leurs caractristiques et les connexions ; une premire correspondance des classes actives sur les nuds ; la vue architecturale du modle de dploiement, avec ses lments signilicalils soi |< p l u architectural. Comme nous le montrerons dans les chapitres suivants, les modles de conception et de dploiement sont considrs comme les principales entres des activits ultrieures d'impie mentation et de tests. Les sous-systmes de conception et de service seront implments par des SOUS-systmes d'implmentation contenant les vritables composants : fichiers de code source, scripts, binaires, excutables et autres lments du mme type. Ces sous-systmes d'implmentation prsenteront une relation de traabilit un--un (isomorphe) avec les sous-systmes de conception. Les classes de conception seront implmentes par des composants fichiers contenant le code source. I l n'est pas rare que plusieurs classes de conception soient implmentes par un seul et unique composant fichier ; cela dpend du langage de programmation choisi. Par ailleurs, les classes de conception actives renvoyant des processus indpendants serviront d'entre lors de l'identification des composants excutables. Les ralisations-conception de cas d'utilisation seront utilises lors de la planification et de l'excution par tapes limites et grables de l'effort gnral d'implmentation, qui dbouchera sur des constructions . Chaque construction implmentera principalement un ensemble complet ou partiel de ralisations de cas d'utilisation. Le modle de dploiement et les configurations rseau serviront lors de la distribution du systme par le dploiement de composants excutables sur des nuds.

R s u m d e la c o n c e p t i o n
Le pi mcipal rsultat de la conception est le modle de conception qui tente de prserver une .uIK line du systme impose par le modle d'analyse et sert de plan d'laboration et de Mr.miction l'implmentation. Le modle de conception se compose des lments Indiqus ci-dessous. I es sous-systmes de conception et de service et leurs dpendances, interfaces et contenu. I es sous-systmes de conception des deux couches suprieures (c'est--dire de la couche ipcifique l'application et de ta couche gnrale aux applications) sont esquisss partir des paquetages d'analyse (section 9.5.1.2, paragraphe Identification des sous-systmes d'application ). Certaines des dpendances entre sous-systmes de conception sont issues des dpendances entre les paquetages d'analyse correspondants (section 9.5.1.2, paragraphe Dfinition des dpendances entre sous-systmes ), tandis qu'une partie des interfaces drive des classes d'analyse (section 9.5.1.2, paragraphe Identification des interfaces de sous-systme ).

9.7

Rfrences
I V A R J A C O B S O N , M A G N U S C H R I S T E R S O N , P A T R I K JONSSON et Ci I I N N A l < "i VI l 11A A N1 , < <

I es classes de conception, y compris les classes actives, et leurs oprations, attributs, i dations et exigences d'implmentation. Certaines classes de conception significatives sur le plan architectural sont dfinies partir des classes d'analyse pertinentes sur le plan architectural (section 9.5.1.3, paragraphe Identification des classes de conception partir des classes d'analyse ), de mme que certaines classes actives sont issues de classes d'analyse (section 9.5.1.3, paragraphe Identification des classes actives ). D'une manire gnrale, les classes d'analyse servent de spcification lors de l'bauche des classes de conception (section 9.5.3.1). Les ralisations-conception de cas d'utilisation, qui dcrivent la faon dont les cas d'utilisation sont conus en termes de collaborations au sein du modle de conception. D'une manire gnrale, les ralisations-analyse de cas d'utilisation servent de spcification lors de l'bauche des ralisations-conception de cas d'utilisation (section 9.5.2).

Object-Oriented Software Engineering: A Use-Case Driven Approach, Reading. M A Addison-Wesley, 1992 (quatrime dition rvise, 1993). J. R U M B A U G H , M . B L A H A , W. P R E M E R L A N I , F. E D D Y et W. L O R E N S K N , Objed Oriented Modeling and Design, Englewood Cliffs, NJ, Prentice Hall, 1991 OMG Unified Modeling Language Spcification, Object Management Group, Framingham, MA, 1998. Internet : www.omg.org.

1 0
Implmentation

10.1 I n t r o d u c t i o n
L'implmentation part des rsultats de la conception pour implmenter le systme sous forme de composants, c'est--dire de code source, de scripts, de binaires, d'excutables et d'autres lments du mme type. Heureusement, l'armature de l'architecture du systme a t cre pendant la conception. Le principal objectif de l'implmentation est donc d'toffer l'architecture et le systme dans son ensemble. Pour tre plus prcis, les objectifs de l'implmentation sont les suivants : planifier les intgrations du systme ncessaires chaque itration. Nous adoptons une dmarche incrmentale ; l'implmentation du systme revient donc une succession d'tapes courtes et parfaitement grables ; distribuer le systme en faisant correspondre les composants excutables des nuds du modle de dploiement. Cette rpartition s'appuie avant tout sur les classes actives identifies au cours de la conception ; implmenter les classes et les sous-systmes de conception identifis au cours de la conception. Les classes de conception doivent, en particulier, tre implmentes sous forme de composants fichiers contenant du code source ; tester les composants unit par unit, puis les intgrer en les compilant et en les reliant les uns aux autres pour former un ou plusieurs excutables avant de leur faire suhii les lests d'intgration et les tests systme. Ce chapitre et les suivants prsentent la ralisation de rimplcmcnlalion. ainsi qui les lin vailleurs et les artefacts qu'elle implique (voir la figure 10.1). Notre approche de ecl eiuiiiu nement d'activits est trs proche de celle adopte pour l'enchanement il'acliviii i conception.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Implmentation
CHAPITRE 10 Mm

figure 10.1
liimiilleurs uiir/uits tlims ttlllon. et impliqus
inii-(|i.iif,i, 6grnt( /lien syrill.NHi

10.3 A r t e f a c t s
I

l"implmen-

10.3.1 Artefact : modle

d'implmentation

ri):;|>oii!..ihli' < nisnl) l

I
Modle Description de Modle de d'implmentation l'architecture dploiement Plan de construction des intgrations Composant Sous-nystmo d'implmentation Interface

Le modle d'implmentation dcrit la faon dont les lments du modle de conception, tels que les classes de conception, sont implments par des composants de type fichiers de code source, excutables, etc. I l prsente galement l'agencement des composants en fond ion des mcanismes de structuration et de modularisation disponibles dans l'environnenn m d'implmentation et le ou les langages d'implmentation utiliss, ainsi que les dpeiuliiiu es qui lient les composants les uns aux autres.

10.2 R l e d e l ' i m p l m e n t a t i o n d a n s le c y c l e de vie d u logiciel

Le modle d'implmentation dfinit une hirarchie, comme l'indique la ligure I0.3 Il est reprsent par un systme d'implmentation montrant le sous-syslinc le niveau siqu rieur du modle. L'utilisation d'autres sous-systmes offre, par consquent, un moyen >ti dcouper le modle en portions plus grables. Les artefacts du modle d'implmentation font l'objet de descriptions dtailles dan li sections qui suivent.
Figure 10.3
Le modle hirarchie Modle d'implmentation Systme d'implmentation d'implmentation

Si l'implmentation est au cur des proccupations des itrations de construction, elle intervient galement lors de l'laboration - pour la cration de l'architecture excutable de rfrence - et au cours de la transition -pour la prise en compte d'anomalies apparues tardivement, par exemple celles qui sont dtectes la livraison de la version bta du systme (indique dans la figure 10.2 par un pic dans la colonne de transition).
ligure 10.2
l'oint de i invergence de convergence ae / implmentation.

Phases Enchanements d'activits

i n c i

est une Transition de dots

Cration

, laboration ,

Construction

sous-systmes de

d'implmentation composants et d'interfaces.

Besoins Analyse Conception | Implmentation

Composant Tests Itrations prliminaires Iter. #1 iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 iter. #m iter. #m+1

Interface

70.3.2 Artefact :

composant

Itrations

Un composant est l' empaquetage d'lments de modle, tels que les classes de COtl ception du modle de conception [5]. Parmi les strotypes standard, citons : e x c u t a b l e , qui dsigne un programme pouvant s'excuter sur un nud ; f i c h i e r , qui dsigne un fichier contenant du code source ou des donnes ; bi bl i o t h q u e , qui dsigne une bibliothque statique ou dynamique ; t a b l e , qui dsigne une table de base de donnes ; document , qui dsigne un document.

Le modle d'implmentation illustrant l'implmentation relle du systme sous forme de composants et de sous-systmes d'implmentation, il est naturel de le conserver tout au long du cycle de vie du logiciel.

mm L e s e n c h a n e m e n t s d ' a c t i v i t s principaux miM PARTIE II

Implmentation CHAPITRE 10

Il est possible, lors de la cration de composants dani Ull Mvim UMUl d'implmentation donn, de modifier ces strotypes afin qu'ils refltent 111 qui "Ipfl n vritablement les composants. Les composants prsentent les caracli isin|in suivante-, ils entretiennent des relations de traabilit avec les lment! de modle qu'ils implmentent ;

il peut exister des dpendances de compilation entre composants, indiquant quels sont les composants ncessaires pour compiler un composant spcifique.
jflfHfl Dpendances de compilation entre composants

Dans le systme interbancaire, le composant (fichier) VirementsEntreComptes.java se compile en un composant (excutable) Vi rementsEntreComptes.cl ass (voir la figure 10.6).
1

i l n'est pas rare qu'un composant implmente plusieurs lments tels que des classes de conception ; nanmoins, le mode de cration prcis le celte traabilit dpend de la structuration et de la modularisation prvues pour les fichiers de code source, selon le langage de programmation utilis ;

ZD fichier T"^ VirementsEntreComptes.java 1\ compilation

BUfl

Traabilit d'un composant avec une classe de conception Dans le systme interbancaire, la classe de conception Vi rements entre comptes est implmente par le composant de code source Vi rementsEntrecomptes. java, car une convention et la pratique courante de Java imposent de crer un fichier de code source .java pour chaque classe, mme si cette rgle n'est pas toujours respecte. Quoi qu'il en soit, cette implmentation est modlise par une dpendance de traabilit entre les modles de conception et d'implmentation (voir la figure 10.4). M o d l e de conception Modle d'implmentation

Figure 10.6 Dpendances de compilation entre deux composants.

Z3 excutable "H VirementsEntreComptes.class

' Igure 10.4 lijiendances de . ruabilit entre < omposants et fiasses de onception.

10.3.2.1

Stubs

fichier VirementsEntreComptes.java

Virements entre comptes

Un stub (ou bouchon) est un composant dont l'implmentation, minimale ou ddie un objectif prcis, peut tre utilise pour dvelopper ou tester un autre composant dpendant du stub. Vous en trouverez une dfinition semblable dans [1]. On peut utiliser les stubs pour rduire le plus possible le nombre de nouveaux composants ncessaires chaque nouvelle version (intermdiaire) du systme, ce qui limite les problmes d'intgration et simplifie les tests d'intgration (voir la section 10.5.2, Activit : intgrer le systme ).
Figure 10.7 Contenu et associations cls des sous-systmes. Sous-systme d'implmentation

les composants fournissent les mmes interfaces que les lments de modle qu'ils implmentent ;

jflgff

Interfaces en conception et en implmentation Dans le systme interbancaire, la classe de conception Vi rements entre comptes fournit une interface Vi rements. Cette interface est galement fournie par le composant Vi rement sEntreComptes.java, qui implmente la classe Virements entre comptes (voir la figure 10.5).

raliser

Modle de conception

Modle d'implmentation
I fichier VirementsEntreComptes.java Composant

Figure 10.5 / ts composants i.mrnissent les ncmes interfaces que les classes i[lt 'ils implmentent.

Virements entre comptes

<-

trace

Virements

~5

Virements

1. Pour tre plus prcis, le composant est en fait interprtable par la machine virtuelle Java.

n e n c h a n e m e n t s d ' a c t i v i t s principaux
l'WIIII II

Implmentation
CHAPITRE 10 Wtm

0,3.3 Artefact : sous-systme

d'implmentation

I .es sous-systmes d'implmentation offrent un moyen de lparlii les nileini i il odle d'implmentation en portions plus grables (voir la ligure 10.7). Un sous syslmi peul clic Cl institu de composants, d'interfaces et d'autres sous-systmes (de faon rcursive). Il peut, en outre, raliser - et par consquent fournir - des interfaces reprsentant les fonctions exportes sous forme d'oprations. II est important de comprendre qu'un sous-systme d'implmentation se manifeste par un mcanisme d'empaquetage dans l'environnement d'implmentation, par exemple : un paquetage en Java [2] ; un projet en Visual Basic [3] ; un rpertoire de fichiers dans un projet C++ ; un sous-systme dans un environnement de dveloppement intgr tel que Rational Apex ; un paquetage de la vue de composants dans un outil de modlisation visuelle tel que Rational Rose. I ,a notion de sous-systme d'implmentation bnficiera d'une smantique lgrement ilInie lorsqu'elle s'exprimera dans un environnement d'implmentation. Toutefois, nous aborderons dans ce chapitre l'implmentation sur un plan gnrique applicable la plupart des environnements d'implmentation. I ,cs sous-systmes d'implmentation sont trs fortement lis aux sous-systmes de conI eplion du modle de conception (voir le chapitre 9, section 9.5.4, Activit : concevoir un sous-systme ). En fait, un sous-systme d'implmentation doit avoir une traabilit un-iin (isomorphe) avec le sous-systme de conception correspondant. Rappelez-vous qu'un sous-systme de conception dfinit dj : les dpendances par rapport d'autres sous-systmes et/ou interfaces d'autres soussystmes ; les interfaces que doit fournir le sous-systme ; les classes de conception ou, de faon rcursive, les autres sous-systmes de conception au sein du sous-systme qui doivent fournir les interfaces que propose le sous-systme lui-mme. ( 'es aspects sont importants pour le sous-systme d'implmentation correspondant, parce qu'il doit : dfinir des dpendances analogues envers les autres sous-systmes d'implmentation et/ ou interfaces (correspondants) ; fournir les mmes interfaces ; dfinir les composants ou, de faon rcursive, les autres sous-systmes d'implmentation contenus dans le sous-systme qui doivent fournir les interfaces que propose le soussystme lui-mme. La figure 10.8 clarifie la relation entre les modles de conception et d'implmentation.
Figure 10.8

Les changements intervenant dans la manire dont les sous-systmes fournissent et utilisent les interfaces, ou affectant les interfaces elles-mmes, sont dcrits dans l'enchanement d'activits de conception (veuillez vous reporter au chapitre 9, section 9.5.4, Activit : concevoir un sous-systme ). Ils ne sont donc pas traits dans l'enchanement d'activits d'implmentation, bien qu'ils influent galement sur le modle d'implmentation. Notez que la correspondance que nous venons de dcrire vaut galement pour les soie, i y i tmes de service du modle de conception. Les sous-systmes d'implmentation remontant ces sous-systmes de service rsideront par consquent un niveau infrieur dans la lue rarchie du modle d'implmentation et rempliront le mme rle que les sous systmes ili service en question : ils permettront de structurer le systme en fonction des sen u iv qui celui-ci propose. C'est pourquoi les sous-systmes d'implmentation qui remoiileiii n il< sous-systmes de service du modle de conception sont susceptibles d'cncapsulei des i uni posants excutables fournissant les divers services du systme.
Modle de conception Modle d'implmentation

Sous-systme d'implmentation du modle d'implmentation ayant une traabilit un--un avec un soussystme de conception du modle de conception. Les sous-systmes des diffrents modles fournissent la mme interface (a) et dpendent de la mme interface (fi). Les composants du sous-systme d'implmentation implmentent les classes du soussystme de conception.

10.3.4 Artefact : interface

Les interfaces sont dcrites en dtail dans le chapitre 9. On peut employer les mmes mlei faces dans le modle d'implmentation pour spcifier les oprations implmentes put les composants et les sous-systmes d'implmentation. Par ailleurs, comme nous l'avons lait remarquer plus haut, les composants et les sous-systmes d'implmentation peuvent avuii des dpendances d'utilisation vis--vis des interfaces (figure 10.9).

i.... ,.,.< h.iinements d ' a c t i v i t s principaux

Implmentation
CHAPITRE 10

11 | imposant ralisant (et, par consquent, fournissant) une Interfai r rjoil lm| ton ,,, innent toutes les oprations dfinies par cette interface. De mme qu'un sous systme d'implmentation fournissant une interface doit galement contenir les compoiantl ou, de manire rcursive, les autres sous-systmes qui proposent cette interlacc.

10.3.5 Artefact : description d'implmentation)

de l'architecture (vue du

modle

La description de l'architecture contient une vue architecturale du modle d'implmentation (annexe C), qui en dcrit les artefacts significatifs sur le plan architectural (voir la figure 10.12). Les artefacts numrs ci-dessous sont gnralement considrs comme importants sui le plan architectural.

wii

els

< raliser

I/III e

Sous-systme d'implmentation

Interface

Composant

La dcomposition du modle d'implmentation en sous-systmes, avec leurs inlcrlai es i i leurs dpendances mutuelles. D'une manire gnrale, cette dcomposition est fondamentale pour l'architecture. Mais, comme les sous-systmes d'implcntentation mit une traabilit un--un avec les sous-systmes de conception, qui son! susceptible! de figurer dans la vue architecturale du modle de conception, i l est gnraleincnl lili di dcrire les sous-systmes d'implmentation dans la vue architecturale du motleli d'implmentation. Les composants cls, comme ceux qui remontent des classes de conception significatives sur le plan architectural, les composants excutables cl les composant! gnraux, centraux, ceux qui implmentent des mcanismes gnriques de conception dont dpendent d'autres composants.

S o u s - s y s t m e d'implmentation fournissant une interface Le systme interbancaire dispose d'un sous-systme d'implmentation nomm Gesti onDesComptes (un paquetage Java), qui fournit l'interface Virements (voir la figure 10.10).

in lu
i . v \ifme nlle\( l'Interface 'omptes GestionDesComptes

a
Virements

Sous-systme d'implmentation.

La section 10.5.1.1, Identification des composants significatifs sur le plan architectural , propose des exemples de ce qui peut figurer dans la vue architecturale du modle d'implmentation.
Figure 10.12
Vue du architecturale modle Description de l'architecture vue architecturale

d'implmentation.

m
m r

II If Virements,

package GestionDesComptes // interfaces fournies : public Interface Virements { public Compte creer(Client titulaire, Solde argent, id_compte NumeroCompte); public vold Depot (Montant argent, String raison) public vold Retrait (Montant argent, String raison); }

' fini I r sousnllrsl omptes.

Modle d'implmentation

10.3.6 Artefact : plan de construction

des

intgrations

Il est trs important de construire le logiciel de faon incrmentale, par le. tapes l'ai les a grer dont chacune ne laisse apparatre que des problmes limits d'intgration ou le tests Le rsultat de chaque tape est appel construction . Il s'agit d'une version exl Utabll du systme, en gnral d'une partie spcifique du systme. Chaque construction est I II lUlti soumise des tests d'intgration (comme le dcrit le chapitre 11) avant la mise au poinl 'le la construction suivante. Afin d'anticiper toute construction dfaillante (par exemple, une traction ne russissant pas les tests d'intgration), chaque construction est soumise ; .on

Lea e n c h a n e m e n t s d ' a c t i v i t s principaux

I'AIIIII II

Implmentation
CHAPITRE 10 mm

irle de version afin qu'il soit possible de revenir une construction prcdente Cette approche incrmentale prsente divers avantages : on peut crer trs tt une version excutable du systme, au lieu d'attendre une vcu m plus complte. Les tests d'intgration dbutent alors trs vile, cl la version excutable permet de faire une dmonstration des caractristiques du systme aux membres de l'quipe interne comme aux intervenants extrieurs ; les anomalies sont plus faciles localiser pendant les tests d'intgration, car seule une partie du systme, petite et grable, vient enrichir une construction existante. Il est mme fort probable (mais ce n'est pas toujours le cas) que les anomalies soient prcisment lies cette partie ajoute ou modifie ; les tests d'intgration ont tendance tre plus exhaustifs que ceux pratiqus l'chelle du systme global, car ils portent sur des parties plus limites et mieux matrises. L'intgration incrmentale (annexe C) est l'intgration systme ce que le dveloppement itratif contrl est au dveloppement logiciel en gnral : l'un et l'autre s'appuient sur des incrments de fonctions relativement limits et grables.

10.4 T r a v a i l l e u r s 10.4.1 Travailleur : architecte

Au cours de la phase d'implmentation, l'architecte est responsable de l'intgrit du modle d'implmentation, dont il doit s'assurer de l'exactitude, de la cohrence et de la lisibilit yU, baies. Dans le cas de l'analyse et de la conception de vastes systmes complexes, il est pos sible qu'un autre travailleur prenne en charge les responsabilits du sous-systme de niveau suprieur (c'est--dire le systme d'implmentation) du modle d'implmentation Le modle est jug correct lorsqu'il implmente les fonctions dcrites par le modle .I, . on ception, ainsi que toute exigence supplmentaire (pertinente), et uniqucnicni i ei fol I L'architecte est galement charg de l'architecture du modle d'implcincntalion. < v i ,, h de l'existence des parties de ce modle significatives sur le plan architectural, telles qn i II figurent dans la vue architecturale du modle. Rappelez-vous que celle vue lait paiiie de la description de l'architecture du systme (voir la figure 10.13).
Figure 10.13
Responsabilits de l'architecte au cours de l'implmentation.

Si l'on se replace dans le contexte d'un dveloppement itratif, chaque itration donnera lieu au moins une construction. Mais les fonctions destines tre implmentes par une itration spcifique sont souvent trop complexes pour tre intgres en une seule construction. l'inverse, i l est possible que l'on doive crer une squence de constructions au sein mme de l'itration, chacune reprsentant un pas en avant et une tape grable par l'ajout d'un modeste incrment au systme. Chaque itration ajoutera au systme un incrment plus important, ventuellement form de l'accumulation de plusieurs constructions (voir le chapitre 5). Un plan de construction de l'intgration dcrit la squence de constructions requise dans une itration. Plus prcisment, ce type de plan dcrit, pour chaque construction, les lments suivants : les fonctions devant tre implmentes par la construction. I l s'agit d'une liste de cas d'utilisation et/ou de scnarios (complets ou partiels), comme nous l'avons indiqu dans les chapitres prcdents. Cette liste peut mentionner des exigences supplmentaires ; les parties du modle d'implmentation affectes par la construction. I l s'agit d'une liste des sous-systmes et composants ncessaires l'implmentation des fonctions que doit livrer la construction. La section 10.5.2, Activit : intgrer le systme , dcrit une approche systme pour la cration d'un plan de construction des intgrations.

Modle d'implmentation

Modle de dploiement

vue architecturale

vue architecturale

Description de l'architecture

Enfin, l'implmentation livre un rsultat important : la correspondance des composants exe cutables avec les nuds. C'est l'architecte qui est responsable de celle correspondance, dcrite dans la vue architecturale du modle de dploiement. Pour de plus .impies dtail! consultez le chapitre 9, section 9.3.7, Artefact : modle de dploiement . Notez que l'architecte n'est pas responsable du dveloppement continu et de la m. aiain i des divers artefacts figurant dans le modle d'implmentation, qui sont du ressort de l'inu.i nieur de composants concern.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

J ! PARTIE II

Implmentation
CHAPITRE 10

10.4.2 Travailleur : ingnieur

de

composants

Figure 10.15
Responsabilits d'un intgrateur systme.

o
f~J Intgrateur systme responsable de

L'ingnieur de composants dfinit et actualise le code source d'un ou de plusieurs compo sants fichiers, en s'assurant que chaque composant implmente la bonne l'onction (par exemple, telle qu'elle a t spcifie par les classes de conception).

1
Plan de construction de l'intgration

En gnral, l'ingnieur de composants est galement charg de veiller l'intgrit d'un ou de plusieurs sous-systmes d'implmentation. Ces derniers ayant une traabilit un--un avec les sous-systmes de conception, la plupart des changements affectant ces sous-systmes seront pris en charge pendant la conception. Mais l'ingnieur de composants doit quand mme s'assurer que le contenu (par exemple, des composants) des sous-systmes d'implmentation est juste, que leurs dpendances vis--vis d'autres sous-systmes et/ou interfaces sont exactes et qu'ils implmentent correctement les interfaces qu'ils fournissent (voir la figure 10.14).

10.5

E n c h a n e m e n t d'activits
Aprs avoir dcrit, dans les sections prcdentes, le travail d'implnicntatioii en teinii t.i tiques, nous allons maintenant envisager le comportement dynamique du diagramme d'au n vits (voir la figure 10.16).
1

D'une manire gnrale, i l est souhaitable de confier l'ingnieur de composants charg d'un sous-systme la responsabilit des lments de modle (par exemple, des composants) que contient ce sous-systme. En outre, pour instaurer un dveloppement parfaitement fluide, i l semble naturel que le mme ingnieur de composants porte la responsabilit d'un sous-systme et de son contenu tout au long des enchanements d'activits de conception et d'implmentation. Cet ingnieur doit, par consquent, concevoir et implmenter les classes sous sa responsabilit.
Figure 10.14
Responsabilits d'un ingnieur ,le composants pendant l'implmentation.

O
f_J Ingnieur de composante

O
Composant Sous-systme d'implmentation Interface

Le principal objectif de l'implmentation est, prcisment, d'implmenter le systme. C'est l'architecte qui lance le processus en esquissant les composants cls du modle d'implmentation. Ensuite, l'intgrateur systme planifie les intgrations du systme ncessites par l'itration en cours sous forme de squence de constructions. I l dcrit, pour chacune de ces constructions, les fonctions implmenter et indique les parties du modle d'implmentation (c'est--dire les sous-systmes et les composants) qui seront concernes. Les exigences imposes aux sous-systmes et aux composants de la construction sont ensuite implmentes par les ingnieurs de composants, et les composants qui en rsultent sont tests individuellement, puis intgrs dans une construction par l'intgrateur systme. Ce dernier transmet la nouvelle construction aux testeurs d'intgration, qui lui font subir des tests d'intgration (voir le chapitre 11). Les dveloppeurs peuvent alors commencer l'implmentation de la construction suivante, en prenant en considration les anomalies dtectes dans la construction prcdente.

10.4.3 Travailleur : intgrateur

systme

L'intgration du systme dpasse les attributions de l'ingnieur de composants. Cette responsabilit revient l'intgrateur systme, qui planifie la squence de constructions ncessite par chaque itration et l'intgration de chaque construction une fois ses diverses parties implmentes. Cette planification se traduit par un plan de construction des intgrations (voir la figure 10.15).

1. C'est--dire un certain nombre de personnes formant ensemble le travailleur architecte, ventuellement au sein d'une quipe d'architecture.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Implmentation
CHAPITRE 10

igure 10.16

tation des classes. Une simple esquisse des composants significatifs sur le plan architectural devrait suffire (voir la section 10.3.5, Artefact: description de l'architecture (vue du modle d'implmentation ).
Figure 10.17
Entres et rsultat de l'implmentation de l'architecture. O Modle de conception

. enchanement d'activits de l'implmentation, vec les availleurs y prenant part et leurs activits.
r

..7

,-' CompoHiinl [esquisse et tWonlimlloiiHMil correspondance nvm: la mmtiU|

Ingnieur de composants Implmenter un sous-systme Modle de dploiement

-->

g^*.

Architecture d'implmentation

-*0.5.1 Activit

: implmenter

l'architecture

L'implmentation de l'architecture a pour objectif de dlimiter le modle d'implmentation et son architecture : en identifiant les composants significatifs sur le plan architectural, tels que les composants excutables ; en assurant la correspondance des composants avec des nuds dans les configurations rseau appropries.

Description de l'architecture [vues des modles de conception et de dploiement]

Description dn l'architecture [vues d e s m o d l e s d ' I m p l m n i i l n t i u n el de d p l o i e m e n t |

Identification des composants excutables et correspondance avec les nuds Pour identifier les composants excutables pouvant tre dploys sur des nuds, on prend en compte les classes actives dtermines pendant la conception et dont chacune se voit affecter un composant excutable reprsentant un processus lourd. I l peut galement tre question de dtecter d'autres composants fichiers et/ou binaires ncessaires la cration de composants excutables, bien que l'importance de cette opration soit relativement secondaire. RWflJfj
u m m

Identification des composants excutables

Le modle de conception comporte une classe active nomme Traitement des demandes de r g l ement. La phase d'implmentation permet l'identification d'un composant excutable correspondant appel TraitementDesDemandesDeRgl ement (voir la figure 10.18).

Souvenez-vous que c'est pendant la conception de l'architecture (voir le chapitre 9, section 9.5.1, Activit : conception architecturale ) que sont esquisss les sous-systmes de conception, avec leur contenu et leurs interfaces. On utilise ensuite, au cours de l'implmentation, des sous-systmes d'implmentation ayant une traabilit un--un avec ces soussystmes de conception et fournissant les mmes interfaces. L'identification de ces sous-systmes d'implmentation et de leurs interfaces est donc relativement vidente et ne sera pas traite ici. La principale difficult de l'implmentation consiste crer, au sein des sous-systmes d'implmentation, des composants qui implmentent les sous-systmes de conception correspondants. Au cours de cette activit, l'architecte prcise et actualise la description de l'architecture, ainsi que les vues architecturales des modles d'implmentation et de dploiement.
10.5.1.1 Identification d e s c o m p o s a n t s significatifs s u r le p l a n a r c h i t e c t u r a l

Figure 10.18
On utilise des classes actives pour identifier les composants excutables.

Modle de conception

Traitement des demandes de rglement

Modle d'implmentation
TraitementDesDemandes DeRglement

Il est assez pratique, pour lancer le travail d'implmentation, d'identifier les composants significatifs sur le plan architectural tt dans le cycle de vie du logiciel (voir la figure 10.17). Mais un grand nombre de composants, en particulier les composants fichiers, s'imposent ds le dpart avec une certaine vidence lors de l'implmentation des classes, tout simplement parce qu'ils se contentent d'offrir un moyen de regrouper l'implmentation de ces classes dans des fichiers de code source. C'est pourquoi les dveloppeurs doivent veiller ne pas identifier un nombre trop lev de composants ce stade et ne pas se fourvoyer dans les dtails, sous peine d'avoir refaire toute une partie du travail au moment de l'implmen-

L e s e n c h a n e m e n t s d ' a c t i v i t s principaux
PARTIE II

Implmentation
CHAPITRE 10

mm

Figure 10.20
Entres systme. et rsultat du Exigences supplmentaires-. de l'intgration Les de cas ralisationsconception modle de forment d'utilisation du conception une base essentielle cette activit. Modle de conception Modle des cas d'utilisation

Un examen plus approfondi des modles de conception et le ileploieineni pet met de vriflet si des objets actifs sont affects des nuds. Si c'est le cas. les compoitntl I) .1 e Iraa bilit avec les classes actives correspondantes doivent tre dploys sut les mmes uu-utls. BfflgH Dploiement de composants sur des nuds
Un objet actif de la classe Traitement des demandes de r g l e m e n t est affect au nud Serveur acheteur.

D
Intgrateur systme

Plan de construction de l'Intgration

w w

I
| line 10.19

tant donn que le composant Trai tementDesDemandesDeRgl ement implmente la classe Traitement des demandes de r g l e m e n t (voir l'exemple prcdent), il doit tre, lui aussi, dploy sur le nud Serveur acheteur (voir la figure 10.19).
N u d s avec leurs objets actifs N u d s avec leurs instances de composant

,-7 le

Intgrer systme

\.. s objets actifs affects des -mis impliquent I f dploiement squence en des

: Serveur acheteur donne lieu des demandes de rglement

: Serveur acheteur

Modle d'implmentation [constructions prcdentes]

Modle d'implmentation [constructions ultrieures!

. omposonts.

des demandes de rglement excutable

10.5.2.1 Planification d ' u n e c o n s t r u c t i o n u l t r i e u r e

La correspondance des composants sur les nuds est particulirement significative pour l'architecture du systme et doit tre dcrite dans la vue architecturale du modle de dploiement.

Nous allons aborder, dans cette section, les moyens de planifier le contenu d'une construction ultrieure, que l'on se fonde sur une construction existante ou que l'on parte de zro. Nous considrons galement que l'on nous fournit un certain nombre de cas d'utilisation et/ ou de scnarios (c'est--dire de chemins travers des cas d'utilisation) et d'autres exigences devant tre implmentes dans l'itration en cours. Vous trouverez ci-dessous quelques critres applicables une construction venant aprs une autre construction.

0.5.2 Activit

: intgrer

le

systme

L'intgration du systme a pour objectifs : la cration d'un plan de construction de l'intgration dcrivant les constructions ncessites par une itration et les exigences pesant sur chacune d'elles ; l'intgration de chaque construction avant qu'elle ne soit soumise aux tests d'intgration.

I.
I I I I

La construction doit ajouter des fonctions par rapport la construction prcdente travers l'implmentation de cas d'utilisation complets ou de scnarios de ces cas d'utilisation. (Pour plus de clart, nous emploierons cas d'utilisation pour cas d'utilisation et/ou scnario dans le reste de cette liste.) Les tests d'intgration de la construction s'appuieront sur ces cas d'utilisation, sachant qu'il est plus simple de tester des cas d'utilisation complets que des fragments de cas d'utilisation (voir le chapitre 11). La construction ne doit pas comprendre une trop grande quantit de composants nouveaux ou affins, car cette abondance pourrait rendre l'intgration de la construction cl la conduite des tests d'intgration particulirement dlicates. Si ncessaire, on peul implmenter certains composants en tant que stubs, afin de rduire le plus possible le nombre de nouveaux composants introduits dans la construction (voii la seeiiiui 111 1 ' I Stubs ). Chaque construction doit se fonder sur la prcdente et se dvelopper de faon asi eiulann et latrale dans la hirarchie des sous-systmes en couches. Cela signifie que les premires constructions doivent partir des couches infrieures (les couches de uiiildlcwiu * et de logiciel systme), tandis que les constructions suivantes remontent en direction de II couche gnrale aux applications et de la couche spcifique l'application. Pourquoi 7

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

implmentation
CHAPITRE 10

Tout simplement parce qu'il est difficile d'implmentci des i posants dQI IfU OM suprieures avant que les composants ncessaires <lcs conclus inli ieitres ne soicnl en place et en tat de fonctionner.

10.5.2.2 I n t g r a t i o n d'une construction

Si la construction a t correctement planifie selon les indications de l'tape prcdente, son intgration doit tre relativement directe. I l faut recueillir les versions appropries de sous-systmes d'implmentation et des composants, les compiler et les lier en uni' <, traction. Notez qu'il peut tre ncessaire d'effectuer la compilation de bas en li.un rapport la hirarchie en couches, l'existence de dpendances de compilation dM fil suprieures envers les couches infrieures n'tant pas exclure.
v

La construction qui en rsulte est ensuite soumise aux tests d'intgration, pull >" Il I systme si elle a pass les premiers avec succs. Il s'agit de la dernire constiui sein d'une mme itration (voir le chapitre 11).

On peut, en gardant ces critres l'esprit, commencer valuer les hesouis. tell que les % r. d'utilisation (et/ou des scnarios de ces cas d'utilisation), impleiuenles Noie/ qu'il laudra sans doute trouver un compromis si l'on veut satisfaire ces diffrents critres de manire approprie. Par exemple, l'implmentation d'un cas d'utilisation complet (premier point) peut ncessiter l'intervention d'un grand nombre de nouveaux composants (deuxime point). Il est videmment possible, malgr ces mises en garde, de procder l'implmentation de ce cas d'utilisation si cette implmentation est essentielle pour la construction en cours. Dans tous les cas, i l est crucial d'identifier les vritables besoins devant tre implments par une construction et de laisser les autres aux constructions ultrieures. Pour chaque cas d'utilisation susceptible d'tre implmente, procdez de la faon dcrite cidessous. 1. Prenez en compte la conception du cas d'utilisation en en identifiant la ralisationconception de cas d'utilisation correspondante dans le modle de conception. Rappelezvous qu'on peut remonter depuis une ralisation-conception de cas d'utilisation jusqu'au cas d'utilisation concern (et donc, implicitement, tous ses scnarios) par le biais de dpendances de traabilit. 2. 3. Identifiez les sous-systmes et les classes de conception prenant part la ralisationconception de cas d'utilisation. Identifiez les sous-systmes d'implmentation et les composants du modle d'implmentation remontant aux sous-systmes et aux classes de conception trouvs au cours de l'tape 2.

10.5.3 Activit

: implmenter

un

sous-systme

Le propos de l'implmentation d'un sous-systme est de s'assurer que , , sou remplit son rle dans chaque construction, selon les prvisions du plan les i onsliin lions <l. l'intgration. Ce qui suppose de faire en sorte que les besoins (par exemple, les scenni ne, et/ ou les cas d'utilisation) soient implments dans la construction cl que ceux qui allcelcnl ce sous-systme soient correctement mis en uvre par les composants ou (de faon rcursive i par d'autres sous-systmes au sein du sous-systme lui-mme (voir la figure 10.21).
Figure 10.21
Entres et de des rsultat l'implmentation sous-systmes.

o
D
Ingnieur de composants Plan de construction de l'intgration <.
N

4.

Tenez compte de l'impact qu'a l'implmentation des besoins sur ces sous-systmes d'implmentation et sur les composants au-dessus de la construction en cours. Notez que ces besoins sont exprims sous forme de sous-systmes et de classes de conception, comme l'indique l'tape 3. valuez si cet impact est acceptable ou non en fonction des critres noncs plus haut. Si c'est le cas, planifiez l'implmentation du cas d'utilisation dans la construction suivante ; sinon, reportez-la une construction plus tardive.

Description de l'architecture [vue du modle d'implmentation]

Sous-systme d'implmentation [implmente pour une construction] - 'T'implmenter -. un sous-systme Interface [implmente pour une construction]

Sous-systme de conception [conu]

Les rsultats doivent apparatre dans le plan de construction de l'intgration et tre communiqus aux ingnieurs de composants responsables des sous-systmes d'implmentation et des composants concerns. Ces ingnieurs peuvent alors commencer l'implmentation des sous-systmes d'implmentation et des composants en question dans la construction en cours (comme le dcrivent les sections 10.5.3, Activit : implmenter un sous-systme et 10.5.4, Activit: implmenter une classe), puis les tester unit par unit (comme le dcrit la section 10.5.5, Activit : effectuer les tests unitaires ). Enfin, les sous-systmes d'implmentation et les composants sont transmis pour intgration l'intgrateur systme (voir la section suivante).

Interface [conue]

10.5.3.1 A c t u a l i s a t i o n du c o n t e n u d e s

sous-systmes

On considre qu'un sous-systme remplit ses objectifs lorsque les beioim a Implmi i dans la construction en cours et ceux qui affectent le sous-systme sont eoneeien pli mentes par des composants de ce sous-systme. Si le contenu du sous-systme (par exemple, les composants qu'il renferme) Ml di I Il les architectes, i l peut ncessiter quelque amlioration de la pari de l'ingnieu! dl l ompu

L e s e n c h a n e m e n t s d ' a c t i v i t s principaux
PARTIE II

Implmentation
CHAPITRE 10

sants, en fonction de l'volution du modle d'implmentation. Cette amlioration peul l O U cerner les aspects dcrits ci-dessous.

Figure 10.23
Une interface exige par une construction doit galement fournie par un sous-systme d'implmentation. (a) tre

M o d l e de conception

r f

Chaque classe du sous-systme de conception correspondant ncessaire a la eonslnn lion en cours doit tre implmente par des composants du sous-systme d'iiuplenicnlalion (voir la figure 10.22). Notez que si le sous-systme de conception contient (de faon rcursive) d'autres sous-systmes de conception exigs par la construction en cours, la mthode est identique : chacun de ces sous-systmes de conception doit alors tre implmente par un sous-systme d'implmentation correspondant dtenu par le sous-systme d'implmentation considr. Chaque interface fournie par le sous-systme de conception correspondant et ncessaire la construction en cours doit galement tre fournie par le sous-systme d'implmentation. Ce dernier doit, par consquent, dtenir soit un composant, soit (de faon rcursive) un sous-systme d'implmentation fournissant l'interface en question (voir la figure 10.23).

Modle d'implmentation

r Igure 10.22
/ r.v classes de

M o d l e de conception

Modle d'implmentation
sous-systme d'implmentation

Interfaces ncessaires la construction en cours

c onctptton
"(luises par une I ' (instruction sont nplmentes par les ci imposants.

S o u s - s y s t m e fournissant une interface

1
Classes ncessaires la construction en cours

fichier

Figure 10.24
Le composant Traitement des factures fournit l'interface Facture. Traitement des factures Gestion des factures par l'acheteur |

fichier

partir de l, les ingnieurs de composants peuvent commencer implmenter les lments indispensables par des composants du sous-systme (comme le dcrit la section l u i Activit : implmenter une classe) et les tester par unit (comme le dcrit la section 10.5.5, Activit : effectuer les tests unitaires ). Le sous-systme rsultant de ce processus est alors transmis pour intgration ;i riniep.iaieiu systme (comme le dcrit la section 10.5.2, Activit : intgrer le systme ).

L e s e n c h a n e m e n t s d ' a c t i v i t s principaux
PARTIE II

i
I

Implmentation
CHAPITRE 10

5.4 Activit

: implmenter

une

classe

L'objectif de cette activit est d'implmenter une classe de conception dans un i nmposnnl fichier et s'articule autour des tapes suivantes (voir la figure 10.25) : esquisser un composant fichier qui contiendra le code source ; gnrer le code source partir de la classe de conception et des relations qu'elles entretient avec d'autres lments ; implmenter les oprations de la classe de conception sous forme de mthodes ; s'assurer que le composant fournit les mmes interfaces que la classe de conception. Bien qu'ils ne soient pas dcrits ici, cette activit comprend galement la prise en compte de divers aspects de maintenance de la classe implmente, comme la correction des anomalies une fois la classe teste. O n
Ingnieur de composants Classe de conception [conue] Implmenter une classe Composant [Implmente]

tions est gnre ; les oprations elles-mmes restent implmenter (voir la section 10.5.4.3, Implmentation des oprations ). Notez galement que la gnration de code partir des associations et des agrgations peut se rvler trs dlicate et que ses modalits varieront en fonction du langage de program mation. Par exemple, i l est courant qu'une association navigable dans un sens soit impie mente par une rfrence entre objets ; cette rfrence sera alors reprsente ce m attribut de l'objet rfrant, attribut qui sera nomm d'aprs le nom de rle I extrmit de l'association. La multiplicit de cette extrmit indiquera, a son tout, | | l'attribut (de la rfrence) doit tre de type simple pointeur (si la multiplicit esi mlci i un < ou gale un) ou de type collection de pointeurs (si la multiplicit est supeiieuic i
10.5.4.3 I m p l m e n t a t i o n des o p r a t i o n s

Iguro 10.25

es et rsultat Mlmi>lmenJ 'l .l'une classe.

Chaque opration dfinie par la classe de conception doit tre implmente. a moins qu'elle ne soit virtuelle (ou abstraite ) et implmente par des descendants (tels que d types) de la classe. On utilise le terme mthodes pour dsigner rimplciiiciiiiiiinii des oprations [5], dont on trouvera des exemples avec les mthodes Java |2|, les mthode'. Visual Basic [3] et les fonctions membres C++ [4].

O"'
Interface [fournie par la classe de conception]

L'implmentation d'une opration suppose de choisir un algorithme appropri et des slrue tares de donnes adaptes (comme des variables locales de la mthode), puis de coder les actions requises par l'algorithme. N'oubliez pas que la mthode peut avoir t spcifie en langue naturelle ou en pseudo-cod au cours de la conception de la classe (bien que ce soit rare et que cela reprsente souvent une perte de temps ; voir la section 9.5.3.6). Quoi qu'il en soit, toute mthode de conception peut, bien entendu, tre utilise comme entre pour cette tape. Notez galement que les tats dcrits pour la classe de conception peuvent influer sur l'implmentation des oprations, puisque l'tat de la classe dtermine le comportement de celle-ci lors de la rception d'un message.
1 0 . 5 . 4 . 4 F a i r e e n s o r t e q u e le c o m p o s a n t f o u r n i s s e l e s i n t e r f a c e s appropries

10.5.4.1 E s q u i s s e d e s c o m p o s a n t s f i c h i e r s

Le composant rsultant de ce processus doit fournir les mmes interfaces que la ou les classes de conception qu'il implmente. Vous en trouverez un exemple dans la section 10.3.2, Artefact : composant .

10.5.5 Activit

: effectuer les tests

unitaires

Le code source implmentant une classe de conception rside dans un composant fichier. I l faut par consquent esquisser ce composant fichier et en dlimiter la porte. I l est assez courant d'implmenter plusieurs classes de conception dans un mme composant fichier. Rappelez-vous nanmoins que l'approche par la modularisation des fichiers et les conventions du langage de programmation utilis auront un impact sur l'laboration des composants fichiers (voir la section 10.3.2, Artefact : composant ). Par exemple, avec Java, on crera un composant fichier java pour chaque classe d'implmentation. D'une manire gnrale, les composants fichiers choisis doivent prendre en charge la compilation, l'installation et la maintenance du systme.
1 0 . 5 . 4 . 2 G n r a t i o n d e c o d e partir d ' u n e c l a s s e d e c o n c e p t i o n

Le propos de cette activit est de tester les composants implments en tant qu'units inilivi duelles (voir la figure 10.26). Les types de tests suivants sont effectus : les tests des spcifications, ou tests bote noire , qui vrifient le comportement du composant observable de l'extrieur ; les tests de structure, ou tests bote blanche , qui vrifient rimplincnlalion interne le l'unit.

I'

Pendant la conception, une grande partie des informations concernant la classe de conception et ses relations sont exprimes dans la syntaxe du langage de programmation, ce qui simplifie considrablement la gnration de certaines parties du code source qui implmente la classe en question. Ceci vaut, en particulier, pour les oprations et les attributs de la classe, ainsi que pour les relations qu'entretient la classe. Toutefois, seule la signature des opra-

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Implmentation
CHAPITRE 10

mgj
mm

de valeurs situes en dehors des classes d'quivalence acceptables, comme le retrait d'une valeur suprieure ou infrieure la porte autorise ; de valeurs interdites, comme le retrait de -140 ou de A. En choisissant les tests effectuer, l'ingnieur de composants doit s'efforcer de couvrir toutes les combinaisons de classes d'quivalence d'entres, d'tats et de sorties, comme le retrait de 140 FF:
Composant [test par unit]

.jures ,

Hgure 10.:26 et rsultat

mit. Composant [implmente]

les tests d

Ingnieur de composants

.=7 Effectuer les tests unitaires

d'un compte ayant un solde de -234,15 FF, ce qui n'aboutira aucun retrait ; d'un compte ayant un solde de 0 FF, ce qui n'aboutira aucun retrait ;

O "
Interface

d'un compte ayant un solde de 130,10 FF, ce qui n'aboutira aucun retrait ; d'un compte ayant un solde de 150 FF, ce qui aboutira un retrait de 140 FF.

Notez que certaines units peuvent subir d'autres tests, comme des tests de performances, d'usage de la mmoire, de charge et de capacit. Enfin, i l convient de pratiquer des tests d'intgration et des tests systme pour s'assurer que plusieurs composants se sont bien comports lors de leur intgration (voir le chapitre 11).
10.5.5.1 R a l i s a t i o n d e s t e s t s d e s s p c i f i c a t i o n s

Le rsultat net de ces quatre cas de tests est que toutes les combinaisons possibles iln dasui:. d'quivalence pour les tats (Solde p o s i t i f et Solde n g a t i f ) et pour les soitliis (h t r a i t posi t i f et R e t r a i t nul ) sont testes pour une seule valeur dans une classe d'ni|iil valence. L'ingnieur de composants doit alors choisir de tester des cas prsentant dos valums d'tats identiques (peut-tre -234,15 FF, 0 FF, 3 FF et 150 FF) et de sortie (0 FF et 140 FF), mais avec une autre valeur issue de la mme classe d'quivalence d'entres, par exemple 3,14 FF. L'ingnieur de composants labore ensuite des gammes semblables de cas de tests pour d'autres classes d'quivalence de valeurs d'entre, comme les tentatives de retrait des valeurs suivantes : 0 FF, 4 FF, 3,14 FF, 5 923 FF, 0,000 000 01 FF, 37 000 000 000 000 000 000 000 FF (s'il s'agit l du nombre possible le plus lev), 37 000 000 000 000 000 000 001 FF, -14 FF et A. 10.5.5.2 R a l i s a t i o n d e s tests d e structure

On effectue des tests des spcifications pour vrifier le comportement du composant sans s'intresser la faon dont est implmente ce comportement au sein du composant. Les tests des spcifications examinent alors les sorties que le composant produira partir des entres donnes et en fonction d'un tat de dpart spcifique. La gamme des combinaisons d'entres, d'tats de dpart et de sorties possibles tant souvent considrable, i l devient difficile de les tester une une. On prfre rpartir ces gammes d'entres, de sorties et d'tats en classes d'quivalence. Une classe d'quivalence est un ensemble de valeurs d'entre, d'tat ou de sortie pour lesquelles un objet est cens se comporter de manire identique. En testant un composant pour chaque combinaison de classes d'quivalence d'entres, de sorties et d'tats de dpart, i l est possible de parvenir une couverture de tests presque aussi efficace que si l'on testait chaque combinaison de valeurs une une, mais au prix d'un effort considrablement rduit.
BMS Classes d'quivalence

Les tests de structure permettent de vrifier le fonctionnement interne d'un composant. L'ingnieur de composants doit s'assurer, au cours de ce type de test, qu'il teste tout le code. Chaque instruction doit donc tre excute au moins une fois. I l faut galement veiller tester les chemins les plus intressants travers le code, c'est--dire ceux qui sont le plus couramment emprunts, les plus stratgiques, les plus improbables travers les algorithmes et ceux qui sont associs un niveau de risques lev.
EffijH Code source Java pour une mthode La figure 10.27 montre une implmentation (simplifie) de la mthode de retrait dfinie pai la classe Compte.

L'tat d'un compte prsente trois classes d'quivalence : Vi de, Sol de n g a t i f (ventuellement dcouvert) et Sol de posi t i f. De mme, les arguments d'entre peuvent tre rpartis en deux classes d'quivalence : Z r o et Nombres p o s i t i f s . Enfin, les arguments de sortie se rpartissent en deux classes d'quivalence : R e t r a i t p o s i t i f et R e t r a i t nul. L'ingnieur de composants doit choisir des valeurs pour les tests partir : de valeurs normales situes dans la porte autorise pour chaque classe d'quivalence, comme le retrait de 4 FF, de 3,15 FF ou de 5 923 FF d'un compte ; de valeurs situes la frontire des classes d'quivalence, comme un retrait de 0, du plus petit nombre positif autoris (par exemple, 0,000 000 01 ) ou du plus grand nombre autoris ;

jmmfmm

I i "
PARTIE

o h a n e m e n t s d ' a c t i v i t s principaux
II

Implmentation

pjpjj

KISIMI

cTJTnl^FTWm
public class Compte { 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 else {return 0} } else {return 0} } //Dans cet exemple, le Compte n'a qu'un solde private Solde argent = new Argent (0) public Retrait argent(Montant crgent) { //Il laut d'abord s'assurer que le solde est au moins //aussi important que le retrait demand if solde >= montant //On vrifie ensuite qu'on ne retirera pas un montant ngatif then {if montant >= 0 then { try{ solde = solde - montant; return montant } catch (Exception exc) { //Traitent des checs rduisant le solde //... dfinir...

10.6

R s u m de

l'implmentation

L'implmentation a pour principal rsultat le modle d'implmentation, compos des l ments suivants : les sous-systmes d'implmentation et leurs dpendances, interfaces et contenu ; les composants, y compris les composants fichiers et excutables, et leurs dpend.ni M mutuelles. Les composants sont tests unit par unit ; la vue architecturale du modle d'implmentation, avec ses lments significatifs sui li plan architectural. L'implmentation se traduit galement par un raffinement de la vue archiici lui,il. du Ii li de dploiement, qui fait apparatre la correspondance des composants exc iilnbli nvi i li nuds du rseau. Comme l'indiquera le chapitre suivant, le modle d'implmenlalic)ii c eue,mm I enti, , pritl cipale des activits ultrieures de tests. Pour tre plus prcis, chaque c onsluu lion issue de l'implmentation subit des tests d'intgration et, ventuellement, des lests systme au c de la phase de tests.

Figure 10.27 Code source Java pour une mthode de retrait simple dfinie par la classe Compte.

10.7
2

Rfrences
1 IEEE Std 610.12. 1990.
KEN ARNOLD et JAMES GOSLING, The Java Programming Language, Reading, MA,

Addison-Wesley, 1996.
3 ANTHONY T. M A N N , Visual Basic5Developer's Guide, Indianapolis, IN, SAMS

Publishing, 1997. 4 5 6 BJARNE STROUSTRUP, The C+ + Programming Language, 3 dition, Reading, MA, Addison-Wesley, 1997.
e

The Unified Modeling Language for Object-Oriented Development, Documentation set, ver. 1.1, Rational Software Corp., Septembre 1997. J. RUMBAUGH, M . BLAHA, W. PREMERLANI, F. EDDY et W. LORENSEN, ObjectOriented Modeling and Design, Englewood Cliffs, NJ, Prentice Hall, 1991.

Il faut s'assurer, en testant ce code, que toutes les instructions i f sont values successivement avec t r u e et avec f al se, et que tout le code est excut. On peut, par exemple, tester les cas suivants : retrait de 500 FF d'un Compte dont le solde est de 1 000 FF, o le systme excute les lignes 10 13; retrait de -500 FF d'un Compte dont le solde est de 100 FF, o le systme excute la ligne 21 ; retrait de 500 FF d'un Compte dont le solde est de 100 FF, o le systme excute la ligne 19 ; dclenchement d'une exception lorsque le systme excute l'instruction sol de = solde - montant, o le systme excute les lignes 14 17.

L e s e n c h a n e m e n t s d ' a c t i v i t s principaux PARTIE II

r r

11
Test

! I I I 1 I
11.1 I n t r o d u c t i o n
L'enchanement d'activits des tests s'attache la vrification des rsultats de l'implmentation en testant chaque construction, aussi bien les constructions internes et intermdiaires que les versions finales du systme, livrables l'extrieur. Vous trouverez une excellente prsentation gnrale des tests dans [2]. Les divers objectifs que poursuit la phase de tests sont numrs ci-dessous. Planifier les tests ncessaires pour chaque itration, y compris les tests d'intgration et les tests systme. Les tests d'intgration doivent tre mens sur chaque construction d'une itration, tandis que les tests systme ne sont exigs qu' la fin de l'itration. Concevoir et implmenter les tests en crant des cas de test spcifiant ce qui doit tre test, des procdures de test prcisant les modalits d'excution des tests, et enfin des composants de test excutables destins automatiser les tests, si possible. Effectuer les divers tests et prendre systmatiquement en compte les rsultats de chacun d'eux. Les constructions faisant apparatre des anomalies sont retestes et ventuellement renvoyes d'autres enchanements d'activits principaux, comme la conception ou l'implmentation, afin que les anomalies significatives puissent tre corriges. Nous allons prsenter, dans ce chapitre, les conditions de ralisation des lests ainsi que Ici travailleurs et les artefacts y prenant part (voir la figure 11.1). Notre approche le cel cm liai nement d'activits est trs proche de celle adopte pour l'enchanement d'activits d'impie mentation.

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Test
CHAPITRE 11

Phases Enchanements d ' a c t i v i t s principaux

Figure 11.1 Travailleurs et artefacts impliqus dans les tests.

"i Inynnlnur d composants

r u s p o i i M i h l i ' iJi'

i i .'M. .,, d'Intgration

n
yHt

11.2 de converties tests.

/
Analyse

X
Anomalie Conception

Modle des tests

Cas de test

Procdure de test

valuation Plan des tests des tests

Composant de test

11.2 R l e d e s t e s t s d a n s le c y c l e d e v i e d u l o g i c i e l

iter. #2

Iter. #n

Iter. #n+1

lier Iter. I Iter. #n+2 I m I in.

Itrations

S'il est possible de commencer planifier les tests ds la phase de cration, lorsqu'on dlimite la porte du systme, ils interviennent avant tout au moment o chaque construction (comme rsultat de l'implmentation) doit subir des tests d'intgration et des tests systme. Ce qui signifie que les tests mobilisent l'attention la fois pendant l'laboration, lors du test de l'architecture de rfrence excutable, et pendant la construction, lors de l'implmentation de la masse du systme. Pendant la phase de transition, l'attention se porte principalement sur la correction des anomalies dtectes au cours des premires utilisations et sur les tests de non-rgression (voir la figure 11.2). En raison de la nature itrative du dveloppement, certains des cas de test spcifiant les modalits de test des premires constructions peuvent galement servir de cas de test de nonrgression, dont ils dfinissent les conditions pour les constructions plus tardives. Le nombre de tests de non-rgression requis augmente par consquent de faon constante aufildes itrations ; les dernires itrations en ncessitent un volume substantiel. I l est donc naturel d'actualiser le modle des tests tout au long du cycle de vie du logiciel, bien que ce modle subisse constamment des volutions dues : la suppression des cas de test devenus obsoltes (ainsi que des procdures et des composants de test correspondants) ; au raffinement de certains cas de test en vue de les transformer en cas de test de nonrgression ; la cration de nouveaux cas de test pour chaque construction ultrieure.

11.3 A r t e f a c t s 11.3.1 Artefact : modle des tests

Le modle des tests dcrit avant tout les conditions dans lesquelles les composants excutables (tels que les constructions) du modle d'implmentation subissent des tests d'intgration et des tests systme. I l peut galement indiquer les modalits de tests de certains aspects spcifiques du systme (par exemple, si l'interface utilisateur est utilisable et cohrente ou si le manuel d'utilisation du systme remplit sa fonction). Ce modle se compose d'un ensemble de cas de test, de procdures de test et de composants de test, comme l'illustre lafigure11.3. Les sections suivantes prsentent en dtail les artefacts du modle des tests. Notez que si ce modle est important, c'est--dire s'il contient un grand nombre de cas de test, de procdures de test et/ou de composants de test, i l pourra tre utile d'y introduire des paquetages afin qu'il reste grable. Il s'agit l d'une extension relativement simple du modle des i c s i s . qui ne sera pas traite dans ce chapitre.
Figure 11.3 ^Modle des tests.

Modle des tests

FD+-

Systme de test

L e s e n c h a n e m e n t s d ' a c t i v i t s principaux PARTIE II

Test CHAPITRE 11

11.3.2 Artefact : cas de test

Entres Une commande correcte de V T existe et a t soumise au vendeur, VTT & Co. Le prix du V T est de 2 000 FF, port et manutention compris. Une confirmation de commande (n 99765) d'un VTT a bien t reue par le vendeur. Le prix confirm du VTT est de 2 000 FF, port et manutention compris. Une facture (n 12345) a bien t reue par l'acheteur. Cette facture est conforme a la confirmation de commande du VTT. Le montant factur doit atteindre un total de 2 000 FF, et la facture doit se trouver dans l'tat En attente. La facture doit, on uuiie faire rfrence au compte n 22-222-2222, destinataire du montant facilit Ce tantipln prsente un solde actuel de 963 456,00 FF et doit tre dtenu par le vendout. Le compte n 11-111-1111 de l'acheteur prsente un solde de 2 500 FF.

Un cas de test spcifie une manire de tester le systme, en pin c.ani i r qui doit e n avec quelles entres ou quel rsultat et sous quelles conditions (voit la figure M l |. tique, les tests peuvent porter sur n'importe quelle exigence ou collection d'exigences systme dont l'implmentation justifie la ralisation de tests dont l'excution sera mat lement possible et n'entranera pas un cot insupportable. Vous trouverez, ci-dess quelques exemples de cas de test courants.

Rsultat L'tat de la facture doit tre devenu Sol de (pour indiquer qu'elle a t rnlnit). Le compte n' 11 -111 -1111 de l'acheteur doit prsenter un solde de 500 FF. Le solde du compte n" 22-222-2222 du vendeur doit tre pass 965 956,00 FF.

Un cas de test spcifiant les conditions de test d'un cas d'utilisation ou d'un scnario spcifique de ce cas d'utilisation. Ce type de test comprend la vrification du rsultat de l'interaction entre les acteurs et le systme, la satisfaction des pr et postconditions spcifies par le cas d'utilisation, et le respect de la squence d'actions dicte par le cas d'utilisation. Notez qu'un cas de test fond sur un cas d'utilisation spcifie gnraleme un test bote noire du systme (c'est--dire un test du comportement du systme observable depuis l'extrieur).

Conditions Aucun autre cas d'utilisation (ou instance de cas d'utilisation) ne doit tre autoris accder aux comptes pendant l'excution de ce cas de test.

Un cas de test spcifiant les conditions de test d'une ralisationconception de cas d'utilisation ou d'un scnario particulier de la ralisation. Ce type de test peut compren la vrification de l'interaction entre les composants implmentant le cas d'utilisation. Notez que les cas de test fonds sur une ralisation de cas d'utilisation spcifient gnralement un test bote blanche du systme (c'est--dire un test de l'interaction interne entre les composants du systme).
Modle des tests

Cas d'utilisation [issu du modle des cas d'utilisation]

---<>

Cas de test [test bote noire]

Notez que certains cas de test peuvent tre trs proches et ne diverger que par une seule valeur d'entre ou de rsultat, notamment lorsqu'il s'agit de cas de test vrifiant diffrents scnarios d'un mme cas d'utilisation. I l peut alors tre souhaitable de spcifier ces cas de test sous forme de matrice, en reprsentant chaque cas de test par une ligne et chaque plage de valeurs d'entre ou de rsultat par une colonne. Ce type de matrice pourra offrir une intressante vision d'ensemble des cas de test similaires et constituer une entre utile la cration ultrieure de procdures de test et de composants de test (voir les sections 11.3.3 et 11.3.4). D'autres cas de test, destins tester le systme dans son ensemble, peuvent tre spcifis ; quelques exemples en sont donns ci-dessous.

Figure 11.4 Un cas de test peut tre driv d'un cas d'utilisation du modle de cas d'utilisation ou d'une ralisation de cas d'utilisation du modle de conception, auxquels il est, par consquent, li par une relation de traabilit.

Ralisation-conception de cas d'utilisation [issu du modle de conception]

Cas de test [test bote blanche]

Les tests d'installation vrifient que le systme peut tre install sur la plate-forme du client et qu'il fonctionne correctement une fois install. Les tests de configuration vrifient que le systme fonctionne correctement dans diverses configurations, notamment dans des configurations rseau diffrentes.

Cas de test Les ingnieurs de tests proposent un ensemble de cas de test pour tester le cas d'utilisati Rgi er l a f a c t u r e , en consacrant chaque cas de test un scnario du cas d'utilisation. L'un des cas de test proposs est le rglement d'une facture d'un montant de 2 000 FF po la commande d'un V T , qu'ils appellent R g l e r 2 000-VTT. Pour tre complet, ce cas de test doit prciser les entres, le rsultat escompt et les autre conditions pertinentes pour la vrification du scnario du cas d'utilisation.

Les tests de robustesse tentent de provoquer l'chec du systme afin de meilre au |0U1 Wl points faibles. Les ingnieurs de tests identifient les cas de test qui essaient d'utillse le systme dans des conditions anormales : mauvaise configuration rseau, capacit matrielle insuffisante ou charge de travail impossible . Les tests de stress identifient les problmes que rencontre le systme en cas de manque .1. ressources ou de concurrence pour l'utilisation des ressources. alenient appels cas d'abus .

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II CHAPITRE

Test
11 Mml

On trouvera la plupart de ces cas de tes. en examinant le. ,.,, d'util], , section H.5.2 revient plus en dtail sur ce sujel.

le Compte doit correspondre au compte spcifi dans le cas de test [22-222-2222].

11.3.3 Artefact : procdure

de test
(

Une procdure de test spcifie les conditions d'excution d'un ou de plusieurs ,ir de certaines parties de ces cas de test. U peut s'agir, par exemple, d'instructions pou* | cution manuelle d'un cas de test ou d'une spcification des conditions d'inten manuelle avec un outil d'automatisation pour crer des composants de test excutables ( la section 11.3.4). Il arrive que les conditions d'excution d'un cas de test soient spcifies par une procV de test, mais i l est souvent utile de rutiliser une mme procdure de test pour plusieurs de test et de rutiliser plusieurs procdures pour un seul cas de test (voir la figure 11.5).
spcifie les conditions d'excution 1. 1..* Cas de test

4. Cochez la case Autoriser le rglement pour lancer le rglement de cette facture. La bote de dialogue Rglement de la facture s'affiche. 5. Etc. (La suite spcifie les conditions d'excution du chemin complet du cas d'utilisation Rgi er la facture par l'intermdiaire de l'interface utilisateur en fournissant un certain nombre d'entres au systme, et ce qui doit tre vrifi dans les sorties du systme.)

Notez que cette procdure de test peut galement servir d'autres cas de tcsl soudain, qui ne diffrent que par leurs valeurs en entres et celles de leur rsultat (c'est a due les ali m entre crochets). En outre, cette procdure de test s'apparente la description de Ilot d i vi m ments du cas d'utilisation Rgler la facture (voir la section 7.4.3.1 ), niais elle compri ml des informations complmentaires: les valeurs d'entre utiliser a pailu du . a d niili sation, la faon de saisir ces valeurs dans l'interface utilisateur cl les lment: a venin-1
I f m i P r o c d u r e s g n r a le s de test

LXJ
Procdure de test

Figure 11.5 Les procdures de lest sont lies aux cas de test par des associations plusieurs-plusieurs.

Au moment de suggrer des procdures de test, les concepteurs de tests remarquent quu plu sieurs cas d'utilisation (et les cas de test permettant de les vrifier) commencent par la validation d'objets ds le dbut du cas d'utilisation, comme la comparaison de la facture la confirmation de commande.

P r o c d u r e de test

2 K 2of l u l T , "' ^'utilisation Rgler 2 000-VTT de l exemple prcdent (section 11.3.2). La premire partie rie 1 procdure de test est spcifie comme suit (le texte entre crochets p a s * spcification, puisqu'il apparat dj dans le cas de test). *
U 5 5 m q U n e p e r S O n n e P u i s s e e x c u t e r l e

Cas de test pris en charge : Rgi er 2 000-VTT. 1. Dans la fentre principale, slectionnez le menu Parcouri r les factures. La fentre Requte d'exploration des factures s'ouvre. 2. Dans le champ tat de la facture, slectionnez En attente et cliquez sur le bouton! Requte. La fentre Rsultats de la requte s'affiche. Vrifiez que la facture spcifie dans le cas de test (n 12345) apparat bien dans la fentre Rsultats de la r e | |

Ils proposent alors une procdure gnraledetestappeleValider les objets mtier et destine tester de telles squences. Cette procdure spcifie que les objets valider doivent d'abord avoir t crs (en lisant dans un fichier les valeurs qu'ils doivent prendre, puis en les crant dans la base de donnes). Elle indique ensuite que l'objet actif qui valide les objets mtier doit tre invoqu (comme le Gestionnai re de commandes dans le cas d'utilisation Rgi er 1 a facture). Elle prcise, enfin, que le rsultat de la validation doit tre compar au rsultat escompt (tel qu'il a t dcrit dans le fichier mentionn). Les concepteurs de tests proposent galement une procdure de test appele Vri fier l'chancier; elle prcise les modalits de test de la programmation d'une facture et vrifie ensuite que l'envoi en rglement de la facture provoque bien un virement entre comptes.

qute.
3. Slectionnez la facture rgler spcifie en double-cliquant dessus. La fentre Dtai 1 s de la facture concernant la facture en question s'affiche. Vrifiez les champs suivants : I

Sachant que plusieurs cas d'utilisation effectuent des virements entre comptes, les concepteurs de tests crent une procdure de test part, nomme Vri fier les virements entre comptes, afin de spcifier les conditions de vrification des virements.

11.3.4 Artefact : composant

de test

l'tat doit tre E attente ; n

la Date de rglement doit tre vide; le N * de confirmation de commande doit correspondre au numro indiqu dans le cas j de test [n 99765] ; le Montant de la facture doit correspondre au montant spcifi dans le cas de test [2 000 FF] ;

Un composant de test automatise tout ou partie d'une ou de plusieurs procdures di h si (voir la section 10.3.2 et la figure 11.6). Les composants de test peuvent tre mis au point l'aide d'un langage de script O d'Utl U langage de programmation, ou encore tre enregistrs par un outil d'automatisation des tl II On utilise les composants de test pour tester les composants du modle d'implmentation (voir le chapitre 10) en fournissant les entres de test, en contrlant et en surveillant l'ex

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II CHAPITRE

Test
11

( ) h

value les tests d'intgration et les tests systme une fois qu'ils ont t effectus (voir la figure 11.7). Notez que les concepteurs de tests n'excutent pas les tests, mais s'occupent de leur prpa ration et de leur valuation. Deux autres types de travailleurs, les testeurs d'intgration et le testeurs systme, sont chargs de raliser les tests.
figure 11-7
I Responsabilits concepteur jt tests dans ffun

O n
Ingnieur de tests

cution du composant test et, ventuellement, en rendani , >i i|.1. des ie aillais du ,,. , appelle parfois ces composants pilotes de test, envimnncmcnl de leM 111 nu s. , ,,,|. ,| ., ' Notez que les composants de test peuvent tre implments laide de la le. luiul,,^,. j ! Si plusieurs composants de test exercent des interactions complexes, enlre eux ou ave. U composants ordinaires du modle d'implmentation, on peut avoir recours a un modle : conception des tests part (semblable au modle de conception ; voir la section 9 3 pour modliser les composants de tests et en fournir des vues de haut niveau. Bien n | puisse tre utile, ce type de modle n'est pas trait dans cet ouvrage.
Figure 11.6
Les composants test sont lis aux procdures par des associations plusieurs-plusieurs. de test Composant de test Procdure de test de automatise

1..*

1..*

enchanement Jbf activits testsModle des tests Cas de test des

responsable de

Procdure de test

valuation Plan des tests don t<mU

11.3.5 Artefact : plan des

tests

11.4.2 Travailleur : ingnieur

de

composants

Le plan des tests dcrit les stratgies de tests, ainsi que leur calendrier et les ressources mises leur disposition. La stratgie des tests dfinit le type et les objectifs des tests effectuer pour chaque itration, le niveau requis de test et de couverture du code, et enfin le pourcentage des tests devant livrer un rsultat spcifique.

11.3.6 Artefact : anomalie

Une anomalie dsigne une anomalie du systme, telle que le symptme d'un chec logiciel ou un problme dcouvert lors d'une runion de rvision. Elle permet d'exprimer tout ce que les dveloppeurs doivent consigner en tant que symptme d'un problme du systme suivre et rsoudre.

Les ingnieurs de composants sont responsables des composants de test qui automatisent certaines procdures de test (toutes les procdures de test ne peuvent tre automatises), car la cration de tels composants peut rclamer de srieuses comptences en programmation (dj exiges de la part de l'ingnieur de composants dans l'enchanement d'activits d'implmentation ; voir la section 10.4.2).

11.4.3 Travailleur : testeur

d'intgration

11.3.7 Artefact : valuation

des

tests

Lvaluation des tests consiste valuer les rsultats de l'ensemble des tests : la couverture des cas de test, la couverture du code et l'tat des anomalies.

Les testeurs d'intgration sont chargs d'effectuer les tests d'intgration ncessaires pour chaque construction produite au cours de l'enchanement d'activits d'implmentation (voir la section 10.5.2). Ces tests permettent de vrifier que les composants intgrs une construction fonctionnent correctement ensemble. C'est pourquoi ils sont souvent drivs des cas de test spcifiant les modalits de test des ralisations-conception de cas d'utilisation (voir la section 11.3.2).

11.4 T r a v a i l l e u r s

11.4.1 Travailleur : concepteur

de tests

Les tests d'intgration font apparatre des anomalies, prsentes par le testeur d'intgration. Notez qu'un testeur d'intgration teste le rsultat (c'est--dire une construction) cr par un intgrateur systme dans l'enchanement d'activits d'implmentation. Certains 1 hel's de projet choisissent, par consquent, d'attribuer ces responsabilits aux mmes peis. .nues alin de rduire le plus possible les chevauchements entre les comptences requises

Le concepteur de tests doit veiller l'intgrit du modle des tests et s'assurer que celui-ci remplit bien son rle. D est galement charg de planifier les tests, en leur fixant des objectifs adapts et en dfinissant le calendrier de leur droulement. Enfin, non seulement i l slectionne et dcrit les cas de test et les procdures correspondantes requises, mais de plus i l

11.4.4 Travailleur : testeur

systme

Le testeur systme est charg d'effectuer les tests systme exigs pour une COnsttl > n reprsentant le rsultat (excutable) de toute une itration (voir la section 10.3 2). Ll Wll systme servent avant tout vrifier les interactions entre les acteurs et le systme ils sont

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Test
CHAPITRE 11

donc souvent drivs des cas de test spcifianl les modalits de lest dos , as d'titili ,| Toutefois, d'autres types de tests s'appliquent l'ensembli du systme (voit section 11.3.2).
sa

En exploitant en tant qu'entres ces cas, procdures et composants de test, les testeurs d'intgration et les testeurs systme testent chaque construction et font apparatre toute anomalie dtecte. Ces anomalies sont ensuite reverses dans les autres enchanements d'activits, tels que ceux de conception et d'implmentation, et transmis aux ingnieurs de tests, qui procdent une valuation systmatique des rsultats des tests.

.5.1 Activit

: planifier les tests

L'objectif est de planifier les tests (voir la figure 11.9) raliss pour une itration : en dcrivant une stratgie de test ; en estimant les exigences imposes par les tests, comme les ressource hum. systme ncessaires ; en fixant le calendrier des tests. Pour dresser le plan des tests, les ingnieurs de tests puisent diverses sonnes I i Ii l < des cas d'utilisation et les exigences supplmentaires les aident lixci un ordre itilupli i les tests et estimer les efforts qu'ils requirent. De son ct, le conceptem de tests utilise comme entres d'autres artefacts, tels que le modle de conception. Les concepteurs de tests mettent sur pied une stratgie gnrale de lests poui l'itration quel type de tests raliser, quand et comment les excuter, comment dterminer s'ils ont cl concluants. EflfflH Stratgie des tests systme pour la dernire itration de la phase d'laboration Au moins 75 % des tests doivent tre automatiss, tandis que le reste doit rester manuel. Chaque cas d'utilisation soumis aux tests sera test selon son flot normal et selon trois autres flots. Critres de succs : 90 % des cas de test russis. Aucune anomalie de priorit moyenne leve reste sans solution.

Les tests systme font apparatre des anomalies, prsentes par le lestent systme. En raison de la nature mme des tests systme, les personnes agissant en tant que testa' systme n'ont pas besoin d'en savoir trs long sur les fonctionnements internes du systm Ils doivent, en revanche, parfaitement connatre le comportement du systme observa depuis l'extrieur. Certains tests systme peuvent donc tre raliss par d'autres membres l'quipe du projet (les spcificateurs de cas d'utilisation), ou mme par des parties extern (les clients bta).

11.5 Enchanement d'activits

Aprs avoir, dans les sections prcdentes, dcrit les tests en termes statiques, nous allons maintenant utiliser un diagramme d'activits (figure 11.8) pour en examiner le comportement dynamique Le principal objectif de l'enchanement d'activits des tests est, videmment, de raliser et d'valuer les tests tels qu'ils sont dcrits par le modle des tests. Ce sont les ingnieurs de tests qui sont l'origine de cet enchanement d'activits, puisqu'ils planifient les tests effectuer dans chaque itration. Ils dcrivent ensuite les cas de test ncessaires la ralisation de ces tests et les procdures correspondantes. Puis les ingnieurs de composants crent, dans la mesure du possible, des composants permettant d'automatiser certaines de ces procdures. Le mme processus se rpte pour chaque construction issue de l'enchanement d'activits d'implmentation.
Figure 11.8
Enchanement d'activits des tests, avec les travailleurs y prenant part et leurs activits.

Ingnieur de tests

valuer les tests

o
\r \s tests \n

Testeur d'intgration

j
ai Effectuer les tests systme

\
\
\

Testeur systme

Le dveloppement, l'excution et l'valuation subsquente de chaque cas, procdure et composant de test exige un investissement temporel et financier. Comme i l est impossible de tester l'intgralit d'un systme, i l faut reprer les cas, procdures et composants de test garantissant le meilleur retour sur investissement en termes d'amlioration de la qualit [3|. Le principe de base consiste mettre au point des cas et des procdures de test ayant un nombre de chevauchements minimal afin de tester les cas d'utilisation les plus Importants Bl les exigences associes auxrisquesles plus srieux.

\
Implmenter les tests

Ingnieur de composants

Les e n c h a n e m e n t s d ' a c t i v i t s principaux

PARTIE II

Test
CHAPITRE 11

Figure 11.9
Entres et rsultat de la planification des tests. Modle des cas d'utilisation Exigences supplmentaires

11.10
W rsultat ception Exigences supplmentaires

Ingonloui << Iimls !

O 7
Ingnieur de tests

Modle des cas d'utilisation

-A
Plan des tests M o d l e d'analyse Planifier ,"^7 les tests 7!

- 7
Cas de Concevoir les tests

Modle d'analyse

-A ->
Modle de conception ^

Modle de conception

E r "

'kl

Modle d'implmentation

Modle d'implmentation

mini" do i.-..

Description de l'architecture [vues architecturales des modles]

Description de l'architecture [vues architecturales / des modles]

11.5.2 Activit

: concevoir

les tests

La conception des tests (voir la figure 11.10) a pour objectif : d'identifier et de dcrire des cas de test pour chaque construction ; d'identifier et de structurer des procdures de test indiquant les conditions de ralisati des cas de test.
11.5.2.1 C o n c e p t i o n d e s c a s d e test d ' i n t g r a t i o n Figure 11.11
premire partie pour " parcourir factures

Plan des tests [stratgie et calendrier des tests]

Cas de test d'intgration

Les concepteurs de tests commencent par examiner un diagramme de squence faisant partie d'une ralisation-conception de cas d'utilisation pour le cas d'utilisation Rgi er la facture. La figure 11.11 montre la premire partie de ce diagramme (voir la section 9.5.2.2).

des factures

: Confirmation de commande

'un diagramme isquence 4a' ralisationRgler

Les cas de test d'intgration servent vrifier l'interaction des composants les uns avec autres aprs leur intgration au sein d'une construction (voir la section 10.5.2). La plup des tests d'intgration peuvent tre drivs des ralisations-conception de cas d'utilisatio' puisque ces ralisations dcrivent les interactions entre classes et entre objets (et, par cons quent, entre composants).

de demande de rglement

des demandes de rglement

conception du cas d'utilisation la facture.

parcourlr()

parcourirFactures() Gestionnaire de commandes

obtenirlnfos ExplorationQ

vrifierFacture

Les ingnieurs de tests doivent crer un ensemble de cas de test permettant d'atteindre, av un minimum d'efforts, les objectifs fixs par le plan des tests. Ils essaient, pour ce fair d'identifier un ensemble de cas de test prsentant le moins de chevauchements possible et testant chacun un chemin ou un scnario intressant travers une ralisation de cas d'utilisation.

obtenirlnfosConfirmatlonO

obtenirFactureQ obtenirlnfosFacturo()

-tj

Pour crer les cas de test d'intgration, les testeurs d'intgration considrent en priorit les diagrammes d'interaction des ralisations de cas d'utilisation. Ils recherchent diverses combinaisons d'entres et de sorties d'acteurs et d'tat de dpart du systme formant des scnarios intressants qui mettent contribution les classes (et, par consquent, les composants) figurant dans les diagrammes.

Notez qu'un mme diagramme de squence peut offrir plusieurs squences dlftinniii'. selon, par exemple, l'tat de dpart du systme et les entres de l'acteur. En considrant le diagramme de squence de la figure 11.11, on peut par exemple, remarquer que de nnm breux messages ne seront pas envoys s'il n'y a pas de Facture dans le systme.

Les enchanements d'activits principaux PARTIE II

Test mm CHAPITRE 11 K

Un cas de test driv d'un diagramme de squence tel que celui ci pinmai! di n | , lits de test d'une squence intressante travers cedia'jiniiiiiiiiiMiitxpiiiiinul l'lal dedp requis du systme, les entres effectues par l'acteui et tout ce qui sciail susceptible de lan la squence.
M! ( n i

cas de test, ce qui permet de disposer rapidement et prcisment d'un ensemble resserr de procdures de test pour un grand nombre de cas de test.

Une fois les tests d'intgration correspondants effectus, on formule les vritables interao tions des objets au sein du systme (par exemple, en ditant une trace de l'excution 014 t l'excutant pas pas). Puis on compare ces interactions relles avec celles du diagrantl d'interaction : si elles ne sont pas identiques, c'est qu'une anomalie a t dtecte.

11.5.2.2 Conception des cas de test systme

La plupart des cas de test vont tester plusieurs classes issues de plusieurs sous-systmes de service (puisque les cas de test sont fonds sur les cas d'utilisation ou sur les ralisations de cas d'utilisation), mais chaque procdure doit, si possible, spcifier le moyen de Icslci les classes provenant d'un seul sous-systme de service. Plusieurs procdures de lest peuvent nanmoins dfinir les conditions de test de tout un sous-systme de service. ( 'Inique 1 n: di test impliquera alors plusieurs procdures de test, ventuellement une pour chiqui IOU systme de service test par le cas de test. L'alignement des procdures de test sur ICK HIIIIN systmes de service facilite la maintenance des procdures. Lorsqu'un soie, l y i t i Il service change, les rpercussions de ce changement sur les procdures de lest i n oui llmlii aux procdures de test utilises pour la vrification de ce sous-syslme 1 le servit 1 lundi qui les autres procdures de test ne subiront aucun impact.

Les tests systme servent vrifier que le systme fonctionne correctement dans so ensemble. Chaque test systme teste principalement des combinaisons de cas d'utilisatio instancis sous diffrentes conditions : i l peut s'agir de diffrentes configurations matrielles (processeurs, mmoire principale, disques durs, etc.), de diffrents niveaux de charge: systme, d'un nombre vari d'acteurs et de diverses tailles de bases de donnes. En mettant au point les cas de test systme, les concepteurs doivent privilgier les combinaisons de cas d'utilisation : devant fonctionner en parallle ; susceptibles d'tre excuts en parallle ; susceptibles de s'influencer les uns les autres s'ils sont excuts en parallle ; impliquant de nombreux processus ; utilisant frquemment les ressources systme telles que les processus, les processeurs, les bases de donnes et les logiciels de communication, ventuellement de faon complexe et imprvisible. On trouvera, par consquent, un grand nombre de cas de test systme en examinant les cas d'utilisation, en particulier leurs flots d'vnements et leurs exigences particulires (comme les exigences de performances).

B U

Procdure de test
Le sous-systme de service Comptes fournit la fonction permettant de procdot il dos mou vements entre comptes. Cette fonction prend part plusieurs ralisations de cas d'utilisation, comme celles des cas d'utilisation R g l e r la facture et Effectuer des virements en t r e comptes. Les modalits de test des mouvements entre comptes seront dfinies pat une procdure de test appele V r i f i e r les virements entre comptes. La procdure spcifie par V r i f i e r les virements entre comptes prend comme paramtres d'entre l'identit de deux comptes et le montant virer, puis valide ce virement en demandant le solde des deux comptes impliqus avant et aprs le virement. Les concepteurs de tests crent huit cas de test pour le cas d'utilisation Rgi er la facture et quatorze pour le cas d'utilisation Effectuer des virements entre comptes. La procdure de test V r i f i e r les virements entre comptes spcifie les conditions d'excution de tous les cas de test (ou d'une partie d'entre eux).

11.5.3 Activit

: implmenter

les tests

11.5.2.3 Conception des cas de test de non-rgression

Certains cas de test issus des constructions prcdentes peuvent servir de tests de nonrgression aux constructions ultrieures, mais pas tous. Pour tre exploitables et contribuer au maintien de la qualit du systme, les cas de test doivent faire preuve d'assez de souplesse pour ragir correctement aux changements affectant le logiciel tester. Comme la souplesse requise par un cas de test de non-rgression peut avoir un cot en terme de dveloppement, i l faut veiller la rentabilit de cette transformation.

L'objectif de l'implmentation des tests est d'automatiser, dans la mesure du possible, les procdures de test en crant des composants de test (toutes les procdures de test ne peuvent pas tre automatises) ; voir la figure 11.12. O n cre des composants de test en utilisant comme entres les procdures de test, dans les conditions dcrites ci-dessous. Lorsqu'on utilise un outil d'automatisation des tests, on excute ou l'on spcifie les actions dcrites par les procdures de test. Ces actions sonl ensuite consignes et Imeni en sortie un composant de test, par exemple un script de test Visual Basic. Lorsqu'on effectue la programmation explicite des composants de lest, ou utilise les procdures de test comme principales spcifications de l'effort de programmation Note/ que cette programmation peut rclamer des comptences assez pointues. Souvent, les composants de test prennent en entre des volumes importants de donner 1 tester et produisent en sortie des volumes comparables de donnes comme rsultais des lests Il est apprciable de disposer d'un mode de visualisation clair et intuitif de ces donnes, 11I111

11.5.2.4 Identification et structuration des procdures de test

Les concepteurs de tests peuvent prendre les cas de test un par un et suggrer des procdures de test pour chacun d'eux. O n essaiera autant que possible de rutiliser des procdures de test existantes ; i l peut donc tre ncessaire de modifier ces procdures afin qu'elles spcifient les conditions d'excution d'un cas de test indit et/ou modifi. Les concepteurs de tests doivent aussi faire en sorte de crer des procdures de test rutilisables avec plusieurs

Les e n c h a n e m e n t s d ' a c t i v i t s principaux PARTIE II CHAPITRE

Test 11

d'tre en mesure de les spcifier correctement c l i r i i i i . i | i i r i n les rsultai utilise cet effet des applications de tableurs et de bases de de ces
Figure 11.12 Entres et rsultat de V implmentation des tests. Cas de test.

di i ,

2. 3. 4.

Comparez les rsultats des tests aux rsultats escompts et examinez les rsultats de tests qui s'loignent de ceux qui taient prvus. Rendez compte des anomalies dtectes l'ingnieur de composants responsable des composants susceptibles de contenir les anomalies en question. Rendez compte des anomalies aux concepteurs de tests, qui les utiliseront ensuite |>"in valuer les rsultats globaux de l'effort gnral de test (comme le dcrit la
section 11.5.6).

CD

Ingnieur de composants

LXJ Procdure de test

Implmenter

->s:
Composant de test

11.5.5 Activit

: effectuer les tests

systme
11.5.1.2)

D ' " "

Modle d'implmentation [construction tester]

L'objectif est de raliser les tests systme (voir la section ration et d'en exprimer les rsultats (voir la figure 1 1 . 1 4 ) .

requis Dtl hiqui Itl

1

Les tests systme peuvent dbuter lorsque les tests d ' i n t g r a t i o n i n d i q u e u i qu. I. systme satisfait aux objectifs de qualit de l'intgration fixs par le plan dei tStS DOUt l'itration en question (par exemple, 9 5 % des cas de tesl d ' i i i i c g i a i i n u sY\o. iiieni . n e . un rsultat prvisible).

11.5.4 Activit

: effectuer les tests

d'intgration

Les tests systme sont mens de faon analogue aux tests d'intgration (voir la section pr cdente).
Figure 11.14 "ntres et s tests rsultat systme. Cas de test

Cette activit permet de raliser les tests d'intgration (voir la section 11.5.2.1) que doit subir chaque construction cre au cours d'une itration (voir la section 10.5.2) et de formuler les rsultats de ces tests (voir la figure 11.13).
Figure 11.13 Entres et rsultat (Us lests d'intgration. Cas de test

C D

Testeur d'intgration

O 7

Testeur systme

o O

Lxj Procdure de test Anomalie s* Effectuer les tests systme

Lxj Procdure de test

| #*
yl

Composant de test

Effectuer les tests d'intgration

Anomalie

>x

Composant de test

Modle d'implmentation [construction tester]

Modle d'implmentation [construction tester]

Les tests d'intgration sont effectus selon la squence dcrite ci-dessous. 1. Effectuez les tests d'intgration pertinents pour la construction en excutant manuellement les procdures de test pour chaque cas de test ou en excutant tous les composants de test qui automatisent ces procdures.

Les enchanements d'activits principaux

PARTIE II CHAPITRE

Test
11

11.5.6 Activit

: valuer

les tests

L'objectif de cette activit est d'valuer les lests mens an sein I une iiciation (von figure 11.15).
Figure 11.15
Entres de et rsultat l'valuation. Test Plan

l'assouplissement des critres d'valuation des tests, si les objectifs de qualit ont plac la barre trop haut pour l'itration en cours ; l'isolement des parties du systme qui semblent prsenter un niveau de qualit acceptable et leur prsentation comme rsultat de l'itration en cours. Les parties ne rpondant pas aux critres de qualit doivent tre rvises et testes de nouveau. Les concepteurs de tests documentent la compltude et la fiabilit des tests, ainsi que tel actions suggres, dans une description de l'valuation des tests.

Test Engineer

11.6
Test Model Evaluate Test Test Evaluation [for an itration]

Rsum des tests

Le principal rsultat des tests est le modle des tests, qui dcril la manire dotll N systme. Ce modle contient les lments suivants : les cas de test, qui spcifient ce qui doit tre test dans le systme ; Il

X
Defect

les procdures de test, qui spcifient la faon d'excuter ces cas de lesl . les composants de test, qui automatisent les procdures de
lest

Les concepteurs de tests valuent les rsultats des tests en comparant ces rsultats aux objectifs fixs dans le plan des tests. Ils prparent galement les mtriques leur permettant de dterminer le niveau de qualit du logiciel et les tests restant effectuer. Le concepteur de tests doit examiner en particulier deux mtriques :

Les tests se traduisent galement par un plan des tests, des valuations des teitl e l l e , tut I des anomalies susceptibles de nourrir les autres enchanements d'activits prlm Ipaux, tell que ceux de conception et d'implmentation.

11.7

Rfrences
1 2 3 IEEE Std 610.12. 1990. Bill H E T Z E L , The Complte Guide to Software Testing, deuxime dition, Wellesley, MA, QED Information Sciences, Inc., 1988. Robert V. BlNDER, Developing a test budget , Object Magazine, 7(4), juin 1997.

la compltude des tests, drive du degr de couverture des cas de test et de celui des composants tests. Cette mtrique indique le pourcentage des cas de test excut et le pourcentage de code test ; la fiabilit, reposant sur l'analyse des tendances se dgageant des anomalies dtectes et des tests s'excutant avec un rsultat prvisible. Pour dterminer la fiabilit du systme, les concepteurs de tests crent des diagrammes de tendances gnrales des anomalies illustrant la rpartition des types spcifiques d'anomalies (tels que les anomalies indites ou fatales). Ils peuvent galement laborer des diagrammes de tendances indiquant le ratio de tests excuts avec russite (c'est--dire les excutions de test gnrant les rsultats escompts). Les tendances gnrales des anomalies sont souvent similaires d'un projet l'autre. Par exemple, le nombre d'anomalies nouvelles surgissant lorsqu'un systme subit des tests augmente en gnral assez rapidement au dbut des tests, puis se stabilise au bout d'un certain temps, pour finir par s'inflchir progressivement. En comparant la tendance observe celles issues de projets antrieurs, i l est possible de prvoir l'effort ncessaire pour atteindre un niveau de qualit satisfaisant. partir de l'analyse de ces tendances, les concepteurs de tests peuvent suggrer un certain nombre d'actions : l'excution de tests supplmentaires pour localiser un plus grand nombre d'anomalies, si la mesure de fiabilit laisse penser que le systme n'est pas encore prt ;

artie III Un dveloppement itratif et incrmental

Un systme logiciel passe par un certain nombre de eyt les de dV( lop pement pendant sa dure de vie. Chacun de ces cycles donne lieu ,i un. nouvelle version du produit livre des clients cl utilisateurs et donl la premire risque d'tre la plus dlicate laborer. Cette premire version pose, en effet, les fondations du systme, c'est--dire son architecture. Elle explore un nouveau territoire, susceptible d'entraner des risques graves. Un cycle de dveloppement prsente donc un contenu diffrent selon le stade du cycle de vie global auquel est parvenu le systme. Dans les versions plus tardives, un changement spectaculaire de l'architecture peut signifier un travail supplmentaire dans les premires phases. Dans la plupart de ces versions tardives, toutefois, si l'architecture d'origine peut tre toffe, le nouveau projet ne fera que s'ajouter ce qui existe dj. En d'autres termes, une version tardive du produit sera construite au-dessus de la version prcdente. L'ide qu'il vaut mieux traiter les problmes ds le dbut de chaque cycle de dveloppement, et non la fin, commence faire son chemin On applique le terme d'itration aux squences de rsolution des pro blmes dans les phases de cration et d'laboration, ainsi qu' chaque srie de constructions de la phase de construction.

I I . C I H I

I I

Les risques ne se prsentent pas dans un emballai'.' sophistiqui accompagn d'une carte de visite glisse sous un j o l i rose feu! les identifier, les dlimiter, les surveiller et les rduite. El il VBUl mit s'attaquer en premier aux risques les plus graves. De mme, l'ordrt dans lequel s'ajoutent les itrations doit tre soigneusement reflet ni, afin que les problmes les plus importants soient rsolus en picnuei En bref, faites d'abord le sale boulot.
U

La deuxime punie de l'ouvrage .1 )> ill . liai un l e s enelianem d'activits sparment. I.a ligure 0 .' moiiliail. pat exemple, l'attend, accorde l'enchancmenl d'activits des hcsoms a liavcis les difTdJ rentes phases, tout comme la ligure 8.2 le laisatt poin l'analyse la figure 9.2 pour la conception, la ligure 10.2 pont l'implciui-maiion et | figure 11.2 pour les tests.
a

Nous allons, dans cette troisime partie, expliquei les diverses associations possibles de ces enchanements d'activits, selon le stade du cycle de vie auquel on se trouve. Le chapitre 12 dcrit, .l'abord, | points communs toutes les phases, c'est--dire ce qui traverse toutes les phases, comme la planification d'une itration et la dfinition de critres d'valuation pour cette itration, l'tablissement d'une liste de risques, l'affectation d'un ordre de priorit aux cas d'utilisation et l'valuation des itrations. Les chapitres suivants s'attardent ensuite sur chaque phase.
e s

12
Enchanement d'activits de l'itration gnrique
Nous revenons, dans ce chapitre, sur la notion d'itration gnrique, aborde dans le chapitre 5. Le propos de ce chapitre est de dgager le modle commun qui caractrise les itrations des quatre phases, malgr leur apparente diversit. Ce modle gnrique sert de pivot la mise au point des itrations concrtes, dont le contenu change pour reflter les objectifs spcifiques de chaque phase (voir la figure 12.1).
Figure 12.1
L'enchanement d'activits l'itration gnrique de dcrire enchanements d'activits itrations pour chaque des concrtes phase. permet les de comprend : la planification des itrations les enchanements d'activits principaux l'valuation des itrations

Dans la phase de cration (chapitre 13), l'activit se concentre sur le premier enchanement d'activits, celui des besoins, et ne porte que peu d'attention aux deuxime et troisime enchanements (ceux d'analyse et de conception). Cette phase ne s'aventure que trs rarement dans les deux derniers enchanements d'activits : ceux d'implmentation et de tests. Dans la phase d'laboration (chapitre 14), alors que l'activit s'appesantit encore sur la finalisation des besoins, les enchanements d'analyse et de conception se voient accorder plus d'attention, puisqu'ils sous-tendent la cration de l'architecture. Pour obtenir une architecture de rfrence excutable, i l faut aussi qu'une partie de l'activit soit consacre aux enchanements d'activit d'implmentation et de tests. Dans la phase de construction (chapitre 15), l'enchanement d'activits des besoins s'amenuise considrablement, l'analyse s'allge, tandis que les trois autres enchanements d'activits mobilisent l'essentiel de l'attention.

Enfin, dans la phase de transition (chapitre 16), l'importance respective des enchanements d'activits dpend des retours des tests d'acceptation ou des bta tests. Par exemple, si les bta tests dvoilent des anomalies dans l'implmentation, une grande partie de l'activit sera consacre l'amhoration des enchanements d'activits d'implmentation et de tests. Le dernier chapitre, le chapitre 17, revient au thme central du livre. E nous suffit d'un chapitre pour montrer comment divers cheveaux (enchanements d'activits, phases, itrations) finissent par tisser un processus adapt au dveloppement de logiciels stratgiques. Ce chapitre consacre galement quelques paragraphes la gestion de ces relations et la transition au Processus unifi.

1
L'enchanement d'activits de l'itration gnrique se compose de cinq en, li. principaux: besoins, analyse, conception, implmentation et tcsls, auxquels l'ajOUMM II planification, qui les prcde, et l'valuation, qui les suit (les chapitres 6 1 I I de. 1 n . n i ipa rment chaque enchanement d'activits principal). Dans ce chapitre, n o n . ail.il nou pencher sur la planification, sur l'valuation et sur les autres activits communes I (OUI II enchanements d'activits.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

E n c h a n e m e n t d ' a c t i v i t s de l ' i t r a t i o n g n r i q u e
CHAPITRE 12

la planification et la gestion du projet ; l'tablissement et la gestion de l'environnement de dveloppement, c'est--dire processus et des outils ; le dploiement d'un produit sur un site client ; la prise en compte des retours des utilisateurs.
tics

La planification est indispensable tout au long du cy< le de dveloppement Mali poui af nifier, encore faut-il savoir ce qu'il y a faire... I.es cinq cm hainemcnls d'activits prin cipaux fournissent un point de dpart. La gestion des risques, c'est B due leui identification et leur rduction par la ralisation de l'ensemble de cas d'ulilisaiiou c orrespondants, est un autre aspect fondamental de la planification. Bien sr, aucun plan ne saurait tre < oinp| | sans l'estimation des ressources ncessaires. Enfin, l'excution de chaque itration et dechaque phase doit absolument tre value.
e

12.1 Le besoin d'quilibre

12.2 Les phases constituent la premire division du travail

a i
1

Chaque moment du cycle de vie d'un projet de dveloppement logiciel est marqu par la simultanit de plusieurs squences d'activits. On travaille la mise en place de nouvelles fonctions, on chafaude l'architecture, on reoit les retours des utilisateurs, on rduit les risques, on prvoit la suite, etc. I l faut, tout moment, quilibrer et synchroniser ces diffrentes squences d'activits pour en dominer la complexit. Les dveloppeurs divisent le travail, bien trop complexe dans sa globalit, en portions plus facilement comprhensibles. Sur l'ensemble du cycle de vie du dveloppement, la tche est ainsi rpartie en phases et, au sein de ces phases, en itrations, comme l'indique la deuxime partie du prsent ouvrage.

Le premier pas vers la division du processus de dveloppement l o r i c i c l , on a .n chronologiquement en quatre phases : cration, laboration, construction Bl trini phase est ensuite divise en une ou plusieurs itrations. Ce chapitre esquisse In un de ces phases et itrations, abordes en dtail dans les quatre chapitrai luivantl

r Ituqtn nl<

12.2.1 La phase de cration

tablit

la

faisabilit

Le premier objectif de cette phase est de procder l'tude de rentabilit : le projet vaut il la peine d'tre entrepris ? Cette tude s'enrichira d'informations complmentaires dans la phase d'laboration. La phase de cration ne propose pas une tude complte du systme envisag. Elle ne vise qu' dgager le faible pourcentage de cas d'utilisation qui prendront en charge l'tude initiale. La cration de cette tude s'articule autour de quatre tapes, dcrites ci-dessous. 1. Dlimitez la porte du systme propos : dfinissez les frontires du systme et commencez identifier les interfaces avec d'autres systmes situs au-del de ces frontires. Dcrivez et esquissez l'architecture candidate du systme, en particulier les parties indites, risques ou complexes du systme. Cette tape s'arrte gnralement la description de l'architecture et cre rarement un prototype excutable. La description de l'architecture se compose des premires vues approximatives des modles. L'objectif est ici d'affirmer la crdibilit de la mise au point, dans la phase suivante, d'une architecture stable du systme envisag. I l n'est pas question de construire l'architecture dans cette phase ; le but est simplement de montrer qu'elle est ralisable. Sa construction reprsente le rsultat principal de la phase d'laboration.

Au sein de chacune de ces itrations, l'quipe du projet cherche trouver un quilibre entre les diverses squences d'activits. I l s'agit donc de se concentrer sur les points essentiels de chaque itration. Or, ces points essentiels varient en fonction du stade du cycle de vie auquel on est parvenu : i l faut donc les slectionner et y consacrer la majeure partie des efforts. Tout en quilibrant ces squences d'activits, i l faut galement s'assurer qu'elles sont d'importance comparable, afin de pouvoir les hirarchiser et les synchroniser avec efficacit. I l semble que l'impossibilit d'atteindre un tel quilibre et une excution efficace soit l'origine de l'chec de plus d'un cycle de vie de dveloppement itratif et incrmental. Les premires itrations traitent avant tout des risques majeurs, des cas d'utilisation essentiels, des problmes d'architecture, du choix de l'environnement de dveloppement, de toutes les activits ncessitant des recherches, tandis que les itrations plus tardives s'attachent aux activits de dveloppement, aux problmes d'implmentation, de tests, d'valuation des performances et au dploiement du systme. L'association harmonieuse et quilibre de toutes ces activits est une tche dlicate. C'est prcisment ce qui explique l'incroyable complexit du dveloppement logiciel. Comprendre et quilibrer ces diverses squences d'activits : voil bien l'objet de chaque itration. Certaines de ces squences d'activits ont t identifies dans le Processus unifi et dcrites en tant qu'enchanements d'activits principaux. I l existe d'autres squences qui, bien que n'ayant pas t formellement identifies, pourraient tre abordes d'une faon similaire. Par exemple : l'interaction avec les clients propos de nouveaux besoins et exigences ; la prparation d'une offre destine des clients ; la comprhension du contexte d'un systme par l'laboration d'un modle du mtier ;

2.

3. Identifiez les risques les plus srieux, ceux qui affectent la capacit construire le systme, et voyez si l'on peut envisager un moyen de les rduire, ventuellement dans une phase ultrieure. On ne considre, dans cette phase, que les risques concernant II faisabilit, ceux qui compromettent la russite du projet. Tout risque non critique identifi ce moment-l doit tre plac sur la liste des risques pour tre es; e dans la phase suivante. 4. Dmontrez aux clients et aux utilisateurs potentiels que le systme propose est en mesure de rsoudre leurs problmes ou de prendre en charge leurs objecti 11 professionnels en construisant un prototype de mise l'preuve du concept I >ans la

mmm Un d v e l o p p e m e n t
mm PARTIE III

itratif et

incrmental

E n c h a n e m e n t d ' a c t i v i t s de l ' i t r a t i o n g n r i q u e
CHAPITRE 12

4.

Ils formulent les cas d'utilisation permettant de couvrir environ 80 % des besoins fonctionnels et de planifier la phase de construction. (Nous expliquerons plus loin dans ce chapitre ce que nous entendons par ces 80 %.) Ils laborent une offre abordant les questions de calendrier, de personnel et de budget dans les limites fixes par les pratiques du mtier. i

5.

phase de cration, on peut construire un prototype nom apporter la preuve que la solution rpond au problme des clients et des futurs utilisateurs ( le p ype lait la dmonstration des ides matresses du nouveau systme, en s'allac haut pailiculici ement son utilisation : les interfaces utilisateur et/ou quelques nouveaux algorithmes intressants. Il marque une tendance l'exploration, dans le sens ou il dmontre une solution possible mais qui ne sera pas forcment celle retenue dans le produit final. Il s'agit, la plupart du temps, d'un prototype jetable , par opposition au prototype architectural, mis au point dans la phase d'laboration et gnralement volutif, c'est-dire susceptible d'tre amlior dans la phase suivante. Ces efforts se poursuivent jusqu'au point o il apparat rentable de dvelopper le produit. On montre ainsi que le systme produira, dans des limites assez larges, un revenu ou un autre type de valeur proportionnel l'investissement ncessaire sa construction. En d'autres termes, la premire bauche de l'tude de rentabilit est acheve. Elle se prcisera dans la phase suivante, l'laboration. L'objectif est de rduire le plus possible le budget et les dlais consacrs cette phase pour arriver la conclusion que le systme est rellement faisable. Dans le cas d'un systme largement indit dans un domaine peu explor, cette recherche peut mobiliser des dlais et des efforts considrables et s'tendre sur plusieurs itrations. En revanche, si les risques et les inconnues concernant un systme courant dans un domaine tabli, ou l'extension d'un systme existant, sont minimes, la ralisation de cette premire phase peut durer quelques jours seulement.

Les besoins et l'architecture (en analyse, conception et implmentation) repiesc l'essentiel du travail des phases de cration et d'laboration.

12.2.3 La phase de construction

construit le

systme

L'objectif gnral de la phase de construction est tout entier conlenu dan p pal jalon : la capacit oprationnelle initiale. I l s'agit de livrer un produit prt n s u l n i l I i i < tests. Cette phase emploie plus de personnel et pendanl plus longtemps .in, u ioii< laquelle des autres phases. C'est pourquoi il est fondamental que toutes les .pi, d'importance soient tout fait claircies avant de s'y engager. I Ile c o m p o i i e l'cncialc un ni un nombre d'itrations suprieur ceux des phases prcdentes. Il semble que, dans bien des cas, la construction dure trop longtemps en raison d'une miU vaise prparation des besoins, de l'analyse et de la conception. Les dveloppeurs sont donc obligs de bricoler dans leur coin et mettent plus longtemps satisfaire aux besoins et liminer les anomalies (bogues). L'un des grands avantages que prsentent les approches de l'ingnierie logicielle qui s'appuient sur un dveloppement itratif, incrmental, phases multiples est d'quilibrer l'affectation des ressources et des dlais tout au long du cycle de vie (voir la section 12.1). La phase de construction comprend les activits suivantes : 1. 2. Extension de l'identification, de la description et de la ralisation des cas d'utilisation l'ensemble des cas d'utilisation. Finalisation de l'analyse (il peut rester analyser plus de la moiti des cas d'utilisation au dbut de la phase de construction), de la conception, de l'implmentation et des tests (il peut en rester 90 % effectuer). Prservation de l'intgrit de l'architecture (modification si ncessaire). Surveillance des risques critiques et significatifs identifis dans les deux premires phases et, en cas de matrialisation, rduction de ces risques.

12.2.2 La phase d'laboration de ralisation

s'intresse

la

capacit

La phase d'laboration livre comme principal rsultat une architecture stable, qui guidera le systme tout au long de sa future vie. Cette phase pousse galement l'tude du systme propos jusqu' une planification trs fidle de la phase de construction. Pour satisfaire ces deux objectifs gnraux - l'architecture et l'estimation fidle des cots - , les membres de l'quipe effectuent les tches numres ci-dessous. 1.

3. 4.

Ils crent une architecture de rfrence couvrant toutes les fonctions du systme significatives sur le plan architectural et les caractristiques importantes pour les intervenants, comme le dcrit le chapitre 4. Cette architecture de rfrence se compose des artefacts des modles, de la description de l'architecture et de l'implmentation excutable. Elle ne dmontre pas seulement la possibilit de construire une architecture stable, mais englobe toute l'architecture. Ils identifient les risques les plus significatifs, ceux qui sont de nature bouleverser le plan, le cot et le calendrier des phases suivantes, et les rduit des activits dont les dlais et les budgets peuvent tre estims. Ils dfinissent les niveaux de qualit atteindre, par exemple en termes de fiabilit (taux d'anomalies) et de temps de rponse.

12.2.4 La phase de transition aborde l'environnement

utilisateur

2.

3.

La phase de transition commence souvent par la version bta : la socit de devcloppcmcnl distribue le produit logiciel, alors capable d'un fonctionnement initial, un chantillon d i n i lisateurs rels reprsentatif. Le fonctionnement dans le contexte plus ardu des soi ltl lltill satrices reprsente souvent une preuve bien plus difficile pour l'tal de devcloppcmcnl icel du produit que son utilisation dans le royaume protg des dveloppeurs. La transition comprend les activits suivantes : prparation des activits, comme la prparation des sites ;

Un d v e l o p p e m e n t i t r a t i f et i n c r m e n t a l PARTIE III

E n c h a n e m e n t d ' a c t i v i t s de l ' i t r a t i o n g n r i q u e CHAPITRE figure 12.2 ^ Besoins ^ ^ Analyse ^ ^ Conception ^ ^ Implmentation^ ^ 12

recommandations au client sur la mise jour de rcnvimiinciucnl (matriel, systmes d'exploitation, protocoles de communication, etc.) destin a atrueillii le logiciel , laboration des manuels et de la documentation concernant la version du produit I a phase de construction aura vu la mise au point d'une premire documentation pour les utilisateurs de la version bta ; adaptation du logiciel afin qu'il puisse fonctionner avec les paramtres rels de l'environnement utilisateur ; correction des anomalies dtectes aprs les retours des testeurs de la version bta ; modification du logiciel la lueur des problmes qui n'avaient pas t prvus. La phase de transition s'achve par la livraison d'une version formelle du produit. Toutefois, avant que les membre de l'quipe ne vaquent d'autres occupations, les chefs de projet organisent une runion post mortem destine : dgager les leons du projet, en dbattre, les valuer et les consigner comme rfrence pour l'avenir ; consigner les questions d'utilisation dans la version ou la gnration suivante.

Les cinq enchanements \ se i rptent dans chaque itration, prcds par la planification et suivis de l'valuation.

i Itration gnrique

Comprend on pltn (Kl plnnllliaitlmi ai n, ru.ilu M 11. ,

12.3.2 Les travailleurs prennent part aux d'activits

enchanements

12.3

L'itration gnrique revisite

Nous faisons une distinction entre enchanements d'activits principaux et enchanements d'activits d'itration. Les premiers - les enchanements d'activits des besoins, d'analyse, de conception, d'implmentation et de tests - font l'objet des chapitres 6 11. Dans le Processus unifi, ces enchanements d'activits ne se produisent pas une seule fois, comme c'est thoriquement le cas dans le modle en cascade, mais ils reviennent chaque itration, comme enchanements d'activits de l'itration. Cependant, chaque fois, les dtails en sont diffrents : ils traitent les questions centrales chaque itration.

Nous avons parfois voqu le dveloppement logiciel comme tani complexe I a figure 12.3 propose une vision d'ensemble simplifie de ce processus. Mme dans celle optique, la figure est loin d'tre simple, et la ralit, comme vous le savez, est encore plus complique. Dans ce chapitre, nous n'allons pas dtailler la faon dont chaque travailleur produit les artefacts dont i l est responsable, ni dcrire la nature mme de chaque artefact. Les engrenages de la figure 12.3 symbolisent ce travail, tandis que les flches reliant les activits reprsentent les relations temporelles (pour plus de dtails, voir les chapitres 6 11).

12.3.1 Les enchanements chaque itration

d'activits

principaux se

rptent

Les enchanements d'activits principaux, qui englobent les travailleurs et les activits qu'ils excutent, sont reprsents par les cercles tracs la main. L'ingnieur de composants, par exemple, analyse une classe et un paquetage dans l'enchanement d'activits d'analyse, conoit une classe et un sous-systme dans l'enchanement d'activits de conception, implmente une classe et un sous-systme et effectue des tests unitaires dans l'enchanement d'activits d'implmentation. Malgr cette simplification, la figure 12.3 donne une ide de ce qui relve d'une itration. Par exemple, en partant du coin suprieur gauche, un analyste systme identifie les cas d'utilisation et les acteurs, et les structure au sein d'un modle de cas d'utilisation. Puis un spcificateur de cas d'utilisation vient dtailler chacun de ces cas d'utilisation, tandis qu'un concepteur de cas d'utilisation prototype les interfaces utilisateur. Enfin, l'architecte dfinit l'ordre de priorit des cas d'utilisation dvelopper dans une itration en prenant en consi dration les risques impliqus.

L'itration gnrique comprend les cinq enchanements d'activits principaux (besoins, analyse, conception, implmentation et tests), auxquels s'ajoutent la planification et l'valuation (voir la figure 12.2). Alors que les sections 12.4 12.7 traitent de la planification prcdant l'itration, la section 12.8 aborde l'valuation de chaque itration et les chapitres 13 16 voquent ensuite en dtail la faon dont les cinq enchanements d'activits s'appliquent chaque phase.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

E n c h a n e m e n t d ' a c t i v i t s de l ' i t r a t i o n g n r i q u e
CHAPITRE 12

Dans les chapitres suivants, la figure 12.3 est complte par les lments ncessaires la reprsentation des enchanements d'activits de chaque phase, qui suivent tous le modle de cette figure gnrique. L'attention se portant sur diffrents aspects selon les phases, les enchanements d'activits des itrations correspondantes varient en degr.

12.4 La planification prcde l'action

Quand nous nous trouvons au dbut de la phase de cration, nous savons au moiltl choses : nous allons mener le projet bien par une srie d'itrations se dploj Ull lui QUBtrt phases ; nous disposons des informations concernant le systme propos q u i nos prdcesseurs (et qui ont conduit au lancement d'un projet) ;
o u i ei.

ni

ueillu

pai

nous disposons de nos propres sources d'informations sur le domaine el Ut di comparables auxquels nous avons pu collaborer dans le pass. Il s'agit, partir de ces informations, de planifier la fois le projet ( p l a n d u projet i et chaqui itration (plan d'itration). Au dbut, les informations tant limites, ces d e u x plaie, c o u tiennent peu de dtails, mais ils s'enrichissent progressivement, mesure que l'on avam e dans les phases de cration et d'laboration. Nous allons d'abord expliquer la planification des phases et des itrations et le moyen d'valuer chaque itration. Puis les sections 12.5 et 12.6 voqueront respectivement l'impact des risques sur ce plan et le moyen de rduire ces risques en slectionnant les cas d'utilisation adquats. Enfin, l'affectation des ressources sera traite dans la section 12.7.
Figure 12.3
Les titres des travailleurs avance de gauche sont recenss droite. verticalement gauche et droite et identifient chaque trave . Le temps

12.4.1 Planifier les quatre

phases

Nous savons, d'aprs les prescriptions du Processus unifi, ce qu'implique chaque phase. Dans le plan du projet, notre tche consiste traduire ces prescriptions en actions concrtes. Affectation des dlais. I l s'agit de dfinir les dlais attribus chaque phase et de fixer chacune d'elles une date d'achvement. Bien que dtermins avec prcision, ces dlais peuvent rester quelque peu incertains au dbut de la phase de cration, mais ils doivent s'affermir grce aux informations accumules. Aprs tout, nous ne sommes pas tenus de faire une offre dfinitive avant la fin de la phase d'laboration. Jalons majeurs. Une phase s'achve lorsque les critres dfinis au pralable sont a l l a n t s Si ces critres peuvent, au dbut, s'apparenter des devinettes savantes, ils se m u n i r . m toutefois de notre exprience antrieure dans le domaine (jusqu'au point o le .\u envisag se dmarque des prcdents), des spcifications de performance! q u i a i r u . , atteindre le systme et des capacits de nos quipes de dveloppement logil le! Itrations par phase. Au cours de chaque phase, le travail progresse a travail O U plusieurs itrations. Le caractre gnral de chaque itration transparat dan I. plu encore approximatif du projet.

Vous pouvez constater que les activits excutes dans le cercle des exigences varieront en fonction de l'emplacement de l'itration par rapport au processus de dveloppement dans son ensemble. Dans la phase de cration, par exemple, les travailleurs limitent la description dtaille des cas d'utilisation et l'attribution d'un ordre de priorit la stricte proportion de cas d'utilisation ncessaire cette phase. Les quatre premiers enchanements d'activits se suivent peu prs chronologiquement, mme s'il peut y avoir des chevauchements. Les trois travailleurs impliqus dans l'enchanement d'activits d'analyse conduisent le projet jusqu' la conception. Nanmoins, l'enchanement d'activits des tests commence trs tt, avec la planification, par l'ingnieur de tests, de ce qui doit tre fait. Ds qu'on dispose de suffisamment d'informations, l'ingnieur de tests conoit les tests dans l'enchanement d'activits d'implmentation. Au fur et mesure de l'intgration des composants ayant subi les tests unitaires, le testeur systme et le testeur d'intgration peuvent tester les rsultats de plusieurs niveaux d'intgration. L'ingnieur de tests value ensuite si les tests prescrits par ses soins se sont rvls adapts.

Un d v e l o p p e m e n t i t r a t i f et i n c r m e n t a l
mm PARTIEI

E n c h a n e m e n t d ' a c t i v i t s de l ' i t r a t i o n g n r i q u e
CHAPITRE 12

m
WM

Plan du projet. Le plan du projet trace les grandes lignes d'un plan de roule abordant le calendrier, les dates et les critres des jalons majeurs, ci enfin II dcomposition des phases en itrations.

p 'notai

r l

Jalons mineurs (annexe C). La satisfaction des critres pralablement dfinis (de prfrence la date prvue) indique l'achvement de chaque itration. Plan d'itration (annexe C). Les activits de chaque itration sont consignes dans un plan prcis de l'itration. Les personnes devant agir en tant que travailleurs sont affectes au dbut de chaque itration.

On peut s'attendre rencontrer quelques difficults dans la premire ilcralion de la phase de cration. Outre l'itration elle-mme, i l faut traiter les aspects numrs ci-dessous. Personnaliser le Processus unifi pour l'adapter au projet et slectionner les outils permettant d'automatiser le processus. Commencer runir les personnes possdant les comptences requises par le projet. tablir des relations permettant de former une quipe vraiment efficace. Comprendre le domaine, souvent inconnu pour l'quipe. Percevoir la nature du projet, tche qui sera plus dlicate dans le cas d'un projet tout neuf (green-field project) que dans celui de l'extension d'un produit existant en vue d'en crer la gnration suivante. Familiariser l'quipe avec les outils adapts au processus personnalis et au projet.

Le nombre d'itrations prvu pour chaque phase varie, essentiellement en fonction de II complexit du systme envisag. Un projet extrmement simple pourra clic M I C I H a I avec une seule itration par phase, alors qu'un projet plus complexe en exigci a lop.iqm nu m un nombre suprieur. Par exemple : Phase de cration (annexe C) : une itration, essentiellement consacre il lu di I de la porte du systme. Phase d'laboration (annexe C) : deux itrations ; la premire effccluein passe sur l'architecture et la seconde aboutira l'architecture de rfrent e Phase de construction (annexe C) : deux itrations, afin de s'assura qui II qui en rsultent fonctionnent de faon satisfaisante. Phase de transition (annexe C) : une itration. On peut s'attendre, avec l'accroissement et la complexificalion progressives du projet cl le surgissement de nouvelles questions, ce que la taille des quipes de devcloppcmcnl augmente. Il y aura plus d'itrations et la dure de chacune variera, selon la taille du systme, d'une semaine environ trois mois. i li n n '

12.4.2 Planifier les

itrations

Chaque phase consiste en une ou plusieurs itrations. La planification des itrations passe par un srie d'tapes assez comparables celles qui permettent de planifier les phases. Calendrier des itrations. I l s'agit de dfinir les dlais attribus chaque itration et de fixer chacune d'elles une date d'achvement, d'abord approximative, puis de plus en plus prcise grce l'accumulation des informations. Contenu des itrations. Alors que le plan du projet esquisse les itrations prvues en termes gnraux, la planification de l'objet de chaque itration gagne en prcision mesure qu'approche la date de dbut d'une itration. Le contenu d'une itration se dgage des points suivants : - Quels sont les cas d'utilisation que doit remplir, au moins partiellement, l'itration ? - Quels sont les risques techniques qu'il est temps d'identifier, de traduire sous forme de cas d'utilisation et de rduire ? - Tous les changements de besoins ou les anomalies ayant pu tre corriges doivent tre pris en compte. - Quels sont les sous-systmes qui doivent tre, partiellement ou compltement, implments ? (Ce point varie en fonction de la phase examine. La phase d'laboration identifie la plupart des sous-systmes et toutes les classes significatives sur le plan architectural, alors que la phase de construction toffe le comportement des sous-systmes, ce qui donne lieu des composants plus complets.)

12.4.3 Penser long terme

La longue priode pendant laquelle le systme est susceptible de durer peut tre tmoin de changements radicaux : l'mergence de nouvelles technologies, de nouvelles interfaces avec l'environnement du systme ou des plates-formes volues. Par ailleurs, les planificateurs doivent examiner les ventuels besoins d'adaptation du mtier d'autres organisations, telles que des filiales ou des partenaires de fusion. Inutile, toutefois, de spculer jusqu' l'absurdit sur l'avenir. Certes, personne n'imagine de construire une architecture systme rigide en sachant pertinemment qu'elle devra tre modifie l'avenir ; mais ce n'est pas non plus la peine de doter le systme d'une flexibilit inutile qui ne servira jamais rien.

12.4.4 Planifier les critres

d'valuation

Les itrations sont courtes par rapport aux projets traditionnels. Pour viter qu'elles ne se prolongent indfiniment, les chefs de projet doivent, en plus de fixer un calendrier, esquissa les objectifs cls de chaque itration. Pour la satisfaction de ces objectifs, ils tabllstenl d e s critres indiquant le degr de ralisation de l'itration. Ces critres, tels que la i .u.u n i e . tique minimale dfinie un point donn, mobilisent l'attention sur l'itration en qui Itiotl I facilitent son achvement en temps et en heure. Voici quelques exemples de ces ci
1

Le plan de l'itration en cours est intgralement dtaill, tandis que celui des itrations suivantes se prcise la lueur des informations rcoltes. Le dtail des itrations suivantes peut se limiter aux connaissances alors disponibles :

besoins fonctionnels, exprims sous forme de cas d'utilisation ; exigences non fonctionnelles, associes aux cas d'utilisation qu'elles
e o n c c i lient

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

E n c h a n e m e n t d ' a c t i v i t s de l ' i t r a t i o n g n r i q u e
CHAPITRE 12

exigences non fonctionnelles, non spcifiques a un i as d'ulile.al des exigences supplmentaires comme le dcrit la scciiou (> /

eccnies dani

1 5 Les risques affectent la planification du projet

L'un des objectifs d'une itration du dbut peul consister, pm exemple, a levei toute* ambiguts de la formulation des besoins par le client. Ce type de critre pri ise ce que planificateurs attendent de cette itration en termes mesurables, ci ic le niveau de pei mances, ou observables, comme l'ajout d'une fonction souhaite. Le responsable du projet dfinit l'avance des critres d'valuation pour chaque itration c i l pour la phase elle-mme. Chacune doit se terminer par un point d'achvement parfaitement clair, qui permettra aux dveloppeurs de s'apercevoir que leur tche est termine Ces p^mu i d'achvement constituent en outre des jalons qui permettront aux responsables d'apprci! la progression du travail. En gros, les critres d'valuation se rpartissent en deux catgories : les exigences vrifiables et les critres plus gnraux.

La manire dont on planifie le dveloppement d'un nouveau systme est, dans une des largi mesure, influence par les risques entrevus. L'une des premires tapes, au tout dbut de la phase de cration, consiste donc tablir la liste des risques. Dans un premier temps, s'il est possible que le manque d'informations soit une entrave, on aura sans doute quelque uni malgr tout, de la nature des risques critiques, c'est--dire de ceux qui dle m a t, systme pourra tre construit ou non. Puis, mesure qu'avancera le travail daie. I. mires phases, on en viendra estimer ce que seront les risques sif.nilicatils c est a d m ceux qui doivent tre rduits afin d'tablir un calendrier et un budget cl il nlli mdi objectif de qualit.

i2.5-1 Grer

une liste des

risques

C'est une chose de savoir vaguement que le dveloppement logiciel implique di nsqui C'en est une autre de les rendre visibles, de s'en servir comme guides ei il ne .n . quence. C'est l tout le propos de la liste des risques. Il ne s'agit pas, evidemini ul d un document banal destin dormir au fond d'un tiroir ou dans un dossier inli atique In \e vous devez savoir sur un risque pour pouvoir le traiter, y compris son identifiant que. figure sur cette liste. Vous y trouverez les lments ci-dessous :
Mm

Description : commencez par une brve description, que vous enrichirez progressivement. Priorit : affectez-lui une priorit, en commenant par critique, significatif ou courant. L'allongement de la liste vous amnera sans doute crer d'autres catgories.

Bf
Impact : quelles sont les parties du projet ou du systme qui seront touches par ce risque ? Responsable : qui est charg de garder la trace d'un risque continu ? Moyens mettre en uvre : que faut-il faire si le risque se matrialise ? Sur un projet de taille respectable, i l est possible que l'on finisse par recenser des centaines de risques. Dans des projets de grande envergure, il faudra sans doute placer ces risques dans une base de donnes, afin d'en faciliter le tri et la recherche. L'quipe ne peut s'attarder sur tout la fois. C'est d'ailleurs l'une des raisons de l'adoption d'un dveloppement itratif. Les risques sont tris par degr de gravit ou en fonction de leur effet sur le dveloppement, et traits dans l'ordre. Comme nous l'avons dj rpt haut et fort, les risques traiter en premier sont ceux qui sont susceptibles de provoquer l'chec du projet. Certains risques ne se prtent pas une rsolution simple et demeurent longtemps sur la liste des risques, Il peut tre utile, comme le pratiquent certaines entits de dveloppement, de placei en tte de liste le palmars des dix risques les plus graves afin d'y consacrer toute l'attention iicessauc La liste des risques n'est pas un instrument statique. Elle s'toffe avec la dcouvcile de non veaux risques et s'allge mesure qu'en sont limins d'autres ou que l'on ilepassi li i. i du dveloppement auquel un risque particulier est susceptible de se concrtisa I 1 o 1 sable du projet organise des runions rgulires, souvent en parallle avec les valuai des itrations, pour revoir l'tat des risques majeurs, tandis que d'autres r e s p o n s a l i animent les runions concernant les risques moins srieux.

Comme le dcrit en dtail le chapitre 11, les ingnieurs de tests participent au dvelop-j pement ds la phase de cration. Ils dterminent les caractristiques des cas d'utilisation susceptibles d'tre confirmes par des tests. Ils planifient les cas de test qui dfinissent les tests d'intgration et les tests de non-rgression, ainsi que les tests systme. Dans un dveloppement itratif, le cycle de tests est, lui aussi, itratif. Chaque construction cre au sein d'une itration peut tre sujette des tests. Les ingnieurs de tests enrichissent et prcisent les tests excuts pour chaque construction et constituent de la sorte un corpus de tests qui permettra d'effectuer plus tard des tests de non-rgression. Les premires itrations introduisent un plus grand nombre de nouvelles fonctions et de nouveaux tests que les itrations ultrieures. A mesure que se poursuit l'intgration des constructions, le nombre de tests nouveaux diminue, tandis que de plus en plus de tests de non-rgression sont excuts en vue de valider l'implmentation accumulative du systme. Les premires constructions et itrations rclament donc davantage de planification et de conception de tests, alors que celles qui viennent plus tard s'appesantissent plutt sur l'excution et l'valuation des tests. Les critres gnraux ne sont pas rductibles aux chemins travers le code pouvant. ne tests. Ils peuvent toutefois, dans un premier temps, tre perus dans des prototypes, puis dans la srie de constructions et d'itrations. Les utilisateurs, les intervenants et les dveloppeurs peuvent considrer les affichages et les interfaces utilisateur graphiques avec plus : de perspicacit qu'ils ne peuvent examiner les informations statiques contenues dans les artefacts des modles. Ces critres d'valuation indiquent les moyens de vrifier que les besoins et les exigences imposs une itration ont t dvelopps de faon satisfaisante. Ils spcifient, en termes:; observables ou vrifiables, ce qu'attend le responsable du projet de l'itration en question. Ils s'inspirent, l'origine, de la dclaration d'intention et gagnent en prcision mesure que les cas d'utilisation, les scnarios de cas d'utilisation, les exigences de performances et les cas de test expriment concrtement ce que doivent tre les incrments successifs.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

E n c h a n e m e n t d ' a c t i v i t s de l ' i t r a t i o n g n r i q u e
CHAPITRE 12

12.5.2 Les risques affectent le plan des

itrations

Au cours de la phase de cration, les risques critiques sont Identifll et les membres I l'quipe tentent de les rduire. Ils en explorent la nature en allant |usqu'au stade o ils peuvent mettre au point un plan des itrations. Pour disposer des Informations permettant raliser ce plan, i l est possible qu'ils doivent, par exemple, dveloppa les quelques cas d'utilisation lis ce risque et les implmenter dans le prototype de mise a l'preuve du concept. En fournissant certaines entres, ils voient ensuite que le prototype gnre ur.~ sortie inacceptable (un tir prmatur, par exemple), soit un risque critique. (Ces entres doivent rester dans la gamme d'entres spcifie, ou ventuellement la lisire, et nanmoins livrer une sortie inacceptable.) Outre les consquences qu'ont les risques les plus graves sur la russite d'un projet, tous les risques ont un retentissement sur le calendrier, le cot ou la qualit. Certains de ces risques peuvent tre suffisamment graves pour allonger les dlais ou accrotre l'effort ncessaire audel des prvisions, moins qu'ils ne soient rduits avant que ces rsultats indsirables ne se matrialisent. Dans la quasi-totalit des cas, un impact sur le calendrier se traduit par un impact sur le travail et sur le budget. I l arrive parfois qu'un risque ait un retentissement assez faible sur le calendrier ou les cots mais affecte d'autres facteurs, tels que la qualit ou les performances.

Quelle qu'en soit la raison, i l arrive que certains risques soient ngligs jusqu' un moment tardif du dveloppement, en particulier lorsque l'quipe du projet manque d'exprience en matire de gestion des risques. La pratique et l'exprience aidant, les quipes amliorent leut capacit squencer les risques dans un ordre permettant d'instaurer un cheminant m logique pour le projet. Dans la phase de construction, par exemple, les risques susceptible* de retarder la deuxime itration doivent tre traits au plus tard pendant la premire Iti ration de cette phase. L'objectif est que chaque itration de la phase de c o n s i n u i droule sans encombre et selon le plan tabli. Ce qui a peu de chances de se produire il II projet rencontre un risque inattendu qui ne peut tre rsolu rapidement

12.6 Dfinition d'un ordre de priorit pour les cas d'utilisation

12.5.3 Planifier les actions entreprendre

face aux

risques

Le principe gnral est d'entreprendre, face aux risques, des actions planifies. Les phases, et les itrations qui les composent, offrent un mcanisme de planification de ces actions. Par exemple, prvoyez de traiter les risques touchant la capacit construire le systme ds la ou les itrations de la phase de cration : soit vous les liminez (si possible), soit vous disposez au moins d'un plan permettant de les circonscrire. D'aprs notre exprience, l'autre solution, qui consiste ne pas planifier la rsolution des risques, fonctionne assez mal. En l'absence d'une volont rflchie d'agir sur les risques trs tt, ceux-ci se manifestent gnralement tard dans le droulement du dveloppement, au moment des tests d'intgration et des tests systme. A ce stade, la rsolution de problmes graves, susceptibles de rclamer d'importantes modifications du systme, risque de retarder la livraison de plusieurs semaines, voire plus. L'approche itrative, qui prvoit l'laboration de prototypes, de constructions et d'artefacts ds la premire phase, permet de mettre au jour les risques lorsqu'il est encore temps de les attnuer.

Nous allons aborder, dans cette section, la slection des cas d'utilisation dsuni a . n< employs comme pilotes dans une itration. Rappelez-vous que dans le l'une, .us unlflt chaque itration est pilote par un ensemble de cas d'utilisation. Il serai! d'ailleun plui |uiti de dire qu'une itration est pilote par un ensemble de scnarios de cas diuilisaliou Plus juste, parce que les premires itrations n'exploitent pas ncessairemcnl des cas d'utilisation complets. On ne prend alors que les scnarios ou les chemins pertinents pour la tflchc en cours de ralisation. I l arrive que, lorsque nous parlons de slectionner des cas d'utilisation, nous fassions en fait allusion aux seuls scnarios de ces cas d'utilisation qui nous intressent ce moment-l. Cette slection donne lieu la dfinition d'un ordre de priorit pour les cas d'utilisation (voir la section 7.4.2). Les cas d'utilisation sont ainsi hirarchiss, classs selon l'ordre dans lequel ils (ou leurs scnarios) doivent tre traits dans les itrations, et ce sur plusieurs itrations. Dans les premires itrations, certains cas d'utilisation (ou scnarios) sont classs, mais la plupart n'ont pas encore t identifis. Une fois identifis, ils sont classs leur tour. Ce classement se traduit par une liste hirarchise des cas d'utilisation. Ce sont les risques qui gouvernent ce classement. Les cas d'utilisation sont, en effet, classs dans l'ordre des risques qu'ils impliquent. Nous utilisons ici le terme risque au sens large. Par exemple, le fait d'avoir modifier l'architecture du systme dans les dernires phases reprsente un risque qui doit tre vit. Ne pas construire le systme appropri constitue un risque qu'il faut rduire trs tt en identifiant les vritables besoins. Le processus de slection est donc pilot par les risques. Aprs leur identification, les risques sont placs dans une liste des risques, comme l'indique la section 12.5.1, et chacun de ces risques est traduit par un cas d'utilisation qui, une fois implmente, permet de le rduire < 'e c as d uldi sation est donc insr dans la liste de classement des cas d'utilisation ;i nu niveau | UTM pondant son degr de risque. Dans les premires itrations, l'activit de classement des cas d'utilisation l'attai hi W > tiellement aux risques lis la porte du systme et l'architecture. Les itrationi llltrlt un voient ensuite la slection des cas d'utilisation destins toffer l'architecture t lioisie de nouvelles fonctions. Le squelette se muscle. Enfin, les derniers cas d'utilisation ijot selon un ordre logique, correspondant au classement de la liste des cas d'utilisation l'ai
1

Nous avons parfaitement conscience que certaines catgories de risques sont difficiles identifier et dcrire. Certains de ces risques peuvent demeurer obscurs , tout simplement parce qu'on n'a pas t habitu les rechercher avec assez d'ardeur. I l arrive aussi que des risques chappent notre vigilance, parce que certaines personnes impliques dans le projet se laissent abuser par un battage mdiatique surestimant ce qui peut rellement tre effectue au prix envisag et dans les dlais souhaits. Si certains risques sortent des crans de contrle , le projet ne peut plus les planifier dans des itrations et les rduire dans un semblant d'ordre.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

E n c h a n e m e n t d ' a c t i v i t s de l ' i t r a t i o n g n r i q u e
CHAPITRE 12

u s

exemple, les cas d'utilisation dpendants d'autres cas d'utilisation apparais* m plus h dans le classement et sont donc dvelopps aprs les autrel POUI U t i l vocation de l'approche itrative comme tentative pilote par les risques, consulte/ la sei lion t. | . > trois sections ci-dessous traitent maintenant des trois catgories de risques les risques sp cifiques, les risques architecturaux et les risques lis aux besoins et aux exigences.
lL s

impact modeste sur l'architecture, i l peut tre ncessaire de les dvelopper tt dans le processus de dveloppement. I l peut par exemple s'agir d'un intervenant exprimant le besoin de consulter certaines donnes, telles que les frais de transactions dcrits dans l'exemple de la section 12.6.3. Ce cas d'utilisation sera alors class un rang p l u s cleve puisque l'objectif est de rduire le risque de ne pas satisfaire aux vritables exigences. Les cas d'utilisation de confort (agrables avoir). Ces cas d'utilisation ne soni pas essentiels l'architecture et n'engagent pas de risques critiques. Ce niveau de . as d'utilisation entre rarement enjeu au cours des itrations des phases de crai al d'laboration. Si c'est le cas, leur prsence ne joue qu'un rle m i i i e i u dans I. ., point des cas d'utilisation critiques ou importants. Les cas d'utilisation facultatifs. Quelques cas d'utilisation peuvent eiie . i Itiqui I OU importants, mme s'ils ne sont pas prsents en permanence. I l peut r h e n , , , , |, i, traiter, car ils affectent l'architecture lorsqu'ils sont prsents.

12.6.1 Risques

spcifiques

un produit

particulier

Il s'agit du type de risques, c'est--dire des risques techniques, abord dans la section 5.3.1. Ces risques sont transposs en cas d'utilisation qui, s'ils sont correctement raliss, permettent de les rduire. On attribue donc chaque risque un cas d'utilisation correspondant. Il faut absolument identifier ces risques un par un, car leur traitement n'est pas formellement inscrit dans le processus ; nous entendons par l que le processus accorde une place spcifique au traitement d'un certain type de risques. Certains risques architecturaux, par exemple, sont examins dans la phase de cration, d'autres dans la phase d'laboration, comme le montre la section 12.6.2. Mais les risques qui ne sont formellement inscrits dans le processus doivent tre grs un par un, et rduits avant que leur prsence n'entrave la progression du dveloppement.

12.6.2 Risques

de crer

une architecture

inadapte

L'un des risques majeurs est de construire un systme incapable d'voluer lgamment dans les phases suivantes ou sur l'ensemble de sa dure de vie, c'est--dire de crer une architecture ne sachant pas ragir aux changements. Ce risque est explicitement trait dans les phases de cration et d'laboration : on s'assure que l'on dispose de l'architecture approprie et que l'on peut donc la figer (sauf pour y introduire de menus changements imposs par la phase de construction). C'est ce que nous entendons dans le paragraphe prcdent, quand nous disons que l'identification et le traitement de certains risques sont inscrits dans le Processus unifi. Dans ce cas, par exemple, les phases de cration et d'laboration traiteront explicitement de l'architecture.

Il faut en outre s'assurer que l'on a bien recens tous les cas d'utilisation .. i ptlbli d'influer sur l'architecture. I l ne saurait tre question de laisset d a n s l ' o m b u In m . lu fonction qui pourrait faire clater, un peu tard, le manque de stabilit de l ' a n l i i t e i n u e I I e a impratif d'atteindre un taux lev de couverture des cas d'utilisation pouvant a i l e , tel l'architecture. C'est important, non pas seulement pour laborer l'architecture, m a i s aussi pour s'assurer que le cot de dveloppement du produit peut tre estim avec prcision dans le premier cycle. I l faut tout prix viter de s'apercevoir trop tard qu'on ne pourra pas accueillir une fonction rcemment dcouverte. C'est pourquoi i l faut couvrir environ 80 % des cas d'utilisation dans la phase d'laboration. Couvrir signifie comprendre les cas d'utilisation et leur impact sur le systme. En pratique, on identifie en moyenne quelque 80 % des cas d'utilisation, qui sont ensuite intgrs au modle des cas d'utilisation, mais qu'il n'est gnralement pas ncessaire de dtailler un par un. I l suffira, dans la plupart des projets, d'en dcrire certaines parties en quelques lignes tout au plus, juste assez pour claircir ce qui servira dans cette phase. Sur des projets relativement simples, on peut se contenter de dtailler une faible proportion de ces cas d'utilisation au moment de saisir les besoins et les exigences. Dans des projets plus ambitieux, en revanche, i l est recommand de dcrire avec prcision au moins 80 % d'entre eux.

Comment dterminer les cas d'utilisation fondamentaux pour l'obtention de l'architecture approprie ? Comment rduire le risque de ne pas aboutir une architecture stable ? I l faut, pour cela, rechercher les cas d'utilisation significatifs sur le plan architectural. I l s'agit de ceux qui couvrent les principales tches ou fonctions qu'est cens accomplir le systme. Posez-vous la question suivante : Pourquoi construisons-nous ce systme ? La rponse est contenue dans les cas d'utilisation critiques, c'est--dire ceux qui comptent le plus pour les utilisateurs du systme. Les cas d'utilisation ayant d'importantes exigences non fonctionnelles - performances, temps de rponse, etc. - ressortissent galement cette catgorie. Ces cas d'utilisation permettent en gnral d'baucher le squelette du systme, auquel i l suffit ensuite d'ajouter le reste des fonctions ncessaires (voir la section 7.2.4). Vous trouverez, ci-dessous, les autres catgories de cas d'utilisation. Les cas d'utilisation secondaires. Ces cas d'utilisation viennent suppler les cas d'utilisation critiques. Ils impliquent des fonctions secondaires, comme la supervision et la compilation des statistiques de fonctionnement. Si la plupart d'entre eux n'ont qu'un

12.6.3 Risque

de ne pas bien comprendre

les

besoins

Autre risque grave : celui qui consiste crer un systme ne faisant pas ce que les utilisa teurs attendent prcisment de lui. Les moyens de traiter ce risque figurent galement dans le processus. On vrifie, l'issue de la phase d'laboration, qu'on est bien en train le voie, truire le systme souhait. Cette investigation ne doit pas tre reporte, car la phase de , . ne, traction met enjeu des sommes considrables. Quels sont les cas d'utilisation permettant de s'assurer que l'on dveloppe bien le systme qui conviendra ses utilisateurs 7 Quels ' o u i les cas d'utilisation garantissant que le systme pourra voluer dans les phases s u i v i ii prendre en charge toutes les exigences imposes par la premire version 7 Aucune Ion. non ne doit rester dans l'ombre. I l faut savoir si ce que l'on construit peut voluer.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

E n c h a n e m e n t d ' a c t i v i t s de l ' i t r a t i o n g n r i q u e
CHAPITRE 12

De combien de mois les premires phases vont-elles retarder ce qu'on considre gnralement comme la vritable activit du dveloppement logiciel, c'est--dire la construction ?

La premire partie de la rponse rside, bien entendu, dans la juste apprhension des besoins et des exigences. On peut, pour cela, crer un modle du mtier (ou, dans certains l I I un modle du domaine, plus restreint). La seconde partie consiste construire, pai le biais des premires itrations et de divers prototypes, le systme qu'exigent les utilisateurs et a sus citer leurs ractions le plus tt possible. Seule l'utilisation relle permet de s'assurer qu'on a construit le systme voulu.
MjiJJIJ S y s t m e de facturation et de r g l e m e n t On pourrait considrer, dans le systme de facturation et de rglement, que la banque dcide qu'elle doit gagner de l'argent sur les services qu'elle procure. Elle pourrait, par exemple, facturer des frais modiques sur chaque transaction. L'intgration de ces frais constituerait de nouvelles fonctions s'ajoutant aux cas d'utilisation de base Commander des marchandises et des services, Confirmer la commande, Facturer l'acheteur et R g l e r la facture. Du point de vue de l'architecte, toutefois, cette fonction de facturation de frais peut ne pas jouer un rle cl dans l'laboration de l'architecture approprie. Elle pourra tre traite comme une extension d'autres cas d'utilisation ou associe plusieurs cas d'utilisation couvrant cette facturation de frais. Pour les dveloppeurs, il s'agit d'une fonction de pure routine. Ils en ont fait bien d'autres. En revanche, du point de vue du client, il est extrmement important que les cas d'utilisation concernant cette facturation de frais soient correctement implments avant la livraison. C'est pourquoi cette fonction est classe comme risque lev et qu'elle acquiert, de ce fait, une grande importance. Lorsque le chef de projet examine l'ordre des itrations, il ne doit donc pas ngliger l'importance de cette fonction. D'un ct, s'il s'aperoit que la facturation de ces frais reprsente une simple fonction dans le cas d'utilisation en cours ne posant aucun problme particulier aux dveloppeurs, il peut estimer qu'il n'est pas ncessaire de la traiter pendant la phase d'laboration et qu'il peut, en toute scurit, la reporter la phase de construction. D'un autre ct, s'il dcouvre que cette fonction prsente un certain nombre de problmes internes compliqus (indpendants des autres cas d'utilisation), il doit prvoir de la traiter dans une itration de la phase d'laboration. L'un de ces problmes compliqus pourrait venir, par exemple, de l'exigence du client de voir cette facturation de frais rsolue de prmaturment.

12.7.1 Les projets

diffrent

normment

Ce n'est un secret pour personne que le moment o un projet de systme logiciel est prt entrer en dveloppement varie normment d'un projet l'autre. Prenons quatre exemples. 1. Un produit totalement nouveau ou sans prcdent dans un domaine inexplor (greenfield project). Personne ne sait grand-chose de ce qui doit tre fait, ni mme s'il est possible de le faire. La matire dont on dispose est assez maigre. I l va donc falloir se reposer sur quelques personnes exprimentes et jouer un peu aux devinettes. Dans un tel contexte, la socit ou la personne qui demande la cration de ce systme est, en un sens, responsable du financement des phases de cration et d'laboration. Ces phases doivent presque tre finances comme de la recherche, c'est--dire sur la base d'un cot supplmentaire. On n'en sait pas assez pour garantir le respect d'un calendrier ou d'un budget prcis dans les phases de cration et d'laboration. Dans ce type de situation, la dfinition de la porte, l'laboration d'une architecture candidate, l'identification des risques critiques et la prparation d'une tude de rentabilit exigent du temps dans la phase de cration. De mme, la satisfaction des objectifs de la phase d'laboration, qui consistent mener le projet au stade o la phase de construction pourra tre planifie, prendra encore plus de temps. 2. Un type de produit dj ralis, dans un domaine o les produits prcdents fournissent des exemples, mais aucun composant rutilisable. Si ces produits prcdents servent de guide l'architecture candidate, i l peut falloir plusieurs jours avant de s'assurer que l'architecture prcdente convient vraiment. Dans de telles circonstances, la phase de cration sera probablement brve (quelques semaines). Elle pourra n'exiger la prsence que d'une ou deux personnes d'exprience plein temps et se nourrira sans doute des connaissances d'autres personnes exprimentes que devra consulter cette quipe rduite. Ce type de produit ayant t ralis par le pass, l'existence de risques majeurs est peu probable. I l faudra peut-tre, nanmoins, consacrer plusieurs jours s'en assurer.

12.7 Ressources ncessaires

Tout en sentant confusment que le plan itratif du dveloppement logiciel fond sur les phases possde des mrites considrables, vous vous posez peut-tre encore quelques questions : A quel prix vont revenir les phases de cration et d'laboration, que ce soit en termes d'efforts de dveloppement ou en matire de formation du personnel ? D'o vient le budget qui doit tre consacr ces phases ? Combien de temps va-t-il falloir consacrer ces phases ?

3. Un produit patrimoine existe, mais i l doit tre actualis et migrer, par exemple, d'un gros systme vers une plate-forme client-serveur. Dans une certaine mesure, on peut encapsuler et utiliser certaines parties du code existant dans le nouveau systme. L'quipe de cration doit trouver une architecture candidate. Comme d'autres organisations ont dj rutilis des produits existants, l'quipe sait ce qu'elle a l'aire Toutefois, si l'organisation charge de ce travail ne l'a jamais l'ait auparavant, ou i isque de manquer d'informations sur les budgets et le calendrier. Il va falloir Imagine e architecture de rfrence, identifier une interface entre le nouveau systme et l'ani len I partir des cas d'utilisation et de la dcouverte des sous-systmes - l'un de ces ms systmes tant une encapsulation des parties du systme existant qui n'ont pas besoin d'tre modifies. 4. Des composants existent, soit sur le march, soit en interne. L'organisation logicielle s'attend pouvoir laborer un pourcentage important du nouveau systme (entre 50 et

rjaffjaaM Un d v e l o p p e m e n t itratif et i n c r m e n t a l

E n c h a n e m e n t d ' a c t i v i t s de l ' i t r a t i o n g n r i q u e
CHAPITRE 12

KfilOi

PARTIE

II!

Figure 12.5
les imposes projet conditions par un plus exigent la et 8% aux phases aux Cration-20% Elaboration-33% Constructlon-6u%
ll.M.IIIUM fS

encore

complexe d'augmenter

60% 6% 6% 6% 24%

90 %) par assemblage de ces composants ; il y aura cepciulanl des Irons qu il faudra combler en crivant du code. Le projet va devoir idcniilici i i speediei les interfaces, non seulement entre composants rutilisables et nouveaux composants, mais aussi etilie systmes externes et utilisateurs. Le dveloppement de composants exige du lemps et des efforts et i l est possible que l'quipe rencontre des risques. Dans l'ensemble, toutefois, le dveloppement base de composants est plus rapide el moins onreux que le dveloppement ex nihilo.

part du travail des dlais

consacre premires par rapport suivantes.

Ces exemples ne visent pas dfinir des catgories distinctes. Ils reprsentent plutt des positions de chevauchement. I l nous faut donc penser en termes de point de dpart. De quelle exprience peut-on justifier dans le domaine de l'application ? Sur quelle base de composants rutilisables peut-on compter ? La proposition porte-t-elle sur un projet plus ambitieux qu'une nouvelle version d'un produit existant ? Va-t-elle promouvoir l'tat de l'art ? S'agit-il d'un systme distribu (alors qu'on ne connat que les systmes mono-plateforme) ?

FWfftf IN

12.7.2 Voici quoi ressemble

gnralement

un

projet...

Malgr les incertitudes que peuvent introduire diffrents points de dpart, le cycle initial de dveloppement d'un projet de taille moyenne rpartira grosso modo les efforts et les dlais comme l'indique la figure 12.4. En gnral, pour l'laboration de l'architecture et la rduction des risques, le dveloppement par phases fait porter une grande partie l'effort sur les parties frontales du cycle, contrairement l'approche en cascade.
Figure 12.4
/principal de travail temps dans bloc et de demeure la phase de mais autres ncessitent des dlais non et Elaboration-30% Construction-50% Transition-10% Temps

Nous nous empressons de prciser que les pourcentages apparaissant daltl 11 rlgUI hypothtiques et ne sauraient tre appliqus arbitrairement des projet! m l . l l l \ plutt dmontrer que plus un projet prsentera d'inconnues, plus il devra i oniat n i di temps et d'nergie aux phases de cration et d'laboration. Dans notre exemple, nous con crons plus de temps aux deux premires phases qu'aux deux dernires. Toutefois, lei effort! consentis n'ayant pas le mme impact, i l n'est pas ncessaire d'accrotre les ressources dans les mmes proportions, mme si elles augmentent aussi. En mme temps, le travail cl les dlais accords au projet augmentent globalement. L'utilisation de cadres gnriques (frameworks) courte de faon spectaculaire la construction, mais a en revanche peu d'effet sur les premires phases. Si l'on envisage de faire de la rutilisation, les phases de cration et d'laboration seront plus longues, mais les fonctions dj disponibles sous forme de cadres gnriques n'auront pas tre analyses et conues, si bien que, en fin de compte, le projet ncessitera des dlais et des efforts moindres.

12.7.4 Une nouvelle ligne de produits exige de

l'exprience

, onstruetion, 1rs trois phases aussi

tles efforts ngligeables.

12.7.3 projets complexes,

besoins

suprieurs

Quels seront les effets si l'on prend l'hypothse d'un projet plus ambitieux et plus complexe (avec de nouvelles fonctions, une architecture distribue ou, par exemple, un fonctionnement en temps rel), employant de surcrot une nouvelle technologie sous-jacente ? I l faudra certainement un plus grand nombre d'itrations. I l faudra aussi consacrer plus de temps et d'efforts aux phases de cration et d'laboration. Ces deux phases sont donc susceptibles de s'allonger, comme le montre la figure 12.5.

Dans la plupart des cas - coup sr pour les systmes innovants ou dlicats - , l'quipe doit rcolter des informations en plus de celles dont elle dispose dj. Les spcialistes du domaine du systme envisag constituent la source la plus naturelle o puiser ces informations. Mme si l'on possde une liste dtaille des besoins et des exigences, l'quipe doit mener des entretiens avec ces spcialistes afin de dgager l'architecture et d'accorder toute son attention aux risques. L'identification des spcialistes reprsente dj, elle seule, la moiti du chemin parcouru. I l est possible que les simples utilisateurs ne connaissent queleur partie du processus global. En plus, ils ne savent pas forcment ce que peut laue un systme informatique. Une erreur courante lorsqu'on commence travailler sur une nouvelle ligne de produits i on siste ngliger de rutiliser les connaissances. L'essentiel des connaissances soi le loin non nement rel de l'entreprise se trouvant dans la tte de ses employs plutt que d u dl documents (qu'on ne lit pas, de toute faon, la plupart du temps...), la rutilisation dei naissances revient en fin de compte rutiliser les personnes d'expricni e ( 'elle eiieui se manifeste souvent dans l'affectation l'quipe initiale du projet de jeunes I C I rues piuli que de personnes connaissant bien la culture de l'entreprise, dfaut de connatre II ligna dl produits.

mmm lin d v e l o p p e m e n t itratif et i n c r m e n t a l

mum PARTIFI

E n c h a n e m e n t d ' a c t i v i t s de l ' i t r a t i o n g n r i q u e
CHAPITRE 12 mm

Lorsqu'une entreprise envisage la mise au point d'une nouvelle ligne de produits, une partie de son intelligence collective sait parfaitement que ce projet exigera la mobilisation de ses collaborateurs les plus comptents et les plus expriments. Mais, eu mme temps, une antre partie de cette intelligence collective estime que les personnes d'une telle Staline sont essentielles la bonne marche de l'activit de l'entreprise. 11 faut satisfaire les clients existants. L'entreprise ne peut entraver le flux de ses entres d'argent. Il est impossible de trancher simplement ce dilemme. Les responsables hirarchiques de ces personnes d'exprience sont dchirs entre ces deux objectifs : l'vidence, la ligne de produits actuelle et la future ligne de produits sont d'gale importance. Dans la pratique, les cadres les plus anciens exploitent la ligne de produits actuelle depuis de nombreuses annes. Ils y sont psychologiquement attachs. Et la plupart d'entre eux rpugnent souvent risquer de compromettre leurs affaires en cours en cdant leurs principaux collaborateurs au nouveau projet. Si bien que l'quipe du projet ne comptera que quelques personnes d'exprience, qui ne seront pas forcment les meilleurs responsables, tant sur le plan technique que sur celui de la gestion. I l peut s'agir, en effet, de personnes dont la direction souhaitait plus ou moins se dbarrasser. Ces responsables nouvellement promus doivent alors toffer leurs quipes d'un grand nombre de nouvelles ttes, parfois fraches moulues de l'universit.

Dans le cas d'une socit dveloppant un produit pour un client en interne, le cot des deux premires phases provient soit de son propre budget de frais gnraux, soit de fonds verss directement par le client, soit encore de fonds allous par la direction. On notera que les deux dernires mthodes de financement supposent que des responsables extrieurs la socit de dveloppement comprennent la valeur des deux prenucie , phases et y consacrent des fonds.

Dans le cas d'une socit dveloppant un produit destine un entreprise clients totalement indpendante, le cot des deux premires phases pourra clic p u s eu ha gl BU son propre budget de frais gnraux. Mais la socit ne disposera de surplui a de p. M l I que si elle a intgr cette dpense dans des offres faites par le passe Ni le projet suivent entre dans le cadre de l'activit normale de la socit, celle s o n n e de linaneenn m i tre suffisante. Si le projet propos semble anormalement r i s q u e , il parat rail Ilbll qui le client contribue aufinancementdes deux premires phases.
t

Bref, un travail essentiel s'accomplit au cours des deux premires phaiei il lit temps et de l'argent. Mais i l rclame aussi la coopration du client < 'elle COOpi ration qui revient mettre la disposition de la socit de dveloppcmcnl tontes les m l o i m a i i o n , elle a besoin, cote aussi de l'argent (mme si cette dpense n'entre pas formellcmenl dani les comptes).

Outre leur inexprience, ces nouveaux venus sont porteurs d'une culture particulire : ils ont tendance considrer tout ce qui est ancien (c'est--dire ce que fait l'entreprise) comme compltement dpass. Seul l'innovation compte. Les jeunes recrues ne peroivent pas toujours l'importance des questions qui n'ont pas t traites l'cole : par exemple, les mthodes de production et la gestion du cycle de vie.

12.8 valuer les itrations et les phases

Pour tirer tous les bnfices possibles du travail itratif, le projet doit valuer ce qui a t accompli la fin de chaque itration et de chaque phase. C'est le responsable du projet qui est charg de cette valuation. I l y procde non seulement pour valuer l'itration ellemme, mais aussi pour promouvoir deux autres objectifs : replanifier l'itration suivante la lueur de ce que l'itration acheve a appris l'quipe et effectuer les changements ncessaires ; modifier le processus, adapter les outils, poursuivre la formation et entreprendre d'autres tapes, comme le suggre l'exprience de l'itration value. Si le premier objectif d'une valuation est d'examiner ce qui a t accompli l'aune des critres d'valuation dfinis au pralable, le second s'attache vrifier la progression par rapport au plan de l'itration ou au plan du projet ; Le travail avance-t-il dans le respect des budgets et des dlais ? Satisfait-il aux exigences de qualit, selon ce que rvlent les tests ou l'observation pat les intervenants concerns du fonctionnement des prototypes, des composants, des constructions ou des incrments ? Dans l'idal, le projet rpond aux critres dfinis. Le responsable du projet disinbue alois les rsultats de l'valuation aux intervenants concerns et classe le document, qui M M i l pi actualis, puisque chaque valuation fera l'objet d'un document part.

Nous avons constat que, souvent, les entreprises n'arrivent pas affecter au dveloppement d'une nouvelle ligne de produits les talents ncessaires la mise sur le march d'une version complte en temps et en heure. Les dficiences ne sont gnralement pas corriges avant la deuxime gnration du produit. Par essence, la premire gnration se rsume souvent une exprience en direct sur le terrain, mme si ce n'tait pas forcment l'intention de l'entreprise au dpart.

12.7.5 II faut payer le prix des ressources

utilises

La mobilisation d'une quipe travaillant sur les deux premires phases, aussi rduite soitelle, ncessite des fonds. En fait, la difficult obtenir des crdits destins prendre en charge ces deux phases tait, jusqu' prsent, l'un des facteurs qui conduisaient les organisations logicielles s'engager prmaturment dans la phase de construction. Ce qui aboutissait parfois des checs retentissants et largement mdiatiss. D'o ces fonds proviennent-ils ? Dans le cas d'une socit ditrice d'un produit destin tre commercialis, les crdits viennent du budget des frais gnraux et sont, par consquent, sous le contrle de la direction. Si l'on se place d'un point de vue plus large, on se rend compte qu'ils trouvent leur origine chez les clients ou les consommateurs. En d'autres termes, l'diteur doit vendre ses produits actuels suffisamment cher pour financer le dveloppement des futurs produits.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

E n c h a n e m e n t d ' a c t i v i t s de l ' i t r a t i o n g n r i q u e
CHAPITRE 12

12.8.1 Les critres

ne sont pas

remplis
rc

Les valuations se droulent rarement sans encombre. Bien souvcnl, une iiralinn n'aura atteint un niveau suffisant de satisfaction des critres et le projet risque d'avou a n-|>n-iu) une partie du travail dans l'itration suivante (ou dans une itration tardive plus appropris] Il peut s'agir : de modifier ou d'toffer le modle des cas d'utilisation ; de modifier ou d'toffer l'architecture ; de modifier ou d'toffer les sous-systmes dvelopps jusqu' prsent ; de rechercher d'autres risques ; d'apporter l'quipe certaines comptences ou connaissances.

Notons que, dans un dveloppement bas sur les composants, la mtrique (c'est--dire le nombre de lignes de code crites) ne constitue pas un indicateur fiable de la progression : un dveloppeur peut trs bien rutiliser des briques de base (sous-systmes, classes et compo sants) dj conues et l'criture de quelques lignes de codes suffit parfois amener des progrs sensibles.

12.8.4 volution

de l'ensemble

des

modles

Ou alors, i l faudra simplement accorder des dlais supplmentaires pour mener bien le plan existant. Si tel est le cas, le projet pourra rallonger le temps consacr la premire itration. Mais il faudra alors fixer une date d'achvement ferme.

12.8.2 Les critres

eux-mmes

Une des caractristiques essentielles du dveloppement itratif par phases est rvolution d. l'ensemble des modles. Cette volution contraste avec le modle en cascade, dsUM lequel on imagine que l'expression des besoins est d'abord mene bien, puis l'analysi l I lin I dl suite. Dans le dveloppement itratif, les modles voluent ensemble, de . on. eil les diverses phases. Dans les premires itrations, certains m o d l e . lOfll M .o. pu rapport aux autres. Par exemple, le modle des cas d'utilisation est plie, nviinei qui h modle d'implmentation. On n'assiste plus l'volution d'un modle imlcpendiiu dit modle suivant, mais on envisage l'volution d'un tat du sysieme dans ,i uibli \ i un tat plus avanc du systme dans son ensemble, comme l'illustre la ligure i2,5, < ihaqui itration, et peut-tre chaque construction au sein d'une itration, reprsente une avanol ' l ' l'tat de l'ensemble du systme. Cette volution se reflte dans le moiivemenl p i o g i e s s d vers la finalisation de l'ensemble des modles. Le degr d'volution identifi pni chaque valuation constitue un indicateur majeur prendre en compte par le groupe des valuateurs. Nous allons revenir, dans le chapitre suivant, aux dbuts du projet et envisager les mrites propres de la phase de cration.

Il faut, toutefois, penser considrer les critres d'valuation eux-mmes. I l est possible que l'quipe ait tabli ces critres un moment o elle ne disposait pas de toutes les informations pertinentes. Le droulement de l'itration peut avoir fait merger de nouveaux besoins ou fait apparatre l'inutilit des besoins retenus au dpart. Les valuateurs auront peut-tre modifier les critres, sans se borner vrifier s'ils ont t atteints.

12.8.3 L'itration

suivante

Un jalon majeur (annexe C) marque l'achvement d'une phase, le stade auquel non seulement l'quipe du projet, mais aussi les intervenants, et en particulier les responsables financiers et les reprsentants des utilisateurs, s'accordent considrer que le projet a atteint les critres du jalon et que le passage la phase suivante se justifie. Sur la base de l'valuation, le responsable du projet (assist de quelques collaborateurs ayant travaill sur l'itration ou la phase, auxquels s'ajoutent certaines des personnes affectes l'itration suivante) effectue les tches suivantes : i l prend note du fait que le travail est prt pour l'itration suivante ; si des amliorations sont ncessaires, i l dtermine les itrations suivantes auxquelles elles doivent tre affectes ; i l planifie en dtail l'itration suivante ; i l actualise le plan, avec moins de dtails, pour les itrations venant aprs l'itration suivante ; i l met jour la liste des risques et le plan du projet ; i l compare le cot et les dlais rels de l'itration avec ceux qui avaient t prvus.

13
La phase de cration lance le projet
Le propos gnral de la phase de cration est de lancer le projet. Avant la cration, le projet n'est peut-tre qu'une vague ide en l'air. Cette ide peut tre stimulante si elle est Iota lement indite dans un domaine innovant. Elle peut tre relativement soporifique s'il s'agit de la nime version d'un produit existant. La cration peut se borner la rdaction d'une dclaration d'intention, l'esquisse d'une architecture l'aide de divers diagrammes et la ralisation d'une tude de rentabilit raisonnable. Elle peut tre aussi complexe qu'un vritable projet de recherche. En rsum, la phase de cration ne peut tre rduite un unique strotype. A l'issue de la phase de cration, mme si le systme est nouveau, non seulement vous avez dlimit le problme rsoudre, mais vous tes all assez loin pour acqurir la certitude qu'il est la fois possible et souhaitable de dvelopper le systme. Bien sr, cette certitude ne vous appartient pas en propre. Le travail effectu pendant la phase de cration offre au client (ou ses reprsentants), l'organisation de dveloppement et aux autres intervenants l'assurance que l'architecte et les dveloppeurs seront en mesure de rduire les risques critiques, de formuler une architecture candidate et d'laborer l'tude de rentabilit initiale.

13.1 La phase de cration en bref

L'objectif de la phase de cration est de pousser l'tude de rentabilit jusqu'au stade propre a justifier le lancement du projet. I l faut d'abord, pour procder celle lude, dlimita la porte du systme envisag et cerner le champ d'investigation du projet de dveloppement Cette porte est indispensable pour saisir l'tendue mme de l'architecture, file esl inilis pensable pour tracer le cadre de recherche des risques critiques. Elle est indispensable, riilin pour fixer des limites l'estimation des cots, des dlais et des retours sut investis .enient tous les ingrdients de l'tude de rentabilit.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase de c r a t i o n lance le projet

CHAPITRE 13

On tente alors d'baucher un dbut d'architecture, juste l e qu II ftUl p Si quril la titude qu'il existe une architecture - nomme architecture candidate capable de prcndi charge la porte du systme. On s'efforce galement d'anticiper un ventuel fiasco. Nombre de projets difficiles mu trbuch parce qu'ils taient confronts des risques critiques, parfois aussi tardivement qu'au moment de l'intgration et des tests du systme, qu'il tait impossible de rduire dans le respect des budgets et des dlais encore disponibles. Qu'on le veuille ou non, les incertitudes, ou les risques, existent. La seule alternative consiste les rduire trs tt, limiter la porte du systme ou accrotre les dlais et les ressources (c'est--dire le budget) afin d'viter les risques irrductibles. Par ailleurs, on s'vertue raliser l'tude de rentabilit initiale afin de considrer le systme propos d'un point de vue conomique, c'est--dire d'effectuer les premires estimations de budget, de calendrier et de retour sur investissement. On se demande alors : si les gains gnrs par l'utilisation ou la vente du produit logiciel feront plus que compenser le cot de son dveloppement ; si le produit arrivera temps sur le march (ou dans l'application interne) pour permettre ces gains. On s'efforce, enfin, de soutenir l'quipe du projet par la mise en place d'un environnement de dveloppement, c'est--dire d'un processus et d'outils. Bien entendu, l'environnement de dveloppement d'une organisation logicielle est l'aboutissement d'annes d'efforts, dont l'essentiel intervient avant le dbut d'un projet donn. On adapte, toutefois, le Processus unifi au type de systme en cours de dveloppement et le niveau de comptence de l'organisation de dveloppement charge de raliser le travail. C'est l le genre de questions que doit traiter la phase de cration.

dveloppement. En d'autres termes, on aura dj procd une partie de la phase de cration. Les organisations logicielles ralisant des systmes pour d'autres services d'une mme entreprise, soit le type mme de l'organisation de dveloppement en interne. ( )n rencontre, grosso modo, deux types de situations. Dans le premier cas, un semer m SOI le besoin d'un systme logiciel et demande au service de dveloppement de le p u n i Le service demandeur fournit alors une description du systme souhaite, sans avou forcment une ide trs claire des ramifications du logiciel, lin d'autres le l'organisation logicielle dispose de peu d'informations au moment ou dobuii la plia cration. Dans le second cas, la direction gnrale estime nccssaiie la mitt S i Il d Ull U systme l'chelle de l'entreprise et a affect un groupe d'ini'eiuei ie inetiei a I l ,l< possibilits que doit offrir ce systme. La phase de cration peui alors ( une bonne comprhension des besoins et des exigences. Les organisations logicielles ralisant des systmes pour des clients I appel il nln initial regorge souvent de dtails pouvant remplir des pages et des pages di l l d'exigences. Dans le contexte de relations plus formelles, le client peut n'avoll qu Uni vision trs parcellaire de ses besoins. Si le produit reprsente une volution d'une version antrieure, l'essentiel du travail de pli nification de la premire itration du nouveau projet aura t effectue lors de la dernire u < ration du cycle prcdent. Dans le cas d'un projet globalement nouveau, toutefois, les pres du projet souhaiteront voir leur concept men plus loin. Ils auront peut-tre dj procd une estimation approximative du travail ncessaire, obtenu des fonds couvrant la phase de cration et fix un calendrier.

13.2.2 Planifier la phase de

cration

13.2 Premiers stades de la phase de cration

Commencez planifier ; dveloppez la vision du systme et commencez difier vos critres d'valuation.

13.2.1 Avant le dbut

de la phase de

cration

Le dbut d'un projet nous place toujours face un dilemme. Des personnes bien intentionnes vous conseillent de planifier, mais vous n'avez gure d'informations sur lesquelles fonder cette planification. Votre connaissance de ce qui doit tre fait vous donne, toutefois, quelque conscience de ce qui doit tre planifi. Nous aborderons ce point plus loin, dans les sections 13.3. et 13.4. Entre-temps, vous pouvez toujours commencer par les tapes suivantes : collationner les informations runies avant le dbut du projet ; classer ces informations afin de les rendre utilisables ; rassembler un certain nombre de personnes qui sauront s'en servir ; identifier les manques, non en fonction des quatre phases, mais selon les Objet tlfl extrmement limits de la phase de cration. En d'autres termes, limitez cette recherche ce qu'il vous faut pour ralisa les uh|ci n i . . t. de cette phase, rsums dans la section 13.1. Puis faites une tentative de plan DOUI l larilli ' les besoins et les exigences portant sur ces objectifs de dpart et les dtaille! dan d'utilisation correspondants. Prvoyez de crer une architecture candidate, qui dl Wl i borner dmontrer la faisabilit du projet et ne proposer par consquent qui qui Iqu.

Avant mme le dbut de la phase de cration, vous saviez plus ou moins ce que vous alliez faire. Quelqu'un - un client, votre service du marketing, ou mme un membre de votre propre service de dveloppement - a mis une ide et l'a justifie au point de la mettre en chantier. La teneur du travail effectu avant la phase de cration varie considrablement : elle couvre un certain champ, qui peut s'articuler autour des trois ples spcifiques voqus ci-dessous. Les organisations logicielles ralisant des produits destins la vente dans le commerce. Le volume d'informations de dpart peut tre assez substantiel. Il est plus que probable que le marketing et la direction auront consacr au produit venir des tudes extensives, compltes par des tudes techniques menes par des membres de l'quipe de

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase de c r a t i o n lance le projet

CHAPITRE 13

esquisses des vues architecturales. Ds que vous le pourrez, essaye/ il'eiiihlu le Lui n 'ji vous faudra une ou, dans certains cas, deux itrations.
u

cas, les critres d'valuation resteront plutt gnraux. Ils se prciseront au fil de l'itration et de l'accumulation progressive des informations. Nous proposons, toutefois, quelques ci I tres d'valuation gnraux pour les quatre objectifs de la phase de cration. Dlimiter la porte du systme

Gardez l'esprit que ce plan initial est provisoire. Il se modifiera progrcssiveiiicni pi nu lunir compte des informations accumules. Essayez, bien entendu, de termina la phase J cration dans les dlais et les budgets allous au dpart par la direction (ou le i lient) Comme les responsables ont d, forcment, fixer ces chiffres partir de connaissance! limites, pensez les informer (ainsi que tout autre intervenant) de la progression du travail au cours de cette phase. I l pourra se rvler ncessaire de revoir ces chiffres.
e

13.2.3 largir

la vision du

systme

Nul doute que la vision initiale donne quelque ide de la porte du systme, mais elle n. i , dfinit pas prcisment. Dans la phase de cration, le projet trace une ligne exacte deI i.un ce qui doit se trouver l'intrieur du systme envisag et ce qui doit rester;) rcxlciiciu l'iu sont identifis les acteurs externes, qui peuvent tre d'autres systme! O des i U im avec lesquels le systme va dialoguer. La nature de cette interaction Bit dflllil I lev. Les questions abordes ici sont les suivantes : Sait-on avec clart ce qui doit figurer l'intrieur du systme 7 Les acteurs sont-ils tous identifis ? La nature gnrale des interfaces (interfaces utilisateur cl protocoles de . i est-elle dfinie ? i u

Il est possible, au dbut du cycle de vie, que l'quipe n'ait sa disposition gure plus qu'une dclaration d'intention d'une page. Celle-ci contient une liste de caractristiques (voir la section 6.3), quelques informations sur les performances, une connaissance trs pauvre des risques que pourront rencontrer les dveloppeurs, ventuellement une vague rfrence une possible architecture (la simple mention client-serveur ou quelque chose du mme ordre) et des chiffres ronds et parfaitement alatoires en guise de budget et de dlais (par exemple, 10 millions d'euros sur deux ans). Cette quipe de dpart peut se composer du responsable du projet, de l'architecte, d'un ou deux dveloppeurs expriments, d'un ingnieur de tests (en particulier si les tests jouent un rle important), et certainement de reprsentants du client ou des utilisateurs. La premire tape consiste toffer la dclaration d'intention afin qu'elle guide la phase de cration.

Les lments situs dans la porte du systme peuvent-ils constitua letU MUllUfl systme capable de fonctionner ? Lever les ambiguts sur les besoins et les exigences ncessaires dans cette phase Les besoins et exigences , au dbut de la phase de cration, peuvent aller d'une vision gnrale sommaire une description textuelle de plusieurs pages. Ces premires exigences sont toutefois susceptibles de receler quelques ambiguts. L'valuation doit prendre en compte les questions suivantes : Les quelques exigences (fonctionnelles et non fonctionnelles) des cas d'utilisation ncessaires pour atteindre les objectifs de cette phase ont-elles t identifies et dcrites en dtail ? Les autres exigences ont-elles t identifies et dcrites en dtail dans les exigences supplmentaires (voir la section 6.7) ? tablir une architecture candidate

Voil qui est facile dire, mais un peu plus difficile mettre en uvre. C'est pourquoi il faut absolument que soient impliqus des reprsentants de tous les intrts en jeu. C'est aussi pourquoi i l faut qu'il s'agisse de gens d'exprience. C'est encore pourquoi i l faut qu'ils prennent en compte diffrents points de vue et ne se rallient pas un timide compromis. C'est pourquoi, enfin, il faut un peu de temps pour rflchir srieusement cette tche extrmement dlicate. N'oubliez pas qu'on ne recherche pas un consensus, mais la meilleure rponse. Les rponses adquates proviendront d'un responsable, de la personne charge de grer les fonds accords au projet, mais aussi d'un responsable conseill par des spcialistes parfaitement informs. Dans le cas d'un produit similaire un produit antrieur, i l peut s'agir simplement d'tablir cette proximit, ce qui ne prendra que quelques jours. Certaines phases de cration ne durent qu'une journe (dans le cas, par exemple, du deuxime cycle d'un produit simple existant), alors que celle d'un projet totalement nouveau pourra prendre plusieurs mois. De mme, dans le cas de systmes vritablement originaux, la phase de cration peut tre longue et coteuse.

L'exprience nous enseigne qu'on peut se tourner assez rapidement vers les fonctions nouvelles ou rclamant des performances sans prcdent. I l faut alors slectionner, parmi ces fonctions, celles qui sont susceptibles de compromettre le dveloppement de tout le systme. Pour ces quelques fonctions, on dveloppe au moins une architecture capable le fonctionna Les critres d'valuation sont les suivants : Cette architecture satisfait-elle les besoins des utilisateurs ? Est-elle susceptible de fonctionner ? (Considrez ce critre par rapport au degic d'accomplissement auquel est parvenue l'architecture candidate. Aucun prototype n'ayant t prpar, la description de l'architecture candidate sera juge sur ses promesses di fonctionnement.) Pour rpondre cette question, il faut examiner plusieurs points. L'architecture p o u i i a i . II. utiliser de faon adapte la technologie (bases de donnes, rseau, etc.) sui l a q u e l l e i M

13.2.4 Dfinir

les critres

d'valuation

Une fois que le responsable du projet dispose d'un volume suffisant d'informations pour prsenter un plan granularit fine de la premire itration, i l en profite pour fixer les critres d'valuation permettant d'tablir que l'itration a atteint ses objectifs. Ce plan granularit fine peut en ralit tre assez grossier en raison de la raret des informations. Si c'est le

Un d v e l o p p e m e n t itratif et i n c r m e n t a l PARTIE III

L a phase de c r a t i o n lance le projet CHAPITRE 13

devra reposer? Pourra-t-elle fonctionner correctement 7 Tonna l clic exploite! lei tes sources disponibles ? Sera-t-elle fiable, tolrante aux pannes et robuste ' Saura i elle ragu aux changements? voluera-t-elle sans heurts lorsque des besoins et .les exigences s'ajouteront ? Rduire les risques critiques Les risques critiques sont ceux qui, s'ils n'taient pas rduits, compromettraient la russite du projet. L'valuation doit examiner les points suivants : Les risques critiques ont-ils tous t identifis ? Les risques identifis ont-ils t rduits ou est-il prvu de le faire ?

13.3.11ntroduction

aux cinq enchanements

d'activits

principaux

Le principal objectif de la phase de cration consiste tablir l'tude de rentabilit, c'est | dire la justification du point de vue commercial de la poursuite du projet. Pour tabli] I et objectif, i l faut dfinir la porte du systme envisag, esquisser une architecture, identifll l les risques susceptibles de compromettre la russite du projet et tracer les grandei ligm d'un plan de rduction de ces risques. Si l'on propose un nouveau type de systme. , l t peut-tre en prsenter la nature et l'utilisation en construisant un prototype, pins | \ un prototype (gnralement jetable) de mise l'preuve du concept. Des prototypi pi u m galement tre utiliss slectivement pour la gestion et la rduction des riiqui i ||i d'abord les domaines haut risque, puis on prototype les parties essentielles du avec des fonctions dlicates ou des problmes connus de performant 61 O de nablllli Un I U dans un systme de ngoce financier tolrant aux pannes, il pourra tre Utile di i ni i trs tt un mcanisme de rcupration aprs panne. L'essentiel de la phase de cration s'accomplit dans le premiei enchanai I |t dvltl celui des besoins, comme l'illustre la figure 13.1, tandis qu'une partie du iiav.nl .vu dans les enchanements d'activits d'analyse et de conception. Les cmiiameni, ntl d II 1 1 vitsfinalsd'implmentation et de tests, en revanche, ne reprsentent qu'une pan m a t i n a l e Il s'agit, dans cette phase, de faire la dmonstration de nouveaux concepts, sans o u b l i a de s'assurer que les prototypes d'exploration, s'il y en a, fonctionnent correctement sous tous les aspects.

Dire qu'un risque critique a t rduit ne signifie pas ncessairement qu'il a t entirement limin dans cette phase. Cela peut signifier que le client prfre modifier les exigences concernes, plutt qu'tre confront l'ventualit d'un chec du projet. Cela peut aussi signifier que l'quipe du projet entrevoit un moyen de contourner le risque, dont les dtails pourront tre prciss dans une phase plus tardive. Dans d'autres cas, ce terme peut renvoyer au fait que l'quipe envisage un moyen de limiter la probabilit de ce risque ou d'en rduire au maximum la gravit si jamais i l se concrtisait. Enfin, i l peut galement tre question d'laborer un plan visant circonscrire le risque pour rpondre sa matrialisation ventuelle. Aucune de ces questions ne saurait tre tranche par un jugement simple et mcanique, au moins dans les situations inhabituelles. Le principal objectif de la phase de cration est de parvenir un stade du processus de dveloppement qui permettent au chef de projet, la hirarchie et aux intervenants responsables sur le plan financier (y compris les clients) d'exercer leur capacit de jugement professionnel. Estimer la valeur de l'tude de rentabilit initiale L'objet de l'valuation est le suivant : l'tude de rentabilit initiale est-elle suffisamment fiable pour justifier l'avancement du projet ? L'tude de rentabilit initiale couvre un autre domaine du projet appelant toute la finesse de jugement des responsables. Si le domaine du projet vous est familier, l'tude de rentabilit livrera sans doute des chiffres assez fiables la fin de la phase de cration. Dans un domaine tout fait nouveau ou difficile, en revanche, on ne disposera souvent que d'une fourchette de chiffres assez large sur lesquels fonder son jugement.

L'analyste systme identifie les acteurs et les cas d'utilisation dfinissant la porte du systme, auxquels l'architecte attribue un ordre de priorit en slectionnant ceux qui sont pertinents pour l'architecture candidate. L'architecte rdige ensuite une description initiale de l'architecture candidate. Les spcificateurs de cas d'utilisation dtaillent certains chemins des cas d'utilisation identifis. Les cas d'utilisation dcrits de faon prcise et dtaille sont ceux qui prsentent de l'intrt pour la comprhension de la porte du systme, de l'architecture candidate et des risques critiques, c'est--dire ceux qui permettent d'laborer l'tude de rentabilit initiale. Ce travail dbouche sur la cration du premier modle des cas d'utilisation dans le cas d'un dveloppement tout neuf (green-field), ou d'une nouvelle version de ce mme modle si l'on reprend le dveloppement d'un systme existant. On peut aussi dresser un classement des cas d'utilisation, comme l'indique le chapitre 12. L'enchanement d'activits d'analyse voit la cration d'un premier modle d'analyse pour la majeure partie des cas d'utilisation ou des scnarios de cas d'utilisation traits dans la phase de cration. Ce modle d'analyse est fondamental pour une comprhension limpide des oai d'utilisation. I l permet galement d'apprhender ce qui sous-tend la premire bam lie de l'architecture.

13.3 Enchanement d'activits de l'itration typique de cration

La phase de cration voit la ralisation de trois ensembles d'activits. L'un est la planification des itrations, que dcrivent les sections 12.4 12.7 et la section 13.2.3 ; le deuxime regroupe les cinq enchanements d'activits principaux et est abord brivement dans la section 13.3.1, puis largement dans la section 13.4 ; enfin, le troisime est la slection de l'environnement de dveloppement adapt au projet, auquel est consacre la section 13.3.2. Par ailleurs, la section 13.5 dcrit l'tude de rentabilit initiale et la section 13.6 les valuations de cette phase.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l

La phase de c r a t i o n lance le projet

CHAPITRE 13

366

PARTIE

III

367

Figure 13.1

Ressources

projet, soit l'chelle de l'entreprise, pour prendre en charge les besoins inhabituels du projet. Les services renvoient l'administration du systme, la sauvegarde des donnes cl aux tlcommunications.

Enchanements d'activits principaux

^ Besoins ^ Analyse ^ Conception ^ lmplmenlalio^~

La phase de cration marque le dbut de l'activit visant installer renvironnemeni tic dveloppement de l'organisation logicielle au cur d'une relation d'accompagncmcni .lu projet. Cet effort se poursuit dans la phase d'laboration, mesure que l'quipe du proji | manifeste un besoin croissant d'outils et autres services. L'quipe du projet veille doni I l'installation de son environnement de dveloppement tout en fournissant I. ii.iv.nl ,, dans cette phase.

Se concentrent sur la dfinition de la porte du s y s t m e pour la ralisation d'une t u d e de rentabilit Enchanements d'activits des itrations de cration

Le travail effectu pendant une itration de la phase de cration passe par les cinq enchanements d'activits principaux. Les tailles relatives des rectangles se contentent d'indiquer les enchanements d'activits qui mobilisent le plus d'attention et ceux qui en ncessitent le moins.

13.3.3 Identifier les risques

critiques

Nous avons consacr les sections 12.5 et 12.6 l'identification cl a la rdiii lion doi qm affectant le dveloppement. Dans la phase de cration, ce son i les risques ci un |u. i un souhaite identifier et rduire ou dont on cherche ventuellement a planifie] la rduction l a section 13.2.4 a montr ce que l'on entend par rduire un risque critique D ait ibaolumenl primordial d'identifier les risques de cette ampleur au cours de la pltase de . realion Ni l'on dtecte un risque de ce type mais qu'on n'entrevoit aucun moyen tic le rduit, m de plan susceptible de le circonscrire, i l faut envisager d'abandonner le projet.

S'il s'agit d'un systme nouveau ou sans prcdent, l'quipe de la phase de cration peut laborer un prototype d'exploration destin dmontrer les ides matresses en assemblant rapidement des lments. Un tel prototype vise exposer les concepts impliqus, et non se transformer en implmentation finale ; en d'autres termes, i l sera trs certainement jetable. Dans certains cas, i l pourra tre suffisant d'tablir le fait qu'un algorithme permet de mettre en uvre un nouveau calcul, condition que l'quipe puisse constater que les ingnieurs de composants n'auront aucun problme implmenter l'algorithme en question dans des composants capables des performances exiges. L'itration peut s'achever par la description de l'architecture candidate s'accompagnant de l'bauche des vues des modles, ds que le chef de projet dtermine que l'architecture candidate parat capable de fonctionner et que les risques ne sont pas critiques ou sont rductibles. Ce sera le cas si l'architecture a t bien tablie grce l'exprience antrieure du projet et aux intervenants.

13.4 Excuter les enchanements d'activits principaux : des besoins aux tests
Cette partie du chapitre dcrit plus en dtail les activits de cette phase dans le cadre d'un projet tout neuf , c'est--dire d'un produit entirement nouveau, sans aucun antcdent. L'extension d'un produit existant est, videmment, beaucoup plus simple.

13.3.2 Adapter le projet l'environnement

de

dveloppement

Chaque itration est une mini-cascade dclinant les cinq enchanements d'activits principaux, des besoins aux tests. La deuxime partie de l'ouvrage a consacr un chapitre chacun de ces enchanements d'activits, et mme deux chapitres au premier d'entre eux. Nous allons nouveau, dans cette section, ddier une sous-section chacun de ces enchanements, mais en les considrant cette fois comme intgrs la phase de cration. Pour bien dlimiter notre champ d'intervention, nous avons trac la main deux patatodes sur la figure 13.2. L'une regroupe les activits visant identifier la porte du systme, l'autre celles permettant la comprhension de l'architecture candidate. Les noms de travailleurs apparaissant dans cette figure dsignent le rle qu'assume chaque collaborateur au cours du dveloppement. Dans cette phase, nanmoins, l'quipe . a en. ...e rduite et chacun peut incarner plusieurs travailleurs.

L'environnement de dveloppement se compose d'un processus, des outils mettant en uvre ce processus et des services destins aux projets : les services de configuration et d'amlioration du processus, de slection, d'acquisition et de fabrication des outils, de formation et de monitorat. Les outils en question sont ceux qui prennent en charge les enchanements d'activits principaux de besoins, d'analyse, de conception, d'implmentation et de tests, ainsi que les outils d'administration de gestion des projets (planification, estimation, suivi), de gestion de configuration et des changements, de gnration de documents et de prise en charge en ligne du processus. Outre ces outils, dont beaucoup ont une vocation gnraliste et sont fournis par des diteurs, i l est possible de dvelopper des outils spcialiss, soit dans le cadre du

Un d v e l o p p e m e n t i t r a t i f et i n c r m e n t a l PARTIE III

La phase de c r a t i o n lance le projet CHAPITRE 13

O 7
Analyste systme

/B
* Identifierles acteurs et les cas d'utilisation

Planifier les tests

Structurer le modle des cas d'utilisation

Tests

B
1er
t

grande distribution, les nouvelles caractristiques proviennent de la demande du march, auxquelles s'ajoutent les possibilits de fonctions suggres par les travailleurs de l'organisation de dveloppement elle-mme. Certaines caractristiques naissent des interactions entre l'organisation logicielle et les utilisateurs, d'autres viennent du marketing. I es propo sitions manant de ces diverses sources sont autant de candidates sur la liste des earacii i>. tiques, dcrite au chapitre 6.

Spcificatei de cas d'utilisatloi

w J^c /

un cas d'utilisation

BesQffns , D f i n i r la p o r t e du s y s t m e W

Implmentation

Concepteur d'Interface utilisateur

Comprendre le contexte du systme Si le client dispose d'un modle du mtier (ou d'un modle du domaine), celui Ci r m I In exploit dans la phase de cration. En l'absence d'un tel modle, en revanche e ||i li client en crer un, mme si cela demande du temps et des ressources dpassant l u i m ceux dont dispose un simple projet. Soyez ferme.
Testeur systme

E s q u i s s e r l'architecture candidate \

Il faut identifier les cas d'utilisation pour les systmes mtier ou techniques dis i iv.nit li pin cessus prendre en charge. I l faut aussi identifier les travailleurs el les i lull prtilt sionnels de base (les entits de travail et les entits mtier). Vous devez, globalemt ni V l)ll ralis 50 70 % du modle du mtier avant de vous lancer dans la m o d l e . . u t Util! des cas d'utilisation pertinents. Il est impossible de dvelopper un logiciel sans i i aitu I. processus qu'il est cens mettre en uvre.

, ^1

/ Impimenter une classe

Formuler les besoins fonctionnels Les besoins fonctionnels sont reprsents sous forme de cas d'utilisation, comme le dcrivent le chapitre 7 et la section 13.4.1.1.

Implmenter sous-systme

uFpImoIdes porte du systme

traces

la main regroupent les principales activits candidate.

de la phase de cration

: dfinition

de la

et esquisse de l'architecture

13.4.1 Formuler les

besoins

Formuler les exigences non fonctionnelles Les exigences non fonctionnelles spcifiques un cas d'utilisation sont associes au cas d'utilisation qu'elles concernent (voir les sections 6.3 et 7.2.3.2). Celles qui sont spcifiques un objet du modle du mtier ou du modle du domaine renvoient un terme du glossaire accompagnant le modle des cas d'utilisation (section 6.3) ; celles, beaucoup moins nombreuses, qui sont plus gnrales, figurent dans la liste des exigences supplmentaires (section 6.7). Parmi ces exigences plus gnrales, certaines sont essentielles la slection de la plate-forme, du logiciel systme et de l'architecture des middleware, et joueront un rle primordial dans cette phase (voir la section 4.3, Cas d'utilisation et architecture ).

Dans la phase de cration, l'attention se porte essentiellement sur le premier enchanement d'activits principal, celui des besoins, qui consiste identifier et dcrire en detafi les cas d'utilisation intressants pour cette phase. Cet enchanement d'activits aborde les thmes suivants, dcrits dans le chapitre 6 : 1. Recensement des besoins et des exigences candidats la liste de caractristiques du systme. 2. 3. 4. Comprhension du contexte du systme. Formulation des besoins fonctionnels pertinents sous forme de cas d'utilisation. Formulation des exigences non fonctionnelles lies.

13.4.1.1 Formuler les besoins sous forme de cas d'utilisation

Revenons maintenant la figure 13.2 pour nous pencher sur les activits qui y sont voques. Dans cette section, nous allons expliquer la manire de formuler les besoins sous forme de cas d'utilisation travers les activits indiques par la figure 13.2.

I I

Recenser les besoins et exigences candidats Les caractristiques exiges trouvent souvent leur origine dans l'exprience qu'ont les clients ou les utilisateurs de systmes antrieurs ou de mme type. Dans le cas de produits

Identifier les acteurs et les cas d'utilisation (voir la section 7.4.1) L'exhaustivit des besoins, ou la finalisation du modle des cas d'utilisation, dpasse l < moyens dont dispose la phase de cration. Les travailleurs impliqus dans cette phi t doivent, tout d'abord, dgager la fraction de cas d'utilisation ncessaire a son ai i ouipli sment, puis les dcrire en dtail, comme l'indique le chapitre 7. L'identification di d'utilisation est aborde dans la section 12.6.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase de c r a t i o n lance le projet

CHAPITRE 13

r j

371

De nouveau, le problme de la phase de cration csl de si' limita essentiellement ., dtail les cas d'utilisation affectant les objectifs de cette phase. Ne tenez pas i pte les i as il m, lisation, ni des branches et des chemins de cas d'utilisation, qui ne prsentent pas d'intrt pour la porte du systme et l'architecture candidate, qui n'impliquent aucun i isque critique ou qui ont peu d'effet sur l'tude de rentabilit initiale.

Cela signifie tout simplement que, si l'on examine un grand nombre de cas d'utilisation, seuls les plus pertinents seront dcrits en dtail. Par exemple, si l'on slectionne 50 % du total final des cas d'utilisation en tant que cas potentiellement pertinents et que l'on s'aperoit que seulement 20 %, en moyenne, des scnarios de chacun de ces cas d'utile.. doivent tre dtaills, on n'aura abord en profondeur que quelque 10 % de toute la m . des cas d'utilisation. L'ide est d'essayer de maintenir le cot et les dlais de la phase di cration un faible niveau. La valeur exacte de ces pourcentages sur des projetl Indh Idlit I dpend de leur difficult ou de leur caractre atypique. Tous les besoins fonctionnels devant tre pris en considration dans cette phase s sentes sous forme de cas d'utilisation, comme l'explique le chapitre / Prototyper l'interface utilisateur (voir la section 7.4.4) - Ne prsente aucun intrt dans cette phase. Structurer le modle des cas d'utilisation (voir la section 7.4.5) - Ne mobilise pas l'attention ce stade. pu

Pour slectionner les cas d'utilisation exploiter au cours de la phase de cration, le chef de projet travaille en collaboration avec l'analyste systme et l'architecte. La tche de l'analyste systme consiste rendre possible la dfinition de la porte du systme, tandis que l'architecte devra s'intresser chaque cas d'utilisation afin d'liminer ceux qui n'ont pas tre envisags plus prcisment. L'architecte doit galement se proccuper des risques critiques et significatifs et identifier les cas d'utilisation ncessaires la planification du travail d'architecture, qui fait l'objet de la phase suivante. Les efforts requis pourront tre trs limits dans certaines parties du systme dont l'architecte aura tudi les cas d'utilisation dans des systmes antrieurs et saura, par consquent, qu'ils ne prsentent pas d'intrt pour les objectifs de cette phase. L'architecte doit examiner tous les cas d'utilisation, au moins pour tre en mesure d'liminer ceux qui n'entrent pas en considration ce stade. Dfinir un ordre de priorit pour les cas d'utilisation (voir la section 7.4.2) Puis l'architecte considre le modle des cas d'utilisation et fournit des entres au chef de projet charg de crer le plan du projet ou le plan des itrations. Ce travail s'effectue paralllement celui des enchanements d'activits principaux de chaque phase : on peut, en effet, planifier les itrations venir tout en dtaillant les cas d'utilisation identifis. Le plan des itrations est le rsultat final refltant l'ordre de priorit des cas d'utilisation associs aux objectifs de cette phase.

13.4.2 Analyse
Les objectifs de l'enchanement d'activits d'analyse sont, d'une manire gnrale, d'ana lyser les besoins, de les prciser et de les structurer au sein d'un modle objet faisant office de premire bauche du modle de conception. Dans cette phase, cet enchanement se traduit par la cration d'un modle d'analyse initial ; ce dernier permet de dfinir prcisment les cas d'utilisation et sert de guide l'esquisse de l'architecture candidate, qui sera toffe dans la phase d'laboration. Cela signifie, bien sr, qu'une trs faible partie du modle d'analyse (environ 5 %) sera acheve au cours de la phase de cration. On pourrait caractriser le modle d'analyse dans la phase de cration comme une sorte de brouillon : il n'est qu'une premire tape vers la vue architecturale de ce modle. Procder l'analyse architecturale (voir la section 8.6.1) L'objet de la phase de cration consiste slectionner les cas d'utilisation ou les scnarios de cas d'utilisation qu'il faudra tudier avec attention dans le cadre de la cration, en veillant principalement les comprendre et les prciser. partir de cet ensemble initial de cas d'utilisation et de scnarios, l'architecte btit une premire version simple du modle d'analyse pour les parties concernes du systme. Inutile de viser l'exhaustivit ou la pet fection. I l n'est pas forcment indispensable de continuer enrichir ce modle dans la phase suivante : on peut trs bien le laisser en plan et n'en retenir que la valeur de guide. Analyser un cas d'utilisation (voir la section 8.6.2) Dans certaines situations, tudier les cas d'utilisation un par un ne suffira pas I e modi U di cas d'utilisation n'aborde qu'un cas d'utilisation la fois. Dans la ralit les cas d uiili sation partagent les ressources, telles que les bases de donnes ou les processeurs, au sein du systme. Or, le modle d'analyse dvoile ces ressources partages. Il faut dont palfol pousser l'analyse suffisamment loin pour rsoudre ces conflits.

I G

Dcrire en dtail un cas d'utilisation (voir la section 7.4.3) Tout en acceptant la ralit de cette limitation du travail, nous raffirmons nanmoins l'importance qui doit tre accorde la finalisation de toutes les branches des cas d'utilisation concerns dans la phase de cration, c'est--dire des cas d'utilisation ncessaires la dfinition de la porte du systme, ainsi qu' la planification de la rduction des risques et de la cration de l'architecture de rfrence. On croit trop souvent comprendre les besoins et les exigences alors que l'on est en train de passer ct de certains, absolument essentiels. De mme, on a frquemment tendance penser que les avantages qu'apporte la description dtaille des cas d'utilisation n'en valent pas le prix, ce qui est une profonde erreur de jugement. L'objectif est de savoir o l'on va. Cela n'implique toutefois pas de mener leur terme un nombre considrable de cas d'utilisation. Comme on ne cre gnralement pas de prototype architectural dans cette phase, i l n'est pas ncessaire de procder l'implmentation et aux tests. Si, nanmoins, vous souhaitez faire la dmonstration des principaux concepts en crant un prototype jetable, i l faudra prendre en compte pour ce prototype un faible pourcentage de la masse des cas d'utilisation (annexe C), qui sera explique par la suite. Il pourra tre ncessaire de dcrire en dtail environ 10 % de la masse des cas d'utilisation dans le modle des cas d'utilisation.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase de c r a t i o n lance le projet

CHAPITRE 13

On peut, dans l'enchanement d'activits de celle Itration, analysa I I iffllMI 11 rutlni i d'utilisation (les 10 % de la masse des cas d'utilisation) exposes c l . M I S la sec lion I | | \ dont on dtaillera ensuite la moiti, soit environ 5 % de la masse totale, Analyser une classe et analyser un paquetage Si l'on procde l'une ou l'autre de ces activits au cours de cette phase, c'esl de faon lout fait minime.

Concevoir un cas d'utilisation (voir la section 9.4.2) Dans la phase de cration, le travail de conception des cas d'utilisation reste tout fait mai ginal. Concevoir une classe et concevoir un sous-systme L encore, si l'on procde l'une ou l'autre de ces activits au cours de cette phase, c'est le faon tout fait minime.

13.4.3

Conception
L'objectif principal de l'enchanement d'activits de conception dans cette phase consiste esquisser un modle de conception afin d'intgrer l'architecture candidate la description de l'architecture prliminaire. S'il faut dvelopper un prototype de dmonstration, on emploiera des modules prfabriqus, des langages de quatrime gnration ou toute technique de dveloppement rapide permettant de montrer la validit du concept envisag. La dmonstration d'interfaces utilisateur et d'algorithmes inhabituels prsente l'intrt de convaincre tous les intervenants que le projet vaut la peine d'tre poursuivi. Ce prototype est prsent des utilisateurs reprsentatifs en vue de s'assurer qu'il satisfait leurs besoins et d'effectuer les changements ncessaires la lueur de leurs remarques. Procder la conception architecturale (voir la section 9.4.1)

3.4.4

Implmentation
La porte de cet enchanement d'activits dpend des dcisions prises prcdemment r Il chef de projet. Doit-il mettre un terme la phase de cration une lois qu'il dilj Ultl description de l'architecture candidate ?
1

D'un ct, certains prtendent qu'on ne peut tre sr que l'architecture candidate le tant qu'on - on incluant les intervenants - n'a pas observ un protolypi l'irii' peut avoir la certitude d'avoir lev un risque tant que la partie du prototype qui le naile m fonctionne pas rellement. D'un autre ct, la volont de maintenu les quipes cl li di in un niveau minimal commande d'interrompre les enchanements d'activits de la phase d. cration ds qu'existe la description d'une architecture qui semble marcher. Il ivvicui au chef de projet de dterminer jusqu'o dvelopper l'architecture candidate. Dans la plupart des cas, le chef de projet dcidera de s'arrter la description de l'architecture candidate : i l ne sera donc pas ncessaire de mettre en uvre l'enchanement d'activits d'implmentation. La mise au point d'un prototype de dmonstration (jetable) pourra cependant se rvler utile. Le projet devra alors appliquer un enchanement d'activits d'implmentation, mme si celui-ci reste limit.

Le propos de l'enchanement d'activits de conception est de mettre au point une premire esquisse (ou esquisse initiale) du modle de conception, premire tape vers la vue architecturale du modle de conception ralisant les cas d'utilisation (identifis prcdemment dans l'enchanement d'activits des besoins) sous forme de collaborations entre sous-systmes/ classes. Nous tenons identifier les interfaces (et tout au plus en dfinir quelques oprations) entre sous-systmes/classes, mme s'il s'agit d'une simple esquisse de la conception. Ces interfaces ont en effet de l'importance, car elles constituent le cur de l'architecture. I l faut en outre dfinir les mcanismes gnriques de conception ncessaires en tant que couches sous-jacentes des sous-systmes qui raliseront les cas d'utilisation identifis. On slectionne enfin le logiciel systme et les infrastructures prfabriques (frameworks) utiliser, qui forment la couche de middleware (voir la section 9.5.1). Ce modle de conception initial doit tre cr mme s'il se borne une simple esquisse, puisque nous nous arrtons, dans cette phase, la description de l'architecture candidate. Le modle de conception ne ralise pas seulement les besoins fonctionnels reprsents par les cas d'utilisation dsigns, mais aussi les exigences non fonctionnelles, telles que les performances, susceptibles d'entraner des risques. Si le systme propos doit tre dploy sur des nuds, l'architecte concevra une version petite chelle du modle de dploiement, limit, par exemple, aux nuds soumis des impratifs de performances ou aux connexions entre nuds. A ce stade, le chef de projet pourra demander un ingnieur de cas d'utilisation de modliser certaines parties de deux nuds ainsi que l'interaction entre ces deux nuds o se situe la difficult.

13.4.5 Tests
En parallle avec les activits d'analyse, de conception et d'implmentation, comme le montre la figure 13.2, les ingnieurs de tests se familiarisent avec la nature gnrale du systme envisag. Ils dtermine les tests qui seront ncessaires et mettent au point quelques tests provisoires. Les tests demeurent toutefois extrmement limits dans la phase de cration, comme l'indiquent les figures 11.2 et 13.1, la vocation du prototype de dmonstration exploratoire tant avant tout illustrative. Le chef de projet peut nanmoins estimer utile de procder un certain nombre de tests.

13.5 laborer l'tude de rentabilit initiale

Une fois que l'on constate, assez tard dans la phase de cration, que l'on dispose d'une an In tecture candidate et que les risques critiques peuvent tre surmonts, il est temps le H d la vision du projet en termes conomiques par l'tude des besoins en ressources, d Invt ii sements ncessaires, des projections de revenus et de l'acceptation (en interne o u i pal l' march. Cette tude de rentabilit prsente deux facettes : l'une est l'offre qui scia soi S U client, l'autre s'intresse aux gains conomiques que doit gnrer l'utilisation du produil

Un d v e l o p p e m e n t i t r a t i f et i n c r m e n t a l
PARTIE III

La phase de c r a t i o n lance le projet

CHAPITRE 13

375

13.5.1 Tracer les grandes lignes de l'offre

s u u

Nanmoins, l'tude de rentabilit reste toujours une proccupation dans les projets que les entreprises envisagent srieusement : elle ncessite toujours des recherches approfondie Les besoins en personnel et en dlais des premires itrations doivent tre finani n i e pris en charge. On nglige trop souvent le besoin qu'ont les chefs de projet, d a n s le | , mires itrations, de donnes sur lesquelles fonder le travail et le calendriei des proji I futurs. Il est donc impratif de garder la trace des mtriques adaptes la phase de , Ces chiffres fourniront une base pour l'estimation du nombre d ' i t r a t i o n s que dl Wl porter la phase de cration du projet suivant. Ils pourront aussi tre modifi! en Font lu degr de complexit du projet suivant par rapport celui des projets stockes d. i| .

h'

Les formules d'estimation qui sous-tendent l'offre commerciale dpendenl gnralement i la taille du produit final. l'issue de la phase de cration, toutefois, celle taille ( . venez-vous que seul un faible pourcentage de la masse des cas d'utilisation a t train risque de s'carter de la taille finale relle d'un pourcentage substantiel, de 50% exemple. la fin du projet, cette premire estimation risque donc de diverger du cot r dans les mmes proportions. Prenez, par exemple, les cas d'utilisation comme mesure de la taille dans un objectif d'estimation. Le nombre d'heures-homme ncessaire la conception, l'implmentation et aux i tests d'un cas d'utilisation peut varier d'une centaine quelques milliers. Plusieurs facteu peuvent expliquer un tel cart : le style : si les dveloppeurs concentrent un plus grand nombre de caractristiques au sein d'un mme cas d'utilisation, celui-ci sera plus puissant qu'un cas d'utilisation moyen mais risquera d'tre plus coteux en heures-homme ; la complexit du systme propos : plus le systme sera complexe, plus i l risquera de coter cher (pour une taille donne). Voyez si vous pouvez simplifier le systme en rduisant le nombre de fonctions ; la taille : un cas d'utilisation d'un systme modeste sera gnralement plus simple raliser qu'un cas d'utilisation d'un systme ambitieux. Ce facteur peut aller jusqu' multiplier par dix le nombre d'heures-homme par cas d'utilisation ; le type d'application : les systmes temps rel contraintes extrmes fonctionnant dans un environnement distribu, par exemples les systmes tolrants aux pannes/ haute disponibilit, influent sur le cot par cas d'utilisation selon un facteur de 3 5 par rapport des applications SIG sur une plate-forme client-serveur. Cette liste ne prtend pas l'exhaustivit. Les organisations de dveloppement et les intervenants peuvent affiner les variables d'estimation en constituant leur propre base d'exprience. En l'absence d'une telle base, nous vous suggrons de procder comme vous l'avez toujours fait. ces estimations s'ajoute ensuite celle des cots et des dlais d'apprentissage d'une nouvelle approche, de l'utilisation de nouveaux outils et de l'adoption des autres caractristiques nouvelles du Processus unifi. I l suffit une organisation d'une ou deux expriences avec le Processus unifi pour constater une baisse vertigineuse des cots, une rduction spectaculaire des dlais de mise sur le march et une amlioration notable de la qualit et de la fiabilit du systme.

.5.2 Estimer le retour sur

investissement

L'estimation de l'offre commerciale constitue l'une des deux laccltes de I ludl d bilit. En ce qui concerne l'autre facette, i l n'existe pas de formule miracle pOUl I I l lit ul dl gains que pourra gnrer le logiciel. Dans le cas d'un logiciel destine au m a i . lu i, , i. i, ,,, tels que le nombre d'exemplaires vendus, le prix de vente et la priode sui laquelle sVm leront les ventes doivent tre dtermins par le marketing et tranchs pal les responsables Dans le cas d'un logiciel usage interne, en revanche, il faudra demander aux services c on cerns d'valuer les conomies qu'ils esprent raliser. La marge d'erreur est gnralement assez large, mais au moins cette estimation offre-t-elle une base permettant de comparer les gains envisags aux cots identifis. Pour un produit logiciel commercial, l'tude de rentabilit devra inclure un ensemble d'hypothses de base sur le projet, ainsi que l'ordre de grandeur du retour sur investissement dans le cas o ces hypothses se confirmeraient. Pour garantir des chances raisonnables de rentabilit, les responsables estiment souvent le retour sur investissement en prenant, par mesure de scurit, la valeur la plus pessimiste. ce stade, l'tude de rentabilit est gnralement possible : i l parat profitable de poursuivre le projet. L'important, au moment de conclure la phase de cration, n'est pas d'avoir des chiffres exacts, mais d'acqurir la certitude que le systme ne dbordera pas le cadre des moyens conomiques de l'organisation et de son ou ses clients. On ne dispose alors pas des informations dtailles qui permettront de clore l'tude de rentabilit sur le plan financier ; il faut pour cela parvenir au stade o l'offre commerciale sera raisonnablement ferme et prcise. Ces hypothses seront rexamines la fin de la phase d'laboration, une fois le projet dfini plus prcisment.

6 valuer les itrations dans la phase de cration

Vers la fin de la phase de cration, ds qu'il dispose des informations adquates, le I hel de projet fixe les critres qui lui permettront d'valuer le niveau d'achvcmeni de la prei itration et de la phase dans son ensemble, comme l'explique en dtail la section I i .' -I I I dsigne galement un groupe (qui peut se limiter deux personnes) charg d'vluet I I phase. Ce groupe d'valuation comprend gnralement un reprsentant du client O des u n U

En principe, les quipes de projet ne sont pas en position de rdiger l'tude de rentabilit finale la fin de la phase de cration. Trop peu de facteurs sont alors runis. Le Processus unifi dlivrant l' offre ferme la fin de la phase d'laboration, nous appelons l'tude de rentabilit de la phase de cration tude de rentabilit initiale. Cette tude initiale doit se contenter, sans entrer dans le moindre dtail, de justifier le passage la phase d'laboration. Par exemple, dans l'tat actuel du march de l'informatique personnelle, i l ne sera pas utile de passer par une phase de cration pour s'apercevoir qu'aucune tude de rentabilit ne saurait justifier le lancement sur le march d'un nouveau logiciel de traitement de texte ordinaire.

mm
HM

u n dveloppement itratif et incrmental

PARTIE III

La phase de cration lance le projet

CHAPITRE 13

377

lisateurs. Les projets d'une certaine ampleur pourront rctptciii la pn-.cn.c .le reprsenta de tous les intervenants concerns. Certains de ces critres pcuvcnl se rvlei hors de p | dans le cadre du plan original. En voici quelques exemples :
()

extension du modle des cas d'utilisation jusqu'au point ncessaire dans celle phase ; laboration d'un prototype exploratoire de mise l'preuve du concept en tal de dmonstration ; suspicion d'une dtection seulement partielle des risques critiques ; fait que certains risques critiques dj recenss n'aient pas t correctement rduits ou suffisamment couverts par un plan visant les circonscrire.

de la masse des cas d'utilisation clairent tout ce qu'il faut savoir des cas d'utilisation significatifs ce stade. Cette fraction de l'ensemble des cas d'utilisation oriente le travail sur l'architecture de rfrence, qui comprend alors une description de l'architecture et des versions de tous les modles. C'est ainsi que l'on progresse travers les itrations indispensables la phase de cration (s'il en faut plus d'une). On peut supposer qu'il y aura une seule itration, mais les cas ...n. plexes peuvent en exiger plusieurs. On dcide ensuite de ce qui doit tre fait dans chaqu. n. ration, des besoins implmenter et tester et, en consquence, des risques a red L'exprience montre qu'une partie importante de la conception et de l'implrnentado au point dans la phase de cration, comme les prototypes exploratoires de misi .. I i p.. nv. du concept, ne conviendra pas au travail de construction de la phase suivante Vous prouvez peut-tre quelque difficult vous y retrouver entre Pour plus de clart, nous les avons regroups dans le tableau 13.1.
Ions . es p.

Le chef de projet transmet ces critres encore incomplets aux itrations suivantes et modifi en consquence les plans et les calendriers des itrations concernes. Par exemple, il faudra peut-tre que l'quipe s'adjoigne, dans une prochaine itration, les services de collaborateurs possdant certaines comptences ou un certain type d'exprience.

Tableau 13.1 : Exploitation des cas d'utilisation.

L'valuation de la phase de cration dbouche sur une dcision absolument cruciale : faut-il poursuivre le projet ou l'abandonner ? Aprs examen des objectifs de cette phase (porte^ risques critiques, architecture candidate), il est dcid s'il convient ou non de mener le projet son terme. I l faudra peut-tre attendre de parvenir ce jalon majeur pour prendre la dcision de poursuivre. En revanche, celle d'abandonner le projet devra tre prise ds que les lments permettant de justifier cet abandon seront runis. Il est vain de perdre son temps en efforts inutiles. Mais cette dcision ne saurait tre arbitraire. Le signal du feu vert ou de la suspension exige le concours de tous les intervenants, en particulier des responsables du financement et des reprsentants des utilisateurs. Il est toujours possible que le client trouve une solution de contournement au problme.

Modle du mtier O complet

Cas d'utilisation identifis

Masse des cas d'utilisation dcrits

Masse des cas d'utilisation analyss

Masse des c a s d'utilisation conus, implments et tests

13.7 Planifier la phase d'laboration

Phase de cration

50 70 %

50%

10%

5%

Un faible pourcentage pour un prototype de mise l'preuve du concept Moins de 10 % 100%

Phase d'laboration Phase de construction Phase de transition

Prs de 100 % 100%

Au moins 80 % 40 80 % 100% 100%

20 40 % 100% si maintenus

La fin proche de la phase de cration marque le dbut de la planification de la phase d'laboration, alors que se prcise la question du budget et du calendrier de cette phase. L'objectif est d'laborer environ 80 % de l'ensemble des besoins et exigences et de ne laisser dans l'ombre aucun aspect important de l'architecture. Il faut atteindre ce double objectif afin de pouvoir faire une offre plus prcise que ne le permettaient les donnes limites de la phase de cration ; cette offre servira en outre slectionner l'architecture. La proportion gnralement ncessaire l'laboration de l'offre commerciale est d'environ 80 %. Il faudra peuttre analyser la moiti de ces 80 % de cas d'utilisation pour acqurir une parfaite comprhension des besoins.

La cration de l'architecture de rfrence pourra ncessiter jusqu' 80 % des cas d'utilisation afin de s'assurer qu'aucun lment d'importance n'aura t nglig. Sur ces 80 %, ori slectionne la partie significative de la masse totale des cas d'utilisation sur laquelle reposera la conception de l'architecture de rfrence. Ces cas d'utilisation significatifs reprsentent une proportion plus faible de la masse totale que les 80 % recherchs : environ 40 % des cas d'utilisation et 20 % de chacun d'eux en moyenne. Le produit de ces pourcentages constitue une masse de cas d'utilisation d'environ 8 % seulement. En d'autres termes, moins de 10 %

Remarque : les chiffres d o n n s ici ne sont que des indications approximatives. Nous lalsons I I I K I .lin tinction entre identifier un cas d'utilisation (et en dire quelques mots) et le dcrire plus en dtail, qui I I I N sortit l'activit dtailler un cas d'utilisation (section 7.4.3). L'analyse des cas d'utilisation est r n l M n pm l'activit analyser un cas d'utilisation (section 8.6.2). La colonne de droite indique la proportion . l u In masse des cas d'utilisation figurant dans l'architecture de r f r e n c e la fin des phases.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l

378

PARTIE

III

13.8 lments livrer l'issue de la phase de cration

La phase de cration livre : une liste des caractristiques ; une premire version d'un modle du mtier (ou du domaine) dcrivant le contexte .lu systme ; une bauche des modles constituant une premire version du modle des cas d'utilisation, du modle d'analyse et du modle de conception, tandis que les modles d'implmentation et de tests resteront plus rudimentaires. I l existe galement une premire version des exigences supplmentaires ; un premier projet de description de l'architecture de rfrence accompagn d'esquisses des vues des modles des cas d'utilisation, d'analyse, de conception et d'implmentation ; ventuellement, un prototype exploratoire de mise l'preuve du concept, dmontrant l'utilisation du nouveau systme ; une liste initiale des risques et une liste de classement des cas d'utilisation ; les grandes lignes d'un plan concernant tout le projet et prvoyant les diffrentes phases ; une premire esquisse de l'tude de rentabilit comprenant : le contexte professionnel et les critres de russite (projection des revenus, notorit sur le march, estimation du projet). En principe, les intervenants ont dsormais une comprhension assez claire de la vision et de la faisabilit du projet. Un ordre de priorit entre cas d'utilisation a t tabli. Le chef de projet dispose maintenant d'informations suffisantes pour planifier en dtail la phase suivante. Les rsultats obtenus dans cette phase sont affins dans la phase d'laboration, laquelle est consacr le chapitre 14. En abordant la phase d'laboration, nous franchissons un jalon majeur marquant trois accomplissements : nous avons formul une architecture initiale - l'architecture candidate - , ce qui signifie que nous savons comment construire, pour le systme envisag, une architecture qui en englobera les parties innovantes ou dlicates ; nous avons identifi les risques les plus graves - les risques critiques - , que nous avons explors avec suffisamment d'attention pour acqurir la certitude que le systme est faisable ; nous avons tabli une tude de rentabilit initiale suffisamment dtaille pour permettre le passage cette deuxime phase et avons obtenu l'assentiment des diffrents intervenants, en particulier de ceux qui financent le projet.

14
La phase d'laboration fabrique l'architecture de rfrence

.1 La phase d'laboration en bref

Nos principaux objectifs sont les suivants : dgager la plupart des besoins et exigences restants, en exprimant les sous forme de cas d'utilisation ;
besoins lonetionnels

mettre en place des fondations architecturales saines - l'architecture de rfrence afin de guider le travail des phases de construction et de transition et prolonger ce lil condui teiu dans les gnrations suivantes ; continuer surveiller lesrisquescritiques restants et identifier les risques signifit .ml jusqu' ce qu'il soit possible d'en estimer l'impact sur l'tude de rentabilit, en partictihei sur l'offre commerciale ; finir de dtailler le plan du projet.

L'

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III CHAPITRE 14

(H

d'laboration. En s'appuyant sur une connaissance actualise des ressources, du calendrier et des personnes disponibles, le chef de projet modifie le plan de l'itration et le plan de la phase.

11

Pour atteindre ces objectifs, nous considrons une vue en coupe d'un kilomtre de largeu sur 3 cm de profondeur . Dans les cas o ce sont les risques technique! qui dominent ou qgj sont les plus significatifs, i l pourra tre ncessaire d'aller un peu plus en prolondcui p , mettre en place une architecture saine. Dans un projet d'envergure, d faudra peut tre eu plus considrer une vue en coupe d'un kilomtre de profondeur sur 3 cm de largeur des points les plus dlicats du systme. Les architectes du systme doivent identifier ds que possible les parties les plus prilleuses et lancer des claireurs sous forme de prototypes ou de pilotes pour identifier et grer les risques.

14.2.2 Constituer

l'quipe
-

Tout ce qu'a dcouvert l'quipe l'uvre dans la phase de cration n'a pas t c n u s i p i i i chef de projet conserve donc autant de membres de l'quipe initiale que le n c e s s i t e la pli > d'laboration. Ces personnes constituent, en quelque sorte, la mmoire de I i qinpi t outre, d'autres comptences passent au premier plan de l'laboration Par exampli II pet sonnes ayant une connaissance oprationnelle des briques de base leuidi ..iM. . d. \ indispensables. D'ailleurs, l'quipe d'laboration est gnralement un peu plut lltl|
que l'quipe de cration. On embarque de nouvelles recrues. I.c ehel de pi*.in ,i |<

Les dcisions architecturales sont prises partir d'une comprhension du systme dans son ensemble : sa porte et ses exigences fonctionnelles et non fonctionnelles, comme celles de performances. I l faut de plus veiller quilibrer les exigences, telles qu'elles s'expriment dans les cas d'utilisation et le modle des cas d'utilisation, par rapport l'architecture. Le modle des cas d'utilisation et l'architecture sont labors de concert et s'influencent mutuellement (voir la section 4.3).

tionner certaines de ces personnes et leur donner la possibilit de poursuivie lent lui vin I dan la phase de construction et, ventuellement, de diriger les quipes de conception

14.2.3 Modifier l'environnement

de

dveloppement

Dans la phase d'laboration, l'attention se porte principalement sur la formulation de l'architecture de rfrence, ce qui implique de combler environ 80 % des cas d'utilisation et de traiter les risques faisant obstacle cet objectif. L'environnement de dveloppement se voit galement enrichi, non seulement pour permettre la conduite des activits propres cette phase, mais aussi pour prparer la phase de construction. On aura accumul, vers la fin de cette phase, suffisamment d'informations pour planifier la phase de construction, et l'on disposera aussi des informations ncessaires l'laboration d'une tude de rentabilit fiable, commence dans la phase de cration.

la lueur des dveloppements de la phase de cration et de ceux prvus dans la phase d'ela boration, le chef de projet continue mettre en uvre les changements de r environnement de dveloppement, d'abord traite par la section 13.3.2. 14.2.4 Dfinir les critres d'valuation

14.2 Premiers stades de la phase d'laboration

Les critres spcifiques auxquels doit satisfaire une itration ou la phase d'laboration tout entire sont propres chaque projet, mais on peut en examiner les rsultats en termes d'objectifs de la phase.

14.2.4.1 Dvelopper les besoins et les exigences

Les critres d'valuation sont indiqus ci-dessous. Les besoins et exigences, les acteurs et les cas d'utilisation ncessaires la conception de l'architecture de rfrence, l'identification des risques significatifs et la prise en charge de l'tude de rentabilit et de l'offre commerciale ont-ils t identifis ? Ont-ils t suffisamment dtaills pour que les objectifs de cette phase soient atteints ?

Pour commencer, la phase de cration transmet la phase d'laboration un plan en dcrivant les grandes lignes, un modle des cas d'utilisation partiellement rempli et une description de l'architecture candidate, auxquels peuvent ventuellement s'ajouter les prmices d'un modle d'analyse et d'un modle de conception. I l vaut mieux ne pas compter rutiliser ces modles, qui peuvent toutefois servir de guide. L'une des tches de la phase d'laboration consiste enrichir ces modles, l encore non pas de faon complte, mais jusqu'au stade qui permettra de dgager l'architecture de rfrence.

14.2.4.2 tablir l'architecture de rfrence

Les critres d'valuation sont indiqus ci-dessous. L'architecture de rfrence excutable satisfait-elle non seulement aux besoins ei aux exigences formellement exprims jusqu' prsent, mais aussi aux besoins ressentis pai li intervenants face une architecture de rfrence en tat de fonctionnement 7 L'architecture de rfrence parat-elle assez robuste pour rsister la phase de construction et l'ajout des caractristiques que pourront ncessiter les versions ultrieures ?

On pourra galement disposer d'un prototype de mise l'preuve du concept dmontrant l'utilisation du systme, mais qui ne servira pas de base la construction dans la phase suivante. Ce prototype est gnralement mis au point le plus vite possible dans l'unique objectif d'tablir la faisabilit du systme.

14.2.1 Planifier la phase

d'laboration

Il est possible que la planification de cette phase, mene la fin de la phase de cration, ne soit pas tout fait complte. Souvent, les ressources qui seront disponibles dans la phase d'laboration ne sont pas entirement connues avant le dbut de cette phase. Dans certains cas, i l s'coule un laps de temps entre la fin de la phase de cration et le dbut de la phase

Un d v e l o p p e m e n t itratif et i n c r m e n t a l PARTIE III

La phase d ' l a b o r a t i o n fabrique l'architecture de r f r e n c e CHAPITRE 14

14.2.4.3 Rduire les risques significatifs

Les critres d'valuation sont indiqus ci-dessous. Lesrisquescritiques ont-ils t rduits comme il convient, c'est--dire soil limins, soit circonscrits dans le cadre d'un plan adquat ? Tous lesrisquessignificatifs ont-ils t identifis (voir l'identification des risques significatifs dans les sections 12.2.2 et 12.5) ? Les risques significatifs ont-ils t explors au point d'tre sous tutelle ? Les risques figurant toujours sur la liste des risques pourront-ils tre facilement vacus dans la phase de construction ?

cas extrmes, plusieurs itrations, selon la porte du systme, les risques, le degr de non veaut, la complexit de la solution technique et l'exprience des dveloppeurs.

14.2.4.4 Estimer la valeur de l'tude de rentabilit

Les critres d'valuation sont indiqus ci-dessous. Le projet est-il suffisamment dfini pour que l'on puisse en dterminer le cot, le calendrier et le niveau de qualit ? Le projet, tel que le dcrit l'tude de rentabilit, est-il susceptible de produire le retour sur investissement ou de rpondre au taux d'obstacle l'investissement prescrit par le secteur I d'activit ? En bref, sommes-nous prts signer un contrat de forfait (ou l'quivalent en dveloppement interne) ?

L'objectif de l'exploration des risques dans cette phase n'est pas d'liminer les risques de go, mais de les ramener un niveau acceptable pour la phase de construction Poui II F i o muler diffremment, on pourrait dire que la phase d'laboration affronte les risques u , h niques architecturaux... en implmentant l'architecture ! Qu'entend-on par niveau dl risqui acceptable dans la phase de construction ? Tout simplement que les risques oui t exploit jusqu'au point o l'on entrevoit le moyen de les rduire ou d'estimer les elloits et I, i, m,, ncessaires cette rduction. En ralit, les risques ne seront pas limiiu s i. tut li i i d'utilisation les englobant n'auront pas t implments, ce qui se fera paiioi ilan i i pli d'laboration, le plus souvent dans la phase de construction et d'autres fois plus lardh dans la phase de transition. L'essentiel du travail est effectu au C U J de la I OT l. i, besoins, de l'analyse et de la conception ; i l faut comprendre la plupart ,!e bai cevoir le systme. En comparaison, l'implmentation et les tests exigent moins >I. sources.
Ressources

14.3 Enchanements d'activits de l'itration typique d'laboration

Figure 14.1 < Le travail d'une . itration de la phase d'laboration traverse les cinq enchanements d'activits principaux.

Enchanements d'activits principaux ^ Besoins ^ Analyse ^ Conception ^ Implmentatior^ Tests ^

4
Se concentrent sur l'architecture Enchanements d'activits des Itrations d'laboration

14.3.1 Formuler et affiner la plupart des

besoins

L'itration typique se compose des cinq enchanements d'activits, comme l'illustre la figure 14.1. Ces enchanements d'activits ont, certes, dj t dcrits dans la deuxime partie de cet ouvrage, mais ce chapitre ne s'intresse qu'au rle qu'ils jouent dans l'laboration. L encore, quatre ensembles d'activits sont en parties menes en parallle. Le premier de ces ensembles regroupe les enchanements d'activits principaux ; le deuxime s'attache la planification des itrations, dcrite par les sections 12.4 12.7 et par la section 14.2.1 ; le troisime est celui d'valuation, abord dans les sections 12.8 et 14.6 ; enfin, le dernier consiste parfaire la prparation de l'environnement de dveloppement, pralablement prsent dans la section 13.5. Dans cette section, nous nous contenterons de fournir une prsentation gnrale des enchanements d'activits principaux et de leur rle dans l'laboration, sur lesquels nous reviendrons plus en dtail dans la section 14.4. Au cours de la conception architecturale , seuls les besoins et exigences pertinents sur le plan architectural sont formuls, analyss, conus, implments et tests. On prte peu d'attention aux dtails non pertinents sur le plan architectural, qui sont repousss la phase de construction. L'architecture de rfrence ne de ces efforts ne sera qu'un systme minimal. En lui-mme, ce systme ne fera pas grand-chose, sauf dans les parties qui doivent tre implmentes suffisamment en dtail pour s'assurer du fonctionnement de l'architecture dans son ensemble. L'architecture de rfrence est mise au point en une, deux ou, dans les

Que signifie ici formuler la plupart des besoins? Nous avons ouverl le dbet IU! CCtti question dans la section 13.7, au moment de commencer planifier la phase d'claboialioii il a t dit qu'il fallait se fixer pour objectif d'avoir identifi environ 8 0 % des cas dinde,. On peut dcrire en dtail entre 4 0 et 80 % de la masse des cas d'utilisation II n'esl pas Indil pensable d'identifier tous les cas d'utilisation et il est inutile de dcrire en dtail tOUI I U que l'on a identifis : on sait d'exprience que certains sous-systmes peuvent tre iinmedia tement conus (sur le plan architectural), qu'ils ne contiennent aucun risque et qu'ils peuvent faire l'objet d'une offre prcise. Voyez aussi les chapitres 6 et 7.

Il
I

I M B I J

Un d v e l o p p e m e n t i t r a t i f et i n c r m e n t a l

La phase d ' l a b o r a t i o n fabrique l'architecture de r f r e n c e CHAPITRE 14

mmm PARTIE III

Sur la masse des cas d'utilisation dcrits en dtail, environ la moiti doivent tre exami trs attentivement en analyse. Parmi ces derniers, il suffira gnralement de ne prendre compte qu'une partie des scnarios concevoir, implmenter cl a leslei poui eial l'architecture et rduire les risques. Examinez le tableau 13.1 ; le but est de Ibrmulei besoins en vue d'atteindre ces objectifs, sans aller au-del.

d'utilisation pour permettre l'tablissement d'une offre juste et prcise. I l convient, en outre, de clore cette phase avec une architecture de rfrence excutable et stable, susceptible d'tre enrichie dans la phase de construction. I l faut par consquent prter plus d'attention a la qualit et l'extensibilit que ne l'exigeait la phase de cration.

14.3.2 Dvelopper

l'architecture

de

rfrence

Le dbut de cette itration consiste explorer les risques et identifier les cas d'utile... comme le dcrit le chapitre 12. I l s'agit de couvrir environ 80 % des besoins et des e s t afin de dtecter ceux ayant de l'importance pour l'architecture, mais aussi de rMMmblci ul fisamment d'informations pour faire une offre. D'une manire gnrale, il tant b i e i proportion de cas d'utilisation pour identifier les 10% ncessaires au de*velop| il l'architecture de rfrence.

L'architecte assigne un ordre de priorit aux cas d'utilisation et mne les activits d'analyse de conception et d'implmentation au niveau architectural, comme le dcrivent en dtail les chapitres 8, 9 et 10. D'autres travailleurs se chargent des activits d'analyse et de conception, comme l'indiquent les chapitres 8 et 9 : ils analysent les classes et les paquetages (voir le chapitre 8), et conoivent les classes et les sous-systmes (voir le chapitre 9). Les ingnieurs de tests s'attachent tablir l'environnement de tests et tester les composants et toute l'architecture de rfrence mettant en uvre les cas d'utilisation significatifs sur le plan architectural.

14.3.3 Procder

des itrations

tant que l'quipe

est

rduite

On considre, dans le projet hypothtique suivant, un systme modrment c ompl. i iloiii l'architecture de rfrence natra en une seule itration. O n suppose qu'il l'tgll d dl loppement tout neuf (green field). Comme nous l'avons djl liqu II i ht I dl |il(i|i i dispose des premiers lments d'un plan du projet et d'un plan d Iti rttion n loti dtaill pour la premire itration, issus de la phase de cration, l a premire 4U| toffer le plan de l'itration en collaboration avec l'archilecle et les piiui ipnux d. m loppeurs.
1111

Tant que l'quipe reste limite, comme elle l'est pendant l'laboration, c'est le moment de procder des itrations et d'essayer diffrentes solutions (technologies, infrastructures, structures, etc.). Si le projet reprsente une gageure, i l faudra peut-tre trois ou quatre itrations avant d'obtenir une architecture stable. Plus tard, dans la phase de construction, lorsque votre quipe comptera plusieurs dizaines de personnes et qu'il faudra suivre des centaines de milliers de lignes de code, i l sera indispensable de s'appuyer sur une architecture stable et de faire voluer le systme de manire incrmentale.

La description qui suit s'articule autour des cinq enchanements d'activits C e scqiien cment des enchanements d'activits pourrait laisser penser qu'ils doivent Imprativement se suivre, alors que diverses tches peuvent tre effectues en parallle, comme le montre la figure 14.2.
Figure 14.2 Les patatodes > traces la main regroupent les principales activits de la phase d'laboration.

Une seule itration pourra suffire si le systme est modeste et simple, tandis qu'il en faudra plusieurs dans le cas d'un systme vaste et complexe. Le nombre d'itrations supplmentaires dpend de considrations telles que la complexit du systme et de l'architecture de rfrence devant le guider, et la gravit des risques. Les itrations se poursuivent jusqu' ce que l'architecture parvienne un niveau stable, c'est--dire qu'elle reprsente le systme de faon acceptable et qu'elle ait atteint le point o les probabilits de changements sont assez faibles.

14.4 Excuter les enchanements d'activits principaux : des besoins aux tests
La phase d'laboration poursuit le travail amorc dans la phase de cration. Mais s'il suffisait, pendant la cration, de dmontrer qu'il serait possible de construire une architecture dans une phase ultrieure, i l s'agit maintenant de commencer la raliser. Nous allons revisiter ce qui a dj effectu, en ayant conscience qu'assez peu d'lments seront vritablement rutilisables. I l s'agit dsormais de rechercher non seulement les cas d'utilisation reprsentant des risques critiques, mais galement ceux qui prsentent de l'intrt pour l'architecture. Deuximement, i l faut parvenir une couverture beaucoup plus large des cas

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase d ' l a b o r a t i o n fabrique l'architecture de r f r e n c e

CHAPITRE 14

14.4.1 Formuler les

besoins

14.4.1.3 Assigner un ordre de priorit aux cas d'utilisation

Nous allons, dans cette section, identifier, hirarchiser, dtailler cl structurel les c a s d'u sation (pour un traitement plus dtaill des besoins, voir les chapitres 6 et 7).

14.4.1.1 Identifier les cas d'utilisation et les acteurs

L'analyste systme identifie des cas d'utilisation et les acteurs supplmentaires, au-del ceux recenss dans la phase de cration (voir la section 7.4.1). S'il est indispensable de comprendre environ 80 % des cas d'utilisation pour atteindre les objectifs de cette phase, il n'est pas ncessaire d'en dtailler autant. On peut les identifier presque tous (les fameux 80 %), mais on n'en dcrit qu'une fraction, et l'on n'analyse que certaines parties des cas dcrits. Par comprendre, nous entendons comprendre ce qui compte sur le plan architectural et s'assurer qu'aucun lment susceptible d'influer sur l'architecture ou sur l'offre commerciale n'est rest dans l'ombre. La proportion de besoins formuls dpend galement du degr de fidlit exig. Si l'on est sur le point de faire une offre forfaitaire, i l faudra sans doute dtailler un plus grand nombre de cas d'utilisation, ventuellement jusqu' 80 % d'entre eux. Pour certains systmes complexes, i l peut tre ncessaire d'identifier presque tous les cas d'utilisation et d'en dtailler 80 %. Si l'on finance soi-mme le projet, on pourra s'arrter un pourcentage plus faible, ce qui aura cependant pour effet d'augmenter les risques. I l revient aux responsables de dcider si l'on peut accepter un niveau de risques plus lev en change de dlais et d'efforts moindres consacrs la phase d'laboration. Ce serait, peut-tre inconsciemment, conomiser un franc et en dpenser mille que d'tre confront par la suite des risques substantiels parce que l'on a voulu faire des conomies de bouts de chandelle sur l'instant.

L'enrichissement du modle partiel des cas d'utilisation labor dans la phase de cration suit deux fils conducteurs : d'une part, complter un plus grand nombre de cas d'utilisation de l'autre, exploiter l'architecture de rfrence (voir la section 7.4.2). Si l'on consacre d'abord du temps l'identification d'un nombre accru de cas d'utilisation avant tic passa a l'architecture, ces deux activits doivent quand mme se coordonner. Les dcisions que I 'on prend alors sont influences par le niveau de priorit affect aux risques perus cl pai l'onln dans lequel on dcidera de poursuivre le dveloppement (voir le chapitre 7, section / I ' Activit: dfinir un ordre de priorit pour les cas d'utilisation, et le chapilie I section 12.6, Dfinition d'un ordre de priorit pour les cas d'utilisation i A parti) du modle des cas d'utilisation, l'architecte produit une vue qui figurera dans la d. si iq i. l'architecture.
1

14.4.1.4 Dtailler un cas d'utilisation

Les spcificateurs de cas d'utilisation compltent les cas d'utilisalii essnues a I. < prhension totale des besoins et indispensables la cration de l'an Inici nue de rfn m i Pour de plus amples informations sur les spcificateurs de cas d'utilisation, reportaiTOUSS U chapitre7, section7.4.3, Activit : dtailler un cas d'utilisation . Dans cette phase, nous allons limiter nos efforts aux descriptions prliminaires des cas d'utilisation complexes cl significatifs sur le plan architectural. En gnral, on ne s'attarde pas sur l'intgralit des cas d'utilisation slectionns : on se borne en dtailler les scnarios ncessaires cette phase. Inutile de pousser la description au-del du strict ncessaire. Toutefois, comme nous l'avons indiqu prcdemment, dans certains cas complexes i l faudra dtailler presque tous les scnarios et les cas d'utilisation, soit prs de 100 % de la masse des cas d'utilisation.

14.4.1.2 Prototyper les interfaces utilisateur

Une autre activit lie la formulation des besoins consiste identifier les interfaces utilisateur (voir la section 7.4.4).

14.4.1.5 Structurer le modle des cas d'utilisation

L'analyste systme rvise le travail qu'il a effectu et recherche les similitudes, les simplifications et les opportunits susceptibles d'amliorer la structure du modle des cas d'utilisation. I l emploie des mcanismes tels que l'extension et la gnralisation (voir la section 7.4.5) pour obtenir un modle mieux structur et plus comprhensible. Le modle pourra se rvler plus simple modifier, toffer et entretenir, puisqu'on y limite, par exemple, les redondances. I l arrive, toutefois, que l'analyste ne peroive pas tout de suite la meilleure structure, mais qu'il doive attendre le passage des cas d'utilisation dans les enchanements d'activits d'analyse et de conception.
Structuration du m o d l e des cas d'utilisation En travaillant sur le modle des cas d'utilisation, les dveloppeurs dcouvrent que plusiouis cas d'utilisation prsentent des ralisations semblables. Par exemple, les cas d'utilisnlinn Commander des marchandises ou des services,Confirmer la commande,I ai Iurer l'acheteur et Envoyer des relances supposent tous l'envoi de Transactions commerciales entre Acheteurs et Vendeurs. Ce comportement commun peut tre mis ou uni vre par un cas d'utilisation rutilisable Soumettre la t r a n s a c t i o n commerciale, introduit par la restructuration du modle des cas d'utilisation. Lorsqu'ils procdent la ra lisation des cas d'utilisation, les dveloppeurs rutiliseront la ralisation de Soumettre 1 a t r a n s a c t i o n commerci al e. Les transactions commerciales impliques dans cet ensemble

On ne se soucie des interfaces utilisateur au cours de l'laboration que si celles-ci prsentent un intrt sur le plan architectural, ce qui est rarement le cas. Il arrive toutefois qu'elles aient un caractre unique, d'une faon ou d'une autre. Si c'est le cas, i l sera peut-tre ncessaire de crer votre propre infrastructure (framework) d'interfaces utilisateur. Ce sera indispensable, par exemple, si le systme que vous cherchez dvelopper est lui-mme une infrastructure d'interfaces utilisateur ; ou bien si le systme en question utilise des protocoles de communication particuliers, pouvant influer sur l'architecture en termes de performances ou de temps de rponse. Il existe enfin une autre raison de crer une interface utilisateur mme si celle-ci n'est pas significative pour l'architecture : pour vrifier, de la bouche mme des vritables utilisateurs, qu'elle fonctionne bien. Cette solution extrme ne sera toutefois retenue que si la valeur du systme n'a pas t prouve au cours de la phase de cration. En rgle gnrale, i l n'est pas utile de prototyper les interfaces utilisateur pendant la phase d'laboration.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase d ' l a b o r a t i o n fabrique l'architecture de r f r e n c e

CHAPITRE 14

a n

C C N A N

Rengociation des besoins

de cas d'utilisation, telles que Facture, Commande et ton I i rnui l. i mi <i,< , m , i , h . gent d'tat de faon semblable, prennent en charge des oprations identique; ci M.UI ges entre Acheteurs et Vendeurs. L'existence de telles similitudes signifie que i. ii,- , transactions peuvent trouver leur origine dans une mme classe abstraite : I ransactlon commerciale.
M :

14.4.2 Analyse

Imaginons une entreprise commercialisant un logiciel d'analyse de portefeuilles d'actions appel Portfolio-Plus, destin des clients privs. Il y a trois ans, les clients pouvaioni se satisfaire d'entrer manuellement les changements du cours des actions. Avec l'explosion du Web, les clients sont devenus beaucoup plus exigeants. Ils peuvent obtenir les cotations sans effort, gratuitement et presque en temps rel. Pour demeurer concurrentiel, Portfolio-Plus doll pouvoir recevoir les cotations au mme rythme. En raison de son architecture, les modifications qui permettraient Portfolio Plus d'tre dlrei tement en phase avec l'indice des cotations demanderaient un tr.iv.nl considrable Uni

Nous allons maintenant complter l'bauche du modle d'analyse trace dans la phase de cration (pour une description complte de l'analyse, voir le chapitre 8), dont il faudra peuttre abandonner certaines parties importantes. La phase d'laboration s'appesantit sur les cas d'utilisation complexes et sur ceux ayant de l'importance sur le plan architectural, qu'il faut prciser afin d'acqurir une meilleure comprhension des soubassements de l'offre commerciale.

Adapter les besoins et les exigences l'architecture

solution moins onreuse consisterait utiliser l'API dveloppe prcdemmenl pour i les entres d'un tableur Excel. Il suffirait d'implmenter dans Portfolio-Plus une ni.iuo qui i seulement chargerait un tableur Excel, mais qui en demanderai! de plus une nouvelle vol h m sur le site Web de la socit, o se trouveraient les cotations demandes pai l'utilist* travail se limiterait alors trois tches : gnrer le tableur sur le site Web la demande des clients de Portfolio-Plus H permettre au site Web d'accueillir les utilisateurs de Portfolio-Plus dans les proportions attendues ; crire la macro qui ira cherche le tableur Excel, ffill Dans la ralit

mesure que l'on formule des besoins supplmentaires (c'est--dire que l'on complte de nouveaux cas d'utilisation), les connaissances accumules sur l'architecture en cours de dveloppement permettent de procder plus intelligemment (voir la section 4.3). L'estimation de la valeur et du cot de chaque nouvelle suggestion de besoin ou de cas d'utilisation se fait la lumire de l'architecture de rfrence dont on dispose alors. C'est l'architecture qui nous dit si tel ou tel besoin sera simple ou difficile implmenter.

L'exemple suivant montre les possibilits de rutilisation dans un contexte rel et l'impact que peuvent avoir les ngociations sur le projet. En ngociant les besoins avec le client la lueur d'une architecture disponible, on parvient construire des systmes de qualit suprieure moindre cot. Cette amlioration peut tre illustre par un exemple typique concernant une entreprise de tlcommunications. Le client avait prpar une liste prcise de besoins sous une forme quivalant des cas d'utilisation. D'aprs ses estimations, il apparaissait que la construction du systme partir d'une base personnalise aurait ncessit 25 annes-homme. Le fournisseur de logiciels a pu dmontrer aux dirigeants de l'entreprise de tlcommunications qu'en modifiant leurs besoins pour les aligner sur l'architecture existante, ils pouvaient obtenir un rsultat similaire, sinon d'identique. Mais surtout, les frais de dveloppement taient rduits de 90 % ! L'entreprise de tlcommunications a donc dcid de conserver cette architecture. Elle a obtenu un systme qui tait en fait un produit standard, lgrement modifi pour prendre an compte ses besoins propres. Cette option a permis d'conomiser 20 annes-homnn i de deve loppement. En plus, l'entreprise n'a pas eu faire face au cot permanent do m.iinlcM. des logiciels et matriels personnaliss et a pu, au contraire, se reposer sur les services de maintenance incomparablement plus abordables fournis avec le produit standard.

Aprs avoir tudi la situation que crerait l'mergence d'un nouveau besoin, on peut s'apercevoir, par exemple, qu'une modification des besoins (une modification ayant peu ou pas d'impact smantique) serait susceptible de simplifier le fonctionnement de l'implmentation. Pour quelle raison ? Tout simplement parce que cette modification amnerait une conception plus compatible avec l'architecture existante. Tout changement de ce type devra faire l'objet d'une ngociation avec le client. Tandis qu'avancent l'analyse, la conception, l'implmentation et les tests du systme, toutes les modifications de la conception doivent tre alignes sur l'architecture dj en place dans le modle de conception existant. Il faut, pour cela, prendre en compte les sous-systmes, composants, interfaces, ralisations de cas d'utilisation, classes actives, etc., existant dj. C'est cette condition que l'on pourra crer, de manire rentable, une nouvelle conception partir de ce dont on dispose.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase d ' l a b o r a t i o n fabrique l'architecture de r f r e n c e

CHAPITRE 14

mm
K

14.4.2.2 Analyser un cas d'utilisation

La diffrence entre ce que souhaitait au dpart le client et ce qu'il a flnalemenl accept d'acheter est le rsultat d'une restructuration des cas d'utilisation effectue pai le fournlsseui De lgres modifications des interfaces utilisateur, des moyens de surveillance diffrents des principaux processus, un changement des mesures et des prsentations du flot du trafic, etc., expliquent cette incroyable baisse des cots de 90 %. En plus, le client a obtenu davantage de fonctions qu'il n'en avait rclames ; il a en effet acquis, pour un prix infrieur, ce que des clients prcdents avaient largement financ. Si le fournisseur a pu maintenir un faible niveau le prix de ces fonctions supplmentaires, c'est qu'il les avait dj implmentes et testes.

Beaucoup de cas d'utilisation, tels qu'ils apparaissent uniquement dans le modle des l as d'utilisation, ne sont pas clairement comprhensibles (voir la section 8.6.2). Ils doivent 6tT prciss par des classes d'analyse qui figurent dans le contexte des besoins, niais qui ne ., mi pas forcment directement implmentes. Cette ncessit se ressent particulirement poui les cas d'utilisation complexes et ceux exerant une influence mutuelle, c'est due ceux qui dpendent les uns des autres. Par exemple, pour que tel ou tel cas d'utilisation puisse I, i certaines informations, i l faudra que celles-ci aient t pralablement fournie! pat d lUUTi cas d'utilisation. Les cas d'utilisation intressants pour l'architecture et ceux qu'il est important d prendre sont donc prciss par le biais de classes d'analyse. Les autres i as il util qui ne sont pas pertinents pour l'architecture ou pour la compiliension des lu soin m sont ni affins, ni analyss. Les ingnieurs de cas d'utilisation se conlenieni de I. . , ompri ndr prcisment et de s'assurer qu'ils n'ont aucun impact. Ils sauront comment M M i l M moment o i l faudra les raliser, c'est--dire pendant la construction.

Cette section aborde les activits d'analyse architecturale, d'analyse des cas d'utilisation, d'analyse des classes et d'analyse des paquetages. I l faut se soucier des cas d'utilisation d'analyse significatifs pour l'architecture, qui reprsentent en gnral moins de 10 % de la masse des cas d'utilisation. On analyse galement les cas d'utilisation afin de les comprendre plus prcisment et de cerner leurs interfrences mutuelles. I l se peut qu'on ait, au total, examiner environ 50 % de la masse des cas d'utilisation dcrits en dtail.

14.4.2.1 Procder l'analyse architecturale

Dans la phase de cration, nous n'avons men l'analyse architecturale que jusqu'au stade permettant d'tablir que l'architecture tait faisable (voir la section 8.6.1). Ce qui ne va gnralement pas trs loin. I l faut maintenant pousser cette analyse pour dmontrer qu'il est possible de prendre en charge une architecture complte, c'est--dire une architecture de rfrence excutable.

Il n'est pas ncessaire de pousser trs loin la description des cas d'utilisai uni signifie utils ou complexes : i l sufft que les analystes comprennent ce qu'expriment les cas d'utilisation, c'est--dire l'architecture de rfrence et l'tude de rentabilit. Si l'on a examin 80 "/, des cas d'utilisation pour en comprendre le rle dans le systme et dcrit moins de 40 % de la masse des cas d'utilisation, on en traitera nettement moins pendant l'analyse, puisque certains d'entre eux n'ont aucune influence sur l'tude de rentabilit. (Au sujet de ces pourcentages, consultez le tableau 13.1.) Les ingnieurs de cas d'utilisation commencent ensuite trouver les classes d'analyse ralisant les cas d'utilisation. Us utilisent comme entres les classes significatives pour l'architecture identifies par l'architecte et leur affectent des responsabilits. Une grande partie du travail d'analyse des cas d'utilisation consiste parcourir chaque cas d'utilisation du modle des cas d'utilisation et le prciser par des classes et les responsabilits correspondantes. Il s'agit galement de montrer les relations entre ces classes, ainsi que leurs attributs.
filEBH R e s p o n s a b i l i t s des classes Pendant qu'ils travaillent sur le cas d'utilisation Rgi er la facture dans la premire itration, les dveloppeurs suggrent une classe pour la programmation et la ralisation des paiements (l'chancier) ayant les responsabilits suivantes : crer une requte de paiement ; dclencher le virement la date d'chance. Il est possible que, dans une itration ultrieure, les dveloppeurs se rendent complu qi ! te classe doit comporter d'autres responsabilits. L'ajout de ces nouvelles responsabilits ne doit pas ncessiter la restructuration de la classe. Un bon modle d'analyse doit pomintlin d'ajouter de nouvelles responsabilits sans avoir jeter ce qui existe ou, pin;, ;i nisiini luiei dans des itrations ultrieures les classes dj identifies. Ces responsabilit:; ptuiiitini l'he par exemple :

Dans cette optique, l'architecte procde une premire dcomposition (de haut niveau) du systme en paquetages d'analyse, partir de la vue architecturale du modle des cas d'utilisation, des besoins associs, du glossaire et de la connaissance du domaine disponible sous forme de modle du mtier (ou d'un modle du domaine simplifi). Il identifie les paquetages spcifiques l'application et ceux qui sont gnraux aux applications : ce sont les plus importants du point de vue du problme. Tout en examinant les cas d'utilisation pilotes dans la vue architecturale du modle des cas d'utilisation, l'architecte peut identifier des paquetages de service et des classes d'analyse vidents et significatifs pour l'architecture. De mme, tout en s'appuyant sur les besoins collectifs des cas d'utilisation, i l recherche les mcanismes sous-jacents ncessaires l'implmentation des cas d'utilisation. I l identifie les mcanismes gnriques d'analyse (voir la section 8.6.1.3), parmi lesquels les collaborations gnriques (voir le chapitre 3) et les paquetages gnriques. Les collaborations gnriques comprennent des fonctions telles que la rcupration aprs erreur et le traitement des transactions, tandis que les paquetages gnriques regroupent des fonctions comme celles de persistance, d'interfaces utilisateur graphiques et de distribution des objets. L'architecte est dsormais en position d'amliorer la vue du modle d'analyse.


M\

Un d v e l o p p e m e n t itratif et i n c r m e n t a l

La phase d ' l a b o r a t i o n fabrique l'architecture de r f r e n c e

CHAPITRE 14

assurer le suivi des rglements programms ; envoyer une facture une notification l'informant que son rglement a t programm, puis effectu (facture solde).

partir de ce travail d'analyse des cas d'utilisation, l'architecte slectionne les classes significatives sur le plan architectural, qui forment ensuite le socle de la vue architecturale du modle d'analyse.

14.4.2.3 Analyser une classe

Les ingnieurs de composants affinent les classes identifies dans les tapes prcdentes. Ils fusionnent les responsabilits qui leur ont t alloues partir de diffrents cas d'utilisation, identifient les mcanismes d'analyse disponibles et vrifient l'utilisation qu'en fait chaque classe (voir la section 8.6.3).

14.4.2.4 Analyser un paquetage

devront tre utiliss. I l peut aussi intgrer des systmes existants dvelopps par sa propre entreprise ; dans ce cas, il devra identifier les parties rutilisables et les interfaces requises 11 slectionne galement les produits des couches infrieures comme implmentalions des mcanismes de conception correspondant aux mcanismes d'analyse identifis d u r | < tapes prcdentes (voir la section 14.4.2.1). N'oubliez pas que nous dsignons pai m t l nismes de conception les mcanismes du systme d'exploitation sur lesquels doit Font tionner le systme propos: les langages de programmation, les systmes de finse .1, donnes, les ORB (Object Request Brokers), etc. Les mcanismes de conception I vanl tre utiliss par le produit sont limits par l'environnement d'implmentation (in | les construire, soit acqurir des produits les mettant en uvre. Il s'agit souvent dl tmes des couches de middleware et de logiciel systme d'une areliitcs une e u, n, i , construction ou leur slection peut s'effectuer paralllement rencbanemenl il m II' ||i d'analyse. Les ingnieurs de composants en tiendront compte lorsqu'ils pro 1 dl I I i conception.
B M f l
J a v a R l v 1 1

u r

| a

distribution des objets

Comme nous l'avons fait remarquer plus haut, dans l'analyse architecturale l'architecte prend en considration les services du systme et le regroupement des classes en paquetages de service, qui se fait dans le cadre de l'activit d'analyse architecturale. partir de ce regroupement en paquetages d'analyse, les ingnieurs de composants prennent la responsabilit des paquetages ; ils les prcisent et en assurent la maintenance (voir la section 8.6.4).

Java RMI sert la distribution des objets : le paquetage j d v d . nu i scia utilise ikiin; lli;iimii de la phase d'laboration pour implmenter le cas d'utilisation Soumettre la transaction commerciale.

14.4.3

Conception
Cette phase voit gnralement la conception et l'implmentation de moins de 10 % de la masse des cas d'utilisation. Ce faible pourcentage ne reprsente qu'une fraction de l'ensemble des cas d'utilisation identifis dans cette mme phase. La phase d'laboration limite la conception au niveau architectural : on ne conoit donc que les cas d'utilisation, les classes et les sous-systmes ayant de l'importance pour l'architecture. Les paquetages d'analyse et les sous-systmes de conception sont essentiels la dfinition des vues architecturales. De nombreux classificateurs peuvent avoir de l'importance pour l'architecture ou ne pas en avoir ; les paquetages et les sous-systmes en ont gnralement. (Voir le chapitre 9.)

Identifier les sous-systmes

et leurs interfaces

L'architecte se tourne ensuite vers les couches suprieures de l'architecture, proches des couches d'applications. partir des paquetages du modle d'analyse, i l identifie ainsi les sous-systmes correspondants devant figurer dans le modle de conception. En principe, i l tentera de faire de chaque paquetage de service du modle d'analyse un sous-systme de service dans le modle de conception ; les paquetages d'analyse de plus haut niveau deviendront des sous-systmes dans le modle de conception.

14.4.3.1 Procder la conception architecturale

L'architecte est charg de concevoir les aspects du systme significatifs pour l'architecture tels qu'ils apparaissent dans la vue architecturale du modle de conception (voir la section 9.3.6). La vue architecturale du modle de conception comprend les sous-systmes, les classes, les interfaces et les ralisations des cas d'utilisation significatifs pour l'architecture, figurant dans le modle des cas d'utilisation. Les autres aspects de la conception sont du ressort de l'ingnieur de cas d'utilisation et de l'ingnieur de composants. L'architecte identifie l'architecture en couches (y compris les mcanismes gnriques de conception), les sous-systmes et leurs interfaces, les classes de conception significatives pour l'architecture, et les nuds de configuration, traits dans les sections qui suivent. Identifier l'architecture en couches - L'architecte poursuit le travail commenc dans la phase de cration et conoit l'architecture en couches. I l rexamine les couches de logiciel systme et de middleware, abordes dans la section 9.5.1.2, et slectionne les produits qui

Si cette approche donne de bons rsultats dans certains cas, on peut parfois constater un dcalage entre l'analyse et la conception. I l se peut que, dans certaines situations, un paquetage d'analyse ne corresponde pas un sous-systme de conception mais un systme hrit (ou une partie de ce systme). Au lieu d'une correspondance un--un, i l est possible que le systme hrit ralise en totalit ou en partie plusieurs paquetages d'analyse, ou qu'un paquetage d'analyse corresponde plusieurs systmes hrits, situation dbouchant finalement sur une relation plusieurs--plusieurs. Dans d'autres situations, l'architecte pourra slectionner des briques de base comme des infrastructures prfabriques (frameworks), dveloppes en interne ou acquises auprs de fournisseurs externes. Ces briques risquent de ne pas s'intgrer exactement la structure de paquetages propose par le modle d'analyse ; i l est donc possible que l'aiclniei te .m slectionner pour la conception architectarale une structure de sous-systmes quelque peu diffrente de celle choisie dans le travail d'analyse architecturale. Identifier les classes de conception significatives pour l'architecture L'architecte traduit les classes d'analyse pertinentes pour l'architecture en CUUSai dl conception. mesure que les classes d'analyse sont identifies, il slectionne i .Iles qui

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase d ' l a b o r a t i o n fabrique l'architecture de r f r e n c e

CHAPITRE dans 14

395

comptent pour l'architecture, comme les classes actives, et les deci il l'architectare.

la

,1e

a upiiou de

rations ultrieures. Les ingnieurs de composants intgrent les diffrents rles de chaque classe dans une classe cohrente, comme l'indique la section 10.3.

14.4.3.4 Concevoir un sous-systme

Les ingnieurs de composants conoivent les sous-systmes issus de la conception architec turale. L'architecte en profite pour actualiser en consquence la vue architecturale di dele de conception.

Dans le cas d'un systme distribu, identifier les nuds et leur configuration rseau L'architecte tient compte des besoins du systme en matire de concurrence et de distribution en tudiant les threads et les processus requis, ainsi que le rseau physique des processeurs et des autres units. Les cas d'utilisation dj conus, en particulier tels qu'ils apparaissent dans les diagrammes d'interaction, constituent une entre essentielle cette tche. Dans les diagrammes d'interaction, l'architecte affecte les objets utiliss des classes actives, qui sont, leur tour, affectes aux processeurs et autres priphriques. Cette tape permet de distribuer les fonctions, au sens logique et physique du terme. L'architecte dresse une nouvelle version des vues architecturales du modle de conception et du modle de dploiement, qui figurent toutes deux dans la description de l'architecture.

14.4.4

Implmentation

14.4.3.2 Concevoir un cas d'utilisation

Cet enchanement d'activits permet d'implmenter et de tester les composant 1 l i | i, pour l'architecture, en travaillant partir des lments de conception p a t i n e u r , lui II pl m architectural. I l se traduit par l'architecture de rfrence, gnralement Implmenti l i p de moins de 10 % de la masse des cas d'utilisation. Nous allons traiter, d a n s , elle s a , |, activits d'implmentation architecturale, d'implmentation d'une classe et d systme, et d'intgration du systme (voir le chapitre 10.)

14.4.4.1 Procder l'implmentation architecturale

Les composants ncessaires l'implmentation des sous-systmes de service sont Identifi! partir des vues architecturales des modles de conception et de dploiement. Les compo sants excutables trouvent une correspondance avec les nuds du rseau informatique siu lesquels ils seront excuts. L'architecte illustre ensuite cette correspondance dans la vue architecturale du modle d'implmentation (voir la section 10.5.1.)

Les cas d'utilisation significatifs pour l'architecture sont dsormais conus sous forme de sous-systmes de conception, de sous-systmes de service ou de classes de conception (voir la section 9.5.2). (Les autres cas d'utilisation identifis, dtaills et analyss ne font l'objet d'aucune conception au cours de cette phase.) Cette activit s'apparente ce qui a t effectu en analyse (l'activit analyser un cas d'utilisation), avec quelques diffrences essentielles. En analyse, i l s'agissait d'analyser et d'affiner les cas d'utilisation et d'obtenir une spcification robuste, capable de ragir aux changements et rutilisable. Cette spcification devait servir de premire bauche la conception. On avait tent de dgager les responsabilits des classes d'analyse identifies. En conception, i l faut aller bien plus loin dans le dtail. En passant de l'analyse la conception, les ingnieurs de composants doivent adapter le modle d'analyse en vue d'obtenir un modle de conception oprationnel, celui-ci tant limit par les mcanismes de conception. Toutefois, les paquetages et classes d'analyse offrent un moyen direct d'identifier les sous-systmes et les classes de conception. Une fois ceux-ci identifis, on ne se borne pas en dcrire les responsabilits ; on retrace les interactions prcises qui les lient les uns aux autres. Nous avions dcrit, en analyse, le dplacement du point de vue d'un lment l'autre dans l'excution d'un cas d'utilisation. Plusieurs types de diagrammes d'interaction avaient t employs pour montrer ce mouvement. En conception, nous spcifions galement les oprations utilises pour la communication. Il faut alors dterminer les sous-systmes, infrastructures prfabriques ou systmes existants rutiliser, puis les oprations qu'ils fournissent. S'ils sont difficiles comprendre, la conception manquera de clart. Cette activit aboutit un ensemble de ralisations-conception de cas d'utilisation : chaque cas d'utilisation pertinent pour l'architecture est reprsent par l'un de ces artefacts.

14.4.4.2 Implmenter une classe et implmenter un sous-systme

Au cours de l'enchanement d'activits de conception, les ingnieurs de composants ont conu un certain nombre de classes pertinentes pour la cration de l'architecture de rfrence. Cette rfrence doit constituer une premire version excutable du systme sur le point d'tre construit. Dans cet enchanement d'activits, les ingnieurs de composants implmentent ces classes sous forme de composants fichiers (il y a gnralement un ou plusieurs composants pour un sous-systme de service issu du modle de conception). L'activit effectuer les tests unitaires garantit que chaque composant fonctionne en tant qu'unit (voir les sections 10.5.3 et 10.5.4.)

14.4.4.3 Intgrer le systme

partir du faible pourcentage de cas d'utilisation devant tre implments dans cette itration, l'intgrateur systme tablit la squence d'intgration dans un plan de construction de l'intgration, puis i l intgre progressivement les sous-systmes et les composants cnes pondants dans l'architecture de rfrence excutable (voir la section 10.5.2.) EXEMPLE

Trois constructions
L'intgrateur systme suggre trois constructions initiales (voir la figure 14.3).

14.4.3.3 Concevoir une classe

Il s'agit maintenant de concevoir les classes ayant particip aux ralisations de cas d'utilisation dans l'tape prcdente. Notez que ces classes ne sont gnralement pas compltes. ; elles prendront part d'autres ralisations de cas d'utilisation qui seront cres dans des ite|

Un d v e l o p p e m e n t itratif et i n c r m e n t a l PARTIE III

La phase d ' l a b o r a t i o n fabrique l'architecture de r f r e n c e CHAPITRE 14

mm B

14.4.5 Tests
L'objectif est ici de s'assurer du fonctionnement des sous-systmes et de leurs interfaces i) tous les niveaux (les sous-systmes de service comme les sous-systmes de conception) et dans toutes les couches (de la couche de logiciel systme la couche spcifique n l'application) ; voir le chapitre 11. On ne peut, bien sr, tester que les composants ext U tables. S'ils fonctionnent, on peut avoir bon espoir que le reste (les lments des . m i n . modles) fonctionne aussi. Dbuter par les couches architecturales infrieures implique de tester ht d i s l i i h rjl objets, le stockage et la rcupration (persistance) des objets, les objets coin u et d'autres mcanismes des couches infrieures du systme. Il ne s'agit pas de se i ouli un i d, tester la fonction, mais aussi de rechercher des performances a n ipiahlc s Nouibu d< u couches n'ont pas besoin d'tre testes en elles-mmes ; il nous suffi) de testa I u ||gi qui font les couches suprieures des couches infrieures. Dans la couche spcifique l'application et dans la couche gnrale aux applu allons li tests vrifient la faon dont la taille du systme s'adapte l'intgration de nouveaux soie, systmes utilisant des interfaces dj prises en charge.

Figure 14.3 La premire itration comprend trois constructions. Notez que la construction 2 intgre aussi les rsultats de la construction 1.

L'exemple montr dans la figure 14.3 consiste en trois constructions, soumises chacune l'activit effectuer les tests d'intgration : 1. Les classes du sous-systme Gestion des comptes, qui englobe le systme bancaire hrit. 2. Les classes du Paquetage des factures de l ' a c h e t e u r impliques dans le cas d'utilisation Rgi er 1 a f a c t u r e , plus la premire construction. factures du vendeur et celles du Paquetage des 3. Les classes du Paquetage des

14.4.5.1 Planifier les tests

Un ingnieur de tests slectionne les objectifs qui lui permettront d'valuer l'architecture de rfrence. I l pourrait s'agir, par exemple, d'excuter un scnario de cas d'utilisation dans un temps de rponse donn, jusqu' un certain niveau de charge (voir la section 11.5.1.)

14.4.5.2 Concevoir les tests

partir de ces trois objectifs, l'ingnieur de tests identifie les cas de test ncessaires et met au point les procdures qui serviront tester les intgrations ultrieures de sous-systmes, puis l'architecture de rfrence dans son ensemble (voir la section 11.5.2.)

factures de l ' a c h e t e u r impliques dans le cas d'utilisation Facturer l'acheteur. Ces sous-systmes abritent l'origine les classes gnriques du cas d'utilisation abstrait Soumettre la t r a n s a c t i o n commerciale, qui sont ensuite dplaces vers un sousRMI. systme rutilisable par plusieurs autres sous-systmes. Cette construction doit s'intgrer avec le paquetage Java

14.4.5.3 Effectuer les tests d'intgration

Une fois les composants tests, ils peuvent tre soumis aux tests d'intgration. Les testeurs d'intgration testent chaque construction (voir la section 11.5.4.)

14.4.5.4 Effectuer les tests systme

Lorsque le systme, tel qu'il a t dfini par les cas d'utilisation significatifs pour l'architecture, est intgr, i l est soumis aux tests effectus par le testeur systme. Ce systme (qui est une version du systme final) constitue l'architecture de rfrence. Le testeur renvoie pour correction les anomalies dtectes aux ingnieurs de composants ou l'architecte I vou
la section 11.5.5.)

Alors qu'on peut parfaitement envisager de travailler (avec quelque difficult, toutefois) sans outils dans la phase de cration, i l est pratiquement impossible de s'en passer dans la phase d'laboration. Par exemple, on commence maintenant tre oblig de grer des versions : i l est donc ncessaire d'avoir des outils de gestion de configuration. I l faut absolument avoir une vue d'ensemble de ce que l'on est en train de faire. On peut se contenter d'un papier et d'un crayon jusqu'au dbut de la phase d'laboration, mais i l est peu probable d'en venir bout sans placer l'architecture de rfrence sous le contrle de certains outils. Autre exemple : certains travailleurs pourront utiliser le langage de production (disons Java) ainsi qu'un ensemble d'outils. Ce recours prsentera l'avantage de mettre l'preuve l'environnement de dveloppement et de familiariser les travailleurs avec de nouveaux outils et des mthodes in-onnues. I l y a plus de chances, dans un tel cas, que le premier incrment utilise l'infrastructure, c'est--dire le middleware et le logiciel systme, du systme final. Le prototype est, de mme, plus susceptible d'voluer vers le systme rel.

Les ingnieurs de tests rvisent les rsultats des tests systme pour s'assurer qu'ils iciu plissent les objectifs initiaux ou pour dterminer la faon dont il faudra modifia les i as i l test pour atteindre ces objectifs.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase d ' l a b o r a t i o n fabrique l'architecture de r f r e n c e

CHAPITRE 14

Des virements i n c o h r e n t s crent un risque majeur Les tests systme tablissent que la plupart des fonctions semblent satisfaire aux objectifs de qualit fixs, une exception prs : lorsque les testeurs excutent le cas d'utilisation Itg I or 1 a facture, certains rsultats sont incorrects. Le systme hrit contenu dans le sous-systme Gesti on des comptes ne livre pas le rsultat prvisible pour certains virements dont le montant n'est pas arrondi au franc prs, par exemple 134,65 FF. En revanche, d'autres virements de ce type, comme celui d'un montant de 124,55 FF, fonctionnent trs bien. Les testeurs attirent l'attention sur ce problme, que l'architecte dsigne comme risque majeur. Le chef de projet nomme un groupe de travail charg de le rsoudre immdiatement.

14.5.2 Actualiser le retour sur

investissement

Rduite sa substantifique moelle, l'tude de rentabilit examine les points suivants : les gains gnrs par l'utilisation ou la vente du produit logiciel feront-ils plus que compenser le cot de son dveloppement ? Le produit arrivera-t-il temps sur le march (ou dans l'appli cation interne) pour garantir ces revenus ? Les quipes charges du dveloppement disposent maintenant d'une estimation du c o i n d e s phases de construction et d'laboration sous forme d'offre commerciale. C e l l e o l l i e i m e titue l'une des facettes de l'tude de rentabilit. Pour l'autre facelte, il n'existe pus di formule idale permettant de calculer les gains que gnrera le logiciel.

14.5 Elaborer l'tude de rentabilit

La raison qui sous-tend la rduction des risques et la cration de l'architecture de rfrence est qu'il faut amener le projet un stade permettant d'aborder la phase de construction avec la certitude que le produit est faisable dans les limites fixes sur le plan commercial. Ces limites sont de deux natures. L'une est l'estimation des dlais, du travail et des cots pour un niveau de qualit donn. L'autre est le retour sur investissement (ou une mtrique comparable) indiquant que le systme envisag sera une russite sur le plan conomique.

Dans le cas d'un logiciel commercialisable, la question du nombre d'exemptaites vendu d u prix auquel ils seront vendus et de la priode sur laquelle se drouleront les veilles i I du ressort du service du marketing et devra tre tranche par les responsables I linis le i i d'un logiciel usage interne, l'quipe du projet peut demander aux services conoeml d i Htlltli les conomies escomptes. La marge d'erreur dans l'estimation des gains pou util l i i gnralement assez large, mais l'exercice fournit au moins une base pcrmellanl d e i oinpatei les gains potentiels aux cots.
1

II II

l'issue de la phase de cration, l'organisation de dveloppement ne peut juger des mrites de l'tude de rentabilit qu'avec une marge d'erreur assez large - en tout cas pour les projets nouveaux, d'envergure ou complexes. A la fin de la phase d'laboration, la connaissance du projet a permis de rduire considrablement ce spectre. L'quipe peut maintenant rdiger une offre et laborer l'tude de rentabilit dans le cadre plus prcis de la pratique professionnelle.

14.6 valuer les itrations de la phase d'laboration

Une fois termine, chaque itration est value par rapport aux critres fixs dans le plan d'itration mis au point avant le dbut de l'itration, comme l'indique la section 14.2.5. L'quipe d'valuation examine les rsultats de chaque itration pour vrifier que la rfrence reprsente effectivement une architecture susceptible de remplir les objectifs originels et de rduire les risques.

14.5.1 Prparer

l'offre

commerciale

I II
1

L'quipe de dveloppement est cense mener bien la phase de construction partir d'un rfrent commercial, qui peut tre un contrat avec un client externe, une relation avec un autre service de la mme entreprise ou le dveloppement d'un produit destin la vente un large public. Nous observons que l'estimation des logiciels repose souvent sur la taille du projet et sur la productivit des quipes de dveloppement. La productivit des quipes dcoule de l'exprience acquise sur des projets antrieurs, alors que l'estimation de la taille se fonde sur les leons tires de la phase d'laboration. Pour faire une estimation raliste, i l faut poursuivre la phase d'laboration jusqu' obtenir une vision claire du travail effectuer dans la phase de construction. C'est prcisment ce qu'apporte l'architecture de rfrence. Deuximement, si le projet prsente des risques d'une certaine ampleur, ceux-ci doivent tre examins attentivement jusqu' ce que l'on puisse dterminer le temps et les efforts que cotera leur rsolution.

S'il doit y avoir plusieurs itrations, le rsultat de la premire d'entre elles pourra n'tre qu'une bauche relativement grossire de cette architecture. Cette bauche peut aussi se composer de vues architecturales assez prcises des diffrents modles : cas d'utilisation, analyse, conception, dploiement et implmentation. Le rsultat de la deuxime itration constitue la deuxime bauche de l'architecture. Et l'itration finale produit l'architecture de rfrence. A l'issue de chaque itration, le chef de projet, gnralement en coordination avec le groupe d'valuation, compare ce qui a t rellement accompli aux critres prdfinis. Si le projet ne satisfait pas ces critres, le chef de projet doit le rorienter, comme l'indique le chapitre 12. Cela peut se traduire, dans la phase d'laboration, par le report d'activits ma cheves l'itration suivante. Le fait que le chef de projet ait amen le client et les autres intervenants s'accorder sut l a ralisation de chaque jalon mineur permet d'attnuer le traumatisme ventuel suscit pat le jalon majeur ( la fin de la phase). L'quipe du projet aura eu le temps de nouer avec le client une relation plus troite que celle induite par le modle en cascade. I ,c client, de ct, aura eu l'occasion de livrer progressivement ses impressions sur les modles e m de dveloppement. Maintenant, la fin de la phase d'laboration, l'valuation permet de convaincre les inlervi nants que cette phase a rduit les risques les plus graves et qu'elle a bti une architecture de

II
II

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase d ' l a b o r a t i o n fabrique l'architecture de r f r e n c e

CHAPITRE 14

rfrence stable. Elle les convainc que le systme peut tre construil scion les ici mes du plan du projet et de l'offre commerciale concernant la phase de construction.

14.8 Principaux lments livrer

La phase d'laboration doit livrer les lments suivants : de prfrence, un modle complet du mtier (ou du domaine) dcrivant le contexte du systme ; une nouvelle version de tous les modles : modles des cas d'utilisation, d'analyse, de conception, de dploiement et d'implmentation. ( la fin de la phase d'laboration, 001 modles seront complets moins de 10 %, part le modle des cas d'utilisation et le modle d'analyse, qui peuvent englober plus de cas d'utilisation (parfois jusqu' B0 9 i 1 pour garantir que les besoins ont t apprhends. Tous les cas d'utilisation doivent ttn M grande partie compris, afin de s'assurer qu'aucun cas d'utilisation significalil pou l'architecture n'a t nglig et que l'on peut estimer le cot de leur Introduction I une architecture de rfrence excutable ; unedescriptionderarchitecture,aveclavuedesmodlesdecasd'ulilisaiion d ' U t l de conception, de dploiement et d'implmentation ; une liste des risques actualise ; le plan du projet pour les phases de construction et de transition ; un premier manuel d'utilisation (facultatif) ; une tude de rentabilit complte, accompagne de l'offre commerciale.

14.7 Planifier la phase de construction

Vers la fin de la phase d'laboration, le chef de projet commence planifier en dtail la premire itration de construction et exposer la suite en termes plus gnraux. Le nombre d'itrations requis dpend de la taille et de la complexit du projet. Les chefs de projet en prvoient gnralement deux ou trois, parfois quatre ou plus dans le cas d'un projet vaste et complexe. Es esquissent au sein de chaque itration un certain nombre de constructions, chacune ajoutant une partie relativement modeste ce qui a dj t fait. La gestion de projet doit encore traiter un grand nombre de risques figurant sur la liste des risques. Le chef de projet prvoit l'ordre de recherche des risques restants afin de les rduire un un avant qu'ils n'apparaissent dans la squence de constructions ou d'itrations. Le principe opratoire reste le mme : rduire les risques avant qu'ils ne fassent irruption dans la squence de constructions. La phase d'laboration n'aura que partiellement rempli les modles. Le chef de projet envisage l'ordre dans lequel seront abords les cas d'utilisation et les scnarios restants et celui dans lequel seront complts les diffrents modles. Cette proccupation conduit au squencement des constructions et des itrations. Sur de vastes projets, pour rduire les dlais en employant davantage de collaborateurs, le chef de projet rpartit le travail pouvant tre accompli par les travailleurs dans des traves parallles. Le dveloppement de systmes industriels d'envergure oblige l'quipe du projet trouver des voies de travail parallles en raison des contraintes temporelles qu'impose ce type de projet. L'quipe recherche un moyen de dployer un grand nombre de collaborateurs, souvent par dizaines. Ce moyen repose sur les sous-systmes tablis dans l'architecture de rfrence. Dans l'enchanement d'activits de conception (inspir par les paquetages d'analyse), on trouve des sous-systmes diffrents niveaux. Les sous-systmes ont des interfaces : l'un des objectifs de plus haut niveau consistait prcisment identifier et dfinir ces interfaces. Les interfaces sont au cur de l'architecture. Une fois les sous-systmes et les interfaces identifis et spcifis, on est par pour organiser le travail en parallle. Un individu a la responsabilit d'un sous-systme de service dans un sous-systme de conception. Un groupe a la responsabilit d'un sous-systme de conception. Si les individus ou les groupes rduits doivent bnficier d'un niveau raisonnable d'indpendance, i l faut que les interfaces limitant leurs territoires soient solides. Pour souligner l'importance de ces spcifications d'interface, on les appelle parfois contrats. Un contrat engage les dveloppeurs actuels et ceux des cycles suivants par rapport cette interface. C'est le fait qu'une interface soit fermement tablie qui rend possible une architecture intgrable. Plus tard, les dveloppeurs peuvent remplacer un sous-systme par un autre, tant qu'ils n'enfreignent pas le contrat d'interface. La construction de sous-systmes s'interconnectant par le biais d'un contrat d'interface (ou de l'quivalent) s'apparente largement, par le principe, la construction de systmes de systmes, voqus dans l'encadr Modlisation de vastes systmes de la section 7.2.3.

15
La construction aboutit la capacit oprationnelle initiale
Le premier objectif de cette phase est de livrer un produit logiciel sous forme de version oprationnelle initiale, parfois appele version bta. Ce produit doit atteindre un niveau de qualit adapt l'application et tre conforme aux besoins exprims. La construction doit, en outre, s'inscrire dans les limites du plan stratgique (business plan). la fin de la phase d'laboration, nous avons amen le systme propos au niveau d'une architectore de rfrence excutable. Les phases prcdentes ont rduit les risques critiques et significatifs pour les ramener des niveaux de pure routine, grables dans le cadre du plan de la construction. Au cours de la phase d'laboration, l'quipe du projet a pos les fondations des lments significatifs pour l'architecture des modles de conception et de dploiement, c'est--dire les sous-systmes, les classes (actives), les composants et les interfaces les reliant. Ces fondations englobent galement les ralisations des cas d'utilisation significatifs. Une telle partition s'est effectue partir de la description dtaille d'une proportion de cas d'utilisation ne dpassant gure 10 % de la masse totale des cas d'utilisation. Rappelez-vous que la quasi-totalit des besoins (en principe autour de 80 %) a t formule, mais ne ncessitait pas une description complte pour atteindre les objectifs de la phase d'laboration. C'est cela que nous allons dsormais nous atteler dans la phase de COIU truction.

15.1 La phase de construction en bref

partir d'une architecture de rfrence excutable et travers toute une srie d'ileial s ci d'incrments, l'quipe intervenant dans la phase de construction met au point un produit logiciel prt assurer un dbut de fonctionnement dans l'environnement utilisateur, souvent dsign sous le terme de tests bta. Elle complte la description des cas d'utilisation cl des scnarios restants, modifie la description de l'architecture si ncessaire, et poursuit les enchanements d'activits travers des itrations supplmentaires pour parvenir un equi

WfWM U"
BVUMI

d v e l o p p e m e n t itratif et i n c r m e n t a l
III ~

L a construction aboutit la c a p a c i t o p r a t i o n n e l l e initiale B J J M

CHAPITRE 15 wmm

PARTIE

libre entre les modles d'analyse, de conception et d'implmentation butin, clic ime sous-systmes et les soumet des tests, avant de passer l'intgration du systme dans ensemble, qui sera son tour test.
c

cation, la fin de la phase d'laboration. Qu'on le veuille ou non - en gnral, on ne le veut pas ! - , le chef de projet aura replanifier jusqu' un certain point la phase de construction. Dans la grande majorit des cas, i l devra adapter le plan du projet issu de la phase d'laboration aux ressources en personnel disponibles et aux dlais fixs par les intervenants.

Le passage du projet de la phase d'laboration la phase de construction marque un gement d'optique : alors qu'on pouvait comparer les phases de cration et d'laboratk une activit de recherche, la phase de construction s'apparente, elle, au travail de dveli pement. L'attention, qui s'tait concentre jusque-l sur la constitution d'une base de ci naissances ncessaire l'laboration du projet, se tourne dsormais vers la construction effective d'un systme ou d'un produit dans le respect des paramtres de budget, de charge de travail et de dlais.

15.2.1 Constituer l'quipe

de la phase

Dans la phase de construction, le travail dpasse largement le cadre de l'architecture (c'est -dire des lments de modle significatifs pour l'architecture). Les sous-systmes de service identifis par l'architecte dans la phase d'laboration ne sont pas completl lia n'implmentent que les principaux cas d'utilisation et leurs scnarios essentiels. I c i lui d e projet affecte des ressources supplmentaires ce travail. L'architecture de rfrence, avec sa reprsentation des sous-systmes et des intei la> <. titue la source laquelle va puiser le chef de projet pour rpartir le travail ( UltCjUI O U systme tombe sous la responsabilit d'un dveloppeur agissant en tant qu'ingnieui dl composants. Normalement, comme nous l'avons indiqu dans le chapitre 9, le dvcloppcui responsable d'un sous-systme est galement responsable des classes que contient i elul i i I l n'est gure habituel qu'un dveloppeur ait la responsabilit d'une seule classe . c e sciait pousser la division du travail un peu loin.

Pendant la phase de construction, le chef de projet, l'architecte et les principaux dveloppeurs s'assurent que les cas d'utilisation ont t hirarchiss, regroups en constructions et en itrations, et dvelopps dans un ordre permettant d'viter les retours en arrire. Ils actualisent en permanence la liste des risques afin qu'elle reflte l'tat actuel des risques rels encourus par le projet. Leur objectif est d'achever cette phase en ayant rduit tous les risques (hormis ceux qui surgiront du fonctionnement et seront traits en phase de transition). L'architecte veille en permanence ce que la construction soit conforme l'architecture et, si ncessaire, modifie cette architecture pour intgrer les changements mergeant du travail de construction.

15.2 Premiers stades de la phase de construction

Le chef de projet a planifi la phase de construction l'issue de la phase d'laboration. Lorsqu'il reoit, de la part des responsables financiers, l'autorisation de poursuivre le projet, il est possible qu'il ait modifier le plan de la phase de construction dans la mesure o certaines circonstances ont pu changer. Citons deux types de circonstances susceptibles de changer entre-temps.

m , " g

Pour l'essentiel, la phase de construction mobilise les travailleurs suivants : ingnieur de cas d'utilisation, ingnieur de composants, ingnieur de tests, intgrateur systme, testeur d'intgration et testeur systme. Par rapport la phase d'laboration, le nombre de personnes agissant en tant que travailleurs a considrablement augment, passant souvent du simple au double, comme le montre la section 12.7. Le tableau 13.1 indique, pour chaque enchanement d'activits, le volume approximatif de travail restant effectuer dans la phase de construction : 60 % en analyse et 90 % dans les enchanements de conception, d'implmentation et de tests. Outre les travailleurs cits dans le paragraphe prcdent, l'architecte continue tre disponible, bien qu'il consacre gnralement moins de temps cette phase. D'autre part, comme il reste environ 20 % des besoins formuler, l'analyste systme et le spcificateur de cas d'utilisation ont encore du travail.

15.2.2 Dfinir

les critres

d'valuation

La premire est l'cart temporel qui peut sparer les phases d'laboration et de construction. Les responsables financiers du projet peuvent donner immdiatement leur accord au dmarrage de la phase de construction et permettre ainsi au chef de projet et son quipe de poursuivre sans interruption et d'exploiter une connaissance du projet encore trs vivace. I l peut aussi, malheureusement, s'couler plusieurs mois entre la remise de la proposition et de l'offre commerciale et la signature effective du contrat ou de toute autre autorisation de poursuivre. Dans l'intervalle, le chef de projet et les membres de son quipe risquent de se consacrer d'autres travaux, et i l ne sera pas toujours possible de les runir de nouveau lorsque le feu vert sera accord. Dans le pire des cas, c'est un nouveau chef de projet, entour d'une quipe presque intgralement renouvele, qui prendra en charge la phase de construction. Autres circonstances susceptibles de changer : les fonds et les dlais accords au projet sont infrieurs ceux prvus dans la phase d'laboration. Il est possible que la porte du projet ait t revue la baisse pour s'accorder au budget et aux dlais, mais ce n'est pas forcment le cas. Ce que nous voulons dire, c'est que, au dbut de la phase de construction, les circonstances peuvent s'carter (un peu ou beaucoup) de celles qui ont servi de base la planifi-

Les critres spcifiques que doit remplir une itration ou la phase de construction dans son ensemble sont propres chaque projet. Ils ont en effet t fixs pendant le dveloppement des cas d'utilisation. Comme nous l'avons fait remarquer dans les chapitres prcdents, les cas d'utilisation eux-mmes correspondent des besoins fonctionnels. Mais ils porlenl ga lement en eux des exigences non fonctionnelles (par exemple, des exigences de peilm mances) et servent rduire les risques. Chaque construction ou itration implmcnli un ensemble de cas d'utilisation. Les critres d'valuation de cet ensemble de cas d'utilisation sont donc fonds sur les besoins fonctionnels et non fonctionnels lis ce mme ensi mbli de cas d'utilisation.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l PARTIE III

L a construction aboutit la c a p a c i t o p r a t i o n n e l l e initiale CHAPITRE 15

Ces critres d'valuation lis aux cas d'utilisation permettent aux dveloppeurs eus mmes de dfinir clairement quel moment achever une construction ou une itration. D'autres lments naissent de la phase de construction, pour lesquels il faudra prvoir des critres d'valuation. Deux exemples en sont donns ci-dessous. Documentation utilisateur

Ressources

Une premire bauche des documentations crites destines aux utilisateurs finals (guides d'utilisation, texte de l'aide, notes de version, manuels de l'utilisateur et du technicien) est labore pendant la phase de construction. Le critre d'valuation est le suivant : ces documents aideront-ils suffisamment les utilisateurs pendant la phase de transition ? Matriel pdagogique

y Besoins

Enchanements d'activits principaux ^ Conception ^ Implmentatio^) Tests ^

y> Analyse

La phase de construction cre galement une premire esquisse du matriel pdagogique destin aux utilisateurs finals (transparents, notes, exemples et didacticiels). Ces supports aideront-ils suffisamment les utilisateurs pendant la phase de transition ? Pour la phase de construction dans son ensemble, le critre d'valuation doit permettre de dterminer si la capacit oprationnelle initiale fait preuve d'une maturit et d'une stabilit suffisantes pour que des versions bta soient distribues aux utilisateurs, sans exposer ces derniers ni l'organisation responsable du dveloppement des risques inacceptables.

S'attachent au dveloppement du systme Enchanements d'activits des itrations de construction

15.3 Enchanements d'activits de l'itration typique de construction

L'itration typique se compose des cinq enchanements d'activits, comme l'illustre la figure 15.1. Ces enchanements d'activits ont, certes, dj t dcrits dans la deuxime partie de cet ouvrage, mais ce chapitre ne s'intresse qu'au rle qu'ils jouent dans la construction. L encore, quatre ensembles d'activits sont en partie menes en parallle. Le premier de ces ensembles regroupe les enchanements d'activits principaux ; le deuxime s'attache la planification des itrations, dcrite par les sections 12.4 12.7 et par la section 15.2 ; le troisime est celui de l'tude de rentabilit, aborde dans les sections 13.5 et 15.5 ; enfin, le dernier se consacre l'valuation, dcrites dans les sections 12.8 et 15.6. Nous nous contenterons, dans cette section, de fournir une prsentation gnrale des enchanements d'activits principaux, sur lesquels nous reviendrons plus en dtail dans la section suivante. Les premires itrations de la phase de construction s'attardent davantage sur les premiers enchanements d'activits, au dtriment des enchanements plus tardifs. L'attention se dplace progressivement tout au long des itrations de construction. Par exemple, si l'on devait dessiner une courbe en forme de cloche pour illustrer les charges de travail successives, le sommet de la courbe se dplacerait de gauche droite, mesure que l'attention se porte vers l'enchanement d'activits d'implmentation.

Figure 15.1 Le travail d'une itration de la phase d'laboration traverse les cinq enchanements d'activits principaux. /.< reste des besoins est dtaill et analys, mais la charge de travail de ces deux enchanements d'activits est relativement lgre, l'essentiel du travail ayant t accompli dans les deux phases prcdentes. La conception joue un grand rle, et c'est dans cette phase qu'est effectue la majeure partie du travail des activits d'implmentation et de tests. (La taille des blocs n 'a qu 'une vocation illustrative et varie selon les projets.)

Construire le systme ce stade, les besoins et l'architecture sont stables. On s'attache avant tout complter les ralisations de tous les cas d'utilisation, concevoir les sous-systmes et classes requis, les implmenter sous forme de composants et les tester la fois un par un et au sein des constructions. Dans chaque construction, les dveloppeurs prennent un ensemble de cas d'utilisation, tels qu'ils ont t tablis par le chef de projet et l'intgrateur systme, et procdent leur ralisation. Le dveloppement itratif, pilot par les cas d'utilisation et centr sur l'architecture construit le logiciel travers une srie d'incrments de taille relativement modeste qui s'ajoutent, l'un aprs l'autre, l'accumulation d'incrments prcdente, afin de maintenir en permanence une construction excutable. Ce type de dveloppement ordonne la squence d'itrations de faon progressive, de sorte que les constructeurs n'aient jamais revenir en arrire sui les incrments prcdents pour les retravailler. La construction du logiciel par des incrments relativement rduits facilite la gestion du projet. Elle limite la porte des enchanements d'activits d'analyse, de conception, d'impie mentation et de tests au nombre minimal de questions et de problmes identifis dans nu seul incrment. Elle isole les risques, les anomalies et les corrections dans le champ I t d'une construction unique, et en simplifie ainsi la dtection et le traitement. Les premires phases ont procd la recherche et la rduction des risques critiques et significatifs, mais la gestion de projet compte encore un grand nombre derisquessur sa I isie

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
mm PARTIE III

La construction aboutit la c a p a c i t o p r a t i o n n e l l e initiale

CHAPITRE 15

W
an

En outre, d'autres risques sont susceptibles d'apparatre pendant que les dveloppeurs mnent bien les constructions et les itrations ou que les utilisateurs essaient les incr ments. Par exemple, la plupart des langages de programmation existant depuis assez longtemps, l'quipe du projet peut lgitimement compter sur le fonctionnement correct du compilateur qu'elle envisage d'employer. Mais les langages voluent et de nouvelles versions des compilateurs voient le jour ; or, i l est parfaitement possible qu'une nouvelle version contienne des anomalies. Dans un projet de 80 000 lignes de code source, le chef de projet a fini par dcouvrir que les anomalies rptes dans les diffrents tests taient provoques par le compilateur. Le projet a encore pris du retard, jusqu' ce que le fournisseur du compilateur dtecte cette subtile anomalie et la corrige.

Les travailleurs prennent part ces diffrents enchanements d'activits, comme le suggrait la deuxime partie de l'ouvrage. Ils compltent les artefacts de l'architecture de rfrence ou des dernires itrations. Dans la phase d'laboration, l'quipe du projet peut avoir conu et implmente moins de 10 % de la masse des cas d'utilisation : juste assez pour difier l'architecture de r f r e n c e 11 reste maintenant, dans la phase de construction, muscler cette ossature architecturale II faut en effet complter les modles prsents dans les chapitres 4 et 5 (consulte/, la liguic '> / pour revoir le taux d'achvement des modles au fil des quatre phases). Chaque construction et chaque itration apportent leur lot de nouvelles ralisations de cas d'utilisation, de classes de sous-systmes et de composants, qui viennent s'ajouter la structure des modles en evo lufion. Les sous-sections suivantes dcrivent les enchanements d'activits de faon lqui ntli 11 comme l'illustre la figure 15.2, bien que cette squence ne reflte pas le mode d'inlei v< des diffrents travailleurs. Par exemple, la planification des lests est effectue au cll Ii chaque itration, afin de dclencher le travail de test ncessaire l'itration * lettC planifl cation des tests peut tre effectue avant mme de dtailler les cas d'utilisation, I.m.ils < la conception et l'implmentation. L'aspect concomitant du travail ne ressortant pas du texte qui suit, nous ne pouvons que rappeler, une fois encore, que les cinq enchanements d ucli vits se rptent dans chaque itration.

15.4 Excuter les enchanements d'activits principaux : des besoins aux tests
Nous avons esquiss, dans la section prcdente, le propos gnral de la phase de construction. Cette section va maintenant prsenter plus en dtail chacune de ces activits, en prenant pour guide la figure 15.2. Comme dans les chapitres prcdents, cette section s'articule autour des cinq enchanements d'activits. Si le dcoupage est squentiel, l encore le travail des diffrents enchanements d'activits s'effectue en parallle, comme le rappelle la figure.

15.4.1

Besoins
Aprs cette introduction la phase de construction, nous passons l'identification des cas d'utilisation et des acteurs, au prototypage des interfaces utilisateur, la description dtaille et la structuration des cas d'utilisation. Dans la phase d'laboration, nous avons identifi tous les cas d'utilisation et les acteurs ; nous avons compris environ 80 % de la masse des cas d'utilisation mais dcrit en dtail seulement quelque 20 %, dont on a tir une proportion encore plus faible (moins de 10 %, qu'il fallait implmenter ce moment-l), alors suffisante pour tablir l'architecture de rfrence. Dans la phase de construction, bien entendu, le but tant de mettre au point le systme oprationnel initial, i l faut absolument achever la formulation des besoins (c'est--dire identifier et dtailler la totalit de ces besoins). Identifier les acteurs et les cas d'utilisation En gnral, seule une faible fraction des cas d'utilisation et des acteurs reste identifier dans la phase de construction (mois de 20 %). L'analyste systme actualise, si ncessaire, les cas d'utilisation et les acteurs dans le modle des cas d'utilisation. Prototyper l'interface utilisateur En rgle gnrale, les phases de cration et d'laboration n'ont pas cr de prototype des interfaces utilisateur, sauf si le projet impose un type nouveau d'interface ou s ' i l e x i r e un prototype des fins de dmonstration. Quoi qu'il en soit, i l faut maintenant concevoir les interfaces utilisateur. L'tendue de la tche dpendra du type de systme qu'il s'agit de- cous traire.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La construction aboutit la c a p a c i t o p r a t i o n n e l l e initiale

CHAPITRE 15

Comme l'indiquait le chapitre 8 (section 8.3), dans certains cas, le modle d'analyse ne sera pas conserv aprs la premire phase d'laboration d'un nouveau produit. Dans d'autres cas, en revanche, le chef de projet pourra continuer l'utiliser dans la phase de construction, el mme jusqu'au bout du projet et au-del de la dure de vie du produit. Ce dernier cas tant le plus complexe, c'est celui que nous prendrons comme hypothse. La diffrence esseniu II. entre les phases d'laboration et de construction rside dans le fait que la phase de cane, truction complte le modle d'analyse. Le modle d'analyse hrit de la phase d'laboration constituait la vue architecturale : i l s'intressait dans une large mesure l'architecture I eu, vue architecturale du modle d'analyse ne reprsentera dsormais plus qu'une partie du modle dans son ensemble. La phase de construction aura permis de mettre en plat l II modle d'analyse complet, dont la vue architecturale n'est qu'un sous ensemble. Procder l'analyse architecturale
la plia., oulie

Pour certains systmes - en particulier ceux dans lesquels certains cas d'ulilisalion exigeai une interface utilisateur extrmement complexe - , i l est difficile d ' a p p r h e n d e r l'interface utilisateur sans avoir recours un prototype. I l faut donc en construire un (ou plusieurs, si ncessaire) et le faire tester par les utilisateurs. Ce prototype sera ensuite remodel en fonction des ractions des utilisateurs, jusqu' ce qu'il rponde leurs besoins. La conception de l'interface utilisateur fait partie de l'enchanement d'activits des besoins et non de celui de conception (malgr ce que son nom peut suggrer) et doit tre effectue avant de passer aux enchanements d'activits suivants. Le prototype devient ensuite la spcification d'interface utilisateur (pour de plus amples dtails, voir le chapitre 7 ) . Pour les systmes destins une large diffusion dans le commerce, i l est indispensable de construire un prototype de l'interface utilisateur, mme si celle-ci n'est pas trs complexe. Le cot du remplacement d'une interface non satisfaisante sur le terrain serait beaucoup trop important.

L'architecte ayant prpar la vue architecturale du modle d'analyse a la hn de d'laboration, i l n'a donc pas grand-chose faire dans la phase de construction, actualisations ncessites par les changements concernant l'architecture. Analyser un cas d'utilisation

Assigner un ordre de priorit aux cas d'utilisation Dans la phase d'laboration, nous avons class les cas d'utilisation ncessaires au dveloppement de l'architecture de rfrence. A mesure que sont identifis les cas d'utilisation dans cette phase, ils s'ajoutent la liste, classs par ordre de priorit (voir les sections 12.6
et 7 . 4 . 2 ) .

les

Dtailler un cas d'utilisation Les spcificateurs de cas d'utilisation compltent la description dtaille des cas d'utilisation, dans l'ordre d'importance des cas d'utilisation et des scnarios restants.

Dans la phase d'laboration, l'architecte n'a utilis que les cas d'utilisation significatifs pou) l'architecture, qu'il a appliqus la vue architecturale du modle d'analyse. Dans chaque itration de la phase de construction, le modle d'analyse s'enrichit des cas d'utilisation inclus dans cette itration. Analyser une classe Les ingnieurs de composants poursuivent le travail entrepris dans la phase d'laboration. Analyser un paquetage Dans la phase de construction, l'architecte prcise les paquetages identifis dans la phase d'laboration en fonction des besoins suscits par les nouveaux cas d'utilisation, tandis que l'ingnieur de composants actualise les paquetages en construction.

Structurer le modle des cas d'utilisation L'analyste systme peut souhaiter amliorer la structure du modle des cas d'utilisation. Toutefois, comme le systme dispose ce stade d'une architecture stable, tout changement doit concerner en priorit les cas d'utilisation n'ayant pas encore t traits. Chaque modification d'un cas d'utilisation exige, en effet, une modification de la ralisation correspondante dans les modles d'analyse et de conception.

15.4.2 Analyse

15.4.3

Conception
Dans cette phase, nous allons concevoir et implmenter les 9 0 % de cas d'utilisation restants, ceux qui n'ont pas servi dvelopper l'architecture de rfrence. De nouveau, nous insistons sur le fait que cet enchanement d'activits et les autres enchanements se rptent chaque itration. Procder la conception architecturale

Dans cette sous-section, nous allons revenir sur les activits d'analyse architecturale, d'analyse d'une classe et d'analyse d'un paquetage commences dans la phase d'laboration. Dans la phase prcdente, i l suffisait de prendre en compte les cas d'utilisation significatifs pour l'architecture ou ncessaires l'laboration de l'offre commerciale. Pour donner au lecteur une ide du stade auquel on se trouve dsormais, i l est probable qu'environ 4 0 % de la masse des cas d'utilisation ont t analyss dans la phase d'laboration, ce qui reprsente environ la moiti de la masse des cas d'utilisation (environ 8 0 %) gnralement ncessaire l'laboration de l'offre commerciale. Ces chiffres sont seulement indicatifs : nous tenons rappeler qu'ils varient en fonction des circonstances propres chaque projet. Maintenant, dans la phase de construction, nous allons nous proccuper de tous les cas d'utilisation, sans ncessairement toffer en consquence le modle d'analyse.

Dans la phase de construction, l'architecte n'ajoutera, en rgle gnrale, aucun sous-system, de conception ou de service. Ces lments existent dj dans l'architecture de rfrence, au moins sous une forme minimale. L'architecte peut ventuellement ajouter des sous-systmes, s'ils sont quivalents ou cousu tuent des solutions de rechange ceux qui sont dj en place. Par exemple, s ' i l existe un sous-systme pour un protocole de communication et que l'architecte ajoute un autre pio

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La construction aboutit la c a p a c i t o p r a t i o n n e l l e initiale

CHAPITRE 15

tocole de communication ne ncessitant pas d'autres interfaces, il sera plus pratique de ci en un autre sous-systme pour ce second protocole.

l'autre tout au long du cycle de dveloppement et transmis aux cycles futurs. Le modle de conception est le plan d'laboration et de construction du modle d'implmentation et de l'implmentation elle-mme.

15.4.4

Implmentation
En partant essentiellement du modle de conception, cet enchanement d'activits impie mente tous les composants, auxquels il fait galement subir les tests unitaires. Il d b o m lie. aprs un certain nombre d'itrations, d'intgrations et de tests du systme, sm la v,a a,u, oprationnelle initiale, qui reprsente 100 % de la masse des cas d'utilisation. ( 'elle |0UI section aborde les activits d'implmentation architecturales, d'implttientalion d'une , h . et d'un sous-systme, de ralisation des tests unitaires et d'intgration du systme C'est dans cet enchanement d'activits qu'est effectue la majeure partie du travail de II phase de construction: l'laboration des composants, comme l'explique le chapitre lit L'quipe du projet enrichit chaque composant d'un nombre croissant de lignes de code, au lil des constructions et des itrations, jusqu' ce que, la fin de la phase, tous l e s , (imposants soient remplis . Procder l'implmentation architecturale

Le comportement d'un sous-systme de service peut gnralement tre driv de certaines parties d'un mme cas d'utilisation ou d'un ensemble de cas d'utilisation lis les uns aux autres. On pourrait aussi formuler cette ide en disant qu'un sous-systme de service joue un rle dominant pour la ralisation d'un unique cas d'utilisation. Entre 40 et 60 % des responsabilits d'un sous-systme de service proviennent d'un cas d'utilisation de ce type. Lorsque le pourcentage est lev, aux environs de 80 %, le chef de projet value si le projet doit complter les 20 % restants du sous-systme de service dans la mme construction ou s'il vaut mieux les laisser une construction ultrieure. E peut tre judicieux d'en autoriser tout de suite l'achvement, alors mme que les autres parties de ce sous-systme sont empruntes des cas d'utilisation classs un niveau infrieur par rapport au cas d'utilisation dominant. Mme si ces cas d'utilisation prsentent un niveau de priorit infrieur et peuvent, de ce fait, tre reports, il sera peut-tre plus efficace de finaliser le paquetage au moment o il entre en jeu.

A ce stade, l'architecture est fermement tablie. Le rle de l'architecte, en dehors d'une sm veillance continue, se limite quelques actualisations, si ncessaire. Implmenter une classe et implmenter un sous-systme

Les ingnieurs de composants implmentent les classes et les sous-systmes dans le modle d'implmentation. Ils implmentent galement les classes reprsentes par des stubs ncessaires l'laboration des constructions. Effectuer les tests unitaires L'ingnieur de composants est charg d'effectuer les tests unitaires sur les composants qu'il ralise et d'en corriger, si ncessaire, la conception et l'implmentation. Intgrer le systme L'intgrateur systme cre un plan de construction de l'intgration traant les grandes lignes de la squence de constructions. Ce plan prsente les cas d'utilisation ou scnarios de cas d'utilisation que doit implmenter la construction et qui aboutiront aux sous-systmes et composants. Les intgrateurs systme prfrent souvent commencer la construction par les couches infrieures de la hirarchie d'une architecture en couches, comme les couches de logiciel systme et de middleware (illustres par la figure4.5). Les constructions suivantes l u d e n t le systme en allant vers le haut, en direction de la couche gnrale aux applications et de la couche spcifique l'application. U est difficile d'assembler une construction sans que lei fonctions de prise en charge fournies par les couches infrieures soient en place. Par exemple, le dpartement informatique d'une socit de produits chimiques prvoyait dt raliser en moyenne un incrment tous les quinze jours. On prtend que les projets 'le Microsoft Corporation livrent une construction par jour partir du moment o du code a t

D'un ct, l'exploitation de cas d'utilisation de moindre priorit ce stade permet l'ingnieur de composants de dvelopper tout le sous-systme d'un coup. Il a donc plus de chances de le structurer correctement, puisqu'il l'a examin en totalit. Si l'ingnieur de composants, ou un autre intervenant, doit revenir sur le sous-systme dans une construction ultrieure pour exploiter le reste des cas d'utilisation de moindre priorit, il peut dcouvrir des divergences ncessitant un changement de toute la conception. Il est possible qu'il ait rcrire le code parce qu'il ne s'articule pas bien avec le code issu des cas d'utilisation de moindre priorit. 1 est donc souhaitable d'inclure dans le sous-systme des parties de cas 1 d'utilisation devant tre conus plus tardivement si - et la prcision est importante - on connat d'avance l'impact qu'elles auront. Pourquoi ? Parce qu'il est prfrable de finaliser un travail en une fois, plutt que de le dissminer sur plusieurs itrations. D'un autre ct, l'exploitation des cas d'utilisation de moindre priorit dans une construction du dbut va rencontre de notre philosophie gnrale, qui consiste examiner en premier les cas d'utilisation de haute priorit. La rgle gnrale est la suivante : s'il vous semble plus pratique de traiter quelques cas d'utilisation de faible priorit en mme temps que des cas d'utilisation urgents et que cela ne vous prend pas trop de temps, allez-y ! Mais, dans ce cas, le propos reste le suivant : crer la bonne conception et ne pas implmenter ni tester tous les cas d'utilisation de faible priorit. Le chef de projet doit reporter ces tches (conception, implmentation et test des cas d'utilisation de moindre priorit) une cous traction ultrieure, o leur niveau de priorit les place naturellement. L'architecte amliore la vue architecturale des modles de conception et de dploiement afin qu'elle reflte l'exprience acquise au cours de la phase de construction. Toutefois, comme il a gnralement achev l'architecture la fin de la phase d'laboration, i l se contente cette fois de l'actualiser. Pour une vocation des autres activits de cet enchanement d'activits (conception des cas d'utilisation, des classes et des sous-systmes), reportez-vous au chapitre 9. Inutile de prciser ici que la conception est l'une des proccupations majeures (moins, toutefois, que l'implmentation) de la phase de construction, comme l'indique la figure 15.1. Elle donne lieu aux modles de conception et de dploiement, conservs l'un et

Un d v e l o p p e m e n t itratif et i n c r m e n t a l

La construction aboutit la c a p a c i t o p r a t i o n n e l l e initiale

CHAPITRE 15

une des principales activits de la phase, comme l'indique la figure 15.1. Si la responsabillti de mener les tests unitaires revient aux ingnieurs de composants, les ingnieurs de testl fournissent, pour leur part, une assistance technique. Mais ce sont bien les ingnieurs d. composants et leurs collaborateurs (le testeur d'intgration et le testeur systme) qui soin chargs de tester les constructions, c'est--dire les incrments livrs par chaque itration puis la construction finale, qui constitue le systme entier. Planifier les tests Les ingnieurs de tests slectionnent les objectifs permettant de tester les construi cessives et, finalement, le systme lui-mme. Concevoir les tests U i

fabriqu. Chaque construction est soumise des tests (tests sur les lments ajouts et tests de non-rgression sur le code dj en place) pour s'assurer que le code en cours de dveloppement fonctionne bien. Ce processus de refabrication quotidienne verdie chaque jour que les units de code insres (par un check-in ) depuis la veille sont bien compatibles. Si cette pratique exhorte fermement les dveloppeurs ne pas casser la construction , elle rduit toutefois la pression long terme pesant sur l'organisation charge de la ralisation du projet, puisque les problmes d'intgration sont dtects au cours des tests, effectus en principe chaque soir, et rsolus immdiatement aprs. Malgr les apparences, la cration quotidienne d'une construction n'inflige pas forcment une contrainte insupportable une quipe de projet. Les dveloppeurs intgrent leur code (par un check-in ) lorsqu'ils estiment qu'il est prt. Inutile d'intgrer du code instable : on risquerait de briser la construction. La pression est tout de mme prsente, et chaque dveloppeur doit intgrer son code en temps et en heure afin de rester conforme au plan de construction de l'intgration. La dure de chaque priode de construction est laisse l'apprciation de chaque organisation de dveloppement. Le principe est de livrer des constructions un rythme suffisamment soutenu pour bnficier des avantages lis aux constructions frquentes.

Les ingnieurs de tests trouvent un moyen de tester les besoins dans l'euscmbli di tractions afin de vrifier tous ceux pouvant tre tests. Ils chafaudeni, dans ce but ili . c i e . e i des procdures de test. Parmi les cas et les procdures de test des constructions pic. edeuli ils slectionnent ceux qui restent pertinents et les modifient de faon a soumettre les corn tructions successives des tests de non-rgression. Ils vrifient les composants devanl I tn tests ensemble, selon la planification tablie au dpart. L'objectif de ces tests d'intgration est de vrifier les interfaces entre les composants tests et de s'assurer que les composant! fonctionnent ensemble. Effectuer les tests d'intgration

Pour que chaque construction se maintienne dans des proportions modestes, l'intgrateur systme a souvent recours un stub ou un pilote pour reprsenter un composant qui n'est pas encore construit. Un stub est un lment trs simple qui se contente de donner une rponse un stimulus, ou tous les stimuli, qu'est susceptible de recevoir le composant de la part d'autres composants (encore incomplets) de la construction. De mme, un pilote fournit un stimulus aux autres composants faisant partie d'une construction en cours de tests. Les stubs et les pilotes tant simples, ils risquent peu d'infroduire des complications supplmentaires.

Les testeurs d'intgration excutent les cas de test, suivant les procdures de test appropries. Lorsque la construction russit les tests, l'intgrateur systme ajoute d'autres constructions, au fur et mesure de leur disponibilit, que le testeur d'intgration peut continuer tester. Lorsque les tests d'intgration dtectent des dfaillances, les testeurs les consignent et en informent le chef de projet. Celui-ci (ou son reprsentant, qui peut tre l'intgrateur systme puisqu'il dispose des connaissances techniques pertinentes) dtermine l'tape suivante. I l peut tre dcid, par exemple, d'approfondir le travail au sein de cette mme construction, de reporter la correction l'tape suivante ou, en particulier dans le cas d'une dfaillance particulirement grave, d'affecter des personnes spcialement qualifies pour pousser les investigations. A la fin de la dernire itration de la phase de construction, le testeur systme teste la version oprationnelle initiale. De nouveau, i l rend compte des dfaillances au chef de projet, qui attribuera l'ingnieur de composants responsable la tche de les corriger. valuer les tests

L'intgrateur systme prend donc en compte l'ordre dans lequel i l convient de placer les composants afin de former une configuration fonctionnelle apte subir des tests. I l documente ses dcouvertes dans le plan de construction de l'intgration, en montrant quel moment doit intervenir chaque construction pour respecter le calendrier de l'intgration et des tests. I l rassemble les classes compltes et les classes reprsentes par un stub en une construction excutable, en accord avec le plan de construction. I l largit le champ des refabrications successives, et charge les testeurs d'intgration de leur faire subir les tests d'intgration et les tests de non-rgression. Dans l'tape finale de chaque itration, puis dans celle de la phase elle-mme, l'intgrateur systme lie le systme dans son ensemble, qui subit ensuite les tests d'intgration et les tests de non-rgression. Cette planification squence l'ordre des constructions dans chaque itration et l'ordre des itrations au sein de la phase de construction. Les couches suprieures d'une architecture en couches entretenant souvent des dpendances de compilation avec les couches infrieures, i l est possible que les intgrateurs systme doivent planifier la compilation de bas en haut.

15.4.5 Tests
, Les efforts entrepris par les ingnieurs de tests pour dcouvrir ce qui peut tre efficacement test et pour mettre au point les cas de test et les procdures permettant de raliser ces tests, comme le dcrit le chapitre 11, portent leurs fruits dans la phase de construction. C'est l

Les ingnieurs de tests vrifient progressivement les rsultats des tests d'intgration cl des tests systme la fin de chaque construction, la lueur des objectifs fixs au dpari dans le plan des tests (ventuellement modifi par les itrations ultrieures). Le propos de celle eva luation est de s'assurer que les tests atteignent leurs objectifs. Si ce n'est pas le cas pont un test en particulier, les cas et les procdures de test concerns devront tre modifi! en couse quence (voir la section 11.5.6).

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La construction aboutit la c a p a c i t o p r a t i o n n e l l e initiale B J I

CHAPITRE 15 mmi

15.5 Matriser l'tude de rentabilit

L'un des propos de l'offre commerciale, prpare la fin de la phase d'laboration, est de servir de guide au chef de projet et aux intervenants dans l'excution de la phase de construction. A cette fin, le chef de projet compare la progression relle la fin de chaque itration avec le calendrier, les efforts et le budget prvisionnels. Il revoit les donnes concernant la productivit du projet, la quantit de code tabli, la taille de la base de donnes, ainsi que d'autres mtriques. Le nombre de lignes de code ralises constitue rarement une bonne mesure de la progression d'un dveloppement bas sur les composants. L'un de ses objectifs tant de rutiliser des classes et des composants, un ingnieur de composants et d'autres travailleurs peuvent progresser rapidement dans les constructions et les itrations en crivant trs peu de code. L'achvement des constructions et des itrations par rapport au plan reprsentera, dans ce cas, une mesure bien plus fiable des accomplissements rels. Les divergences de plus de quelques pour cent, en particulier dans le sens ngatif, doivent conduire le chef de projet prendre des mesures correctives, tandis que des carts plus importants commandent de runir les diffrents intervenants. mesure que le chef de projet affine sa connaissance du cot et des possibilits du produit au cours de la phase de construction, il peut estimer ncessaire d'actualiser l'tude de rentabilit et d'en communiquer la nouvelle version aux intervenants.

15.7 Planifier la phase de transition

L'quipe du projet ne peut s'attendre planifier l'avance la phase de transition de manire aussi dtaille que les phases prcdentes. Les membres de l'quipe savent, bien entendu, qu'ils vont livrer pour valuation des versions bta (ou l'quivalent) des utilisateurs slectionns. Cette partie de la phase - la slection des utilisateurs, la reproduction du code de fonctionnement, la prparation des instructions de tests, etc. - peut tre planifie assez prcisment. En revanche, les retours obtenus - risques, problmes, pannes, suggestions - sont plui dlffl ciles prvoir. Si une quipe a dj quelque exprience des tests bta, elle saura peu pies a quoi s'attendre. Elle pourra alors estimer le nombre approximatif de personnes d'exprienOl qu'il faudra affecter la prise en charge des problmes mis au jour par les testeurs de In version bta.

15.8 Principaux lments livrer

Les lments livrer sont les suivants : le plan du projet pour la phase de transition ; le logiciel excutable lui-mme : la version capacit oprationnelle initiale. Il s'agit de la dernire construction de la phase de construction ; tous les artefacts, y compris les modles du systme ; une description de l'architecture entretenue et actualise de faon minimale ; un premier manuel de l'utilisateur suffisamment dtaill pour guider les testeurs de la version bta ; l'tude de rentabilit refltant la situation la fin de la phase.

15.6 valuer les itrations et la phase de construction

Sur la base d'une rvision des rsultats des tests et d'autres critres d'valuation, tels que ceux dcrits dans la section 15.2.2, le chef de projet et un groupe d'valuation : comparent ce qui a t accompli au cours d'une itration ce qui tait prvu ; choisissent l'itration ultrieure laquelle devra tre report le travail non achev ; dterminent si la construction est prte ou non passer l'itration suivante ; actualisent la liste des risques ; compltent le plan de l'itration suivante ; mettent jour le plan des itrations venant aprs l'itration suivante ; dterminent, l'issue de la dernire itration de la phase, si le produit a pass avec succs les tests systme et atteint sa capacit oprationnelle initiale ; autorisent le passage la phase de transition ; actualisent le plan du projet.

L'objectif, c'est que les lments livrer qualifis de complets le soient vraiment. Le fonctionnement du logiciel au sein de l'environnement utilisateur dans la phase de transition peut faire apparatre certaines erreurs dans ces lments livrs. Ils devront donc tre modifis en consquence.

16
La phase de transition finalise le produit
Au moment o le projet entre en phase de transition, le systme a atteint sa capacit oprationnelle initiale. Le chef de projet a jug le systme suffisamment fiable pour le faire fonctionner dans l'environnement utilisateur, bien que la perfection ne soit pas exige. I l est possible, par exemple, que des problmes, des risques et des anomalies non dtects lors des tests systme, la fin de la phase de construction, fassent leur apparition dans l'environnement utilisateur. I l se peut galement que les utilisateurs dcouvrent tardivement qu'ils ont besoin de certaines fonctions. Si ces fonctions sont vraiment importantes et cohrentes avec le produit existant, le chef de projet peut accepter de les ajouter. Ces changements doivent, nanmoins, rester modestes, et leur introduction ne doit pas avoir d'impact srieux sur le plan du projet. Si une fonction suggre a un retentissement non ngligeable sur le calendrier de dveloppement, il faut s'assurer qu'elle est vraiment indispensable. Nous estimons qu'il est prfrable, dans la plupart des cas, d'inscrire ce type de suggestions dans la liste des caractristiques et de les reporter au cycle de dveloppement suivant, c'est--dire au dveloppement de la nouvelle version du systme. Cette phase poursuit deux objectifs principaux : rpondre aux besoins, tels qu'ils ont t tablis dans les phases prcdentes, la satisfaction des intervenants ; grer toutes les questions conditionnant le fonctionnement dans l'environnement utilisateur, y compris la correction des anomalies rapportes par les utilisateurs de la version bta ou par les responsables des tests d'acceptation. Les tests d'acceptation incombent au client, qui peut toutefois les sous-traiter une socit spcialise dans ce type de tests.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase de transition finalise le produit mm

CHAPITRE 16 lai

16.1 La phase de transition en bref

16.2 Premiers stades de la phase de transition

La production de logiciels s'inscrit dans divers contextes, que l'on peut, sans s'garer dans les dtails, regrouper sous deux principaux archtypes :

La phase de transition s'attache installer le produit dans l'environncmenl oprationnel. I a manire de procder varie en fonction de la nature du rapport qu'entretient le produit avecson march. Si, par exemple, un produit est destin au march commercial, l'quipe du projet en distribue une version bta des utilisateurs typiques rpartis sur des sites clients bta reprsentatifs. Si, en revanche, un produit ne s'adresse qu' un seul client (ou ventuellement une pluralit de sites au sein d'une grande entreprise), l'quipe installe le produit sur un seul site .
1

L'quipe du projet observe les retours en provenance des sites oprationnels afin de : vrifier si le systme offre vritablement les services exigs par les entreprises et leurs utilisateurs ; dcouvrir des risques non perus ; prendre acte de problmes non rsolus ; dtecter des dfaillances ; lever des ambiguts et combler des manques dans la documentation destine aux utilisateurs ; concentrer ses efforts sur les secteurs o les utilisateurs semblent en difficult et en manque de renseignements ou de formation. partir de ce type de retours, l'quipe modifie le systme ou les artefacts qui lui sont associs et prpare les phases suivantes de production, emballage, dploiement et lancement du systme d'une manire gnrale. Dans cette phase, i l ne s'agit pas de chercher reformuler le produit : les modifications importantes des besoins doivent avoir t intgres par l'quipe du projet et par le client dans des phases antrieures. L'quipe recherche ici les dficiences mineures ngliges dans la phase de construction et qu'il est possible de corriger dans le produit de rfrence existant.

Dveloppement par un diteur logiciel d'un produit destin un march Ce march peut tre trs important, comme celui des ordinateurs personnels, ou plus rei treint, comme dans la production de composants rutilisables destins des diteurs de pto grammes prfabriqus adaptables chaque installation. Quelle qu'en soit la taille, ce type de march gnre une relation un--plusieurs (un diteur pour de nombreux clients), qui influence le travail de la phase de transition. Dveloppement par une SSII sous contrat avec un client unique Ce modle se dcline en plusieurs variations. Par exemple : une socit de dveloppement travaillant pour un seul client sur un seul site , une socit de dveloppement travaillant pour un client ayant un gi and noinhie d ,,y> tu et de sites ; une socit de sous-traitance, telle qu'EDS, Computer Science ou Andersen < 'onsulling, dveloppant pour un client unique un logiciel qu'elle adapte ensuite d'autres sites ou clients ; une structure de dveloppement interne mettant au point des logiciels pour d'autres dpartements de la mme entreprise dans le cadre d'un accord comptable spcifique. La relation entre la structure de la phase de transition et l'utilisateur ou le client varie en fonction de ces diffrents contextes. Elle dbute, dans ces conditions, par une version oprationnelle initiale ayant subi des tests systme en interne et l'valuation des jalons majeurs la fin de la phase de construction. Cependant, dans la phase de transition, l'quipe du projet labore des artefacts supplmentaires, comme des scripts d'installation, des programmes de conversion ou de migration des donnes, ou modifie ceux produits dans la phase de construction afin de prparer ce programme excutable franchir ses propres frontires.

Dans le cadre de sa relation avec le client, l'quipe peut fournir une assistance pour la mise en place d'un environnement adapt au produit et proposer des sessions de formation, qui permettront une utilisation efficace du produit. Elle peut galement aider les utilisateurs faire fonctionner en parallle le nouveau systme et celui qu'il remplace, et convertir les anciennes bases de donnes dans la nouvelle configuration. Dans le cas de produits destins de nombreux utilisateurs (le march du sous blister ), ces services sont inclus dans le programme d'installation propos avec le produit et complts par le service d'assistance aux clients. La phase de transition s'achve par la sortie du produit. 1. On peut mentionner deux autres possibilits : les tests alpha et la validation par des tiers. Les tests alpha sont semblables aux tests bta, outre le fait qu'ils sont conduits au sein de la socit dveloppant le logiciel - en dehors, toutefois, du dpartement de dveloppement logiciel lui-mme. Les personnes effectuant les tests alpha sont de vritables utilisateurs. Dans la validation par des tiers, une socit spcialise dans les tests mne des tests d'acceptation dans le cadre d'un contrat avec le client.

16.2.1 Planifier la phase de transition

Une quipe de projet ne peut gure esprer planifier la phase de transition l'avance et trs en dtail comme elle a pu le faire avec la phase de construction. D'un ct, le chef de projet sait que cette phase va livrer un certain nombre d'utilisateurs slectionns une version bta (ou l'quivalent) mise au point dans la phase de construction, qui sera ainsi soumise des tests. Cette certitude forme le fondement des premires planifications de la phase de transition. La production de cette version bta suppose un certain volume de travail, notamment la rdaction de la documentation accompagnant les tests bta, la slection des utilisateurs bta, etc. D'un autre ct, les retours provenant de ces tests vont gnrer une charge de travail inconnue. Le chef de projet devra s'entourer de quelques personnes disponibles. I l pourra toujours les affecter d'autres projets, mais devra les garder sa disposition pour la rsolution des problmes de transition.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase de transition finalise le produit

CHAPITRE 16

p a e m

423

16.2.2 Constituer l'quipe

de la phase de transition

En planifiant la phase de transition, le chef de projet s'attend ce que la version oprai ion nelle initiale issue de la phase de construction ncessite quelques ajustements mineurs en retour des tests bta. En fait, si le projet a t men de faon itrative, ce sera le cas. Ce processus de dveloppement permet en effet aux dveloppeurs de faire des essais ds les premires phases et de dtecter les erreurs de conception grce aux tests mens sur les incrments du dbut et l'observation de leur fonctionnement. De mme, les erreurs videntes doivent tre localises et corriges construction aprs construction mesure qu'avance le dveloppement. En clair, i l est profitable de faire des retouches ds le dbut. Dans la phase de transition, la suite d'un dveloppement itratif, ces retouches ne doivent pas dpasser 5 %. Les chefs de projet doivent quand mme s'attendre un certain volume de retouches. I l y a toujours des omissions et des erreurs qui passent travers toutes les vrifications. Les raisons nonces ci-dessous peuvent conduire une quipe sous-estimer la charge des retouches prvoir : une pression trop forte sur les dlais, donnant lieu au syndrome du vite fait, mal fait , l'absence de tests systme adapts et d'valuation la fin de la phase de construction ; l'incapacit se concentrer sur le travail considrable restant fournir dans la phase de transition ; la croyance que le simple fait d'envisager le besoin de retouches risque d'en provoquer la matrialisation ; la tendance considrer les retouches comme ngatives , aveu d'une incomptence de l'quipe du projet.

L'objectif de cette phase tant de livrer une version aux utilisateurs, des fins de tests bla ou de tests d'acceptation mais aussi dans un objectif d'utilisation, les besoins en personnel seront assez comparables ceux de la phase de construction, bien que l'accent soil plac sm des aspects lgrement diffrents. Analyser les retours de tests bta ou de tests d'acceptation et tenter d'y apporter une rponii peuvent requrir l'intervention de personnes plus orientes vers les services que rompue', au dveloppement proprement parler. Pour juger des mrites d'un amlioration, mme mineure, il faudra peut-tre s'entourer d'experts spcialistes non seulement du s y s i e m e dans son ensemble, mais aussi de la nature mme de l'application laquelle il est destin I > < mme, lorsque les tests ne font que dtecter les anomalies, il faut parfois l'aire preuve d'une exceptionnelle perspicacit pour les reprer dans l'ensemble du systme ou ; oins dans la partie du systme d'o elles semblent provenir. De plus, les documentations destines au utilisateurs et les supports de formation, bien que mis en chantier dans la phase de i oie. truction, ont souvent besoin d'tre rcrits par un rdacteur technique avant que le pioduil ne soit livr l'utilisateur lambda. Certes, l'architecte est d e garde pendant celte phase mais avant tout pour assurer et prserver l'intgrit de l'architecture et, parfois (mais rarement), pour prendre en considration des modifications architecturales mineures.

16.2.3 Dfinir

les critres

d'valuation

la fin de la phase de construction, l'issue des tests systme, on a estim que le produit offrait la capacit oprationnelle initiale ou, en d'autres termes, qu'il rpondait aux conditions de la spcification des besoins. Pour la phase de transition, seules sont values les questions mergeant dans cette phase. Elles sont, globalement, de cinq types. 1. Les utilisateurs de la version bta ont-ils abord les fonctions cls, par exemple celles reprsentes par tous les cas d'utilisation et impliques dans le fonctionnement russi du produit sur le terrain ? 2. De mme, le produit a-t-il pass avec succs les tests d'acceptation mens par le client ? Les critres de ces tests sont fixs par le contrat liant la structure de dveloppement et le client. En outre, les tests d'acceptation excutent en gnral le logiciel en mode de production pendant une priode de temps dtermine d'un commun accord.

La question du logiciel bien assez bon ou non peut surgir dans la planification de la phase de transition. C'est une ralit qu'il faut bien admettre : aucun produit logiciel n'est parfait. Le produit livr peut contenir un certain pourcentage d'anomalies restantes, la prise en charge de certaines exigences peut avoir t reporte une version ultrieure, et enfin les utilisateurs bta ont pu mettre au jours certains besoins, que la phase de transition n'aura plus les moyens de prendre en compte. I l existe trois rponses la question du logiciel bien assez bon .

Premirement, les phases et les itrations du Processus unifi visent identifier les risques, formuler les besoins prcis et planifier le projet en consquence. Dans le Processus unifi, l'quipe du projet effectue ces tches en coordination avec les utilisateurs et les clients, si bien que la version oprationnelle initiale (ou version bta) s'approchera logiquement de ce qu'attendent les dveloppeurs et les intervenants.

3. La documentation destine aux utilisateurs est-elle d'un niveau de qualit acceptable ? 4. 5. Les supports de formation (y compris les instructions l'attention du formateur, s'il y en a) sont-ils prts l'emploi ? Enfin, les clients semblent-ils satisfaits du produit ? Nous commenterons plus longuement cette question dans la section 16.4.6.

Deuximement, comme ni l'quipe du projet ni les intervenants ne s'attendent ce que la version oprationnelle initiale ne prsente aucun dfaut, ils prvoient quelques dlais et ressources pour la phase de transition. Enfin, l'application des deux premires rponses par l'quipe du projet en coopration avec les intervenants peut se traduire par une extension de la phase de transition ou par un report du travail imprvu au cycle de dveloppement suivant.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l PARTIE III

La phase de transition finalise le produit mm CHAPITRE 16 _m

16.3 Les enchanements d'activits principaux jouent un rle mineur dans cette phase

L'itration archtypale se compose des cinq enchanements d'activits abords dans les chapitres prcdents. Dans ce chapitre, nous ne nous intressons qu'au rle que chacun d'eux joue dans la phase de transition. Plus gnralement, quatre ensembles d'activits sont en parties mens en parallle. Le premier de ces ensembles regroupe les enchanements d'actl vits principaux ; le deuxime s'attache la planification des itrations, dcrite par lis sections 12.4 12.7 ; le troisime est celui de l'tude de rentabilit, aborde dans lu section 16.5 ; enfin, le dernier se consacre l'valuation, dcrite dans les sectionl I et 16.6. Dans cette section, nous nous contenterons de fournir une prsentation reneialc d, enchanements d'activits principaux, sur lesquels nous reviendrons plus en dtail due l i section suivante.
1

16.4 Activits de la phase de transition

Les activits de transition s'articulent autour des axes suivants : prparation de la vritable version bta (ou des tests d'acceptation) a partir de la (de capacit oprationnelle initiale) issue de la phase de construction ;
veision

Comme le montre la figure 16.1, l'activit est relativement faible dans les cinq enchanements au cours de cette phase. L'essentiel du travail ayant t effectu dans la phase de construction, le niveau d'activit de la phase de transition reste modr : i l suffira de corriger les problmes dtects par les tests mens dans l'environnement utilisateur (pour de plus amples dtails, voir la section 16.4). On ne doit pratiquement rien avoir faire dans les enchanements d'activits des besoins, d'analyse et de conception. Normalement, les activits de conception sont en recul dans la phase de transition. Tout au moins ne vont-elles gure au-del de simples amliorations destines corriger problmes ou anomalies, ou effectuer des modifications (en principe, mineures) de dernire minute. I l s'agit, dans cette phase, de corriger les anomalies afin d'liminer les dfaillances entravant les premires utilisations, de s'assurer que ces corrections elles-mmes sont valables, et de procder des tests de nonrgression pour vrifier que les corrections n'ont pas introduit de nouvelles anomalies.
Ressources

installation (ou planification de l'installation) de cette version sur le site, avec ralisation d'activits sur le site, comme la migration des donnes de l'ancien systme ; prise en compte des retours en provenance des sites de test ; adaptation du produit corrig au contexte de l'utilisateur ; finalisation des artefacts du projet ; dtermination de l'achvement du projet.
Analyse Conception _ Implmentation/ Tests Enchanements d'activits principaux

S'attachent ta livraison d'une version au client Enchanements . d'activits des itrations de transition

Les dtails de cette squence d'activits varieront selon que le projet livrera un logiciel destin au march ou un client en particulier. Dans le premier cas, le nombre d'utilisateurs potentiels tant lev, la slection et l'accompagnement des utilisateurs bta reprsenteront une tche considrable. En plus, en tant qu'utilisateurs rels, les personnes dsignes ne suivront pas un calendrier de tests impos. Elles utiliseront le produit comme elles l'entendent et rendront compte de ce qu'elles trouveront au fur et mesure de leurs dcouvertes. Dans le second cas, le client slectionnera probablement un site pour l'installation initiale, et les tests d'acceptation qui y seront mens suivront une procdure formelle, systmatique et rsultant d'un accord commun. Si des problmes dpassant la porte du contrat en cours surgissent, les parties s'accordent sur un contrat de suivi.

Figure 16.1 Le travail d'une itration d'implmentation identifies,

de la phase de transition traverse les cinq enchanements

d'activits

principaux. (La d'activits dtectes, Dans

taille des blocs n 'a qu 'une vocation illustrative et varie selon les projets.) Les enchanements et de tests apparaissent au premier plan dans cette phase. C'est l que sont et retestes corriges

les anomalies mises au jour par les tests bta et les tests d'acceptation. d'activits de conception. L'enchanement d'activits

Le droulement des activits variera galement selon que le produit sera le premier du genre (green-field) ou l'amlioration d'un produit existant ou semblable. L encore, l'organisation charge du dveloppement sera amene adapter le processus aux circonstances auxquelles elle sera confronte, comme nous l'avons expliqu dans le chapitre 2.

certains cas, il sera ncessaire en revanche, reste pratiquement

de refaire une partie de la conception pour corriger ces anomalies, ce qui conduira des besoins, inchang.

une lgre augmentation de l'enchanement

16.4.1 Livrer la version

bta

La plupart des membres du premier cercle d'utilisateurs choisis pour les tests bla (ou d'acceptation) seront des personnes exprimentes. L'quipe de transition demande a < i personnes de travailler en s'aidant d'une documentation relativement sommaire, mais [eut

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase de transition finalise le produit mm

CHAPITRE 16 K

fournit en revanche des instructions prcises pour le compte rendu de leurs observations et des dcouvertes issues des tests. Trs tt dans la phase de transition, l'quipe du projet rassemble les documentations rdiges prcdemment dont les utilisateurs bta ou les testeurs d'acceptation auront besoin. Ces documentations sont compltes par des instructions bta spcifiques. Enfin, l'quipe slectionne les utilisateurs bta, auxquels elle distribue la version bta et toute documentation l'accompagnant.

Problmes de plus grande

envergure

16.4.2 Installer la version

bta

Certaines des difficults mises au jour par les tests bta peuvent requrir une intervention plus importante qu'une simple correction d'anomalie, voire imposer une itration suppl mentaire, l'issue des tests. Elles peuvent aussi suggrer des changements, des amliora fions ou des caractristiques devant tre gres formellement (par exemple, pat l'intermdiaire d'un Bureau de contrle des changes). Nous ne pouvons qu'insister, dans t. cas de figure, sur l'importance qui doit tre accorde la gestion de la configuration a mesure que sont implmentes ces modifications. Comme nous l'avons dj dit auparavant les changements substantiels, de nature dpasser les moyens disponibles, iclardei l.i livraison ou modifier l'architecture, doivent tre, dans la mesure possible, repoi les au ev> li de dveloppement suivant.

I l reste essentiel de prserver l'intgrit architecturale du systme pendant la COTTOI don de! problmes et des anomalies. C'est cette fin que l'architecte suit la progression d u travail de transition. I l travaille en mode de suivi pour s'assurer que les corrections des problme! I des anomalies respectent l'architecture. L'architecte (ou l'quipe d'architecture) vrifie que la prise en compte des problmes n'est pas expdie , d'une faon qui pourrait tre d o m mageable l'architecture. Il faudra, pour parvenir ce but, procder quelque ajustement de l'architecture. Si les activits de cette phase affectent l'architecture, la description devra en tre actualise par l'architecte.
1

Les activits menes sur le ou les sites de tests divergent selon qu'on se livre des tests bta ou des tests d'acceptation. Les tests bta se dploient gnralement sur un grand nombre de sites, sur lesquels l'quipe de transition n'est pas prsente. L'quipe doit mettre des instructions spcifiques sur la procdure d'installation du logiciel, son mode d'utilisation, les questions/problmes sur lesquels doivent s'attarder les clients et utilisateurs bta, et les rgles suivre pour rendre compte des anomalies ou problmes dtects. Si la version est une mise jour ou le remplacement d'un logiciel existant, l'quipe de transition doit fournir des instructions sur la migration des donnes ou sur la conversion des bases de donnes vers la nouvelle version. Le cas chant, ces instructions doivent galement prvoir le fonctionnement en parallle de la version bta et de l'ancienne version pendant une certaine dure. En revanche, dans le cas de tests d'acceptation, les membres concerns de l'quipe du projet seront sans doute prsents. Un document formel indiquera les modalits de ces tests d'acceptation et sera complt par des communications informelles. Les anomalies et les problmes seront corrigs sur place, si possible, ou renvoys aux membres du projet possdant les comptences ncessaires.

Bien sr, peu d'organisations de dveloppement livrent des produits parfaits. C'est dans cet esprit que le chef de projet doit estimer les cots et les retards qu'entraneront certaines retouches et les intgrer dans l'tude de rentabilit.

16.4.4 Adapter le produit aux divers environnements

utilisateur

16.4.3 Rpondre

aux rsultats

des

tests

Comme nous l'avons indiqu plus haut, les organisations de dveloppement livrent des produits dans deux contextes relationnels diffrents : les produits du march (relation un--plusieurs) et ceux destins un client unique (relation un--un). L'une et l'autre de ces relations peuvent entraner la ncessit de faire migrer des donnes ou de convertir des bases de donnes d'un systme ancien vers le nouveau systme. Relation avec le march Le march peut regrouper un ensemble extrmement diversifi de contextes, pour lesquels l'quipe doit mettre au point diffrentes versions d'un programme excutable. Parmi ces variantes, citons le pays, la langue, l'unit montaire et autres units de mesure. Si le produit doit s'excuter sur diffrents nuds oprationnels au sein d'un rseau, i l faudra peut-tre le modifier pour chacun de ces nuds. Comme les utilisateurs de la premire version gnrale seront probablement moins expt i mentes que les utilisateurs de la version bta, i l faudra que l'quipe toffe la documentation des tests bta pour l'adapter aux besoins des utilisateurs lambda.

L'quipe du projet recueille et analyse les rsultats des tests afin d'envisager des mesures correctives. Ces rsultats se rpartiront vraisemblablement en deux catgories : d'un ct, les anomalies de code mineures, qu'il suffira de reprer et de corriger (bien que cela puisse tre assez compliqu dans certains cas) ; de l'autre, les problmes plus importants, susceptibles d'avoir de larges ramifications et de conduire une modification de l'architecture. Dfaillances - Une dfaillance rsulte en premire instance d'une anomalie dans un composant. Mais i l faudra peut-tre rechercher l'origine de cette anomalie dans un dfaut de la conception, de l'analyse ou mme d'un modle antrieur. Si cette recherche se rvle difficile, l'quipe de transition devra peut-tre faire appel l'ingnieur de composants ou d'autres personnes ayant effectu les premiers travaux dans ce domaine. Quoi qu'il en soit, une personne comptente doit corriger cette anomalie, qui doit de nouveau subir des tests systme et des tests de non-rgression raliss par l'quipe de tests. L'quipe du projet doit, en outre, se poser des questions telles que : Cette anomalie est-elle susceptible d'tre lie d'autres anomalies non encore dtectes ? Peut-elle tre corrige sans que cela affecte l'architecture ou la conception ? Sa correction n'a-t-elle introduit aucune autre anomalie ?

Les produits distribus sur le march sont gnralement installs par l'utilisateur ou pai l'administrateur systme d'une socit. Parfois, c'est un fournisseur local qui se charge de l'installation. L'quipe prpare les procdures d'installation et un script d'aide en ligne. < 'es procdures peuvent tre relativement complexes, notamment dans les cas o le produit doit

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase de transition finalise le produit

CHAPITRE 16

429

tre install sur un certain nombre d'ordinateurs personnels ou de stations de travail relis par un rseau intranet. Elles le sont encore plus lorsque certaines parties du produit sont installes sur diffrents nuds qui doivent tre monts d'une faon prcise. Diffrents types de nuds peuvent ncessiter diffrentes procdures d'installation. Relation avec un client unique La livraison d'un systme un client unique dans le cadre d'un contrat suit peu prs le mme modle que celui dcrit ci-dessus, quelques diffrences prs. Des reprsentants du client ont probablement particip aux phases antrieures et fourni des retours sur les incrments. Ils ont observ les derniers tests systme effectus dans les locaux du fournisseur de logiciel. Ils ont pu participer des sances d'valuation constatant la russite du jalon de construction. L'organisation charge du dveloppement a sans doute assist l'installation du systme sur le site initial du client. Dans le cas de vastes systmes complexes, elle peut mme avoir effectu l'essentiel de l'installation. Des reprsentants du fournisseur ont observ le droulement des tests d'acceptation et ont peut-tre effectu des corrections sur place lorsque c'tait possible. Dans le cas de problmes plus dlicats, ils ont rendu compte de la situation leur socit afin d'obtenir l'assistance d'experts dans la ralisation des changements ou des corrections. Les tests d'acceptation prennent fin lorsque le client et son fournisseur estiment que le systme rpond aux exigences sur lesquelles ils s'taient pralablement accords. I l est possible, bien entendu, qu'apparaissent des besoins supplmentaires ou des modifications de ces besoins, qui pourront donner lieu un contrat de suivi.

renforcer les explications figurant dans l'aide en ligne, notamment les informations guidant les utilisateurs confronts des installations infructueuses.

16.4.5 Finaliser les

artefacts

La phase de transition ne s'achve pas tant que l'quipe du projet n'a pas finalis tous les artefacts, y compris les modles et la description de l'architecture. Nous insistons notamment sur le fait que l'ensemble des modles doit tre complet ds la fin de la COM traction et ne pas se remplir comme par miracle vers la fin de la phase de transition. Il doit, au contraire, voluer progressivement travers les itrations et les phases successives, comme le dcrit la section 12.8.4. Il sera amend, si ncessaire, dans la phase de dans A la fin de cette phase, nous vrifierons, par l'utilisation relle du produit, que tous les an. facts sont cohrents les uns avec les autres.

16.4.6 Quand le projet se termine-t-il ?

La phase de transition prend fin non seulement une fois que le travail et tons les attelai i . sont achevs, mais lorsque le client est satisfait. Quand peut-on estimer que les utilisateurs sont satisfaits ? La rponse dpend du type de relation que l'on entretient avec le march, Dans le cas de produits destins tre commercialiss, le chef de projet conclut que la grande majorit des clients seront satisfaits lorsque le projet aura tenu compte des retours des tests bta. ce stade, une version gnrale est mise. Dans la plupart des cas, bien sr, l'environnement et le produit continuent voluer, mais l'organisation logicielle rpond cette volution dans les versions suivantes ou, en cas de changement majeur, par un nouveau cycle de dveloppement. Comme les produits russis et les systmes personnaliss voluent gnralement vers des rvisions mineures, puis majeures, le projet, en ce sens, ne prend jamais rellement fin. La phase de transition se termine lorsque l'quipe du projet cde la responsabilit de la maintenance continue un organisme de support. Dans le cas de produits dvelopps sous contrat pour un client unique, le chef de projet conclut la satisfaction du client lorsque le systme russit les tests d'acceptation. Cet aspect dpend videmment de l'interprtation des besoins formuls dans le contrat original (sign la fin de la phase d'laboration), tel qu'il a pu tre modifi au cours des dernires phases. Le client peut confier par contrat un certain type de support de maintenance l'diteur du logiciel, ou grer lui-mme sa propre maintenance, ou encore la sous-traiter une partie tierce. Les dtails peuvent diverger, mais la phase de transition est bel et bien termine.

Migration ou conversion des donnes Il s'agit souvent de remplacer un systme existant, ce qui ncessite des procdures de migration des donnes ou de conversion des bases de donnes. Les donnes existantes peuvent se trouver dans un produit dvelopp par le mme diteur ; i l sera, alors, trs simple de les transfrer dans le nouveau produit. En revanche, si ces donnes rsident sur un produit mis au point par un autre diteur, ventuellement concurrent, leur dplacement pourra tre plus dlicat. Les responsabilits de l'quipe de dveloppement peuvent tre de plusieurs ordres : remplacer l'ancien systme par le nouveau, soit avec une reprise complte des tches existantes par le nouveau systme, soit avec un fonctionnement en parallle des deux systmes jusqu' ce que l'utilisateur soit satisfait du fonctionnement du nouveau systme ; transfrer les donnes de l'ancien systme vers le nouveau, avec un ventuel changement des formats de donnes ; fournir les instructions guidant ces transferts et prvoir, dans la documentation, des tests permettant aux utilisateurs de vrifier que l'installation a t couronne de succs ;

16.5 Achever l'tude de rentabilit

Les cots et le calendrier de la phase de transition ont t pris en compte par l'offre commet ciale la fin de la phase d'laboration. l'issue de la phase de transition, des informations supplmentaires permettant djuger des mrites de l'tude de rentabilit sont dsormais dis ponibles.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

La phase de transition finalise le produit

CHAPITRE 16

431

16.5.1 Matriser

la

progression

16.6.1 valuer

les itrations

et la phase

Le chef de projet compare la progression relle de la phase au calendrier, aux cots et au travail prvus pour cette phase. la fin de la phase de transition, qui marque aussi la fin du projet en termes budgtaires, le chef de projet convoque un groupe pour revoir le vritable calendrier, le nombre d'heureshomme, le cot, le taux d'anomalies et toute autre mtrique que pourra employer la socit, par rapport aux chiffres prvus pour le projet dans son ensemble, afin : de vrifier si le projet a atteint les objectifs prvus ; de s'informer des raisons pour lesquelles ces objectifs n'ont pas t atteints (si tel est le cas) ; d'ajouter les mtriques du projet la base de donnes de mtriques de la socit en vue d'une utilisation future.

D'un ct, si l'organisation du projet a men efficacement les trois premires phases, la phase de transition doit se drouler sans heurts et s'achever dans les dlais et les budgets allous. Les tests bta ne dtectent que des anomalies mineures qui peuvent tre i mu us l u tement corriges. Le groupe d'valuation fait peu de constatations susceptibles d'intreili t le groupe charg du produit ou l'quipe responsable du cycle de vie suivant. D'un autre ct, si l'organisation du projet n'a russi ni identifier tous les risques impt tants, ni crer une architecture capable de prendre en charge les besoins, ni implmeniei une conception fournissant le systme demand, de telles dficiences claleioni ave, un, douloureuse vidence dans la phase de transition. En consquence, le chef de projet i isqm d'avoir allonger la phase de transition pour parvenir un systme offrant au m.me satisfaction minimale. I l est possible qu'il ait la rude tche de soutenir auprs des utilisateur un systme jug bien assez bon. I l faudra peut-tre aussi qu'il reporte a une version ulte rieure des caractristiques pourtant spcifies l'origine dans les besoins Bien entendu, ces dfaillances donnent de la matire au groupe d'valuation Imal, Si membres valuent en effet la totalit du projet : les quatre phases. Ils constatent que le projet n'a pas donn satisfaction. Du point de vue du processus, le propos de l'valuation est de permettre l'quipe qui travaillera sur la version suivante de faire mieux. L'valuation, en tant que telle, ne doit pas servir de justification des actions ngatives l'gard du personnel. De telles actions, si elles s'imposent, doivent s'appuyer sur d'autres preuves. Si le groupe d'valuation sent que ses constatations risquent d'tre mal interprtes, i l peut nuancer son propos. Le plus important, pour la russite future de l'organisation, est d'affronter les faits et de tirer toutes les leons de l'exprience.

16.5.2 Rviser

le plan

stratgique

L'objet de ce plan est d'anticiper la russite conomique du projet. L encore, deux situations typiques se prsentent : d'un ct, la production dans le cadre d'un contrat, de l'autre, la production destination d'un march. Dans le premier cas, la russite est facile dfinir : le prix stipul dans le contrat a-t-il couvert tous les frais engags sur le projet ? Bien sr, cette question relativement simple peut se voir complique par diverses considrations : i l se peut que la socit ait fait une perce dans un secteur duquel elle tait absente, ou bien que certains des composants ou sous-systmes produits dans le cadre de ce contrat permettent une rduction des cots sur de futurs contrats.

Dans le second cas, le plan stratgique est plus compliqu tablir. La russite se mesure la capacit du produit atteindre des objectifs tels que le taux d'obstacles sur le capital investi dans le dveloppement. la fin de la phase de transition et du projet, toutes les donnes, telles que le niveau des ventes futures, ne sont pas encore disponibles, mais la socit sait dj ce qu'elle a dpens et a une meilleure apprhension des perspectives qui s'offrent elle. Le responsable du projet fait en sorte de runir toutes les donnes disponibles et convoque une runion pour les examiner.

16.6.2 Post mortem du projet

Contrairement l'valuation, la runion post mortem est largement consacre l'analyse des russites et des checs de l'organisation du projet. L'objectif est de crer des archives qui permettront aux projets ultrieurs de s'organiser plus efficacement et de mener le processus de dveloppement avec plus de russite. Les points concernant le systme qui vient d'tre dvelopp doivent tre consigns pour servir aux personnes charges de la maintenance et l'quipe de la prochaine version. Par exemple, si les raisons ayant prsid au choix de la conception utilise sont gnralemenl archives, celles qui ont conduit en rejeter d'autres peuvent tre tout aussi utiles aux futures quipes. Les points pertinents pour le processus de dveloppement lui-mme doivent tre examins attentivement : - Est-il ncessaire de complter la formation gnrale ? - Quels sont les aspects requrant une formation spcialise ? - Le monitorat doit-il se poursuivre ? - L'exprience acquise travers ce projet sur certains aspects spcialiss du Processus unifi (voir le chapitre 2) offre-t-elle une vision plus claire, susceptible de bnficier a des projets futurs ?

16.6 valuer la phase de transition

Le chef de projet rassemble un petit groupe de personnes pour valuer la phase de transition (voir aussi la section 12.8) et mener une tude post mortem du cycle de dveloppement dans son ensemble. Cette valuation se dmarque de celles menes l'issue des phases prcdentes pour deux raisons. D'abord, i l s'agit de la dernire phase ; i l n'existe aucune phase ultrieure laquelle lguer le travail non termin. Dans un systme d'une certaine envergure, nanmoins, il y aura un groupe charg du produit, auquel pourront tre transmises quelques ides utiles. Ensuite, bien qu'il s'agisse de la dernire phase du cycle de dveloppement actuel, i l est probable que d'autres cycles de dveloppement suivront. Le groupe d'valuation doit donc archiver les constatations qui pourront leur tre utiles. Ces constatations ressortissent deux catgories, voques par les sous-sections suivantes.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
_ _ \ III

16.7 Planifier la version ou la gnration suivante

L'exprience de l'industrie du logiciel au cours des dernires dcennies montre que peu de produits logiciels demeurent longtemps inchangs. Le matriel et les systmes d'exploitation sur lesquels ils s'excutent voluent en permanence. Le contexte commercial et administratif change constamment. Or, l'industrie logicielle ne cesse d'largir sa prise en charge de secteurs de plus en plus divers du monde des affaires, des domaines industriel et administratif, et de la sphre prive. La quasi-totalit des systmes logiciels entrent presque immdiatement dans un nouveau cycle de dveloppement, qui reprend les phases de cration, d'laboration, de construction et de transition.

17
Application optimale du Processus unifi

16.8 Principaux lments livrer

Les lments que doit livrer cette phase sont trs semblables ceux de la phase de construction (voir le chapitre 15), entre-temps corrigs et dsormais complets : le logiciel excutable lui-mme, avec son programme d'installation ; les documents lgaux, tels que les contrats, licences, conditions de dsistement et garanties ; la version de rfrence du produit complte et corrige, avec tous les modles du systme ; la description de l'architecture complte et corrige ; la versionfinaledes manuels de l'utilisateur, du technicien et de l'administrateur systme et des supports de formation ; les coordonnes des services de support clientle et les adresses Internet o trouver de plus amples informations, rendre compte des anomalies dtectes et obtenir des renseignements sur les correctifs et les mises jour.

Le dveloppement de logiciels dans le cadre de systmes stratgiques demeure extrmemenl complexe, comme l'ont clairement fait apparatre les chapitres prcdents. Dans ce dernier chapitre, nous voudrions une fois encore, titre de rvision gnrale, rassembler les diverses pices du puzzle. Notre but est de montrer, de manire plus concise que dans les chapitres prcdents, la faon dont ces diffrentes pices s'assemblent pour former un processus oprationnel. Par ailleurs, nous largirons notre propos deux autres notions. D'abord, si le processus logiciel est complexe en lui-mme, sa gestion le sera galement. Ensuite, le passage d'une absence totale de processus ou d'un processus antrieur ad hoc au Processus unifi ne sera pas une mince affaire.

17.1 Le Processus unifi aide grer la complexit

Avant tout, i l y a les quatre phases : cration, laboration, construction et transition. Au-del des phases du cycle initial - puisque les systmes logiciels d'envergure ne cessent d'voluer - viennent les versions ultrieures et, pour les rvisions exhaustives, les gnrations suivantes. Au sein de ces phases s'entremlent les enchanements d'activits, l'architecture, la gestion des risques, les itrations et les incrments, dcrits ci-dessous. U n dveloppement logiciel pilot par les cas d'utilisation par le biais des enchanements d'activits : besoins, analyse, conception, implmentation et tests. U n dveloppement guid par l'architecture : l'armature des lments structurels et comportementaux permettant une volution lgante du systme. Un dveloppement l'aide de briques de base et de composants, autorisant un niveau lev de rutilisation. Un dveloppement men travers les itrations et les constructions au sein de ces itrations, donnant lieu une croissance progressive du produit.

' r
mm Un d v e l o p p e m e n t itratif et i n c r m e n t a l
JH PARTIE III

Application optimale du P r o c e s s u s u n i f i mm
CHAPITRE 17 mm

Un dveloppement qui matrise les risques. Un dveloppement visualis et consign grce au langage UML (Unified Modeling Language). Un dveloppement articul autour de jalons. Quatre types de jalon permettent d'ancrer ce processus : les objectifs du cycle de vie, l'architecture du cycle de vie, la capacit oprationnelle initiale et la livraison du produit [1].

17.1.3 Capacit oprationnelle

initiale

Le troisime jalon tablit que le produit a atteint une capacit oprationnelle initiale : le produit est-il dot des capacits lui permettant un fonctionnement initial dans l'environnement utilisateur et propices la conduite de tests bta ?

17.1.1 Les objectifs

du cycle de vie

Le premier jalon clarifie les objectifs du cycle de vie du produit en soulevant des questions du type : Avez-vous clairement dlimit la porte du systme ? Avez-vous tabli ce qui doit se trouver l'intrieur du systme et ce qui doit rester l'extrieur ? tes-vous parvenu un accord avec les intervenants sur les besoins essentiels du systme ? Entrevoyez-vous une architecture capable d'implmenter ces caractristiques ? Avez-vous identifi les risques compromettant la russite du projet ? Voyez-vous un moyen de les rduire ? L'utilisation du produit gnrera-t-elle des avantages justifiant l'investissement ncessaire sa construction ? Est-il raliste d'entreprendre le projet ? Les intervenants contribuent-ils la satisfaction des objectifs ? Il appartient la phase de cration d'apporter une rponse ces questions.

C'est bien l, la question centrale du troisime jalon. Ce jalon se profile dans les conditions suivantes : une architecture de rfrence a t tablie, les risques ont t rpertoris, un plan du projet a t labor et les ressources sont disponibles. I l s'agit donc, maintenant, tic pro cder la construction du produit. Si l'on a progress en s'appuyant sur les objectifs et l'architecture du cycle de vie, cette construction se droulera en douceur. Il est fondamental, dans cette phase, de squencer les constructions et les itrations. Pour que ce .squeiieemeni soit efficace, i l faut que les prrequis de chaque nouvelle itration soient bien en place. Il faut galement faire en sorte de ne pas avoir revenir en arrire pour reprendre une Itration antrieure la lueur de dcouvertes plus tardives. Toutefois, malgr tous les efforts produits pour viter les problmes, il en apparatra ton jours. I l faudra donc surmonter ici ces problmes jour aprs jour. Il appartient a la phase de construction de construire le systme.

17.1.4 Livraison

du

produit

Le quatrime jalon tablit que le produit est prt pour une diffusion sans restriction auprs des utilisateurs : le produit peut-il fonctionner avec succs dans un environnement utilisateur typique ? Une fois que l'on a atteint la capacit oprationnelle initiale, i l reste encore du pain sur la planche : mener les tests bta et les tests d'acceptation, corriger les problmes et les anomalies apparus pendant le fonctionnement dans un environnement de travail. Lorsque les utilisateurs sont satisfaits, le produit peut tre livr. Il appartient la phase de transition de mener bien ces diverses tches.

17.1.2 L'architecture

du cycle de vie

Le deuxime jalon clarifie l'architecture du cycle de vie du produit, travers les questions formules ci-dessous. Avez-vous cr une architecture de rfrence excutable ? Celle-ci est-elle robuste et capable de ragir aux changements ? Est-elle en mesure d'voluer tout au long du cycle de vie du logiciel ? Avez-vous identifi et rduit les principauxrisquesau point d'tre certain qu'ils ne compromettront pas le plan du projet ? Avez-vous dvelopp le plan du projet un degr permettant d'tablir une offre raliste prenant en compte le calendrier, les cots et la qualit ? Le projet, tel qu'il est planifi et budgt, va-t-il produire le retour sur investissement espr ? Avez-vous obtenu l'accord des intervenants ? Il appartient la phase d'laboration d'apporter une rponse ces questions.

17.2 Les principaux thmes

Plusieurs thmes sous-tendent le parcours travers les quatre jalons majeurs et les lient les uns aux autres : les besoins, l'architecture, le dveloppement bas sur les composants, le langage UML, les itrations et la gestion des risques. (L'ordre dans lequel ces diffrents thmes sont recenss ne reflte pas leur importance respective. Ils sont tous importants et doivent se conforter mutuellement.) Identifier les vritables besoins

Identifiez les vritables besoins en modlisant les cas d'utilisation, en procdant l'analyse, en cherchant recueillir des ractions, etc. Les cas d'utilisations constituent le meilleur moyen d'entrer de plain-pied dans le Processus unifi.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

Application optimale du P r o c e s s u s u n i f i
CHAPITRE 17

n
Mm

Crer l'architecture approprie Tout projet d'une taille respectable doit tre centr sur l'architecture. L'architecture permet de scinder un systme en plusieurs parties, qu'elle fait cooprer. Elle solidifie les interfaces entre ces diverses parties et permet aux quipes de travailler indpendamment les unes des autres, de part et d'autre de ces interfaces, qui sont ainsi prserves en l'tat. La surveillance architecturale maintient l'orientation technique du projet. Utiliser des composants Les interfaces fermement tablies de l'architecture (ainsi que les interfaces standard des groupes standard) constituent l'un des lments qui rendent possible le dveloppement bas sur les composants. Les briques de base rutilisables permettent de rduire les cots du dveloppement, de raccourcir les dlais de mise sur le march et d'amliorer la qualit du produit. Rflchir et communiquer en UML Le dveloppement logiciel ne se borne pas l'criture de code. Le langage UML (ainsi que les autres caractristiques du Processus unifi) fait du dveloppement logiciel une discipline d'ingnierie.. I l s'agit d'un langage graphique qui offre aux informaticiens les moyens de rflchir, de visualiser, d'analyser, de communiquer et de consigner. Sans un moyen de communication standard tel qu'UML, i l serait extrmement difficile, non seulement de comprendre ce que font les autres personnes impliques dans le dveloppement, mais aussi de transmettre les informations d'une phase l'autre, d'une version l'autre et d'une gnration l'autre. Procder par itrations Les itrations et les constructions procurent divers avantages : un dcoupage du travail en portions limites, une rpartition des ressources en groupes de travail rduits, un lien avec la gestion des risques, de frquents points de contrle et de retours. Grer les risques Identifiez les risques (qu'ils soient critiques, significatifs ou courants), inscrivez-les sur une liste des risques et rduisez-les avant qu'ils ne surgissent dans le processus de dveloppement.

logiciel, mais n'en sont pas forcment tout fait satisfaites. Certes, ces dernires mettent au point des logiciels, parfois avec une exceptionnelle russite, mais elles sentent confusment qu'il y a moyen de mieux faire. Et elles ont raison. Comment ces socits parviennent-elles trouver la voie qui leur convient ? Ce n'est certes pas un individu isol au bas de l'chelle hirarchique qui est susceptible de provoquer cette transition. I l pourra toujours s'imposer comme le champion de la nouvelle culture, mais aprs que l'organisation dans son ensemble aura dcid de faire sa rvolution interne. Non, cette dcision incombe clairement au sommet de la hirarchie de l'organisation de dveloppement logiciel. C'est aux responsables d'engager le mouvement, car cette orientation aura un effet sur toute l'organisation. C'est eux de comprendre qu'il existe de meilleurs moyens de procder et qu'il serait utile d'en profiter. C'est eux, encore, de sentir que la concurrence impose d'agir vite. Cet embryon d'ide leur sera peut-tre souffl par des confrres dont la socit a dj amorc son virage vers l'adoption d'un processus logiciel

17.3,1 Les raisons d'agir

tant donn que cette nouvelle philosophie va faire tache d'huile dans les autcei MCteuri de l'organisation de dveloppement logiciel et dans l'entreprise tout entire, le principal responsable doit absolument gagner l'adhsion d'autres cadres. I l peut, pour cela, rdiger un plan d'action plaidant en faveur de cette nouvelle orientation. I l suffira, en gnral, de faire le point sur la situation actuelle et d'expliquer qu'elle ne saurait durer plus longtemps : les cots sont trop levs, la qualit trop faible et, surtout, les dlais de mise sur le march beaucoup trop longs. Or, mme si les logiciels sont destins un usage interne, on ne bnficie pas assez tt des avantages que confrent de meilleurs logiciels face la concurrence. Des amliorations de 5 % d'une anne sur l'autre ne suffisent plus. I l est aujourd'hui possible d'obtenir des rsultats nettement suprieurs en termes de cots, de dlais et de qualit. D'autres socits l'ont dj montr.

17.3 Les responsables dirigent la transition vers le Processus unifi

Le travail qui consiste grer et contrler un processus en cours en entrane un autre : i l faut amener l'entreprise ou l'administration abandonner ses anciennes habitudes pour en adopter de nouvelles. Le monde des affaires et celui de l'administration se composent dsormais de nombreuses organisations ; toutefois, celles qui adoptent la notion de processus logiciel ne sont pas lgion. Or, ces organisations dveloppent des logiciels ; c'est donc qu'elles trouvent un moyen d'y parvenir. Mais elles ne suivent pas des procdures rationnelles et reproductibles. D'autres quipes disposent bien d'une sorte de processus

Les plaidoyers en faveur d'une action dcisive conduisent s'interroger sur la nature mme de cette action. Les organisations de dveloppement logiciel, en rgle gnrale, ne sont pas impliques dans l'laboration de mthodes, d'outils, de briques de base ou de composants. Ce rle revient d'autres types d'organisation. I l s'agit, par exemple, de socits de fabrication et de commercialisation de composants, ou d'organisations, telles que SAP, fournissant des systmes prfabriqus adaptables chaque entreprise. (Un systme prfabriqu est une infrastructure complte laquelle le client, avec l'aide du fournisseur, apporte quelques modifications mineures pour rpondre ses besoins spcifiques.) D'autres socits, comme Rational Software Corporation, prennent en charge le Processus unifi. I l appartient au responsable du dpartement logiciel de trouver l'aide dont a besoin son organisation. Les possibilits n'tant pas infinies, la plupart des structures de dveloppement logiciel ne se voient offrir qu'une seule voie : celle du dveloppement bas sur les composants. C'est au responsable, nouveau, qu'il revient d'valuer la situation et de dterminer s'il faut cssayei de faire le maximum par soi-mme, comme dans les secteurs de la banque, de l'assurance, de la dfense ou des tlcommunications, ou s'il est prfrable d'avoir recours un systme prfabriqu, qui s'articulera autour de briques de base rutilisables. Quelle que soit l'option choisie, il sera ncessaire, dans la plupart des cas, de dvelopper en interne une part plus ou

H g Un d v e l o p p e m e n t itratif et i n c r m e n t a l
Jn PARTIE Iil

Application optimale du P r o c e s s u s u n i f i MB
CHAPITRE 17 mm,

moins importante du systme. Quelqu'un devra se charger d'acqurir ces briques de base. Quelqu'un devra se charger de les adapter aux besoins spcifiques de l'entreprise. Tout cela ncessite de suivre un processus. Et c'est bien souvent le Processus unifi qui s'imposera aux yeux de tous comme la rponse la plus approprie.

survie dans le futur. Ces personnes doivent recevoir une premire formation afin de pouvoir participer aux dbats sur l'avenir de la socit. I l ne faut, aucun prix, qu'elles aient l'impression d'tre mises l'cart. Un tel sentiment pourrait compromettre la russite mme de cette transition. Avoir confiance en son propre avenir

17.3.2 La directive

de ringnierie

achve de

convaincre

Le responsable qui est l'origine du changement de procdure doit expliquer de faon claire, dtaille et sans bla-bla, dans la directive de ringnierie, les raisons qui peuvent pousser la socit adopter un processus logiciel amlior. Cette directive aborde les thmes suivants : la situation actuelle de l'entreprise et son volution ; les nouvelles attentes de ses clients ; la concurrence laquelle l'entreprise doit faire face ; les dfis qu'elle doit relever ; le diagnostic qu'imposent ces dfis ; les risques qu'implique l'immobilisme ; les mesures que doit prendre l'entreprise, en particulier en matire de processus logiciel [2] .
1

Les personnes impliques dans cette transition sont des professionnels de l'informatique. Malgr une histoire trs courte selon les standards habituels, ce domaine a dj connu des transformations radicales. Certains prouvent des difficults rester au fait de ces volutions. Les cadres moyens, en raison des charges administratives auxquelles ils doivent faire face, ressentent particulirement ce poids. Le fait de les rassurer sur leur avenir peut faciliter la transition. Les socits traditionnellement soucieuses du bien-tre de leurs employs mai quent un avantage dans ce domaine. Mais toutes doivent avoir conscience de l'importance de cet aspect de la question.

17.3.3 Mettre en uvre la

Le champion

transition

Le responsable informatique se trouve confront des questions de mise en uvre,

Garantie d'un soutien financier Les chefs de projet doivent avoir la certitude qu'ils peuvent compter sur un soutien financier constant. Cette garantie couvre entre autres la formation initiale, un accompagnement lors des premires applications du nouveau processus et une formation continue en fonction de l'volution des besoins. N'essayez pas de passer au nouveau processus sans claireur . C'est le rle des mentors, qui doivent savoir comment procder et peuvent appartenir ou non la socit. Le lancement d'un nouveau projet avec un nouveau processus est tributaire de l'intgration complte de quatre types de prise en charge : le processus, les outils, la formation et les mentors. Continuit des projets existants Dans une socit d'envergure o de nombreux projets sont en cours, les projets actuels et la plupart de ceux qui dbuteront dans un futur proche devront continuer exploiter l'ancien processus. On ne peut pas former tout le monde d'un coup. Et tous les projets ne peuvent se permettre de subir le trouble que risque d'entraner un changement spectaculaire. En mme temps, la directive de ringnierie doit clairement affirmer que les responsables et les membres du personnel qui continueront travailler sur des projets existants ne seront pas pour autant mis l'index. Eux aussi seront forms, en temps et en heure, et se verront affects des projets utilisant le Processus unifi. Mais la transition prend du temps. Et la socit doit videmment poursuivre son activit, condition tout aussi indispensable sa
1. [2] dcrit le contenu de la directive de r i n g n i e r i e , telle q u ' e l l e s'applique la rutilisation. L a psychologie q u i sous-tend cette directive vaut tout autant pour le processus logiciel.

Le premier problme est la constitution de la structure qui va mettre en uvre la transition. Le responsable informatique tant dj suffisamment occup par ailleurs, i l faut qu'il puisse se reposer sur un ingnieur ayant les comptences techniques pour dfendre nergiquement la nouvelle orientation au jour le jour, c'est--dire pour s'assurer que le changement s'impose peu peu. Ce champion du changement doit bien comprendre le Processus unifi. Pour acqurir une telle connaissance, il doit suivre une formation et bnficier de conseils personnaliss. Le champion peut tre un chef de projet techniquement comptent. Ou un architecte ayant les attributions d'un chef de projet. I l a tudi le Processus unifi, est convaincu de son utilit pour la socit et montera volontiers au crneau pour dfendre cette position. En mme temps, i l doit jouir de la confiance des cadres soutenant son action, mais aussi des personnes impliques dans le projet. I l s'entend aussi bien avec les responsables qu'avec les techniciens. D sait convaincre. S'il s'intresse aux mthodes et processus, i l fait preuve d'une maturit suffisante pour viter tout dogmatisme et ne pas vouloir tout recommencer zro avec sa mthode lui . I l aura, au contraire, l'intelligence d'adapter le Processus unifi aux besoins spcifiques du premier projet. Il n'est pas indispensable que le champion ait dj men tout un projet avec le Processus unifi. C'est d'ailleurs peu probable, puisqu'il est cens travailler dans la socit depuis assez longtemps. I l suffit qu'il en comprenne les implications ; on attend de lui qu'il prouve un dsir ardent de mettre en uvre ce processus. Avec l'aide, videmment, du chef de projet et du mentor, tous deux dcrits ci-dessous. Le chef de projet responsable du premier projet Mis part ce champion (au fait, si vous n'arrivez pas trouver l'tre exceptionnel que nous venons de dcrire, prenez le meilleur dont vous disposez et assurez-le de votre soutien ind

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

Application optimale du P r o c e s s u s u n i f i MB
CHAPITRE 17 mm

fectible), le responsable informatique a galement besoin d'un chef de projet particulirement comptent. Un chef de projet capable de sentir au plus profond de lui-mme qu'il importe non seulement d'adopter le nouveau processus, mais encore de le mener son terme. Il n'en reste pas moins que le projet doit russir pour contrecarrer la perplexit que ne manquera pas de susciter l'adoption du nouveau processus.

Certains arrivent parfois, i l faut le reconnatre, rorganiser le processus logiciel petit petit ; mais il vaut mieux ne pas y compter : la procdure est longue et l'chec est souvent au bout du chemin. Quoi qu'il en soit, il est souhaitable que la transition se droule sous un contrle rigoureux pour parvenir son terme. Les checs dus un manque de contrle sont difficiles rattraper.

Le mentor La formation ne fait pas tout. En l'occurrence, elle ne remplace pas l'exprience pratique. Le champion et le chef de projet ont donc besoin du soutien d'un consultant (interne ou externe) ayant men des projets leur terme avec le Processus unifi. Le mentor n'a pas justifier d'une exprience de la gestion de projet, mme si c'est un plus. I l doit runir deux qualits spcifiques. L'une est la capacit anticiper les problmes susceptibles d'apparatre dans le projet. Cette capacit, bien entendu, repose sur son exprience antrieure de l'adoption du Processus unifi. L'autre est la facult de cooprer avec les personnes trs diverses qu'il va rencontrer, notamment le champion, mais aussi le chef de projet, les personnes impliques dans le projet et la direction informatique.

17.4 Spcialiser le Processus unifi

Le Processus unifi, tel qu'il est prsent dans cet ouvrage, ne constitue pas l'alpha et l'omga sur le sujet. I l reste deux choses extrmement importantes en dire. D'abord, c'est une infrastructure prfabrique. Elle doit tre adapte en fonction d'un certain nombre de variables : la taille du systme enjeu, le domaine dans lequel doit fonctionner ce systme, la complexit du systme, enfin le niveau d'exprience, de comptences ou de connaissance du processus de l'organisation du projet et des personnes qui la composent. Deuximement, ce livre, aussi dtaill qu'il puisse vous paratre, n'offre qu'une prsentation gnrale du pin cessus en marche. Pour l'appliquer, i l vous manque un nombre considrable d'informations. Nous abordons ces deux spcialisations dans les sections qui suivent.

Par o commencer ? Le premier projet doit tre un projet rel, dont les rsultats auront de l'importance. Notre exprience des projets pilotes artificiels n'est, en effet, gure encourageante. Ils ont tendance stagner et leurs rsultats, quels qu'ils soient, ne font pas grande impression. Le premier projet doit au contraire tre stratgique, mais soumis des dlais raisonnables. Ah, amusant, vous dites-vous, mais tous les projets stratgiques sont urgents ! Nous le savons. En fait, l'utilisation du Processus unifi permet d'avancer plus rapidement que les anciennes mthodes. Les risques tant dtects trs tt et l'architecture tant rapidement oprationnelle, la construction se droule plus facilement. De plus, le premier projet sera guid par des mentors, proclams tels prcisment en vertu de leur exprience du processus, et donc capables de mener bien sa mise en uvre.

17.4.1 Adapter

le

Processus

Les systmes et produits logiciels, et les organisations qui les mettent au point, sont plus divers que jamais. En consquence, s'il y a bien quelques constantes dans le Processus unifi, comme les quatre phases et les cinq enchanements d'activits principaux, on se trouve confront un grand nombre de variables. Par exemple, quelle doit tre la longueur relative des phases ? Quel est le nombre appropri d'itrations pour chaque phase en fonction du contexte ? quel stade l'architecture candidate (ou la rduction des risques critiques, l'architecture de rfrence, l'tude de rentabilit, etc.) est-elle assez fermement tablie ? La rponse des questions telles que celles-ci dpend de la taille du systme, de la nature de l'application, de l'exprience de l'organisation charge du projet dans le domaine en question, de la complexit du systme, de l'exprience de l'quipe du projet, des comptences des responsables logiciels, et mme de la capacit des intervenants cooprer les uns avec les autres.

En fait, i l est plus prudent d'adopter l'approche complte sur un projet rel, sans pour autant tout bouleverser. Un nouveau processus, oui ; et aussi les outils qui vont avec ( condition qu'ils soient bien intgrs). Mais un nouveau systme d'exploitation, une nouvelle technologie de base de donnes, un nouveau langage de programmation, une nouvelle plate-forme de systme distribu... peut-tre pas. Inutile d'accumuler les nouveauts, notamment des technologies qui ne cohabitent pas trs bien. Selon les circonstances, vous pourrez accueillir une ou deux technologies nouvelles. Et ne choisissez pas un systme trop complexe comme banc d'essai. Autres considrations Notre exprience nous livre quelques ultimes rflexions. L'approche prsente dans ces pages ne reflte pas toujours celle que l'on suivra dans la ralit, mais elle dcrit le moyen systmatique d'adopter le Processus unifi. Une approche plus progressive, marque par un nombre d'tapes suprieur, risquerait de tomber dans l'cueil inverse : la progression devient presque impalpable, les soutiens s'vaporent dans la nature et la transition choue.

Par exemple, si le systme est relativement modeste et que l'quipe du projet connat bien le domaine (si elle a ralis des versions prcdentes ou des produits comparables), la phase de cration peut tre trs brve. Les membres de l'quipe (et certainement les intervenants) savent qu'aucun risque critique ne viendra entraver la russite du dveloppement. Ils savent aussi qu'ils peuvent rutiliser une architecture ayant dj servi. Quelques jours peuvent donc suffire pour terminer la phase de cration en confirmant la porte du systme et en s'assurant qu'aucun risque nouveau n'est apparu dans ce cadre.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

Application optimale du Processus u n i f i mm

CHAPITRE 17 an

Le monde de l'enseignement : enseignants et formateurs peuvent orienter leurs cours sur les lments que doivent connatre les tudiants pour exploiter le Processus unifi et pour rflchir et visualiser leurs ides l'aide du langage UML. Le monde du logiciel : les architectes, dveloppeurs et autres professionnels peuvent passer directement d'un projet l'autre, et mme d'une socit l'autre, sans avoir perdre du temps s'adapter aux pratiques spcifiques l'entreprise en question. Le monde de la rutilisation : les projets peuvent rutiliser plus facilement des soussystmes et des composants, car ils sont reprsents en UML. Le monde des outils : les projets seront pris en charge par des outils plus efficaces, car le march plus vaste du Processus unifi fournit un meilleur argument financier pour le dveloppement d'outils.

Prenons un autre exemple : celui d'un systme vaste, complexe et indit pour l'quipe du projet. On peut, dans ce cas, s'attendre ce que la phase de cration, ainsi que la phase d'laboration, dure beaucoup plus longtemps et passe par un plus grand nombre d'itrations. Les variations sur ces thmes sont aussi nombreuses que les systmes construire. C'est l qu'intervient l'exprience. C'est l que le chef de projet est bien inspir de s'entourer de l'exprience de spcialistes du logiciel, ainsi que des connaissances des intervenants. Vous pouvez ainsi adapter le processus votre propre situation [3].

17.4.2 toffer l'infrastructure

du

Processus

17.6 Profiter des avantages qu'offre le Processus unifi

Etablissez fermement les besoins trs tt en faisant voluer les cas d'utilisation avec la eoo pration des utilisateurs rels et des personnes charges de l'ingnierie du processus. Passe/ ensuite des besoins aux enchanements d'activits suivants (analyse, conception, etc.) en toute efficacit, puisque le Processus unifi est pilot par les cas d'utilisation (annexe C). Consolidez les objectifs du projet. Guidez l'quipe du projet dans cette direction. laborez un guide pour les futures gnrations du produit. Le tout par l'intermdiaire d'une architecture du cycle de vie la fois comprhensible, ractive aux changements, robuste et capable d'voluer dans les annes venir, puisque le Processus unifi est centr sur l'architecture. Dveloppeurs comme intervenants, tirez des leons des constructions et itrations successives, puisque le Processus unifi est itratif (annexe C) et incrmental. Rduisez le plus possible la probabilit que des risques critiques mettent en pril la russite du projet ou que des risques significatifs n'en compromettent le budget ou le calendrier, puisque le Processus unifi est orient vers la rduction des risques (annexe C). Acclrez le rythme du dveloppement, rduisez les cots et amliorez la qualit du produit grce la rutilisation de briques de base, puisque le Processus unifi est bas sur les composants. Permettez tous les membres de l'quipe, ainsi qu'aux intervenants, de travailler de concert, puisque le Processus unifi est plus qu'un guide l'usage de dveloppeurs individuels : c'est un processus rationalis (par des ingnieurs pour des ingnieurs).

Nous l'avons dj dit, le Processus unifi dcrit dans ces pages ne donne qu'une ide sommaire du processus qu'il vous faudra suivre pour diriger une quipe travaillant au dveloppement d'un systme. L'objet de cet ouvrage est de permettre aux techniciens et aux responsables de comprendre le processus. I l ne fournit pas les conseils et les directives dtailles qui devront guider les membres de l'quipe dans leur travail quotidien. I l se contente de nommer certains des artefacts que cre/utilise le processus ; i l y en a d'autres. I l ne procure aucun modle de document. I l n'identifie pas tous les types de travailleurs ; i l y en a d'autres. I l indique, l'occasion, que des outils peuvent se rvler d'un grand secours dans l'application du processus. En fait, une grande partie du travail de routine impliqu par la mise en uvre du processus peut tre effectu par des outils, et ce avec beaucoup plus de rapidit et de prcision que par des personnes livres elles-mmes. L'ouvrage ne dcrit pas prcisment ces outils, ce quoi ils servent, ni leur mode d'emploi. D'une manire gnrale, ce livre n'aborde que les grandes lignes du processus. I l dcrit certains enchanements d'activits, certains artefacts, certains travailleurs et certaines de leurs activits, enfin certains usages du langage UML. Mais i l y a bien plus. Pour une version hautement dveloppe, i l vous faut le processus Rational Unified Process, base de connaissances interrogeable en ligne comprenant environ 2 000 pages de donnes. Ce produit amliore la productivit de l'quipe en lui fournissant tout un arsenal de directives, de modles et d'outils pour les activits les plus dlicates du dveloppement. Le processus s'intgre d'autant mieux avec les outils de Rational qu'ils ont t mis au point ensemble. En permanence actualis, le contenu du processus est pris en charge par un ensemble complet de cours et forme la base des conseils personnaliss que prodiguent les mentors. Le processus Rational Unified Process s'inscrit dans le prolongement de Rational Objectory Process. Si vous avez utilis ce dernier, sa mise niveau avec le nouveau Rational Unified Process ne posera aucun problme.

17.5 largir le cercle de ses interlocuteurs

En plus d'instaurer un environnement de travail plus efficace pour le projet et d'tablir des relations plus fructueuses entre les utilisateurs et les intervenants, le Processus unifi ouvre des possibilits d'change avec les catgories suivantes.

Le fait de disposer d'une telle infrastructure de phases, d'itrations, de jalons et d'valuations offre des points de repre qui permettent aux intervenants de savoir o en est le dveloppement. Grce cette comprhension de l'tat du dveloppement et leur connaissance du domaine de l'application, ils peuvent ainsi mettre des suggestions visant d'ventuelles amliorations du systme. Mais surtout, comme les premires phases prennent en considration les aspects essentiels, comme l'architecture et les risques, ils peuvent soumettre leurs ides un moment o l'on peut encore en faire bon usage.

Un d v e l o p p e m e n t itratif et i n c r m e n t a l
PARTIE III

Aboutissement de 30 ans de pratique, le Processus unifi rassemble l'exprience de plusieurs experts minents et d'organisations spcialises. I l s'unifie autour d'un grand nombre d'applications et de techniques, et prsente les caractristiques suivantes : i l est visualisable : les modles et artefacts visuels employs par le Processus unifi sont exprims dans le langage UML, ce qui confre au processus de nombreux avantages, puisqu'il permet une rutilisation intensive des logiciels et fournit des plans d'laboration et de construction ; i l est outiliable : la prsence d'un processus unifi et d'un langage standard garantit un soutien financier un outillage plus important qui, son tour, amliore l'efficacit du processus ; i l est adaptable : i l s'agit non pas d'un processus rigide, mais d'une infrastructure de processus adaptable diffrents domaines d'application et aux besoins spcifiques de chaque organisation ; i l est extensible : le Processus unifi ne limite pas ses utilisateurs une seule faon de procder, par exemple, l'analyse des risques. Les utilisateurs peuvent trouver d'autres sources d'informations. Le Processus unifi se contente de leur proposer des repres logiques dans lesquels insrer les activits (en l'occurrence l'activit d'analyse des risques), de prfrence tt plutt que tard dans le processus. Le Processus unifi assiste les organisations de dveloppement de bien des manires. Le premier de ses avantages est d'tablir les conditions d'une collaboration optimale entre les membres de l'quipe. Mais la synergie ainsi cre ne s'arrte pas l : le Processus unifi permet aussi l'quipe du projet d'instaurer une coopration fructueuse avec les utilisateurs et les divers intervenants.

A
Prsentation gnrale du langage UML
A.1 Introduction

17.7 Rfrences
1 2
3

Barry BOEHM, Anchoring the software process , IEEE Software, juillet 1996, p. 7382. Ivar lACOBSON, Martin GRISS et Patrik JONSSON, Software Reuse: Architecture, Process
and Organization for Business Success, Reading, MA, Addison-Wesley, 1997. Walker ROYCE, Software Project Management: A Unified Framework, Reading, M A ,

Addison-Wesley, 1998.

Les branches les plus anciennes de l'ingnierie ont depuis longtemps compris l'intrt de reprsenter les conceptions sous forme de graphiques. Ds les premiers temps de l'informatique, les programmeurs ont utilis diffrents types de schmas ou, plus largement, de modles pour prsenter leurs ides. Les dveloppeurs (de logiciels) ont besoin d'un moyen de communiquer leurs modles, non seulement aux membres des quipes de projet, mais aussi aux intervenants extrieurs et, dans une perspective plus long terme, aux dveloppeurs des gnrations suivantes. I l leur faut un langage, certes pour communiquer, mais aussi pour dfinir le cadre de rflexion et d'analyse dans lequel pourra s'inscrire chaque dveloppeur individuellement. Par ailleurs, i l est impossible, pour ces dveloppeurs, de garder tout en tte pendant des mois et des annes : i l faut donc qu'ils puissent consigner leur travail sur papier ou sur un support lectronique. Le langage U M L (Unified Modeling Language) est un langage standard de modlisation des logiciels, c'est--dire un langage de visualisation, de spcification, de construction et de documentation des artefacts de systmes forte composante logicielle. Fondamentalement, le langage UML permet aux dveloppeurs de visualiser les produits de leur travail sous forme de plans d'laboration et de construction ou de diagrammes standardiss. Par exemple, les principaux symboles et icnes utiliss dans la formulation des besoins sont une ellipse pour reprsenter un cas d'utilisation et un bonhomme stylis pour dsigner un utilisateur employant le cas d'utilisation en question. De mme, l'icne centrale de la conception est le rectangle, qui figure une classe. Ces icnes ne forment, toutefois, qu'une notation graphique, c'est--dire une syntaxe. La section A.2 propose un survol rapide de la notation graphique du langage U M L ; [2] fournit une rfrence complte sur cette notation, tandis que [3] propose un guide de l'utilisateur. Mais audel de cette notation graphique, le langage UML vhicule aussi du sens, c'est--dire une smantique. Vous trouverez une prsentation sommaire de cette smantique travers les

rrm

A n n e x e s

P r s e n t a t i o n g n r a l e du langage UML ANNEXE A mmi

dfinitions des principaux termes U M L runies dans la section A.3. Pour une vritable description de la smantique d'UML, nous vous renvoyons de nouveau aux ouvrages [2] et [3]. Autre rfrence traitant la fois de la notation et de la smantique d'UML, le jeu de documentations publiques d'UML [1], d'une nature plus formelle, toutefois. Pour terminer, [4] et [5] constituent d'autres rfrences utiles.

contraintes. Les strotypes permettent de dfinir de nouveaux lments en largissant ou en affinant la smantique d'lments existants, tels que des lments ou des relations (voir la section A . l . l ) . Les valeurs marques permettent, quant elles, de dfinir de nouvelles pro prits d'lments existants. Enfin, les contraintes offrent un moyen d'imposer des rgles (par exemple, des rgles de cohrence ou des rgles mtier) des lments et leurs proprits.

A.1.1

Vocabulaire
Le langage U M L fournit un vocabulaire comprenant trois catgories d'archtypes, que nous ne mentionnerons ici que pour vous donner une ide d'ensemble de la structure lmentaire du langage : les lments, les relations et les diagrammes.

A.2 Notation graphique

Les dernires figures de cette annexe sont empruntes au Guide de l'utilisateur du langage UML, de Grady Booch, James Rumbaugh et Ivar Jacobson [3].

A.2.1 lments
Figure A.2 Classes et interfaces.

structurels
Classe Interface Les objets sont souligns. Les lments abstraits sont en italique.

Il y a quatre catgories d'lments : les lments structurels, comportementaux, de regroupement et d'annotation. Ces quatre catgories s'articulent elles-mmes de la faon suivante : sept types principaux d'lments structurels (cas d'utilisation, classes, classes actives, interfaces, composants, collaborations et nuds) ; deux types d'lments comportementaux (interactions et machines tats) ; quatre types de regroupements (paquetages, modles, sous-systmes et infrastructures prfabriques) ; enfin, un type principal d'lments d'annotation (note). La deuxime catgorie, celle des relations, se dcompose en trois types de classifications : dpendance, association et gnralisation.

+ origine : Point

Enfin, la troisime catgorie propose neuf types de diagrammes : les diagrammes de cas d'utilisation, de classes, d'objets, de squence, de collaboration, d'tats-transitions, d'activits, de composants et de dploiement.
Figure A.1 Vocabulaire du langage UML.
Diagrammes

dplacer(p : Ppjnt)__ + redimensionifr" (e : chelle) + affiche n") # invaliderZoneO Responsabilits - grer l'tat de la forme -- grer les transformations de base de la forme

lApplication

UML

compartiment supplmentaire

Structurels

Comportementaux

Regroupement

Dpendance Association Gnralisation

Interaction Machine t a t s

Figure A.3 Cas d'utilisation et collaborations. (Notez que le nom des cas d'utilisation, par exemple, peut tre plac l'extrieur mieux.) du symbole si cela convient

Cas d'utilisation Classe Classe active Interface Composant Collaboration Noeud

Paquetage Modle Sous-systme Infrastructure prfabrique

De cas d'utilisation De classes D'objets De s q u e n c e De collaboration D'tats-transitions D'activits De composants De d p l o i e m e n t

Collaboration

C a s d'utilisation

_e Chane de responsabilits

A. 1.2 Mcanismes

d'extensibilit

Le langage UML fournit des mcanismes d'extensibilit, qui permettent ses utilisateurs d'en affiner la syntaxe et la smantique. U M L peut ainsi tre adapt un systme, un projet ou un processus de dveloppement spcifique, si ncessaire. Vous trouverez un exemple de ce type d'adaptation dans l'annexe B. Ces mcanismes d'extensibilit se composent des strotypes, des valeurs marques et des

Des compartiments supplmentaires peuvent tre utiliss pour montrer le contenu.

Annexes

P r s e n t a t i o n g n r a l e du langage UML
ANNEXE A

Figure A.4 Classes menas. actives, composants et

Active Class

Component

Noeud

Figure A.6 Machine tats.

Machine tats

Gestionnaire Desvnements f : FileAttenteDesX-^ Evnements suspendre() viderQ

Imbriqu

garde

prt(3) [signalOK] oprations Classe active Composant Noeud Des compartiments supplmentaires peuvent tre uiss pour montrer te contenu. transition interne Connect

dcroch / rcuprerConnexionf)

A.2.2 lments
Figure A.5 Interactions.

comportementaux
Interaction
object

A.2.3 lments
Figure A.7 : BoiteAOutils Paquetages. - ligne de vie

de

regroupement

Paquetage

a1 : excuter(3) i i tiquette de squence

excuter()

calIbackLoopO

rappel Boucle ...

recursion

Des compartiments supplmentaires peuvent tre utiliss pour montrer le contenu.

A.2.4 lments
Figure A.8 Notes.

d'annotation

Note

> Envisager l'utilisation du design pattern Broker ici. egb 11/12/97

Annexes

1
dpendance A.2.8 Mcanismes
Figure A.12
Mcanismes d'extensibilit. i Titulaire -z> cible strotype

P r s e n t a t i o n g n r a l e du langage UML
ANNEXE A

j .2.5 Relations de
jureA.9
lations de ' tendance.

d'extensibilit

Dpendence

conteneur FileAttenteAction {version = 3.2}

valeur marque

{ajouter excutions dans 0(1) fois)

S
.2.6 Relations
i-igure A.10
Relations ISSOCiation.
n o m

ajoutera : Action) supprimer(n : Entier) requte longueur)) : Entier fonctions d'aide commander nouveau!)

contrainte

d'association
Association
multiplicit Emploie navigation

A.3 Glossaire
acteur Ensemble cohrent de rles que jouent les utilisateurs de cas d'utilisation dans leur interaction avec ces cas d'utilisation.

fin

0..1

e : employeur jm f f

> fin employ losange vide pour les agrgations losange plein pour les compositions

Ispcificateur d'interface

nom de rle

action Spcification d'une instruction excutable constituant une abstraction d'une procdure de calcul. Une action se traduit par un changement d'tat et s'effectue par l'envoi d'un message un objet ou par la modification d'une valeur dans un attribut. action asynchrone Requte dans laquelle l'objet expditeur n'attend pas les rsultats. Requte dans laquelle l'objet expditeur attend les rsultats.

.2.7 Relations de
]ure A.11
.^lations de

gnralisation

action synchrone activation

Gnralisation

Excution d'une action.

activit agrgat
-J> parent

tat d'exposition d'un comportement. Classe reprsentant le tout dans une relation d'agrgation.

discriminant

gnralisation.

agrgation Forme spciale d'association spcifiant une relation tout--partie entre l'agrgat (le tout) et une partie le composant (la partie). association Relation structurelle dcrivant un ensemble de liens, dans laquelle un lien est une connexion entre objets ; relation smantique entre deux ou plusieurs classificateurs impliquant les connexions entre leurs instances. association binaire Association entre deux classes. association n-aire Association entre n classes. Lorsque n est gal deux, l'association est binaire. Voir association binaire.

P r s e n t a t i o n g n r a l e du langage UML
ANNEXE A

mm
fmm

attribut Proprit nomme d'un classiflcateur dcrivant une gamme de valeurs que peuvent dtenir les instances de cette proprit. cardinalit Nombre d'lments d'un ensemble.

la dure de vie ; ces parties peuvent galement tre supprimes de faon explicite avant la mort de la classe composite. concurrence Droulement de deux ou plusieurs activits dans le mme intervalle de temps. La concurrence peut tre ralise par l'entrelacement ou l'excution simultane d'au moins deux threads. condition de garde Condition devant tre remplie pour permettre le dclenchement d'une transition associe.

cas d'utilisation Description d'un ensemble de squences d'actions, avec leurs variantes, effectues par un systme et donnant un rsultat satisfaisant pour un acteur particulier. classe Description d'un ensemble d'objets partageant la mme smantique ainsi que les mmes attributs, oprations et relations. classe abstraite Classe n'tant pas directement instancie. classe active Classe dont les instances sont des objets actifs. Voir processus, tche, thread. Classe pouvant tre directement instancie.

conteneur Objet destin contenir d'autres objets et fournissant des oprations permettant d'accder son contenu ou de le parcourir. contexte Ensemble d'lments lis pour un objectif particulier, comme la spcification d'une opration. contrainte Extension de la smantique d'un lment UML, permettant d'ajouter de nouvelles rgles ou de modifier les rgles existantes. dclencher dcoration base. Ou faire franchir. Excuter une transition vers un tat. Dtail de la spcification d'un lment s'ajoutant sa notation graphique de

classe concrte

classe d'association lment de modlisation ayant la fois les proprits d'une association et celles d'une classe. Une classe d'association peut tre vue comme une association ayant galement les proprits d'une classe, ou comme une classe ayant galement les proprits d'une association. classiflcateur Mcanisme dcrivant les caractristiques structurelles et comportementales. Les interfaces, les classes, les types de donnes, les composants et les nuds sont des classificateurs. classification multiple Variation smantique de la gnralisation, dans laquelle un objet peut appartenir directement plusieurs classes. client Classiflcateur demandant les services d'un autre classiflcateur.

dlgation Capacit d'un objet mettre un message adress un autre objet en rponse un premier message. dpendance Relation de smantique entre deux lments, dans laquelle la modification d'un des lments (l'lment indpendant) peut affecter la smantique de l'autre lment (l'lment dpendant). diagramme Prsentation graphique d'un ensemble d'lments, le plus souvent rendu sous la forme d'un graphique associant des sommets (les lments) et des arcs (les relations).

collaboration Socit de classes, d'interfaces et d'autres lments travaillant de concert pour fournir un comportement coopratif plus important que la somme de tous ses lments ; spcification de la faon dont un lment, tel qu'un cas d'utilisation ou une opration, est ralis par un ensemble de classificateurs et d'associations jouant des rles spcifiques, utiliss d'une faon spcifique. commentaire Annotation associe un lment ou un ensemble d'lments. composant Partie physique et remplaable d'un systme respectant et fournissant la ralisation d'un ensemble d'interfaces. composite Classe lie une ou plusieurs classes par une relation de composition.

diagramme d'activits Diagramme montrant le passage d'une activit l'autre ; les diagrammes d'activits donnent une vue dynamique d'un systme. Cas particulier d'un diagramme d'tats dans lequel tous tats, ou la plupart d'entre eux, sont des tats d'action et dans lequel toutes les transitions, ou la plupart d'entre elles, sont dclenches par la ralisation d'actions dans les tats source. diagramme de cas d'utilisation Diagramme montrant un ensemble de cas d'utilisation et d'acteurs, ainsi que leurs relations ; les diagrammes de cas d'utilisation donnent une vue statique des cas d'utilisation d'un systme. diagramme de classes Diagramme montrant un ensemble de classes, d'interfaces et de collaborations ainsi que les relations les unissant ; les diagrammes de classes donnent

composition Forme d'agrgation indiquant une forte relation de proprit et une dure de vie concomitante entre la partie et le tout ; des parties sans multiplicit dfinie peuvent tre cres aprs la classe composite elle-mme, mais une fois cres, elles en partagent

Annexes

P r s e n t a t i o n g n r a l e du langage UML
ANNEXE A

mm
mm

une vue statique d'un systme ; diagramme montrant une collection d'lments dclaratifs (statiques).

vnement Spcification d'une occurrence significative ayant une localisation temporelle et spatiale ; dans le contexte des machines tats, un vnement est l'occurrence d'un stimulus pouvant dclencher une transition vers un autre tat. excutable expditeur Programme pouvant tre excut sur un nud. Objet transmettant une instance de message un objet destinataire.

diagramme de collaboration Diagramme d'interaction mettant en relief l'organisation structurelle des objets expditeurs et destinataires de messages ; diagramme montrant l'organisation des interactions autour des instances et des liens qui les unissent. diagramme de composants Diagramme montrant un ensemble de composants et leurs relations ; les diagrammes de composants donnent une vue statique des composants d'un systme. diagramme de dploiement Diagramme montrant un ensemble de nuds et leurs relations ; un diagramme de dploiement donne une vue statique du dploiement d'un systme. diagramme d'tats-transitions Diagramme montrant une machine tats ; les diagrammes d'tats-transitions donnent une vue dynamique d'un systme.

exportation Dans le contexte des paquetages, fait de rendre un lment visible en dehors de l'espace de noms dans lequel i l se trouve. faade Paquetage strotyp ne contenant rien d'autre que des rfrences des lments de modle appartenant un autre paquetage. Permet de fournir une vue publique d'une partie du contenu d'un paquetage. focalisation du contrle Symbole figurant dans un diagramme de squence et montranl la priode au cours de laquelle un objet effectue une action, soit directement, soit par l'intermdiaire d'une opration subordonne. fournisseur Type, classe ou composant fournissant des services qui peuvent tre Invoqus par d'autres. framework Voir infrastructure prfabrique.

diagramme d'interaction Diagramme montrant une interaction, comprenant un ensemble d'objets et leurs relations, ainsi que les messages pouvant tre rpartis entre eux ; les diagrammes d'interaction donnent une vue dynamique d'un systme ; terme gnrique s'appliquant plusieurs types de diagrammes illustrant les interactions entre objets, comme les diagrammes de collaboration, de squence et d'activits. diagramme d'objets Diagramme montrant un ensemble d'objets et leurs relations un moment donn ; les diagrammes d'objets donnent une vue statique de la conception ou des processus d'un systme. diagramme de squence Diagramme d'interaction mettant l'accent sur l'ordonnancement temporel des messages. lment Constituant atomique d'un modle. Localisation d'un composant sur un nud.

gnralisation Relation de spcialisation/gnralisation telle que les objets de l'lment spcialis (le sous-type) peuvent tre remplacs par ceux de l'lment gnralis (le super-type). hritage Mcanisme par lequel des lments plus spcifiques intgrent la structure et le comportement d'lments plus gnraux. hirarchie de contenance Hirarchie d'espaces de noms compose d'lments et des relations de contenance qui les unissent. hritage d'interface Hritage de l'interface d'un lment plus spcifique ; ne comprend pas l'hritage de l'implmentation. hritage multiple Variation smantique de la gnralisation, dans laquelle un type peut avoir plusieurs super-types. hritage simple Variation smantique de la gnralisation, dans laquelle un type ne peut avoir qu'un seul super-type. importation Dans le contexte des paquetages, dpendance montrant le paquetage dont les classes peuvent tre rfrences partir de paquetages donns (y compris de paquetages imbriqus de faon rcursive l'intrieur de ce paquetage).

emplacement envoyer

Transmission d'une instance de message d'un objet expditeur un objet destinataire.

espace de noms Partie du modle dans laquelle peuvent tre dfinis et utiliss les noms ; au sein d'un espace de noms, chaque nom a une signification unique. tat Condition ou situation de la vie d'un objet pendant laquelle celui-ci remplit une condition, effectue une activit ou attend un vnement particulier. tat d'action tat reprsentant l'excution d'une action atomique, par exemple l'invocation d'une opration.

Annexes

Prsentation gnrale du langage UML mm

ANNEXE A Hi

infrastructure prfabrique Pattern architectural fournissant un cadre extensible pour des applications lies un domaine spcifique. (Framework.) instance Manifestation concrte d'une abstraction ; entit laquelle peut tre appliqu un ensemble d'oprations et ayant un tat stockant les effets des oprations ; synonyme d'objet. interaction Comportement englobant un ensemble de messages changs par un ensemble d'objets dans un contexte particulier et dans le but d'atteindre un objectif particulier. interface Collection d'oprations permettant de spcifier un service d'une classe ou d'un composant. langage de contrainte sur les objets (OCL) contraintes sans effet secondaire. Langage formel permettant d'imposer des

note objet

Commentaire associ un lment ou une collection d'lments, Voir instance.

objet actif Objet possdant un processus ou un thread et pouvant dclencher une activit de contrle. objet persistant d'exister. objet transitoire l'a cr. Objet existant aprs que le processus ou le thread l'ayant cr a cess

Objet n'existant que pendant l'excution du thread ou du processus qui

opration Implmentation d'un service laquelle un objet quelconque de la classe peut demander d'effectuer un certain comportement. paramtre paquetage porte Spcification d'une variable pouvant tre modifie, passe ou renvoye. Mcanisme gnraliste permettant de regrouper les lments.

liaison Cration d'un lment partir d'un template dont on fournit les arguments des paramtres. lien Connexion smantique entre objets ; instance d'une association.

Contexte confrant une signification particulire un nom. Contrainte qui doit tre vraie l'issue de l'excution d'une opration.

ligne de vie Ligne d'un diagramme de squence reprsentant l'existence d'un objet pendant une certaine priode. machine tats Comportement spcifiant les squences d'tats que doit traverser un objet au cours de sa vie en rponse des vnements, ainsi que ses rponses ces vnements. mcanisme d'extensibilit Un des trois mcanismes (strotypes, valeurs marques et contraintes) permettant d'enrichir le langage UML de faon contrle. message Spcification d'une communication entre objets vhiculant des informations, donnant lieu en principe une activit ; la rception d'une instance de message est normalement considre comme une instance d'un vnement. mtaclasse mthode modle Classe dont les instances sont des classes. Implmentation d'une opration. Abstraction smantiquement ferme d'un systme. Spcification de la gamme de cardinalits que peut assumer un ensemble.

postcondition processus cessus.

Flot de contrle lourd pouvant s'excuter concomitamment avec d'autres pro-

prcondition proprit

Contrainte qui doit tre vraie lors de l'invocation d'une opration.

Valeur nomme indiquant une caractristique d'un lment.

ralisation Relation smantique entre classificateurs, dans laquelle un classiflcateur spcifie un contrat dont un autre classiflcateur garantit l'application. recevoir relation Prendre en charge une instance de message transmise par un objet expditeur. Connexion smantique entre lments. Contrat ou obligation d'un type ou d'une classe.

responsabilit rle

multiplicit

Comportement spcifique d'une entit participante dans un contexte particulier. Squence d'actions spcifique illustrant un comportement. Spcification d'un stimulus asynchrone communiqu entre instances. Nom et paramtres d'une proprit comportementale.

noeud lment physique existant l'excution et reprsentant une ressource de calcul, dot en principe au moins de mmoire et souvent de capacits de traitement. nom Dsignation d'un lment, d'une relation ou d'un diagramme ; chane permettant d'identifier un lment.

scnario signal

signature

Annexes

Prsentation gnrale du langage UML

ANNEXE A

sous-systme Regroupement d'lments, dont certains constituent une spcification du comportement fourni par les autres lments contenus. Dans une relation de gnralisation, spcialisation d'un autre type, le super-

type de donnes Type dont les valeurs n'ont pas d'identit. Les types primitifs intrinsques (comme les nombres et les chanes) et les types d'numration (comme les boolens) sont des types de donnes. type primitif Type de base prdfini, comme un entier ou une chane. unit de distribution Ensemble d'objets ou de composants affects en tant que groupe une tche ou un processeur. utilisation Dpendance dans laquelle un lment (le client) exige la prsence d'un autre lment (le fournisseur) pour fonctionner ou s'implmenter correctement. valeur marque Extension des proprits d'un lment UML, permettant d'inclure de nouvelles informations dans la spcification de cet lment. visibilit Faon dont un nom peut tre vu et utilis par d'autres.

sous-type type.

spcification Instruction textuelle de la syntaxe et de la smantique d'une brique de base spcifique ; description dclarative de la nature ou du rle d'un lment. strotype Extension du vocabulaire d'UML permettant de crer de nouveaux types de briques de base drivs de types existants, mais spcifiques un problme particulier. stimulus super-type type. Opration ou signal. Dans une relation de gnralisation, gnralisation d'un autre type, le sous-

systme Collection de sous-systmes agencs de faon raliser un objectif spcifique et dcrits par un ensemble de modles, ventuellement de diffrents points de vue. tche Chemin unique d'excution travers un programme, un modle dynamique ou une quelconque autre reprsentation d'un flot de contrle ; thread ou processus. template lment paramtr. Point de terminaison d'une association, reliant cette asso-

vue Projection d'un modle, envisag d'un point de vue donn ou avantageux, ometlant les entits non pertinentes pour ce point de vue.

A.4

Rfrences
1
2

OMG Unified Modeling Language Spcification, Object Management Group, Framingham, MA, 1998. Internet : www.omg.org.
James RUMBAUGH, Ivar JACOBSON et Grady BOOCH, The Unified Modeling Language Rfrence Manual, Reading, MA, Addison-Wesley, 1998. Grady BOOCH, James RUMBAUGH et Ivar JACOBSON, The Unified Modeling Language

terminaison d'association ciation un classiflcateur. terminaison de lien

Instance d'une terminaison d'association.

User Guide, Reading, MA, Addison-Wesley, 1998. 4 5 Martin FOWLER, UML Distilled, Reading, MA, Addison-Wesley, 1997. Hans-Erik ERIKSSON et Magnus PENKER, UML Toolkit, New York, John Wiley & Sons, 1998.

thread Flot de contrle lger pouvant s'excuter concomitamment avec d'autres threads d'un mme processus. traabilit Dpendance indiquant une relation historique ou de processus entre deux lments reprsentant le mme concept sans rgles spcifiques permettant de les driver l'un de l'autre. transition Relation entre deux tats indiquant qu'un objet tant dans le premier tat va effectuer certaines actions spcifies et entrer dans le second tat lorsque se produira un vnement particulier et que seront remplies des conditions spcifies. trave Cloisonnement d'un diagramme d'activits permettant de rpartir les responsabilits lies aux actions. type Strotype de classe permettant de spcifier un domaine d'objets ainsi que les oprations (et non les mthodes) applicables ces objets.

B
Extensions du langage UML spcifiques au Processus unifi
B.1 Introduction
Cette annexe prsente les extensions du langage U M L qu'exige le Processus unifi. Ces extensions sont dcrites en termes de strotypes et de valeurs marques, c'est--dire en termes de mcanismes d'extension fournis par UML, ainsi qu' l'aide de la notation graphique permettant de reprsenter certains de ces strotypes. Les strotypes ne faisant pas partie des extensions standard des ouvrages [1] et [2] sur le langage UML sont signals par un astrisque (*). Pour une prsentation gnrale du langage UML, consultez l'annexe A.

B.2 Strotypes
Strotype S'applique B r v e description MHHHnMHHHHMI^HMH^HHHIHHRHHHHI^HMIHHHHHH

modle des cas d'utilisation systme de cas d'utilisation 1

modle

Modle contenant des acteurs et des cas d'utilisation, ainsi que leurs relations ; modle dcrivant ce que le systme doit faire pour ses utilisateurs et sous quelles contraintes. Paquetage de plus haut niveau du modle des cas d'utilisation ( systme de cas d'utilisation est un sous-type de paquetageDePlusHautNiveau ).

paquetage de plus haut niveau

Annexes

Extensions du langage UML s p c i f i q u e s au P r o c e s s u s u n i f i

ANNEXE B

Strotype

S'applique

B r v e description

Strotype

S'applique

B r v e description

modle d'analyse

modle

ralisation-conception de cas d'utilisation*

collaboration

Collaboration du modle de conception dcrivant la faon dont est ralis et effectu un cas d'utilisation particulier, en termes de soussystmes de conception, de classes de conception et des objets qu'elles contiennent.

Modle objet dont les buts sont : (1) de dcrire prcisment les besoins ; (2) de les structurer de manire en faciliter la comprhension, la prparation, la modification et, d'une manire gnrale, la maintenance ; et (3) de servir d'entre principale au faonnage du systme en conception et en implmentation - y compris avec son architecture. Paquetage de plus haut niveau du modle d'analyse ( systme d'analyse est un sous-type de paquetageDePlusHautNiveau ). Classe du modle d'analyse reprsentant la coordination, le squencement et le contrle d'autre objets, souvent utilise pour encapsuler le contrle li un cas d'utilisation spcifique. Classe du modle d'analyse permettant de modliser les informations de longue dure, souvent persistantes.

sous-systme

sous-systme de conception

! systme d'analyse classe de contrle classe entit classe frontire

paquetage de plus haut niveau classe

Sous-systme fournissant le moyen d'agencer les artefacts du modle de conception en portions grables. Un sous-systme de conception peut se composer de classes de conception, de ralisations-conception de cas d'utilisation, d'interfaces et (de faon rcursive) d'autres sous-systmes de conception.

sous-systme de service*

sous-systme

classe classe

Variante d'un sous-systme de conception utilis un niveau infrieur de la hirarchie des sous-systmes de conception (dans le modle de conception) pour structurer le systme en fonction des services qu'il fournit. Modle objet dcrivant la distribution physique du systme par la rpartition des fonctions sur les nuds de calcul du rseau. Modle objet dcrivant la faon dont les lments du modle de conception, tels que les classes de conception, sont implments par des composants tels que des fichiers et des excutables de code source. Sous-systme de plus haut niveau du modle d'implmentation ( sous-systme d'implmentation est un sous-type de paquetageDePlusHautNiveau ). Sous-systme fournissant le moyen d'agencer les artefacts du modle d'implmentation en portions grables. Un sous-systme d'implmentation peut se composer de composants, d'interfaces et (de faon rcursive) d'autres sous-systmes d'implmentation. Modle dcrivant principalement la faon dont les composants ex- cutables (tels que des constructions) du modle d'implmentation sont soumis des tests d'intgration et des tests systme. Sous-systme de plus haut niveau du modle des tests ( sous-systme de test est un sous-type de paquetageDePlusHautNiveau ). Composant automatisant une ou plusieurs procdures de test, en totalit ou en partie.

modle de dploiement* modle d'implmentation

modle modle

Classe du modle d'analyse permettant de modliser l'interaction entre le systme et ses acteurs, c'est--dire les utilisateurs et les systmes externes.

ralisation-analyse de cas

collaboration

Collaboration dans le modle d'analyse dcrivant la faon dont est ralis et effectu un cas d'utilisation particulier, en termes de classes d'analyse (c'est--dire de classes de contrle, de classes entits et de classes frontires) et des objets en interaction qu'elles contiennent. j Paquetage fournissant un moyen d'agencer les artefacts du modle d'analyse en portions grables. Un paquetage d'analyse peut se composer de classes d'analyse (c'est--dire de classes de contrle, de classes entits et de classes frontires), de ralisations-analyse de cas d'utilisation et (de faon rcursive) d'autres paquetages d'analyse. Variante d'un paquetage d'analyse utilis un niveau infrieur de la hirarchie des paquetages d'analyse (dans le modle d'analyse) pour structurer le systme en fonction des services qu'il fournit.

paquetage

systme d'implmentation sous-systme d'implmentation modle des tests* systme de test* composant de test*

sous-systme de plus haut niveau sous-systme

paquetage d'analyse*

modle

; paquetage de service*

paquetage

modle

paquetage de haut niveau composant

modle de conception

Modle objet dcrivant la ralisation physique des cas d'utilisation et s'intressant l'impact qu'exercent sur le systme considr les besoins fonctionnels et non fonctionnels ainsi que les autres contraintes lies l'environnement d'implmentation. Sous-systme de plus haut niveau du modle de conception ( soussystme de conception est un sous-type de paquetageDePlusHautNiveau ). Une classe de conception reprsente une abstraction directe d'une classe ou d'une construction similaire de l'implmentation du systme.

I I I

systme de conception classe de conception*

sous-systme de plus haut niveau classe

Annexes

Extensions du langage UML s p c i f i q u e s au P r o c e s s u s u n i f i

ANNEXE B

Valeurs marques
S'applique B r v e description

Figure B.1

Solution 1 :

Valeur narque

Les trois strotypes de classes standard utiliss en analyse.

Compte Solution 2: entit Compte s~\

Interface guichet

contrle Retrait /<\ w

escription nrale (ou 'ensemble) nt d'vneents xigences partiulires xigences partiulires

modle des cas d'utilisation cas d'utilisation cas d'utilisation

Description textuelle destine donner une explication globale du modle des cas d'utilisation. Description textuelle de la squence d'actions du cas d'utilisation. Description textuelle recueillant toutes les exigences (par exem- 1 pie, les exigences non fonctionnelles) pesant sur un cas d'utilisation non formules dans le flot d'vnements correspondant.

frontire _^ Interface h_) guichet

B.5 Rfrences
1 2 OMG Unified Modeling Language Spcification, Object Management Group, Framingham, MA, 1998. Internet : www.omg.org. James RiJMBAUGH, Ivar JACOBSON et Grady BOOCH, Unified Modeling Language Rfrence Manual, Reading, MA, Addison-Wesley, 1998.

classe d'analyse (classe entit, frontire ou de contrle) ralisation-analyse de cas d'utilisation ralisation-analyse de cas d'utilisation

Description textuelle recueillant les exigences non fonctionnelles pesant sur une classe d'analyse. Il s'agit d'exigences spcifies en analyse, mais qui sont plus efficacement prises en charge par la conception et l'implmentation. Description textuelle expliquant et compltant les diagrammes (et leurs tiquettes) dfinissant la ralisation de cas d'utilisation. Description textuelle recueillant toutes les exigences, telles que les exigences non fonctionnelles, pesant sur une ralisation de cas d'utilisation. Il s'agit d'exigences spcifies en analyse, mais qui sont plus efficacement prises en charge par la conception et S l'implmentation. Description textuelle recueillant les exigences, telles que les exigences non fonctionnelles, pesant sur une classe de conception. ; Il s'agit d'exigences spcifies en conception, mais qui sont plus efficacement prises en charge par l'implmentation. Description textuelle expliquant et compltant les diagrammes i (et leurs tiquettes) dfinissant la ralisation de cas d'utilisation. I Description textuelle recueillant toutes les exigences, telles que les exigences non fonctionnelles, pesant sur une ralisation de cas d'utilisation. Il s'agit d'exigences spcifies en conception, mais qui sont plus efficacement prises en charge par l'implmentation.

1 d'vnelonts-analyse xigences partiulires

agences implmentaon il d'vneents-concep> n dgences Implmenta-

classe de conception

ralisation-conception de cas d'utilisation ralisation-conception de cas d'utilisation

i Notation graphique
I .i plupart des strotypes prsents dans la section B.2 n'imposent aucun nouveau symbole p.i|iln<|iic spcifique et peuvent tre dsigns par le nom du strotype entre guillemets I < i > plac dans le symbole du strotype utilis. toutefois les classes de contrle et les classes entits et frontires exigent de nouveaux symi n 'i- d.. r ris dans la ligure B . l .

i I
C.1 Introduction

C Glossaire gnral
Cette annexe regroupe et dfinit les termes gnraux employs pour dcrire le Processus unifi, l'exception des termes lis UML et aux extensions d'UML spcifiques au Processus unifi, qui font respectivement l'objet des annexes A ( Prsentation gnrale du langage UML ) et B ( Extensions du langage UML spcifiques au Processus unifi ).

C.2 Termes

abstraction Caractristiques essentielles d'une entit distinguant celle-ci de tous les autres types d'entits. Une abstraction dfinit une frontire par rapport au point de vue du spectateur.

1 p r

activit Unit de travail tangible ralise par un travailleur dans un enchanement d'activits. Une activit (1) implique une responsabilit dfinie pour le travailleur, (2) livre un rsultat dfini (un ensemble d'artefacts) partir d'une entre dfinie (un autre ensemble d'artefacts) et (3) reprsente une unit de travail aux frontires parfaitement dfinies. D sera sans doute fait rfrence ce type d'activit dans un plan de projet lors de l'affectation de tches des individus. Peut galement tre vue comme l'excution d'une opration par un travailleur. Voir artefact, travailleur. analyse (enchanement d'activits) Enchanement d'activits principal dont le premier objectif est d'analyser les besoins tels qu'ils ont t dcrits dans la formulation des besoins, en les affinant et en les structurant. Le but est (1) de parvenir une comprhension plus prcise des besoins et (2) d'en livrer une description simple entretenir et facilitant la structuration du systme dans son ensemble, y compris de son architecture.

Glossaire g n r a l
ANNEXE C

469

anomalie Dfaut du systme, tel que le symptme d'une dfaillance logicielle dcouverte au cours des tests ou un problme dtect lors d'une runion de rvision. Voir tests. approche en cascade approche du dveloppement de systmes dans laquelle le dveloppement s'organise comme une squence linaire de travail, par exemple dans l'ordre suivant : formulation des besoins, analyse, conception, implmentation et tests. Voir besoins, analyse, conception, implmentation, tests.

besoins (enchanement d'activits) Un des enchanements d'activits principaux dont le propos essentiel est d'orienter le dveloppement vers le systme appropri. I l faudra, pour cela, dcrire les besoins du systme avec suffisamment de justesse pour parvenir un accord entre le client (et les utilisateurs) et les dveloppeurs du systme sur ce que devra et ne devra pas faire le systme. Voir besoin, client, dveloppeur. cas de test Spcification d'un cas permettant de tester le systme, indiquant ce qui doit tre test partir de quelles entres, avec quel rsultat et sous quelles conditions. centr sur l'architecture Dans le contexte du cycle de vie logiciel, signifie que l'architecture d'un systme sert d'artefact principal la conceptualisation, la construction, la gestion et l'volution du systme en cours de dveloppement. client Personne, organisation ou groupe de personnes commandant la mise au point d'un systme, soit construit ex nihilo, soit affin par des versions successives. cohsion Capacit d'une entit (telle qu'un systme, un sous-systme ou un paquetage) maintenir ses diffrentes parties en un ensemble. conception (enchanement d'activits) Un des enchanements d'activits principaux dont le premier objectif est de formuler des modles centrs sur les exigences non fonctionnelles et le domaine de la solution, et prparant l'implmentation et les tests du systme. concurrence Se produit lorsque plusieurs travaux plus ou moins indpendants (threads, processus) partagent simultanment une mme unit matrielle (processeur). construction Version excutable du systme, concernant gnralement une partie spcifique du systme. Le dveloppement se droule travers une succession de constructions. couche Partie clairement identifie d'un systme, dfinie par des paquetages ou des soussystmes. Voir couche spcifique l'application, couche gnrale aux applications, couche de middleware, couche de logiciel systme. couche de logiciel systme Couche contenant les logiciels de calcul et de mise en rseau de l'infrastructure, comme les systmes d'exploitation, les systmes de gestion de bases de donnes, les interfaces avec des matriels spcifiques, etc. C'est la couche situe au bas de la hirarchie des couches. Voir couche de middleware. couche de middleware Couche fournissant des briques de base rutilisables (paquetages ou sous-systmes) pour des infrastructures prfabriques d'utilitaires et des services indpendants de toute plate-forme, par exemple pour le calcul et l'interoprabilit des objets distribus dans des environnements htrognes. I l s'agit, entre autres, des ORB (Object Request Brokers), des infrastructures prfabriques indpendantes de toute plate-forme permettant la cration d'interfaces utilisateur graphiques ou, en gnral, des

architecture Ensemble des dcisions significatives concernant l'organisation d'un systme logiciel, la slection des lments structurels dont est compos le systme et de leurs interfaces, ainsi que leur comportement tel qu'il est spcifi dans les collaborations entre ces lments, la composition de ces lments structurels et comportementaux en sous-systmes progressivement plus importants, et le style architectural guidant cette organisation : ces lments et leurs interfaces, leurs collaborations, et leur composition. L'architecture logicielle ne se soucie pas seulement de structure et de comportement, mais aussi d'utilisation, de fonctions, de performances, de capacit ragir aux changements, de rutilisation, de clart, de contraintes et de compromis conomiques et technologiques, enfin de proccupations esthtiques. architecture de rfrence Rfrence livre la fin de la phase d'laboration, essentiellement centre sur l'architecture du systme. Voir laboration, architecture, rfrence. artefact Information tangible ( 1 ) cre, modifie et utilise par les travailleurs dans la ralisation de leurs activits, (2) reprsentant un domaine de responsabilit et (3) susceptible d'tre place sous un contrle de version part. Un artefact peut tre un modle, un lment de modle ou un document. Voir travailleur, activit. artefact de gestion Artefact autre qu'un artefact d'ingnierie, tel qu'un plan du projet cr par le chef de projet. Voir artefact d'ingnierie. artefact d'ingnierie Artefact cr dans l'un des enchanements d'activits principaux. Voir enchanement d'activits principal. besoin Condition ou capacit laquelle doit se conformer un systme.

besoin fonctionnel Besoin spcifiant une action qu'un systme doit tre capable d'effectuer, sans considrer aucune contrainte physique ; besoin spcifiant un comportement d'entre/sortie d'un systme. Voir besoin. besoin non fonctionnel Besoin spcifiant des proprits du systme, telles que les contraintes lies l'environnement et l'implmentation, et les exigences en matire de performances, de dpendances de plate-forme, de facilit de maintenance, d'extensibilit et de fiabilit. Besoin spcifiant des contraintes physiques sur un besoin fonctionnel. Voir besoin, exigence de performances, fiabilit, besoin fonctionnel.

Annexes 4 7 0

produits mettant en u v r e des m c a n i s m e s g n r i q u e s de conception. Voir c o u c h e de l o g i c i e l s y s t m e , O R B , interface utilisateur, m c a n i s m e de conception. couche g n r a l e a u x applications Partie d ' u n s y s t m e ( c o m p o s e de paquetages ou de

s o u s - s y s t m e s ) r u t i l i s a b l e dans le c a d r e d ' u n m t i e r ou d'un domaine. Cette couche est u t i l i s e par la c o u c h e s p c i f i q u e l'application. Voir couche s p c i f i q u e l'application. couche spcifique l'application Partie d ' u n s y s t m e ( c o m p o s e de paquetages ou de

s o u s - s y s t m e s ) s p c i f i q u e l'application et non p a r t a g e par d'autres parties ( s o u s - s y s t m e s ) . Cette c o u c h e utilise la c o u c h e g n r a l e aux applications. Voir c o u c h e g n r a l e aux applications. cycle de vie logiciel C y c l e comprenant quatre p h a s e s , o r d o n n e s de la f a o n suivante :

c r a t i o n , l a b o r a t i o n , construction et transition. Voir phase de c r a t i o n , phase d ' l a b o ration, phase de construction, phase de transition. description de l'architecture D e s c r i p t i o n de l'architecture d'un s y s t m e comprenant les

vues architecturales des m o d l e s . Voir v u e architecturale, vue architecturale d u m o d l e des c a s d'utilisation, v u e architecturale du m o d l e d ' a n a l y s e , vue architecturale du m o d l e de c o n c e p t i o n , vue architecturale du m o d l e de d p l o i e m e n t , vue architecturale du m o d l e d ' i m p l m e n t a t i o n . d v e l o p p e m e n t base de composants ( C B D ) de tels c o m p o s a n t s . dveloppeur T r a v a i l l e u r participant un e n c h a n e m e n t d ' a c t i v i t s principal, tel qu'un enchanement C r a t i o n et d p l o i e m e n t de s y s t m e s

forte composante logicielle a s s e m b l s partir de composants ; d v e l o p p e m e n t et r c o l t e

i n g n i e u r de c a s d'utilisation, un i n g n i e u r de c o m p o s a n t s , etc. Voir d ' a c t i v i t s principal. distribution

S e produit lorsque p l u s i e u r s travaux plus ou moins i n d p e n d a n t s (threads,

p r o c e s s u s ) sont r p a r t i s sur d i f f r e n t e s u n i t s m a t r i e l l e s (processeurs). domaine S e c t e u r de connaissance ou d ' a c t i v i t c a r a c t r i s par un ensemble de concepts et

une terminologie c o m p r i s par les p r o f e s s i o n n e l s du secteur. domaine de la solution ^ D o m a i n e dans lequel est d f i n i e une solution ( un p r o b l m e ) ,

exprimant g n r a l e m e n t l a conception et l ' i m p l m e n t a t i o n d'un s y s t m e . L e d o m a i n e de l a solution est normalement compris p a r les d v e l o p p e u r s . Voir domaine, d v e l o p p e u r . D o m a i n e dans l e q u e l est d f i n i un p r o b l m e : g n r a l e m e n t un

domaine du p r o b l m e

p r o b l m e devant t r e r s o l u par u n s y s t m e . L e domaine du p r o b l m e est n o r m a lement c o m p r i s par le client du s y s t m e . Voir d o m a i n e , client. enchanement d'activits R a l i s a t i o n de l a t o t a l i t ou d'une partie d'un cas d'utilisation

m t i e r . Peut t r e d c r i t par des d i a g r a m m e s d ' a c t i v i t s comprenant les travailleurs parti-

Glossaire gnral
ANNEXE C

c i p a u l s . les a c t i v i t s q u ' i l s e x c u t e n t et les artefacts q u ' i l s produisent. Voir d ' a c t i v i t s principal, e n c h a n e m e n t d ' a c t i v i t d'une i t r a t i o n . e n c h a n e m e n t d ' a c t i v i t s d'une i t r a t i o n

enchanement

E n c h a n e m e n t d'activits reprsentant l'int-

gration des e n c h a n e m e n t s d ' a c t i v i t s principaux : formulation des besoins, a n a l y s e , c o n ception, i m p l m e n t a t i o n et tests. D e s c r i p t i o n d ' u n e i t r a t i o n incluant les travailleurs y prenant part, les a c t i v i t s q u ' i l s effectuent et les artefacts q u ' i l s l a b o r e n t . Voir nement d ' a c t i v i t s . e n c h a n e m e n t d ' a c t i v i t s principal U n des e n c h a n e m e n t s d ' a c t i v i t s de b e s o i n s , encha-

d ' a n a l y s e , de c o n c e p t i o n , d ' i m p l m e n t a t i o n ou de tests. Voir e n c h a n e m e n t d ' a c t i v i t s , besoins, a n a l y s e , c o n c e p t i o n , i m p l m e n t a t i o n , tests. v a l u a t i o n des tests v a l u a t i o n des r s u l t a t s des travaux de test, notamment du n i v e a u de

couverture des c a s de test, du niveau de couverture du code et de l ' t a t des a n o m a l i e s . Voir tests, c a s de test, anomalie. exigence Voir besoin. E x i g e n c e i m p o s a n t des conditions de comportement aux

exigence de performances

besoins fonctionnels, c o m m e la vitesse, le d b i t , le temps de r p o n s e et l'utilisation de la m m o i r e . Voir besoin fonctionnel, b e s o i n . exigence fonctionnelle Voir besoin fonction: e l . Voir besoin non f o n c t i o n n e l . E x i g e n c e g n r i q u e ne pouvant t r e r e l i e un cas d'utilisation

exigence non fonctionnelle exigence s u p p l m e n t a i r e m t i e r . Voir b e s o i n . fiabilit

en particulier ou une c l a s s e du m o n d e r e l telle q u ' u n e classe e n t i t d u d o m a i n e ou du

C a p a c i t d ' u n s y s t m e se c o m p o r t e r correctement dans son v r i t a b l e e n v i r o n -

nement d ' e x c u t i o n . Peut, par exemple, t r e m e s u r e e n termes de d i s p o n i b i l i t et de p r c i s i o n du s y s t m e , d ' e s p a c e de temps s p a r a n t deux d f a i l l a n c e s , de nombre d ' a n o m a l i e s pour 1 000 lignes de c o d e ( K L O C ) et de nombre d ' a n o m a l i e s par c l a s s e . framework Voir infrastructure p r f a b r i q u e . T c h e consistant d f i n i r et assurer la maintenance des confiVoir

gestion de configuration

gurations et des versions des artefacts. C e c i c o m p r e n d la gestion de l a r f r e n c e , la gestion de v e r s i o n , le c o n t r l e de l ' t a t et le c o n t r l e du stockage des artefacts. artefact, r f r e n c e . green-field project Voir projet tout n e u f .

implmentation (enchanement d'activits)

U n des e n c h a n e m e n t s d ' a c t i v i t s prin-

c i p a u x , dont l'objectif essentiel est d ' i m p l m e n t e r le s y s t m e sous forme de composants c ' e s t - - d i r e de code s o u r c e , de scripts, de binaires, d ' e x c u t a b l e s et d ' e n t i t s de m m e type. incrment Partie modeste et g r a b l e du s y s t m e , constituant g n r a l e m e n t le delta ou

l ' c a r t entre deux constructions s u c c e s s i v e s . C h a q u e i t r a t i o n se traduira par au moins une ( n o u v e l l e ) construction et ajoutera ainsi un i n c r m e n t au s y s t m e . Toutefois, une s q u e n c e de constructions peut t r e c r e au sein d'une m m e i t r a t i o n , chacune ajoutant un modeste i n c r m e n t au s y s t m e . U n e i t r a t i o n ajoutera ainsi un i n c r m e n t plus important au s y s t m e , v e n t u e l l e m e n t c o n s t i t u de l ' a c c u m u l a t i o n de plusieurs constructions. Voir construction, i t r a t i o n . infrastructure p r f a b r i q u e Micro-architecture fournissant un cadre incomplet d e s t i n

des s y s t m e s dans un domaine s p c i f i q u e . Il peut s'agir, par e x e m p l e , d'un s o u s - s y s t m e construit pour t r e t e n d u et/ou r u t i l i s . i n g n i e r i e vers l'aval Voir r t r o - i n g n i e r i e . i n t g r a t i o n du s y s t m e T c h e consistant c o m p i l e r et lier une partie des composants du D a n s le contexte du d v e l o p p e m e n t l o g i c i e l , transformation d'un

m o d l e en c o d e g r c e l a correspondance avec un langage d ' i m p l m e n t a t i o n s p c i f i q u e .

s y s t m e en u n ou plusieurs e x c u t a b l e s (qui sont aussi des c o m p o s a n t s ) . intgration incrmentale D a n s le contexte du c y c l e de vie l o g i c i e l , processus impliquant

l ' i n t g r a t i o n continue de l'architecture du s y s t m e pour produire des versions, chaque nouvelle v e r s i o n apportant des a m l i o r a t i o n s progressives par rapport aux p r c d e n t e s . interface utilisateur le s y s t m e . itratif D a n s le contexte d u c y c l e de v i e l o g i c i e l , processus impliquant la gestion d'un flux Interface par l ' i n t e r m d i a i r e de laquelle un utilisateur dialogue avec

de versions e x c u t a b l e s . itration E n s e m b l e distinct d ' a c t i v i t s m e n e s en fonction d'un plan de l ' i t r a t i o n et de

c r i t r e s d ' v a l u a t i o n de c e l l e - c i , donnant lieu une version, soit interne, soit externe. Voir v e r s i o n , version interne, v e r s i o n externe. jalon majeur J a l o n dans lequel sont prises d'importantes d c i s i o n s sur le plan c o m m e r c i a l .

C h a q u e phase se termine par un j a l o n majeur, o c c a s i o n pour les responsables de prendre les d c i s i o n s c r u c i a l e s de donner ou non le feu vert pour la phase suivante et de fixer les d l a i s , les budgets et les besoins du projet. L e s j a l o n s majeurs peuvent t r e v u s c o m m e des points de s y n c h r o n i s a t i o n o sont atteints des objectifs p r c i s , o sont a c h e v s des artefacts, o est prise l a d c i s i o n de poursuivre ou non sur la phase suivante et o c o n vergent les d o m a i n e s technique et de gestion. Voir phase, projet, artefact.

.y

Glossaire gnral
ANNEXE C

jalon mineur

Jalon i n t e r m d i a i r e entre deux j a l o n s majeurs. Il peut s'agir, par e x e m p l e , de

la lin d'une i t r a t i o n ou de la linalisation d'une construction au sein d'une i t r a t i o n . Voir j a l o n majeur, i t r a t i o n , construction. logiciel s y s t m e Voir c o u c h e de l o g i c i e l s y s t m e . E n s e m b l e complet des actions de tous les c a s d'utilisation

m a s s e des c a s d ' u t i l i s a t i o n

d'un m o d l e des c a s d'utilisation. mcanisme Solution courante un p r o b l m e ou un b e s o i n courant. L e s m c a n i s m e s de

conception offrant des p o s s i b i l i t s de persistance ou de distribution dans le m o d l e de conception en sont un e x e m p l e . m c a n i s m e de conception U n certain nombre de c l a s s e s de conception, de collaborations

ou m m e de s o u s - s y s t m e s du m o d l e de c o n c e p t i o n r a l i s a n t des e x i g e n c e s c o m m u n e s , telles que les e x i g e n c e s de persistance, de distribution et de performances. m o d l i s a t i o n visuelle V i s u a l i s a t i o n de produits de travail (artefacts) sous forme de plans

d ' l a b o r a t i o n et de construction ou de d i a g r a m m e s standard. Voir artefact. ORB (Object Request Broker) M c a n i s m e de m i s e plat (marshaling) et d ' a c h e m i n e m e n t Voir

transparents de m e s s a g e s des objets r p a r t i s dans des environnements h t r o g n e s . distribution. o r i e n t vers la r d u c t i o n des risques

D a n s le contexte du c y c l e de vie l o g i c i e l , signifie

que c h a q u e n o u v e l l e v e r s i o n s'attache avant tout la prise en compte et la r d u c t i o n des risques les plus significatifs pour la r u s s i t e du projet. pattern Solution courante un p r o b l m e courant dans u n contexte d o n n . Pattern d f i n i s s a n t une structure ou un comportement s p c i f i q u e , gal

pattern architectural

g n r a l e m e n t pour la vue architecturale d ' u n m o d l e particulier. E x e m p l e s de c e s patterns architecturaux, les patterns Couches,.Cl i e n t - s e r v e u r , t r o i s niveaux et D ' g a l d f i n i s s e n t c h a c u n une certaine structure pour le m o d l e de d p l o i e m e n t et s u g g r e n t le mode d'affectation des composants (fonctions) aux noeuds. Voir pattern, v u e a r c h i t e c turale. phase E s p a c e de temps s p a r a n t deux j a l o n s majeurs d ' u n processus de d v e l o p p e m e n t .

Voir j a l o n majeur, phase de c r a t i o n , phase d ' l a b o r a t i o n , phase de construction, phase de transition. p h a s e de c o n s t r u c t i o n T r o i s i m e phase du c y c l e de vie d u l o g i c i e l , dans laquelle le

logiciel passe du stade d ' u n e architecture de r f r e n c e e x c u t a b l e c e l u i o il peut t r e transmis aux utilisateurs.

Annexes

phase de c r a t i o n boration. phase d ' l a b o r a t i o n l'architecture. phase de transition

P r e m i r e phase du c y c l e de v i e l o g i c i e l , dans laquelle l ' i d e d'origine

sous-tehdant le d v e l o p p e m e n t est t a y e au point de garantir le passage la phase d ' l a -

D e u x i m e phase du c y c l e de v i e l o g i c i e l , dans laquelle est d f i n i e

Q u a t r i m e phase du c y c l e de vie l o g i c i e l , l ' i s s u e de laquelle le

l o g i c i e l est r e m i s entre les mains des utilisateurs. p i l o t p a r les cas d'utilisation D a n s le contexte du c y c l e de vie l o g i c i e l , signifie que les

c a s d'utilisation servent d'artefact principal la formulation du comportement s o u h a i t du s y s t m e et l a c o m m u n i c a t i o n de c e comportement aux divers intervenants du s y s t m e . S i g n i f i e g a l e m e n t que les c a s d'utilisation constituent l ' e n t r e principale l ' a n a l y s e , la c o n c e p t i o n , l ' i m p l m e n t a t i o n et aux tests du s y s t m e , y compris la c r a t i o n , l a v r i f i c a t i o n et l a validation de l'architecture du s y s t m e . Voir analyse, c o n c e p t i o n , i m p l m e n t a t i o n , tests, architecture. p i l o t p a r les m o d l e s D a n s le contexte du c y c l e de v i e l o g i c i e l , signifie que le s y s t m e

d v e l o p p s'articule autour de d i f f r e n t s m o d l e s , ayant des objectifs s p c i f i q u e s et dont les l m e n t s sont l i s (par des relations de t r a a b i l i t ) les uns aux autres. plan des tests P l a n d c r i v a n t les s t r a t g i e s , les ressources et le calendrier des tests. P l a n g r a n u l a r i t fine du d r o u l e m e n t d'une i t r a t i o n . Plan p r v o y a n t les

plan d ' i t r a t i o n

c o t s en d l a i s et en ressources et indiquant les artefacts devant t r e produits par cette i t r a t i o n . P l a n d f i n i s s a n t le r l e de c h a c u n au sein de cette i t r a t i o n , et Tordre de r a l i sation des a c t i v i t s . P o u r c e faire, les m e m b r e s de l ' q u i p e sont a f f e c t s des trav a i l l e u r s , tandis qu'est d c r i t en d t a i l un e n c h a n e m e n t d ' a c t i v i t s pour l ' i t r a t i o n . Voir i t r a t i o n , artefact, travailleur, e n c h a n e m e n t d ' a c t i v i t s d ' u n e i t r a t i o n . plan d u projet P l a n t r a a n t les grandes lignes d'un plan de route global pour un projet,

abordant le calendrier, les dates et les c r i t r e s des j a l o n s m a j e u r s , a i n s i que la d c o m p o s i t i o n des phases en i t r a t i o n s . Voir projet, j a l o n majeur. plan visant circonscrire les risques P l a n d c r i v a n t l a conduite adopter au c a s o cer-

tains risques se m a t r i a l i s e r a i e n t . Voir risque. portabilit D e g r de f a c i l i t avec lequel un s y s t m e , tel q u ' i l s ' e x c u t e dans un environ-

n e m e n t d ' e x c u t i o n s p c i f i q u e , peut t r e t r a n s f o r m en u n s y s t m e s ' e x c u t a n t dans un autre environnement d ' e x c u t i o n . p r o c d u r e de test S p c i f i c a t i o n des m o d a l i t s de d r o u l e m e n t d ' u n ou plusieurs c a s de

test ou de certaines parties de ces c a s de test. Voir c a s de test.

Glossaire gnral H?PW*3R|

ANNExt.

MJ^|jl

p r o c e s s u s de d v e l o p p e m e n t logiciel

P r o c e s s u s m t i e r (ou c a s d'utilisation m t i e r ) m i s

en u v r e par une entreprise de d v e l o p p e m e n t l o g i c i e l . E n s e m b l e total des a c t i v i t s n c e s s a i r e s la transformation des b e s o i n s d'un client en un ensemble c o h r e n t d'artefacts r e p r s e n t a n t un produit logiciel et, u l t r i e u r e m e n t , la transformation des v o l u tions de c e s besoins en nouvelles v e r s i o n s du produit l o g i c i e l . Voir processus m t i e r , Processus u n i f i . processus m t i e r E n s e m b l e total des a c t i v i t s n c e s s a i r e s la production d ' u n r s u l t a t

d'une valeur perceptible et mesurable pour u n client particulier d'une entreprise. Processus unifi P r o c e s s u s de d v e l o p p e m e n t l o g i c i e l f o n d sur le langage U M L , i t r a t i f ,

c e n t r sur l'architecture, p i l o t par les c a s d'utilisation et o r i e n t vers l a r d u c t i o n des risques. P r o c e s s u s doublement a r t i c u l autour des quatre phases de c r a t i o n , d ' l a b o ration, de construction et de transition, et des c i n q e n c h a n e m e n t s d ' a c t i v i t s des b e s o i n s , d ' a n a l y s e , de conception, d ' i m p l m e n t a t i o n et de tests. Processus d c r i t par le biais d ' u n m o d l e m t i e r , s t r u c t u r son tour par trois briques de base primitives : les travailleurs, les a c t i v i t s et les artefacts. Voir processus de d v e l o p p e m e n t l o g i c i e l , U M L (Unified M o d e l i n g L a n g u a g e ) , i t r a t i f , c e n t r sur l'architecture, p i l o t par les cas d'utilisation, o r i e n t vers la r d u c t i o n des risques, phase, phase de c r a t i o n , phase d ' l a b o r a t i o n , p h a s e de construction, phase de transition, e n c h a n e m e n t d ' a c t i v i t s principal, b e s o i n s , a n a l y s e , c o n c e p t i o n , i m p l m e n t a t i o n , tests, travailleur, a c t i v i t , artefact. projet E f f o r t de d v e l o p p e m e n t menant un s y s t m e travers un c y c l e de v i e . Voir c y c l e de

vie l o g i c i e l . projet tout neuf Projet sans p r c d e n t . Voir projet.

prototype architectural

E s s e n t i e l l e m e n t , prototype e x c u t a b l e c e n t r sur l a vue a r c h i t e c -

turale du m o d l e d ' i m p l m e n t a t i o n et des c o m p o s a n t s constituant ce prototype. S i un prototype architectural doit t r e v o l u t i f , i l prendra sans doute pour base et manifestation une description de l'architecture (avec toutes ses v u e s architecturales) plus c o m p l t e , bien q u ' e l l e - m m e sous forme de prototype (ou d ' e s q u i s s e ) . Voir prototype v o l u t i f , r f r e n c e , description de l'architecture, v u e architecturale. prototype d'interface utilisateur E n p r i n c i p e , prototype e x c u t a b l e d'une interface

utilisateur ; peut cependant se limiter, dans les p r e m i e r s stades du d v e l o p p e m e n t , de s i m p l e s dessins sur papier, des bitmaps sur c r a n et d'autres l m e n t s du m m e type. prototype v o l u t i f Prototype d v e l o p p et a f f i n au point de devenir une partie du s y s t m e

en c o u r s de d v e l o p p e m e n t . Prototype susceptible d ' t r e soumis une gestion de c o n f i guration. Voir gestion de configuration. prototype exploratoire Prototype ne poursuivant q u ' u n objectif d'exploration, a b a n d o n n

une fois cet objectif atteint. Proto'ype n o n susceptible d ' t r e s o u m i s une gestion de configuration. Voir gestion de configuration.

rfrence

E n s e m b l e d'artefacts r v i s s et a p p r o u v s (1) constituant une base consensuelle

l a suite de l ' v o l u t i o n et du d v e l o p p e m e n t , et (2) ne pouvant t r e m o d i f i q u ' travers une p r o c d u r e f o r m e l l e telle que la gestion de configuration et des changements. Voir architecture de r f r e n c e , gestion de configuration. rtro-ingnierie D a n s le contexte du d v e l o p p e m e n t l o g i c i e l , transformation de code en un

m o d l e g r c e la correspondance depuis un langage d ' i m p l m e n t a t i o n s p c i f i q u e . Voir i n g n i e r i e vers l ' a v a l . risque V a r i a b l e d ' u n projet compromettant ou e m p c h a n t la r u s s i t e d'un projet. Il peut

s ' a g i r d ' v n e m e n t s i n d s i r a b l e s a u x q u e l s est c o n f r o n t le projet, c o m m e des retards sur le calendrier, des d p a s s e m e n t s de budget ou une annulation pure et simple. Voir risque technique, risque non technique. risque non technique R i s q u e l i des artefacts de gestion et des aspects tels que les res-

sources disponibles (les i n d i v i d u s ) , leurs c o m p t e n c e s ou les dates de livraison. Voir artefact de gestion, risque, risque technique. risque technique R i s q u e l i des artefacts d ' i n g n i e r i e et des aspects tels que les tech-

nologies d ' i m p l m e n t a t i o n , l'architecture ou les p e r f o r m a n c e s . Voir artefact d ' i n g n i e r i e , architecture, e x i g e n c e de performances, r i s q u e n o n technique. robustesse C a p a c i t d ' u n e e n t i t , g n r a l e m e n t d ' u n s y s t m e , r a g i r au changement. O n dit des s y s t m e s partageant une m m e structure de haut niveau et

style architectural

des m c a n i s m e s q u ' i l s ont un m m e style architectural. suite de s y s t m e s d'applications E n s e m b l e de d i f f r e n t s s y s t m e s d'applications d e s t i n s

c o l l a b o r e r afin de rendre service certains acteurs. Voir s y s t m e d'applications. s y s t m e d'applications utilisateur final. S y s t m e h r i t par u n projet. E n g n r a l , s y s t m e ancien c r l'aide S y s t m e offrant un ensemble c o h r e n t de c a s d'utilisation un

s y s t m e existant

de technologies d ' i m p l m e n t a t i o n plus ou m o i n s o b s o l t e s , mais devant n a n m o i n s t r e i n t g r ou r u t i l i s , en t o t a l i t ou en partie, lors de la c r a t i o n d'un nouveau s y s t m e dans le cadre du projet. Voir projet. systme hrit Voir s y s t m e existant. Voir s y s t m e existant. U n des e n c h a n e m e n t s d ' a c t i v i t s principaux dont

s y s t m e patrimoine

tests ( e n c h a n e m e n t d ' a c t i v i t s )

l ' o b j e c t i f essentiel est de v r i f i e r les r s u l t a t s de l ' i m p l m e n t a t i o n en testant c h a q u e construction, y c o m p r i s les constructions internes et i n t e r m d i a i r e s , ainsi que les versions finales d u s y s t m e devant t r e l i v r e s des parties externes. Voir i m p l m e n t a t i o n , construction, v e r s i o n interne, version externe.

Glossaire gnral ma
ANNEXL C In

lests de n o n - r g r e s s i o n

Fait de lester de nouveau une partie ou la totalit d'une cons-

truction dj leste lors de constructions p r c d e n t e s . Les tests de non-rgression servent essentiellement vrifier qu'une ancienne fonction d ' anciennes constructions fonctionne toujours lorsqu'est ajoute une nouvelle fonction dans une nouvelle construction . Voir lests, construction. travailleur Fonction pouvant tre attribue une personne ou une q u i p e , imposant des

r e s p o n s a b i l i t s et des c o m p t e n c e s telles que la ralisation de certaines activits ou la mise au point de certains artefacts. Voir activit, artefact. U M L f Unified Modeling Language) Langage de m o d l i s a t i o n standard pour le logiciel :

langage de visualisation, de spcification, de construction et de documentation des artefacts d ' u n s y s t m e forte composante logicielle. Langage utilis par le Processus unifi. Langage permettant aux d v e l o p p e u r s de visualiser les produits de leur travail (artefacts) sous forme de plans d ' l a b o r a t i o n et de construction ou de diagrammes standard. artefact, Processus unifi, dveloppeur. utilisateur version H u m a i n ayant une interaction avec le s y s t m e . Voir

Ensemble relativement complet et c o h r e n t d'artefacts, comprenant v e n t u e l -

lement une construction, livr un utilisateur interne ou externe ; livraison d'un tel ensemble. Voir artefact, construction. version externe Voir version. version interne Version non expose aux clients et utilisateurs, mais uniquement destine l ' q u i p e du projet. Voir version. vue Projection d'un m o d l e , envisag depuis un point de vue spcifique ou avantageux, omettant les entits non pertinentes pour ce point de vue. vue architecturale Projection dans la structure et le comportement d ' u n m o d l e spcifique Version e x p o s e aux clients et utilisateurs, externe l ' q u i p e du projet.

d'un s y s t m e , centre sur les aspects de ce m o d l e significatifs pour l'architecture. vue architecturale du m o d l e d'analyse Vue de l'architecture d'un s y s t m e comprenant

les classes d'analyse, les paquetages d'analyse et les ralisations de cas d'utilisation ; vue affinant et structurant essentiellement les besoins du s y s t m e . L a structure apparaissant dans cette vue est conserve autant que possible au moment de la conception et de l ' i m p l m e n t a t i o n de l'architecture du s y s t m e . Voir vue architecturale du m o d l e de conception, vue architecturale du m o d l e d ' i m p l m e n t a t i o n . vue architecturale du m o d l e de conception Vue de l'architecture d ' u n s y s t m e com-

prenant les classes de conception, les s o u s - s y s t m e s de conception, les interfaces et les ralisations de cas d'utilisation constituant le vocabulaire du domaine de la solution du s y s t m e ; vue comprenant g a l e m e n t les threads et les processus fournissant les m c a -

78T

Annexes

nismes de concurrence et de synchronisation du s y s t m e ; vue centre sur les exigences non fonctionnelles, y compris les exigences de performances, de m o n t e en charge et de dbit, d'un s y s t m e . vue architecturale du m o d l e de d p l o i e m e n t Vue de l'architecture d'un systme comprenant les n u d s formant la topologie matrielle du systme sur laquelle s'excute le s y s t m e ; vue centre sur la distribution, la livraison et l'installation des parties constituant le s y s t m e physique. vue architecturale du m o d l e des cas d'utilisation Vue de l'architecture d'un systme

comprenant les cas d'utilisation significatifs pour l'architecture. vue architecturale du m o d l e d ' i m p l m e n t a t i o n Vue de l'architecture d'un systme comprenant les composants permettant d'assembler et de livrer le s y s t m e ; vue centre sur la gestion de configuration des versions du systme, e l l e s - m m e s constitue de composants quelque peu i n d p e n d a n t s pouvant tre assembls de diverses faons pour produire un systme capable de s'excuter.