Le processus unifié de developpement_logiciel

e Processus unifié de

développement 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 matières

H lu, lion autorisée de l'ouvrage en langue anglaise intitulé

The Unified Software Development Process,

I Ongman, a Pearson Education Company, 1999, ISBN 0-201-57169-2 Traduit de l'anglais par Virginie Zaïm Validation technique : Jérôme Desquilbet

I propriété intellectuelle du 1 juillet 1992 interdit en effet expressément la photocollcctif sans autorisation des ayants droit. Or, cette pratique s'est généralisée notam•l;iblissements d'enseignement, provoquant une baisse brutale des achats de livres, au Possibilité même pour les auteurs de créer des œuvres nouvelles et de les faire éditer BSl aujourd'hui menacée. i de la loi du 11 mars 1957, i l est interdit de reproduire intégralement ou partielt quelque support que ce soit, sans autorisation de l'Éditeur ou du Centre Français lopie, 20, rue des Grands Augustins, 75006 Paris, i éducation Company, 1999 pour l'édition en langue anglaise our la présente édition, ISBN 2-212-09142-7 e r

Avant propos

l

6

S D L : Langage de spécification et de description

5

L'approche Ericsson

4

Historique du Processus unifié

4

Approche du livre

3

À qui s'adresse ce livre ?

3

Objectifs du livre

2

Qu'est-ce qu'un processus de développement logiciel ?

9

U M L : Unified Modeling Language

9

Processus Rational Objectory : 1995-1997

8

L'approche de Rational

V

Objectory

10

Remerciements

10

Rational Unified Process Pour leur contribution à cet ouvrage Pour leur collaboration fidèle depuis des années Nous voudrions particulièrement remercier Un processus en marche

10 11 12 12

dessus unifié uoioppement logiciel

»

mu i

17

11 Processus unifié est piloté par les cas d'utilisation

16

i i . Processus unifié en bref

15

•,«><:essus unifié : piloté par l e s c a s d'utilisation, itré s u r l'architecture, itératif et incrémental

\ ,c Processus unifié est centré sur l'architecture Processus unifié est itératif et incrémental

18 21 . 23

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

19

11

Un processus intégré un ipiiiinr « P » du développement logiciel : t o n n e s , projet, produit et p r o c e s s u s I pri sonnes jouent un rôle crucial • i i l es processus de développement ont un impact m les personnes i ' l r > . rôles changent ' M l )CN « ressources » aux « travailleurs »

| Tel projet, tel produit I I lu produit ne se résume pas à du code • | I Qu'es) ce qu'un système logiciel ? I..S.Z I .i\ artefacts • i | l In système dispose de plusieurs modèles i i H, isi-ce qu'un modèle ? ( haque modèle est une vue autonome du système ' i d Exploration d'un modèle • | / Relations entre modèles

•

2 1

25

Table des matières

III

41 41 41 42 43 44

2.5 Les outils font partie intégrante 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 modélisation visuelle au service d'UML 2.5.5 Les outils prennent en charge tout le cycle de vie

37 39 40

2.4 Le processus dirige les projets 2.4.1 Le processus : un cadre générique 2.4.2 Les relations entre activités constituent les enchaînement d'activités 2.4.3 Spécialisation du processus 2.4.4 Les mérites d'un processus

2.6 Références

**

37 37

44

CHAPITRE 3

Un p r o c e s s u s piloté par l e s c a s d'utilisation

47

3.1 Le développement piloté par les cas d'utilisation en bref

49

54

3.3 « Capture » des cas d'utilisation 3.3.1 Le modèle des cas d'utilisation représente les besoins fonctionnels 3.3.2 Les acteurs constituent l'environnement du système 3.3.3 Les cas d'utilisation spécifient le système

28 29 30

51 51 52 54

3.2 Pourquoi les cas d'utilisation ? 3.2.1 Pour appréhender les véritables besoins 3.2.2 Pour diriger le processus 3.2.3 Pour mettre au point l'architecture et plus encore

27 28

32 32 33 33 34 35 35 36 36

54 55 56

70

3.7 Références

70

3.6 Résumé

68

3.5 Tests des cas d'utilisation

67

3.4 L'analyse, la conception et l'implémentation pour la réalisation des cas d'utilisation 3.4.1 Création du modèle d'analyse à partir des cas d'utilisation 3.4.2 Chaque classe doit assumer tous ses rôles de collaboration 3.4.3 Création du modèle de conception à partir du modèle d'analyse 3.4.4 Les sous-systèmes regroupent les classes 3.4.5 Création du modèle d'implémentation à partir du modèle de conception

57 57 62 62 65

Table des matières

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 , — 4.1 L'architecture en bref 4.2 Pourquoi il nous faut une architecture . 4.2.1 Comprendre le système 4.2.2 Organiser le développement 4.2.3 Favoriser la réutilisation 4.2.4 Faire évoluer le système

71 72 74 75 75 76 76 78

97

4.7 Références

96 96 96 96

4.6 Trois concepts intéressants 4.6.1 Qu'est-ce que l'architecture ? 4.6.2. Comment l'obtient-on ? 4.6.3 Comment la décrit-on ?

90 91 91 94 95

4.5 Enfin, une description de l'architecture ! 4.5.1 Vue architecturale du modèle des cas d'utilisation . 4.5.2 Vue architecturale du modèle de conception 4.5.3 Vue architecturale du modèle de déploiement 4.5.4 Vue architecturale du modèle d'implémentation . . .

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 référence est un système « 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 crée l'architecture 1

81

CHAPITRE 5

Un p r o c e s s u s itératif et incrémental

99

103 103 105 106 106 107 108

5.2 Pourquoi un développement itératif et incrémental ? 5.2.1 Réduire les risques 5.2.2 Obtenir une architecture robuste 5.2.3 Gérer les exigences de changement 5.2.4 Permettre des changements tactiques 5.2.5 Parvenir à une intégration continue 5.2.6 Accéder très tôt à la connaissance

100 101 102

5.1 Le développement itératif et incrémental en bref 5.1.1 Procéder par étapes modestes 5.1.2 Ce que n'est pas une itération

Table des matières

113 113 115 H6

5.4 L'itération générique 5.4.1 Qu'est-ce qu'une itération ? 5.4.2 Planifier les itérations 5.4.3 Séquencer les itérations

109 110 112 \YL

5.3 L'approche itérative est guidée par la réduction des risques 5.3.1 Les itérations atténuent lesrisquestechniques 5.3.2 Les responsables ont la charge des risques non techniques 5.3.3 Traiter les risques

5.5 Une itération se traduit par un incrément 5.6 Itérations dans le cycle de vie

V

116 117 120 121 122

5.7 Les modèles évoluent à partir des itérations 5.8 Les itérations remettent en question l'organisation 5.9 Références

PARTIE I I

123

Les enchaînements d'activités principaux CHAPITRE 6

126 127 127

6.1 Pourquoi l'expression des besoins est-elle délicate ? 6.2 Objectif de l'enchaînement d'activités des besoins 6.3 Présentation générale de l'expression des besoins

125

Expression d e s besoins : de la vision aux besoins

6.4 Rôle des besoins dans le cycle de vie du logiciel 6.5 Compréhension du contexte du système à l'aide d'un modèle du domaine 6.5.1 Qu'est-ce qu'un modèle du domaine ? 6.5.2 Élaboration d'un modèle du domaine 6.5.3 Utilisation du modèle du domaine

132 133 133 135 136

6.6 Compréhension du contexte du système à l'aide d'un modèle du métier 6.6.1 Qu'est-ce qu'un modèle du métier ? 6.6.2 Élaboration d'un modèle du métier 6.6.3 Identification des cas d'utilisation à partir d'un modèle du métier

136 137 139 141

Table des matières

6.7 Exigences supplémentaires 6.8 Résumé 6.9 Références

143 144 144

CHAPITRE 7

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

147

187

7.6 Références

186

7.5 Résumé de l'enchaînement d'activités des besoins

169 170 176 182

159 160

7.4 Knchaînement d'activités 7.4.1 Activité : identifier les acteurs et les cas d'utilisation 7.4.2 Activité : définir un ordre de priorité pour les cas d'utilisation 7.4.3 Activité : détailler un cas d'utilisation 7.4.4 Activité : prototyper l'interface utilisateur 7.4.5 Activité : structurer le modèle des cas d'utilisation

156 156 157 158 158

7.3 Les travailleurs 7.3.1 Travailleur : analyste système 7.3.2 Travailleur : spécificateur de cas d'utilisation 7.3.3 Travailleur : concepteur d'interface utilisateur 7.3.4 Travailleur : architecte

155 155 156

149 149 150 151

7.2 Artefacts 7.2.1 Artefact : modèle 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 modèle des cas d'utilisation) 7.2.5 Artefact : glossaire 7.2.6 Artefact : prototype d'interface utilisateur

147

7.1 Introduction

CHAPITRE 8

Analyse

189 192 193 194 194

8.2 L'analyse en bref 8.2.1 Pourquoi l'analyse n'est ni la conception, ni l'implémentation... 8.2.2 Objectif de l'analyse : résumé 8.2.3 Quand employer l'analyse : exemples concrets

189

8.1 Introduction

Table des matières

228 230

8.7 Résumé de l'analyse 8.8 Références

212 213 219 223 227

8.6 Enchaînement d'activités 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

210 210 210 211

8.5 Travailleurs 8.5.1 Travailleur : architecte 8.5.2 Travailleur : ingénieur de cas d'utilisation 8.5.3 Travailleur : ingénieur de composants

209

197 197 198 202 206

8.4 Artefacts 8.4.1 Artefact : modèle d'analyse 8.4.2 Artefact : classe d'analyse 8.4.3 Artefact : réalisation-analyse de cas d'utilisation 8.4.4 Artefact : paquetage d'analyse 8.4.5 Artefact : description de l'architecture (vue du modèle d'analyse)

195

8.3 Rôle de l'analyse dans le cycle de vie du logiciel

VII

CHAPITRE 9

Conception

231

233 233 234 237 240 242

9.3 Artefacts 9.3.1 Artefact : modèle de conception 9.3.2 Artefact : classe de conception 9.3.3 Artefact : réalisation-conception de cas d'utilisation 9.3.4 Artefact : sous-système de conception 9.3.5 Artefact : interface 9.3.6 Artefact : description de l'architecture (vue du modèle de conception) 9.3.7 Artefact : modèle de déploiement 9.3.8 Artefact : description de l'architecture (vue du modèle de déploiement)

231 232

9.1 Introduction 9.2 Rôle de la conception dans le cycle de vie du logiciel

243 244 245

Table des matières

280

9.6 Résumé de la conception

248 248 264 271 278

9.5 Enchaînement d'activités 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-système

245 245 246 247

9.4 Travailleurs 9.4.1 Travailleur : architecte 9.4.2 Travailleur : ingénieur de cas d'utilisation 9.4.3 Travailleur : ingénieur de composants

281

9.7 Références CHAPITRE 10

Implémentation <

283

309 309

10.6 Résumé de l'implémentation 10.7 Références

295 296 298 301 304 305

10.5 Enchaînement d'activités 10.5.1 Activité : implémenter l'architecture 10.5.2 Activité : intégrer le système 10.5.3 Activité : implémenter un sous-système 10.5.4 Activité : implémenter une classe 10.5.5 Activité : effectuer les tests unitaires

293 293 294 294

10.4 Travailleurs 10.4.1 Travailleur : architecte 10.4.2 Travailleur : ingénieur de composants 10.4.3 Travailleur : intégrateur système

291 291

285 285 285 288 289

10.3 Artefacts 10.3.1 Artefact : modèle d'implémentation 10.3.2 Artefact : composant 10.3.3 Artefact : sous-système d'implémentation 10.3.4 Artefact : interface 10.3.5 Artefact : description de l'architecture (vue du modèle d'implémentation) 10.3.6 Artefact : plan de construction des intégrations

284

10.2 Rôle de l'implémentation dans le cycle de vie du logiciel

283

10.1 Introduction

Table des matières

IX

CHAPITRE 11

Test

311

11.1 Introduction 11.2 Rôle des tests dans le cycle de vie du logiciel 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

311 312 313 313 314 316 317 318 318 318

: modèle des tests : cas de test : procédure de test : composant de test : plan des tests : anomalie : évaluation des tests

320 321 322 325 326 327 328

11.5 Enchaînement d'activités 11.5.1 Activité : planifier les tests 11.5.2 Activité : concevoir les tests 11.5.3 Activité : implémenter les tests 11.5.4 Activité : effectuer les tests d'intégration 11.5.5 Activité : effectuer les tests système 11.5.6 Activité : évaluer les tests

318 318 319 319 319

11.4 Travailleurs 11.4.1 Travailleur 11.4.2 Travailleur 11.4.3 Travailleur 11.4.4 Travailleur

: concepteur de tests : ingénieur de composants : testeur d'intégration : testeur système

329

11.7 Références

329

11.6 Résumé des tests

PARTIE I I I

Un développement itératif et incrémental

331

CHAPITRE 12

333

Enchaînement d'activités de l'itération générique

334 335 335

12.1 Le besoin d'équilibre 12.2 Les phases constituent la première division du travail 12.2.1 La phase de création établit la faisabilité

Table des matières

12.2.2 La phase d'élaboration s'intéresse à la « capacité de réalisation » 12.2.3 La phase de construction « construit » le système 12.2.4 La phase de transition aborde l'environnement utilisateur . . . .

336 337 337

341 341 342 343 343

12.4 La planification précède l'action 12.4.1 Planifier les quatre phases 12.4.2 Planifier les itérations 12.4.3 Penser à long terme 12.4.4 Planifier les critères d'évaluation

339

12.3 L'itération générique revisitée 12.3.1 Les enchaînements d'activités principaux se répètent à chaque itération 12.3.2 Les travailleurs prennent part aux enchaînements d'activités

338 338

355 356 356 356 357

12.8 Évaluer les itérations et les phases 12.8.1 Les critères ne sont pas remplis 12.8.2 Les critères eux-mêmes 12.8.3 L'itération suivante 12.8.4 Évolution de l'ensemble des modèles

350 351 352 352 353 354

12.7 Ressources nécessaires 12.7.1 Les projets diffèrent énormément 12.7.2 Voici à quoi ressemble généralement un projet 12.7.3 A projets complexes, besoins supérieurs 12.7.4 Une nouvelle ligne de produits exige de l'expérience 12.7.5 II faut payer le prix des ressources utilisées

347 348 348 349

12.5 Lesrisquesaffectent la planification du projet 12.5.1 Gérer une liste des risques 12.5.2 Les risques affectent le plan des itérations 12.5.3 Planifier les actions à entreprendre face aux 12.6 Définition d'un ordre de priorité pour les cas d'utilisation 12.6.1 Risques spécifiques à un produit particulier 12.6.2 Risques de créer une architecture inadaptée 12.6.3 Risque de ne pas bien comprendre les besoins

risques

345 345 346 346

Table des matières

XI

CHAPITRE 13

L a phase de création lance le projet 13.1 L a phase de création en bref 13.2 Premiers stades de la phase de création 13.2.1 Avant le début de la phase de création 13.2.2 Planifier la phase de création 13.2.3 Élargir la vision du système 13.2.4 Définir les critères d'évaluation

359 359 360 360 361 362 362

13.3 Enchaînement d'activités de l'itération typique de création 13.3.1 Introduction aux cinq enchaînements d'activités principaux . . . 13.3.2 Adapter le projet à l'environnement de développement 13.3.3 Identifier lesrisquescritiques

364 365 366 367

373 374 375

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

367 368 371 372 373 373

13.4 Exécuter les enchaînements d'activités principaux : des besoins aux tests 13.4.1 Formuler les besoins 13.4.2 Analyse 13.4.3 Conception 13.4.4 Implémentation 13.4.5 Tests

378

13.8 Éléments à livrer à l'issue de la phase de création

376

13.7 Planifier la phase d'élaboration

375

13.6 Évaluer les itérations dans la phase de création

CHAPITRE 14

L a phase d'élaboration fabrique l'architecture de référence

379

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 développement 14.2.4 Définir les critères d'évaluation

379 380 380 381 381 381

Table des m a t i è r e s

12.2.2 La phase d'élaboration s'intéresse à la « capacité de réalisation » 12.2.3 La phase de construction « construit » le système 12.2.4 La phase de transition aborde l'environnement utilisateur . . . .

336 337 337

341 341 342 343

12.4 L a planification précède l'action 12.4.1 Planifier les quatre phases 12.4.2 Planifier les itérations 12.4.3 Penser à long terme

339

12.3 L'itération générique revisitée 12.3.1 Les enchaînements d'activités principaux se répètent à chaque itération 12.3.2 Les travailleurs prennent part aux enchaînements d'activités

12.4.4 Planifier les critères d'évaluation

338 338

343

347 348

12.6 Définition d'un ordre de priorité pour les cas d'utilisation 12.6.1 Risques spécifiques à un produit particulier

345 345 346 346

12.5 Les risques affectent la planification du projet 12.5.1 Gérer une liste des risques 12.5.2 Les risques affectent le plan des itérations 12.5.3 Planifier les actions à entreprendre face aux risques

12.6.2 Risques de créer une architecture inadaptée 12.6.3 Risque de ne pas bien comprendre les besoins 12.7 Ressources nécessaires 12.7.1 Les projets diffèrent énormément 12.7.2 Voici à quoi ressemble généralement un projet 12.7.3 A projets complexes, besoins supérieurs 12.7.4 Une nouvelle ligne de produits exige de l'expérience 12.7.5 I I faut payer le prix des ressources utilisées 12.8 Évaluer les itérations et les phases 12.8.1 Les critères ne sont pas remplis 12.8.2 Les critères eux-mêmes 12.8.3 L'itération suivante

,

12.8.4 Évolution de l'ensemble des modèles

348 349 350 351 352 352 353 354 355 356 356 356 357

CHAPITRE 13

La phase de création lance le projet

359 360 360 361 362 362

13.2 Premiers stades de la phase de création 13.2.1 Avant le début de la phase de création 13.2.2 Planifier la phase de création 13.2.3 Élargir la vision du système 13.2.4 Définir les critères d'évaluation

359

13.1 L a phase de création en bref

13.3 Enchaînement d'activités de l'itération typique de création 13.3.1 Introduction aux cinq enchaînements d'activités principaux . . . 13.3.2 Adapter le projet à l'environnement de développement 13.3.3 Identifier les risques critiques 13.4 Exécuter les enchaînements d'activités principaux : des besoins aux tests 13.4.1 Formuler les besoins 13.4.2 Analyse 13.4.3 Conception 13.4.4 Implémentation 13.4.5 Tests

364 365 366 367 367 368 371 372 373 3

7

3

375

13.5.2 Estimer le retour sur investissement

373 374

13.5 Élaborer l'étude de rentabilité initiale 13.5.1 Tracer les grandes lignes de 1 ' offre

376

13.7 Planifier la phase d'élaboration

375

13.6 Évaluer les itérations dans la phase de création 13.8 Éléments à livrer à l'issue de la phase de création

378

CHAPITRE 14

La phase d'élaboration fabrique l'architecture de référence

379 380 380

14.2 Premiers stades de la phase d'élaboration 14.2.1 Planifier la phase d'élaboration

379

14.1 L a phase d'élaboration en bref

381

14.2.4 Définir les critères d'évaluation

381 381

14.2.2 Constituer l'équipe 14.2.3 Modifier l'environnement de développement

384 386 388

14.4 Exécuter les enchaînements d'activités principaux : des besoins aux tests 14.4.1 Formuler les besoins 14.4.2 Analyse

382 383 384 384

14.3 Enchaînements d'activités de l'itération typique d'élaboration 14.3.1 Formuler et affiner la plupart des besoins 14.3.2 Développer 1 'architecture de référence 14.3.3 Procéder à des itérations tant que l'équipe est réduite

14.4.3 Conception 14.4.4 Implémentation 14.4.5 Tests

392 395 397

401

14.8 Principaux éléments à livrer

400

14.7 Planifier la phase de construction

399

14.6 Évaluer les itérations de la phase d'élaboration

398 398 399

14.5 Élaborer l'étude de rentabilité 14.5.1 Préparer l'offre commerciale 14.5.2 Actualiser le retour sur investissement

CHAPITRE 15

La construction aboutit à la capacité opérationnelle initiale

403 404 405

15.2 Premiers stades de la phase de construction 15.2.1 Constituer l'équipe de la phase

403

15.1 L a phase de construction en bref

15.2.2 Définir les critères d'évaluation

405

417


417

15.7 Planifier la phase de transition

416

15.6 Évaluer les itérations et la phase de construction

416

15.5 Maîtriser l'étude de rentabilité

408 409 410 411 413 414

15.4 Exécuter les enchaînements d'activités principaux : des besoins aux tests 15.4.1 Besoins 15.4.2 Analyse 15.4.3 Conception 15.4.4 Implémentation 15.4.5 Tests

406

15.3 Enchaînements d'activités de l'itération typique de construction


XIII

CHAPITRE 16

La phase de transition finalise le produit

419 421 421 423 423

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 Définir les critères d'évaluation

420

16.1 L a phase de transition en bref

429 430 430

16.5 Achever l'étude de rentabilité 16.5.1 Maîtriser la progression 16.5.2 Réviser le plan stratégique

425 425 426 426 427 429 429

16.4 Activités de la phase de transition 16.4.1 Livrer la version bêta 16.4.2 Installer la version bêta 16.4.3 Répondre aux résultats 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 ?

424

16.3 Les enchaînements d'activités principaux jouent un rôle mineur dans cette phase

432

16.7 Planifier la version ou la génération suivante

430 431 431

16.6 Évaluer la phase de transition 16.6.1 Évaluer les itérations et la phase 16.6.2 Post mortem du projet


432

CHAPITRE 17

Application optimale du Processus unifié

433

17.1 L e Processus unifié aide à gérer la complexité 17.1.1 Les objectifs du cycle de vie 17.1.2 L'architecture du cycle de vie 17.1.3 Capacité opérationnelle initiale

433 434 434 435

17.1.4 Livraison du produit

435

17.2 Les principaux thèmes

435

17.3 Les responsables dirigent la transition vers le Processus unifié 17.3.1 Les raisons d'agir 17.3.2 La directive de réingénierie achève de convaincre 17.3.3 Mettre en œuvre la transition

436 437 438 439


443

17.6 Profiter des avantages qu'offre le Processus unifié

442

17.5 Élargir le cercle de ses interlocuteurs

441 441 442

17.4 Spécialiser le Processus unifié 17.4.1 Adapter le Processus 17.4.2 Étoffer l'infrastructure du Processus

444

17.7 Références

Avant-propos

ANNEXE A

Présentation générale du langage UML A . l Introduction A. 1.1 Vocabulaire A . 1.2 Mécanismes d'extensibilité

445 445 446 446

459

A. 4 Références

451

A.3 Glossaire

447 447 448 449 449 450 450 450 451

A.2 Notation graphique A.2.1 Éléments structurels A.2.2 Éléments comportementaux A.2.3 Éléments de regroupement A.2.4 Éléments d'annotation A.2.5 Relations de dépendance A.2.6 Relations d'association A.2.7 Relations de généralisation A.2.8 Mécanismes d'extensibilité

"

ANNEXE B

Extensions du langage UML spécifiques au Processus unifié 461

464

B.4 Notation graphique

464

B.3 Valeurs marquées

461

B.2 Stéréotypes

461

B. l Introduction

465 .

B. 5 Références ANNEEXE C

Glossaire général

467 467

C.2 Termes

467

C. l Introduction

Une croyance, qui a cours chez certains, veut que les entreprises organisent leur activité autour d'un petit groupe d'individus aux compétences supérieures. Ces personnes censées connaître leur travail le feraient le plus naturellement du monde, sans directives ni procédures internes ! Croyance erronée dans la plupart des cas, et qui se révèle particulièrement dommageable dans le cas du développement logiciel. Certes, les développeurs logiciels connaissent leur affaire, mais la profession est encore jeune. I l leur faut donc des directives internes que nous désignons, dans ce livre, sous le nom de « processus de développement logiciel ». En outre, le processus présenté dans ces pages résultant de l'association de plusieurs méthodes auparavant indépendantes, nous nous estimons fondés à le nommer « Processus unifié ». Ce processus fusionne non seulement le travail des trois auteurs, mais il intègre, en plus, les apports de nombreux autres intervenants et entreprises ayant contribué à l'élaboration d'UML, auxquels s'ajoutent un bon nombre de collaborateurs-clés de Rational Software Corporation. Ce processus, enfin, s'enrichit, de l'expérience du terrain de centaines d'entreprises qui utilisent chaque jour les versions antérieures de ce processus sur des sites clients. Prenons l'image d'un chef d'orchestre symphonique. Pendant un concert, son rôle se borne essentiellement à donner le signal du départ aux musiciens et à faire en sorte qu'ils restent ensemble. Mais cela n'est possible, toutefois, que grâce aux nombreuses répétitions et parce que chacun des musiciens maîtrise parfaitement son instrument et en joue indépendamment des autres musiciens de l'orchestre. De manière 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 procédures » guidant l'exécution de l'œuvre. Les développeurs logiciels, en revanche, ne jouent pas de façon indépendante. 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. Il est clair que le besoin de processus va se ressentir de plus en plus fortement, en particulier dans les entreprises dont les systèmes informatiques jouent un rôle « stratégique » : systèmes financiers, systèmes de contrôle du trafic aérien, de défense et de télécommunications, entre autres. Par « stratégique », nous entendons que la réussite ou l'accomplissement de la mission de ces entreprises ou services publics dépend du système logiciel qui les sous-tend.

Or, ces systèmes se complexifient de jour en jour, alors même que leurs délais de livraison ne cessent de s'amenuiser, ce qui accroît d'autant la difficulté de leur développement. Toutes ces raisons expliquent que l'industrie logicielle ait besoin d'un processus capable de guider les développeurs, tout comme un orchestre se fonde sur la partition du compositeur pour donner des concerts.

Su'est-ce qu'un processus de d é v e l o p p e m e n t logiciel ? Un processus définit qui fait quoi à quel moment et de quelle façon pour atteindre un certain objectif. Dans le domaine de l'ingénierie logicielle, le but consiste à élaborer un produit logiciel ou à en améliorer un existant. Un processus digne de ce nom doit fournir des directives garantissant le développement efficace de logiciels de qualité et présenter un ensemble de bonnes pratiques autorisées par l'état de l'art. Ces dispositions permettent de réduire les risques tout en améliorant la prévisibilité. I l s'agit, d'un point de vue plus général, de promouvoir une vision et une culture communes. Un tel processus est indispensable et doit servir de fil d'Ariane à toutes les parties en présence : clients, utilisateurs, développeurs 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 développement. Ce processus doit, par ailleurs, être largement accessible afin que toutes les personnes impliquées puissent en comprendre le rôle dans le développement en question. Un processus de développement logiciel doit également pouvoir évoluer pendant de nombreuses années, tout en hmitant sa portée à ce que permet à chaque instant la réalité des technologies, des outils, des personnes et des structures organisationnelles. • Technologies. Le processus doit reposer sur des technologies (langages de programmation, systèmes d'exploitation, systèmes informatiques, capacités réseau, environnements de développement, etc.) exploitables au moment de l'utilisation du processus. Par exemple, i l y a vingt ans, la modélisation visuelle n'était guère répandue. Elle était trop onéreuse. À l'époque, la personne chargée d'élaborer le processus devait considérer comme pratiquement acquis que les diagrammes seraient effectués à la main. Cette hypothèse limitait considérablement les possibilités d'intégration de la modélisation au sein du processus. • Outils. Le processus et les outils doivent être développés en parallèle, ces derniers faisant partie intégrante du processus. En d'autres termes, un processus largement utilisé peut supporter l'investissement nécessaire à la mise au point des outils le prenant en charge. • Personnes. Le créateur du processus doit limiter les compétences nécessaires à son utilisation à celles que possèdent déjà les développeurs ou viser des compétences pouvant être rapidement acquises. Dans bien des domaines, i l est désormais possible d'intégrer dans des outils informatisés des techniques telles que la vérification de la cohérence des modèles graphiques qui réclamaient auparavant des compétences étendues. • Modèles organisationnels. Si les développeurs logiciels ne jouissent pas de la même indépendance que les membres d'un orchestre symphonique, ils sont toutefois bien

Avant-propos

3 éloignés des automates sur lesquels Frederick W. Taylor fondait sa « gestion scientifique », i l y a un siècle. Le créateur du processus doit adapter son processus à notre époque, en particulier aux réalités de l'organisation virtuelle du travail : le travail à distance par l'intermédiaire de lignes à haut débit ; la collaboration d'actionnaires (dans les petites PME/start-ups), d'employés salariés, de travailleurs indépendants et d'employés de SSII ; enfin, la pénurie continuelle de développeurs logiciels. Il est indispensable de trouver, entre ces quatre types de facteurs, un équilibre capable de subsister dans le temps. Le créateur du processus doit concevoir un processus évolutif, tout comme un développeur logiciel doit faire en sorte que son système soit opérationnel non pas seulement aujourd'hui, mais dans les années à venir. D'autant qu'un processus doit évoluer plusieurs années avant d'atteindre le niveau de stabilité et de maturité qui lui permettra de résister à la rigueur du développement de produits commerciaux, tout en maintenant à un niveau raisonnable les risques liés à son utilisation. Le développement 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 réalité. Le processus doit donc être stable. Sans cet équilibre entre technologies, outils, personnes et organisation, l'utilisation du processus serait périlleuse.

Objectifs du livre Cet ouvrage présente le processus logiciel que nous avions constamment à l'esprit en mettant au point le langage UML (Unified Modeling Language - Langage de modélisation unifié -). Si UML fournit un moyen standard de visualiser, spécifier, construire, documenter et communiquer les artefacts d'un système à logiciel prépondérant, 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, résistante 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 façon à l'exhaustivité. Vous trouverez une présentation didactique détaillée d'UML dans Le Guide de l'utilisateur d'UML [11], et pourrez constamment vous référer au Manuel de référence d'UML [12].

À qui s'adresse ce livre ? Le « Processus unifié de développement logiciel » peut être utilisé par toute personne prenant part au développement de logiciels. I l s'adresse avant tout aux membres de l'équipe de développement chargés des activités du cycle de vie que sont la formulation des besoins, l'analyse, la conception, l'implémentation et les tests ; en d'autres termes, des activités produisant des modèles UML. Cet ouvrage sera donc utile aux analystes et utilisateurs finals (qui spécifient la structure et le comportement souhaités d'un système), aux développeurs d'applications (qui conçoivent les systèmes satisfaisant à ces exigences), aux programmeurs (qui transforment ces conceptions en code exécutable), aux testeurs (qui vérifient et valident la structure et le comportement du système), aux développeurs de composants (qui créent et cataloguent les composants), enfin aux chefs de projet et de produit.

Avant-propos

Il suppose une fréquentation élémentaire des concepts orientés objet. Une expérience dans le développement logiciel et la pratique d'un langage de programmation orienté objet, si elles sont bienvenues, ne sont pas indispensables.

Vpproche du livre

Avant-propos

Figure P.1 Le développement du Processus unifié (les versions du produit figurent dans les rectangles).

Cet ouvrage accorde une place prépondérante aux activités (besoins, analyse et conception) sur lesquelles UML insiste en priorité. C'est dans ce contexte que le processus permet d'établir l'architecture de systèmes logiciels complexes. Le processus est, néanmoins, traité dans sa totalité, bien que de façon moins détaillée. Mais c'est bien le programme qui, en fin de compte, s'exécute. Pour parvenir à ce résultat, le projet réclame 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'activités extrêmement large. Un grand nombre d'artefacts doivent être produits et archivés, et il est indispensable de gérer toutes les activités. L'étude exhaustive du cycle de vie complet d'un processus dépasse largement la portée d'un seul ouvrage. Pour atteindre son objectif, un tel ouvrage devrait couvrir les directives de conception, les modèles d'artefacts, les indicateurs de qualité, la gestion de projet, la gestion de configuration, les métriques, et plus encore, bien plus ! Grâce à l'expansion des accès en ligne, ce « plus encore » est désormais disponible et peut être actualisé sous la pression des nouveaux développements. Nous vous renvoyons donc au Rational Unified Process, nouveau produit logiciel basé sur les technologies du Web guidant les équipes de développement vers des pratiques plus efficaces. (Pour de plus amples informations, consultez le site http://www.rational.com.) Parce qu'il traite intégralement le cycle de vie logiciel, le Rational Unified Process étend le Processus unifié au-delà des questions abordées dans ce livre. I l propose, en plus, des enchaînements d'activités (workflows) qui ne sont que peu ou pas évoqués dans ces pages, comme la modélisation métier, la gestion de projet et la gestion de configuration.

Rational Unified Process 5.0

Rational Objectory Process 4.1 1996-1997

Plusieurs autres sources

/

L'approche de Rational

UML Objectory Pr )cess 1.0-3.8 1987- •1995 /

L'approche d'Ericsson

L'approche Ericsson Le Processus unifié s'enracine profondément dans le passé. Pour reprendre les termes de Peter F. Drucker, i l s'agit d'une « innovation fondée sur des connaissances ». « Un vaste fossé temporel sépare l'émergence d'une nouvelle technologie du moment où elle devient utilisable », indique-t-il. « I l s'écoule ensuite une longue période 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 décalage dans le temps est que « l'innovation fondée sur les connaissances » repose précisément sur l'association de nombreuses connaissances et que cette maturation demande du temps. D'autre part, les personnes chargées de concrétiser cette nouvelle idée ont, elles aussi, besoin de temps pour la « digérer » et la diffuser aux autres.

istorique du Processus unifié Aboutissement de trois décennies de développement 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 première 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 archéologues du logiciel le soin de les identifier. En revanche, nous décrirons le retentissement qu'ont eu les approches Ericsson et Rational sur le produit et ferons état de plusieurs autres sources.

La première étape de cette mise en lumière du développement progressif du Processus unifié nous ramène en 1967. C'est à cette époque qu'Ericsson modélisa le système comme un ensemble de blocs interconnectés (appelés « sous-systèmes » en U M L et implémentés sous forme de « composants »). Les blocs de niveau inférieur étaient regroupés en soussystèmes de niveau supérieur afin d'améliorer la capacité d'administration du système. L'équipe d'Ericsson se fondait sur les cas de trafic spécifiés auparavant (désormais nommés « cas d'utilisation ») pour identifier les blocs. On pouvait alors identifier les blocs coopérant à la réalisation de chacun de ces cas d'utilisation et déterminer leur spécification propre à partir de leurs responsabilités connues. Le travail de conception se traduisait ensuite par la mise au point d'un ensemble de diagrammes de blocs statiques accompagnés de leurs interfaces, et par leur regroupement en sous-systèmes. Ces diagrammes de blocs correspondaient directement à une version simplifiée des diagrammes de classes ou de

Avant-propos

Avant-propos

SDL représentait donc un standard spécialisé de modélisation objet. Ce langage, régulièrement actualisée, est encore utilisée par plus de 10 000 développeurs et pris en charge par différents éditeurs. Mis au point i l y a plus de vingt ans, à une époque où la modélisation objet manquait de maturité, SDL était très en avance sur son temps. I l est vraisemblable qu'il sera finalement supplanté par UML, standardisé depuis novembre 1997.

Le premier produit des activités de conception était une description de l'architecture logicielle, fondée sur la compréhension des besoins essentiels. Ce document décrivait brièvement tous les blocs et leur regroupement en sous-systèmes. 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 décrits un à un dans une bibliothèque de messages. La description de l'architecture logicielle et la bibliothèque des messages constituaient les documents clés qui devaient, non seulement guider le travail de développement, mais également présenter le système aux clients. À l'époque (1968), les clients n'avaient pas l'habitude de découvrir un produit logiciel sous forme de plan d'élaboration.

tions de ce qu'UML appelle désormais diagrammes de classes, diagrammes d'activités, diagrammes de collaboration et diagrammes de séquence.

packages UML, simplifiée en ceci que les diagrammes ne montraient que les associations utilisées pour les communications.

Pour chaque cas d'utilisation, les ingénieurs préparaient soit un diagramme de séquence, soit un diagramme de collaboration. Ces diagrammes (améliorés dans UML) montraient la façon dont les blocs communiquaient dynamiquement pour réaliser le cas d'utilisation. Ils élaboraient une spécification sous forme de graphe d'états (ne comprenant que les états et les transitions). Cette approche d'une conception fondée sur des blocs ayant une interface parfaitement définie était primordiale pour la réussite des projets. I l suffisait, ensuite, pour créer une nouvelle configuration du système (par exemple, pour un nouveau client), de remplacer un bloc par un autre fournissant les mêmes interfaces. Les blocs n'étaient pas de simples sous-systèmes ni des composants à base de code source. Ils étaient compilés en blocs exécutables, installés un à un sur la machine cible, et fonctionnaient avec les autres blocs exécutables. Chaque nouveau bloc exécutable ou chaque bloc modifié devait pouvoir être installé dans un système relayant des appels téléphoniques, sans nécessiter la moindre interruption de service. On ne peut en effet raisonnablement pas interrompre un système de ce type pour procéder à de simples changements. Ce serait comme changer les pneus d'une voiture lancée à 100 kilomètres à l'heure. En substance, l'approche utilisée était ce que l'on appelle aujourd'hui le développement à base de composants. Ivar lacobson est à l'origine de cette méthode de développement. C'est lui qui en a guidé l'évolution, au cours des années qui ont précédé la période Objectory, pour en faire un processus de développement logiciel.

>DL : Langage de spécification et de description Cette période fut marquée par la sortie, en 1976, de SDL (Spécification and Description Language - Langage de spécification et de description) pour le comportement fonctionnel des systèmes de télécommunications. Mis au point par le CCITT (organisme international chargé de la standardisation dans le domaine des télécommunications) et nettement influencé par l'approche Ericsson, ce standard définissait un système comme un ensemble de blocs interconnectés communiquant les uns avec les autres par l'intermédiaire exclusif de messages (nommés « signaux » dans ce standard). Chaque bloc possédait un ensemble de « processus », terme SDL pour désigner les classes actives. De façon assez similaire aux classes du paradigme orienté objet, un processus était doté d'instances qui dialoguaient par le biais de messages. Cette méthode proposait des diagrammes qui étaient des spécialisa-

Objectory En 1987, Ivar Jacobson quittait Ericsson pour fonder Objectory AB à Stockholm. Lui et ses associés passèrent les huit années suivantes à concevoir un processus en tant que produit, appelé Objectory (contraction de « Object Factory »), qu'ils étendirent à des domaines autres que les télécommunications et exportèrent en dehors de la Suède. S'il figurait déjà dans les travaux effectués chez Ericsson, le concept de cas d'utilisation reçut alors son nom définitif (introduit lors de la conférence 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 développement. De même que s'imposa l'idée que c'est l'architecture qui doit guider les développeurs et permettre d'informer les divers intervenants. Les enchaînements d'activités successifs étaient représentés par une série de modèles : modèles des besoins avec des cas d'utilisation, modèles d'analyse, de conception, d'implémentation et de test. Un modèle offre un point de vue sur un système. Les relations unissant les différents modèles étaient capitales, car elles permettaient aux développeurs de suivre une caractéristique d'un bout à l'autre d'une série de modèles. En fait, la traçabilité devint un préalable à tout développement piloté par les cas d'utilisation. Les développeurs pouvaient suivre l'évolution d'un cas d'utilisation à travers toute la séquence de modèles jusqu'au code source et, en cas de problème, revenir en arrière. Le développement du processus Objectory s'est traduit par une série de versions, depuis Objectory 1.0 sorti en 1988, à la première version en ligne, Objectory 3.8, en 1995 (vous trouverez une présentation d'Objectory dans [2]). Il est important de noter que le produit Objectory en lui-même fut bientôt envisagé comme un système. Cette façon de décrire le processus comme un produit système facilitait considérablement la mise au point une nouvelle version d'Objectory à partir d'une version précédente, et le rendait plus modulable aux besoins particuliers de telle ou telle entreprise. Le fait que le processus de développement du logiciel Objectory lui-même faisait l'objet d'une conception rationnelle suffisait à le rendre unique. L'expérience acquise dans le développement d'Objectory permit également de mieux comprendre comment théoriser les processus sur lesquels repose un métier quel qu'il soit. Les mêmes principes pouvaient s'appliquer et furent intégrés dans un livre paru en 1995 [3].

Avant-propos

ipproche de Rational Rational Software Corporation ayant acquis Objectory AB à l'automne 1995, la tâche consistant à unifier les principes de base sous-jacents aux processus de développement logiciel existants s'est faite plus urgente. Rational avait mis au point un certain nombre de pratiques de développement logiciel, qui complétaient, pour l'essentiel, celles définies dans Objectory. Ainsi, « en 1981, Rational s'est mis à produire un environnement interactif capable d'améliorer la productivité pour le développement de systèmes informatiques d'envergure », rappelaient James E. Archer et Michael T. Devlin en 1986 [4]. Us insistaient sur l'importance des notions de conception orientée objet, d'abstraction, de masquage des informations, de réutilisabilité et de prototypage. S'il existe des dizaines d'ouvrages, d'articles et de documents internes retraçant les développements de Rational depuis 1981, la contribution majeure au processus est sans doute la prépondérance accordée à l'architecture et au développement itératif. En 1990, Mike Devlin rédigeait un article visionnaire décrivant un processus de développement itératif piloté par l'architecture, tandis que Philippe Kruchten, chargé de la pratique architecturale au sein de Rational, signait divers articles sur l'approche itérative et l'architecture. Nous citerons l'un de ces papiers, qui envisageait une représentation de l'architecture selon quatre points de vue : logique, processus, physique et développement, auxquels s'ajoutait un autre point de vue illustrant les quatre précédents à l'aide de cas d'utilisation ou de scénarios |6). L'intérêt d'avoir une diversité de points de vue au lieu de chercher à tout intégrer dans un seul type de diagramme, s'est imposé à Philippe Kruchten au gré de son expérience sur d'importants projets. Cette multiplicité de points de vue permettait aux intervenants comme aux développeurs d'identifier, dans la vue appropriée, ce dont ils avaient besoin pour atteindre leurs différents objectifs. Certains ont perçu le développement itératif comme quelque peu chaotique, voire anarchique. Au contraire, l'approche en quatre phases (création , élaboration, construction et transition) a été conçue pour permettre une meilleure structuration et un contrôle plus rigoureux de la progression pendant l'itération. Ces phases imposent un ordre aux itérations. La planification détaillée des phases et l'ordonnancement des itérations au sein de ces phases résultent 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 dès les débuts de Rational, Grady Booch formula dans l'un de ses ouvrages paru en 1996 deux « principes premiers » reposant sur l'architecture et l'itération : • « Un style de développement guidé par l'architecture est, en général, la meilleure approche pour la création de projets complexes à logiciel prépondérant. » • « Pour réussir, un projet orienté objet doit suivre un processus incrémental et itératif » [7].

Avant-propos

Processus Rational Objectory : 1995-1997 À l'époque de la fusion, Objectory 3.8 avait montré comment pouvait être mis au point et modélisé un processus de développement logiciel sous forme de produit, jetant ainsi les bases de l'architecture originale d'un processus de développement logiciel. Un ensemble de modèles avait été identifié, qui devait recueillir les résultats du processus. Si celui-ci était au point dans des domaines tels que la modélisation 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'implémentation et les tests. Par ailleurs, i l n'abordait que sommairement la gestion de projet et de configuration, le déploiement et la préparation de l'environnement de développement (acquisition d'outils et de procédés). Le fruit de l'expérience de Rational et les pratiques mises en œuvre, notamment les phases et l'approche itérative contrôlée, sont venus s'ajouter pour former le Rational Objectory Process 4.1. L'architecture y faisait l'objet d'une description précise (la « bible » de toute équipe de développement logiciel), occupait une place centrale dans le système lui-même et était dépeinte par les différentes vues architecturales des modèles. Le développement itératif partait d'un concept relativement général pour aboutir à une approche guidée par la réduction des risques qui plaçait l'architecture au premier plan. UML, dont les auteurs du présent ouvrage sont à l'origine de la création, était alors en cours de développement et servait de langage de modélisation au Rational Objectory Process. L'équipe de développement, dirigée par Philippe Kruchten, compensa certaines des faiblesses du Rational Objectory Process en renforçant la gestion de projet, notamment à partir des contributions de Royce [8].

UML : Unified Modeling Language Depuis quelque temps déjà, le besoin d'un langage visuel uniforme et cohérent pour exprimer les résultats des méthodes orientées objet encore en usage dans les années 1990 était devenu évident. Au cours de la même période, Grady Booch mettait au point la méthode Booch [9], tandis que James Rumbaugh élaborait, au Centre de recherche et de développement de General Electric, la méthode OMT (Object Modeling Technique) [10]. Lorsque ce dernier rejoignit Rational en 1994, tous deux s'engagèrent, en association avec des clients de Rational, dans un processus d'unification de leurs méthodes. La version 0.8 de la Méthode Unifiée (Unified Method 0.8) sortit en octobre 1995, à l'époque où Ivar Jacobson intégrait à son tour Rational. Cette collaboration à trois donna naissance à la version 0.9 d'UML (Unified Modeling Language). D'autres spécialistes des méthodes furent bientôt mis à contribution, ainsi que plusieurs sociétés, telles qu'IBM, HP et Microsoft, qui participèrent à l'émergence de ce standard. En novembre 1997, à l'issue du processus de standardisation, la version 1.1

ni appelée « phase d'inception

j

Avant-propos

11

Avant-propos

d'UML fut adoptée comme standard par l'OMG (Object Management Group). Pour de plus amples informations, consultez le Guide de l'utilisateur [11] et le Manuel de référence [11]. UML a été utilisé pour tous les modèles du Rational Objectory Process.

National Unified Process Dans le même temps, Rational se lançait dans une politique de fusion-acquisition de sociétés éditrices de logiciels. Chacune d'entre elles contribua, dans son champ d'expertise, au développement du processus Rational Objectory : • Requisite Inc. communiqua son expérience 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 expérience de Rational dans ce domaine ; • Pure-Atria apporta sa connaissance de la gestion de configuration qui vint renforcer celle de Rational en la matière ; • Performance Awareness ajouta les tests de performances et de charge ; • Enfin, Vigortech fournit ses compétences en matière d'ingénierie des données. Le processus s'enrichit également d'un nouvel enchaînement d'activités pour la modélisation métier (cf. [3]) permettant de dériver les besoins à partir des processus métier que devait servir le logiciel, et fut élargi à la conception d'interfaces utilisateur guidées par les cas d'utilisation (à partir de travaux effectués chez Objectory AB). Dès le milieu de l'année 1998, le Rational Objectory Process était devenu un processus complet, capable de prendre en charge la totalité du cycle de vie du développement 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 lança une nouvelle version du produit, Rational Unified Process 5.0 [13]. Un grand nombre d'éléments de ce processus propriétaire entrent aujourd'hui dans le domaine public grâce au présent ouvrage. Le changement de nom rend compte du fait que l'unification s'est opérée à deux niveaux : d'une part, unification des approches de développement à l'aide d'UML, de l'autre, unification du travail de nombreux spécialistes des méthodes, employés par Rational et sur les centaines de sites clients ayant utilisé le processus pendant plusieurs années.

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

our leur contribution à cet ouvrage Birgitte L0nvig a élaboré le premier exemple de l'ouvrage, celui du système interbancaire, qu'elle a mené à son terme en en créant tous les modèles.

Patrik Jonsson a puisé dans la documentation du Rational Objectory Process et en a classé les éléments extraits selon l'ordre des chapitres envisagés. Il a également pris part à l'élaboration des exemples et a suggéré nombre d'idées sur la meilleure façon de présenter le Processus unifié. Ware Myers a participé à la rédaction de cet ouvrage et en a traduit les premiers brouillons en une prose plus lisible. Parmi les réviseurs, 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 réviseurs comprenait également Pete McBreen, Glenn Jones, Johan Galle, N. Venu Gopal, David Rine, Mary Loomis, Marie Lenzi, Janet Gardner et quelques anonymes, à qui nous témoignons 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 détail de l'ouvrage et ses nombreuses suggestions formelles,finalementintégrées dans le livre. Son intervention a largement contribué à l'amélioration de la qualité du livre.

Pour leur collaboration fidèle depuis des années Nous voulons également manifester notre reconnaissance à tous ceux qui, aufildes années, 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, Stéphane 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

2

Nous désirons aussi exprimer toute notre gratitude aux personnes suivantes pour leur indéfectible soutien depuis des années : 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.

Nous voudrions particulièrement

Partie

I

remercier

Mike Devlin, président de Rational Software Corporation, qui a cru en l'intérêt du processus Objectory pour tout type de développement logiciel et en l'utilisation d'un processus logiciel efficace comme pierre de touche du développement 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 méthode UML, tout en préservant la valeur de chacun de ces éléments. Cet objectif serait demeuré inaccessible sans l'engagement personnel et la persévérance de Philippe Kruchten dans l'élaboration de ce que l'on peut, en toute modestie, qualifier de meilleur processus logiciel existant à ce jour.

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

de

P r o c e s s u s

L e

Un processus en marche Cet ouvrage et ceux qui viennent le compléter, les versions en ligne et les outils contribuent à la maturation du processus. Le Processus unifié s'inspire denombreuses sources. Déjà très largement utilisé, il fournit aux cadres de direction, aux développeurs et aux intervenants de toute sorte un moyen de compréhension unique du processus. Il reste, toutefois, beaucoup à faire : i l faut que les développeurs harmonisent leurs techniques de travail, avec, bien entendu, les encouragements des divers intervenants et responsables. Pour beaucoup d'entreprises, cette petite révolution n'est qu'une perspective lointaine. A vous de la faire advenir. Ivar Jacobson Palo Alto, Californie Décembre 1998 [email protected]

u n i f i é logiciel

Un processus piloté par les cas d'utilisation

Chapitre 3.

Les quatre « P » du développement logiciel : personnes, projet, produit et processus

Chapitre 2.

Le Processus unifié : piloté par les cas d'utilisation, centré sur l'architecture, itératif et incrémental

Chapitre 1.

Un processus itératif et incrémental

Chapitre 5.

Un processus centré sur l'architecture

Chapitre 4.

La première partie introduit les principales idées qui sont exposées tout au long de ce livre. Dans le chapitre 1, nous décrivons brièvement le Processus unifié de développement logiciel, en insistant sur le fait qu'il est piloté par les cas d'utilisation, centré sur l'architecture, itératif et incrémental. Le processus décrit dans ces pages utilise le langage U M L (Unified Modeling Language), qui génère 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 développement sur des composants réutilisables, c'est-à-dire des fragments logiciels disposant d'une interface clairement définie. Le chapitre 2 présente la théorie des quatre « P » : personnes, projet, produit et processus, et en décrit les relations, absolument essentielles à la compréhension de cet ouvrage. De même, le processus traité dans ce livre ne saurait être appréhendé sans les concepts fondamentaux d'artefact, de modèle, de travailleur et d'enchaînement d'activités

(« workfiow »). Le chapitre 3 aborde plus en détail la notion de développement piloté par les cas d'utilisation. Les cas d'utilisation constituent un moyen d'identifier les véritables besoins et de les utiliser pour orienter tout le processus de développement. Le rôle 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 différents niveaux de l'organisation du logiciel et s'attache à créer le squelette du système. Le chapitre 5 insiste sur la nécessité d'adopter une approche itérative et incrémentale pour le développement logiciel. Ce qui signifie, en pratique, de se confronter en premier heu aux parties les plus incertaines du système, de définir très tôt une architecture stable, puis d'aborder les parties les plus routinières par des itérations successives, chacune conduisant à l'élaboration d'un incrément jusqu'à la version finale. La deuxième partie va plus en profondeur. Un chapitre est consacré à chacun des principaux enchaînements d'activités : expression des besoins, analyse, conception, implémentation et tests. Ces enchaînements formeront, dans la troisième partie, l'essentiel des activités effectuées au cours des diverses itérations des quatre phases qui composent le processus. Dans la troisième partie, nous décrivons de façon concrète l'exécution des tâches dans chaque phase : élaboration d'une étude de rentabilité dans la phase de création ; mise en place de l'architecture et d'un plan dans la phase d'élaboration; transformation de l'architecture en un système livrable dans la phase de construction ; enfin, vérification du fonctionnement correct du système au sein de l'environnement utilisateur dans la phase de transition. Nous réutilisons, dans cette partie, les principaux enchaînements d'activités, que nous associons de façon spécifique à chaque phase, afin de parvenir aux résultats souhaités. Cependant, l'objectif sous-jacent que poursuit une entreprise n'est évidemment pas de posséder un « bon système informatique », mais d'exploiter les processus métier (ou les systèmes intégrés) pour répondre au mieux à la demande du marché et accélérer la production de biens et de services de qualité à un prix raisonnable. Les systèmes logiciels sont l'arme stratégique qui permet aux entreprises et administrations de réaliser de considérables économies de coûts et de temps de production dans les secteurs secondaire et tertiaire. I l est impossible de réagir promptement à la dynamique du marché sans avoir, au préalable, mis en place des processus efficaces au sein de l'entreprise. Dans une économie mondialisée, en marche vingt-quatre heures sur vingt-quatre, sept jours sur sept, la plupart de ces processus seraient inopérants sans logiciels. La maîtrise d'un processus efficace de développement logiciel est, par conséquent, devenue un facteur incontournable dans le succès d'une entreprise.

Le Processus unifié : piloté par les cas d'utilisation, centré sur l'architecture, itératif et incrémental La tendance, aujourd'hui, en matière de logiciel est à la création de systèmes de plus en plus imposants et complexes. Cette orientation s'explique, en partie, par la rapide montée en puissance des ordinateurs, qui a pour effet d'accroître les attentes des utilisateurs. Autre influence déterminante, l'utilisation croissante de l'Internet pour l'échange de toute sorte d'informations, du texte simple aux documents multimédias, en passant par les diagrammes et le texte mis en forme et doté d'images. Notre soif de logiciels de plus en plus sophistiqués s'aiguise au gré des annonces précédant les sorties de produits : nous voulons des logiciels plus adaptés à 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 délai de mise sur le marché est un autre facteur décisif. Mais la satisfaction de tels objectifs n'est pas des plus simples. Le mode de développement des logiciels ne concorde pas avec nos exigences de logiciels puissants et complexes. Aujourd'hui, la plupart des entreprises développent des logiciels en utilisant les mêmes méthodes qu'il y a vingt-cinq ans, ce qui pose évidemment un problème. On ne peut prétendre réaliser les logiciels complexes que réclament les clients sans actualiser les méthodes qui président à leur développement. Tout le problème du développement logiciel se résume, en fin de compte, à la difficulté qu'éprouvent les développeurs à concilier les différents aspects qu'implique tout projet informatique d'envergure. Les équipes de développement ont besoin d'une méthode de travail contrôlée, d'un processus intégrant les diverses facettes du développement et d'une approche commune, c'est-à-dire d'un processus capable : • de dicter l'organisation des activités de l'équipe ;

PARTIE I

t L f l

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

lygU

logiciel

Besoins de l'utilisateur

Le Processus u n i f i é CHAPITRE

• de diriger les tâches de chaque individu et de l'ensemble de l'équipe ; • de spécifier les artefacts à produire ; • de proposer des critères pour le contrôle et l'évaluation des produits et des activités du projet. L'existence d'un processus clairement défini et parfaitement géré est l'un des éléments clés opposant les projets ultra-productifs aux projets infructueux. (Pour connaître les autres raisons de la nécessité d'un processus, consultez la section 2.4.4.) Aboutissement de plus de trente ans d'expérience, le Processus unifié de développement logiciel offre une solution au problème du développement informatique. Ce chapitre propose une vision d'ensemble du Processus unifié, tandis que les chapitres suivants examinent en détail chacun de ses éléments.

1.1 Le Processus unifié en bref Avant toute chose, le Processus unifié est un processus de développement logiciel, c'est-àdire qu'il regroupe les activités à mener pour transformer les besoins d'un utilisateur en système logiciel (voir figure 1.1). Mais c'est plus qu'un simple processus. C'est un framework de processus générique pouvant être adapté à une large classe de systèmes logiciels, à différents domaines d'application, à différents types d'entreprises, à différents niveaux de compétence et à différentes tailles de projets. Figure 1.1 lin processus de développement loyit ici.

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

Système logiciel

Le Processus unifié est à base de composants, ce qui signifie que le système logiciel en cours de fabrication est fait de composants logiciels (Annexe A) reliés les uns aux autres par des interfaces clairement définies (Annexe A). Le Processus unifié utilise le langage UML (Unified Modeling Language) pour la création des plans d'élaboration et de construction du système logiciel. En fait, UML fait partie intégrante du Processus unifié : l'un et l'autre ont été développés de concert. Néanmoins, les traits véritablement distinctifs du Processus unifié tiennent en trois expressions clés : piloté par les cas d'utilisation, centré sur l'architecture, itératif et incrémental. Voilà ce qui en fait toute l'originalité. Dans les trois sections suivantes, nous allons définir ces trois caractéristiques, avant de passer à un survol du processus : cycle de vie, phases, versions, itérations, enchaînements d'activités et artefacts. L'objectif de ce chapitre est d'introduire les idées maîtresses et de proposer une vue « aérienne » du processus dans son ensemble. Après lecture de ces quelques pages, vous saurez, sans avoir nécessairement parfaitement compris, de quoi i l est question dans le Processus unifié. La suite du livre complétera cette vue d'ensemble en ajoutant tous les détails nécessaires. Dans le chapitre 2, nous mettrons en contexte les quatre

1

I

« P » du développement logiciel : personnes, projet, produit et processus. Nous consacrerons, ensuite, un chapitre à chacune des trois idées fondamentales. Ces chapitres formeront la première partie de l'ouvrage. Les deuxième et troisième parties, qui constituent le cœur de l'ouvrage, décriront en détail les différents enchaînements d'activités du processus.

1.2 Le Processus unifié est piloté par les cas d'utilisation L'objectif d'un système logiciel est de rendre service à ses utilisateurs. Pour réussir la mise au point d'un système, i l importe, par conséquent, de bien comprendre les désirs et les besoins de ses futurs utilisateurs. Le terme utilisateur ne désigne pas seulement les utihsateure humains, mais également d'autreji^ystèmes. Dans ce sens, l'utilisateur représente une personne ou une chose (telle qu'un système autre que le système proposé) dialoguant avec le système en cours de développement. D peut s'agir, par exemple, d'un être humain utilisant un distributeur automatique de billets (DAB). La personne insère sa carte magnétique, répond aux questions que lui pose la machine par l'intermédiaire de son écran de visualisation, et reçoit une somme d'argent liquide. Le système réagit à l'insertion de la carte de l'utilisateur et à ses réponses en effectuant une séquence d'actions (Annexe A) qui fournissent à l'utilisateur un résultat tangible, en l'occurrence un retrait de liquide. Ce type d'interaction est appelé cas d'utilisation (Annexe A ; voir également le chapitre 3). Un c^^^tOwationi est une fonctionnalité du système produisant un résultat satisfaisant pour l'utilisateur. Les cas d'utilisation saisissent les besoins fonctionnels et leur ensemble constitue le modèle des cas d'utilisation (Annexe B ; voir aussi la section 2.3), qui décrit les fonctionnalités complètes du système. Ce modèle remplace la classique spécification fonctionnelle du système, qui répondait à la question suivante : qu'est censé faire le système ? On peut caractériser la stratégie 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 à réfléchir en termes d'avantages pour les utilisateurs et non plus simplement en termes de fonctions dont il pourrait être intéressant de disposer. Mais les cas d'utilisation ne sont pas un simple outil de spécification des besoins du système. Ils en guident également la conception, l'implémentation et les tests ; c'est-à-dire qu'ils guident le processus de développement. A partir du modèle des cas d'utilisation, les développeurs créent une série de modèles de conception et d'implémentation réalisant les cas d'utilisation. Chacun des modèles successifs est ensuite révisé pour en contrôler la conformité par rapport au modèle des cas d'utilisation. Enfin, les testeurs testent l'implémentation pour s'assurer que les composants du modèle d'implémentation mettent correctement en œuvre les cas d'utilisation. Ceux-ci ne se bornent donc pas à enclencher le processus de développement : ils en garantissent la cohérence. Piloté par les cas d'utilisation signifie que le processus de développement suit une voie spécifique, c'est-à-dire qu'il procède par une série d'enchaînements d'activités dérivés des cas d'utilisation. Les cas d'utilisation sont spécifiés, ils sont conçus, 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 sélectionnés de façon isolée, mais doivent absolument être développés en tandem avec l'architecture du

PARTIE

H

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

U

Le Processus u n i f i é

J |

I

système. Les cas d'utilisation guident l'architecture du système, qui influence, à son tour, leur sélection. L'architecture et les cas d'utilisation évoluent donc de façon parallèle au cours du cycle de vie du développement.

1.3 Le Processus unifié est centré sur l'architecture Le rôle de l'architecture logicielle est comparable à celui que joue l'architecture dans la construction d'un bâtiment. Le bâtiment est envisagé de différents points de vue : structure, services, conduites de chauffage, plomberie, électricité, etc. Ce regard multiple dessine une image complète du bâtiment avant le début de la construction. De la même façon, l'architecture d'un système logiciel peut être décrite comme les différentes vues du système qui doit être construit. Le concept d'architecture logicielle représente les_aspects^statiques.et dynarmgj^Jes plus significatifs du système. L'architecture émerge des besoins de l'entreprise, tels qu'ils sont exprimés par les utilisateurs et autres intervenants et tels qu'ils sont reflétés par les cas d'utilisation. Elle subit, néanmoins, l'influence d'autres facteurs, tels que la plate-forme sur laquelle devra s'exécuter le système (par exemple, l'architecture matérielle, le système d'exploitation, le système de gestion des bases de données, les protocoles de communication réseau), les briques de base réutilisables disponibles pour le développement (par exemple, une infrastructure préfabriquée (framework) (Annexe C) pour les interfaces utilisateur graphiques), les considérations de déploiement, les systèmes 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 caractéristiques essentielles en laissant de côté les détails secondaires. Comme la détermination de ce qui est important tient, en partie, à la capacité de jugement, elle-même forgée par l'expérience, la valeur de l'architecture dépend étroitement des personnes auxquelles en est attribuée la tâche. Le processus aide, toutefois, l'architecte à s'attacher en priorité aux vrais objectifs que sont la clarté, la capacité de réaction aux futurs changements et la réutilisation. Quels sont les liens entre cas d'utilisation et architecture ? Tout produit est à la fois forme et fonction. L'une ou l'autre isolément ne saurait suffire. Ces deux forces doivent s'équilibrer pour créer un produit réussi. Dans le cas qui nous intéresse, 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 problème classique « de l'œuf et de la poule ». D'un côté, les cas d'utilisation doivent, une fois réalisés, trouver leur place dans l'architecture. De l'autre, l'architecture doit prévoir la réalisation de tous les cas d'utilisation nécessaires, dans le présent et à l'avenir. En fait, l'architectore et les cas d'utilisation doivent évoluer de façon concomitante. Les architectes vont donc « couler » le système dans une forme. Cette forme (l'architecture) doit être conçue de façon à permettre l'évolution du système, non seulement dans le cadre de son développement initial, mais dans les années et les générations à venir. Pour déterminer une telle forme, les architectes doivent travailler à partir d'une compréhension générale des principales fonctions, c'est-à-dire des principaux cas d'utilisation, du système. Ces cas d'utilisation peuvent ne représenter que 5 à 10% de tous les cas d'utili-

sation du système, mais ils sont les plus significatifs, ceux qui constituent le cœur même des fonctions du système. En clair : • L'architecte crée une ébauche grossière 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 indépendante des cas d'utilisation, l'architecte doit avoir une compréhension globale de ceux-ci avant d'esquisser l'architecture. • I l travaille, ensuite, sur un sous-ensemble des cas d'utilisation identifiés, ceux qui représentent les fonctions essentielles du système en cours de développement. Chaque cas d'utilisation sélectionné est décrit en détail et réalisé sous forme de sous-systèmes (Annexe A ; voir également la section 3.4.4), de classes (Annexe A) et de composants (Annexe A). • L'architecture se dévoile peu à peu, au rythme de la spécification et de la maturation des cas d'utilisation, qui favorisent, à leur tour, le développement d'un nombre croissant de cas d'utilisation. Ce processus se poursuit jusqu'à ce que l'architecture soit jugée stable.

1.4 Le Processus unifié est itératif et incrémental Le développement d'un produit logiciel destiné à la commercialisation est une vaste entreprise qui peut s'étendre sur plusieurs mois, voire sur une année ou plus. I l n'est pas inutile de découper le travail en plusieurs parties qui sont autant de mini-projets. Chacun d'entre eux représente une itération qui donne lieu à un incrément. Les itérations désignent des étapes de Tënchaînement d'activités, tandis que les incréments correspondent à des stades de développement du produit. Pour garantir un maximum d'efficacité, i l est indispensable de contrôler les itérations : celles-ci doivent être sélectionnées et menées à bien de façon planifiée. C'est la raison pour laquelle on les qualifie de mini-projets. Le choix de ce qui doit être implémenté au cours d'une itération repose sutêujtîaçteurs. ^rëfMèremënf, une itération prend en compte un certain nombre de cas d'utilisation qui, - ensemble, améliorent l'utilisabilité du produit parvenu à un certain stade de développement. Deuxièmement, l'itération traite en priorité les risques majeurs. Les itérations successives exploitent les artefacts de développement dans l'état où les a laissés l'itération précédente et les enrichissent progressivement. I l s'agit d'un mini-projet qui part des cas d'utilisation, se prolonge par le travail de développement normal (analyse, conception, implémentation et tests) et réalise sous forme de code exécutable les cas d'utilisation définis au cours de l'itération. Bien entendu, un incrément ne constitue pas nécessairement un additif. Dans les premières phases du cycle de vie, en particulier, i l n'est pas rare de remplacer une conception superficielle par une autre plus détaillée ou plus complexe. Dans les phases suivantes, en revanche, les incréments ne sont généralement que des additifs. À chaque itération, les développeurs identifient et spécifient les cas d'utilisation pertinents, créent une conception en se laissant guider par l'architecture choisie, implémentent cette conception sous forme de composants et vérifient que ceux-ci sont conformes aux cas d'utilisation. Dès qu'une itération répond aux objectifs qui lui sont fixés (ce qui est généralement

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 cas), le développement peut passer à l'itération suivante. Si une itération n'atteint pas ses objectifs, les développeurs doivent réétudier les décisions prises et tenter d'adopter une nouvelle approche. Pour rentabiliser les efforts de développement, chaque équipe essaiera de ne sélectionner que les itérations nécessaires pour atteindre les objectifs du projet. Dans la mesure du possible, ces itérations devront se succéder selon un ordre logique. Un projet réussi suivra un déroulement direct, établi dès le début par les développeurs et dont i l ne s'éloignera que de façon très marginale. Bien sûr, si des problèmes imprévus viennent ajouter des itérations ou en bouleverser la séquence prévue, le processus de développement nécessitera plus de travail et de temps. L'élimination des problèmes imprévus fait partie des objectifs de réduction des risques. L'utilisation d'un processus itératif contrôlé présente de nombreux avantages : • Une itération contrôlée permet de limiter les coûts, en termes de risques, aux strictes dépenses liées à une seule itération. S'il faut reprendre l'itération, l'entreprise ne perd que le bénéfice des efforts mal orientés sur une itération, et non la valeur du produit dans son entier. • Une itération contrôlée permet de limiter les risques de retard de mise sur le marché du produit développé. L'identification des risques dès les premiers stades de développement en permet la résolution précoce, à un moment où les développeurs sont moins soumis à la pression des délais que dans les phases ultimes du projet. Avec l'approche « classique », qui ne fait apparaître les problèmes qu'au moment des tests du système, le temps nécessaire à leur résolution dépasse généralement les délais prévus et conduit presque inexorablement à un retard de livraison.

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

1

1.5 La vie du Processus unifié Le Processus unifié répète un certain nombre de fois une série de cycles constituant la vie d'un système, 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 : création, élaboration, construction et transition. Chacune d'entre elles se subdivise à son tour en itérations, comme nous l'avons indiqué plus haut. Voir lafigure1.3. Figure 1.2 La vie d'un processus se décompose en cycles allant de sa naissance à sa mort.

Naissance

Temps

Cycles donnant naissance à une version

Figure 1.3 Un cycle, avec ses phases et ses itérations.

Temps

• Une itération contrôlée se traduit par une accélération du rythme de l'ensemble du développement, car elle permet aux développeurs de travailler plus efficacement vers des objectifs clairs à court terme, plutôt qu'en fonction d'un planning à long terme soumis à d'inévitables dépassements. • Enfin, une itération contrôlée prend en compte une réalité souvent ignorée : les besoins des utilisateurs et les exigences correspondantes ne peuvent être intégralement définis à l'avance et se dégagent peu à peu des itérations successives. Ce mode de fonctionnement facilite l'adaptation à l'évolution des besoins.

1.5.1 Le produit

Le produit fini comprend les besoins, les cas d'utilisation, les spécifications non fonctionnelles et les cas de test. I l englobe l'architecture et les modèles visuels (les artefacts modélisés par UML). En fait, i l intègre tous les éléments abordés dans ce chapitre, car ce sont eux qui permettent aux intervenants (clients, utilisateurs, analystes, concepteurs, programmeurs, testeurs et responsables) de spécifier, concevoir, implémenter, tester et utiliser un système.

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 enchaînements d'activités, ses phases et ses itérations.

Chaque cycle se traduit par une nouvelle version du système, c'est-à-dire un produit prêt à la livraison. Ce produit se compose d'un corps de code source réparti sur plusieurs composants pouvant être compilés et exécutés, et s'accompagne de manuels et de produits associés. 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 amenés à l'exploiter. Il ne peut, par conséquent, se résumer à un simple code machine exécutable.

Ces concepts - développement piloté par les cas d'utilisation, centré sur l'architecture, itératif et incrémental - sont d'égale importance. L'architecture fournit la structure qui servira de cadre au travail effectué au cours des itérations, tandis que les cas d'utilisation définissent les objectifs et orientent le travail de chaque itération. L'abandon de l'une ou l'autre de ces trois notions clés atténuerait considérablement la valeur du Processus unifié. Comme un tabouret auquel i l manquerait un pied, i l s'effondrerait.


Le Processus u n i f i é CHAPITRE

Ce sont également ces éléments qui rendent possible l'utilisation et la modification du système sur plusieurs générations. Si les composants exécutables sont indéniablement les artefacts les plus importants du point de vue de l'utilisateur, leur seule présence ne saurait suffire. Et cela pour la simple raison que l'environnement change. Les systèmes d'exploitation, de bases de données et les machines sous-jacentes évoluent. I l est possible, alors même que se précise peu à peu le cadre de la mission, que les besoins eux-mêmes se modifient et contraignent les développeurs à entamer un nouveau cycle qui devra être financé par la direction. Pour mener efficacement le cycle suivant, les développeurs ont besoin de toutes les représentations du produit logiciel (figure 1.4) : • un modèle des cas d'utilisation exposant tous les cas d'utilisation et leurs relations avec les utilisateurs ;

Figure 1.4 Modèles du Processus unifié. La plupart des modèles sont liés par des dépendances. Par exemple, les dépendances entre le modèle des cas d'utilisation et les autres modèles sont indiquées.

Modèle des cas d'utilisation

1

spécifié par

Modèle d'analyse

B Modèle de conception

•

• |""|

impiémenté par

Modèle de déploiement

vérifié par

S'

• un modèle d'analyse poursuivant deux objectifs : détailler les cas d'utilisation et procéder à une première répartition du comportement du système entre divers objets appropriés ;

s Implémentation Model

• un modèle de conception définissant (a) la structure statique du système sous forme de sous-systèmes, classes et interfaces, et (b) les cas d'utilisation réalisés sous forme de collaborations (Annexe A ; voir également la section 3.1) entre les sous-systèmes, les classes et les interfaces ; • un modèle d'implémentation intégrant les composants (représentant le code source) et la correspondance entre les classes et les composants ; • un modèle de déploiement définissant les nœuds physiques des ordinateurs et l'affectation de ces composants sur ces nœuds ; • un modèle de tests décrivant les cas de test vérifiant les cas d'utilisation ; • et, bien sûr, une représentation de l'architecture. Il est possible que le système dispose également d'un modèle du domaine ou d'un modèle du métier décrivant le contexte professionnel du système. Tous ces modèles sont liés. Ensemble, ils représentent le système comme un tout. Les éléments de chacun des modèles présentent des dépendances de traçabilité (Annexe A ; voir également la section 2.3.7) avant et arrière favorisées par les liens existant avec les autres modèles. I l est, par exemple, possible de remonter à un cas d'utilisation (dans le modèle des cas d'utilisation) à partir de sa réalisation (dans le modèle de conception) ou d'un cas de test (dans le modèle de test), et inversement. La traçabilité facilite la compréhension et les modifications ultérieures.

i DO

Y Modèle de tests

1.5.2 Les phases d'un cycle Chaque cycle se déroule sur une certaine durée découpée en quatre phases, comme le montre la figure 1.5. Une séquence de modèles permet aux intervenants de visualiser ce qui se passe durant ces phases. Pour chacune d'elles, les chefs de projet ou développeurs peuvent pousser la décomposition du travail en itérations et incréments qui en sont issus. Chaque phase s'achève par un jalon (Annexe C ; voir également le chapitre 5), qui se définit par un ensemble d'artefacts : certains modèles ou documents ont atteint un niveau de réalisation fixé au préalable. Les jalons servent de nombreux objectifs, le principal étant de permettre aux chefs de projet de prendre un certain nombre de décisions cruciales avant de passer à la phase suivante du développement. Ils permettent également aux responsables, et aux développeurs euxmêmes, de surveiller la progression du travail en fonction de ces quatre points clés. Enfin, l'archivage du temps et des efforts consacrés à chaque phase constitue un corpus de données qui se révèlent fort utiles pour évaluer les besoins en termes de délais et de personnel sur d'autres projets, planifier les besoins en personnel sur toute la durée d'un projet et contrôler l'avancement par rapport aux projections. La figure 1.5 indique les enchaînements d'activités (formulation des besoins, analyse, conception, implémentation et tests) dans la colonne de gauche, tandis que les courbes représentent approximativement (ne les considérez pas de façon trop littérale) le degré d'accomplissement des enchaînements d'activités dans chaque phase. N'oubliez pas que chaque phase se décompose en principe elle-même en itérations, ou mini-projets. Une itération couvre généralement les cinq enchaînements d'activités, comme le montre la figure 1.5 dans la phase d'élaboration.


I

Figure 1.5 Les cinq Principaux e n c h a î n e m e n t s enchaînements d'activités d'activités (besoins, analyse, conception, implémentation et Analyse tests) se déroulent sur les quatre Conception phases : création, élaboration, construction et Implémentation transition.

Phases

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

j g

oÂTirREi^m d'élaboration, aboutit à l'émergence d'une architecture de référence (Annexe C ; voir également la section 4.4). À l'issue de la phase d'élaboration, le chef de projet est en mesure de prévoir les activités et d'estimer les ressources nécessaires à l'achèvement 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 maîtrisés pour permettre la réalisation du développement dans le respect du contrat ? »

iter. iter. #1 #2

... I Iter. I #n-1

iter. #n

Itérations

La phase de création (ou d'inception) traduit ce qui n'est, au départ, qu'une bonne idée en une vision du produit fini et présente une étude de rentabilité pour ce produit. Cette phase répond essentiellement aux questions suivantes : • Que va faire, en substance, le système pour chacun de ses principaux utilisateurs ? • À quoi peut ressembler l'architecture d'un tel système ? • Quels sont l'organisation et les coûts du développement de ce produit ? Un modèle simplifié des cas d'utilisation regroupant les principaux cas d'utilisation permettra de répondre à la première question. A ce stade, l'architecture est encore provisoire, elle n'est en général qu'une ébauche révélant les principaux sous-systèmes. C'est au cours de cette phase que sont identifiés et hiérarchisés les risques majeurs, qu'est planifiée en détail la phase d'élaboration et qu'est livrée une estimation approximative du projet dans son ensemble. La phase d'élaboration permet de préciser la plupart des cas d'utilisation et de concevoir l'architecture du système. La relation existant entre l'architecture d'un système et le système lui-même est absolument primordiale. Disons, pour faire simple, que l'architecture s'apparente à un squelette recouvert de peau, mais avec très peu de muscles (le logiciel), juste assez pour permettre au squelette d'effectuer les mouvements les plus élémentaires. Le système est ce corps dans son entier : squelette, peau et muscles. L'architecture doit donc être exprimée sous forme de vues de tous les modèles du système qui, associées les unes aux autres, figurent le système dans son ensemble. Cela implique l'existence d'une vue architecturale de chacun des modèles de cas d'utilisation, de conception, d'implémentation et de déploiement. La vue du modèle d'implémentation doit comprendre les composants témoignant du caractère exécutable de l'architecture. Cette phase, au cours de laquelle sont réalisés les principaux cas d'utilisation identifiés 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 référence se métamorphose en système complet. Notre vision du système est désormais celle d'un produit prêt à être transmis aux utilisateurs. Cette phase consomme l'essentiel des ressources mobilisées. Mais l'architecture du système est stable, et les développeurs peuvent encore découvrir des moyens plus efficaces de structurer le système ou suggérer 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 décidé de mettre au point pour cette version. Celle-ci risque, toutefois, de présenter quelques anomalies. D'autres seront découvertes et résolues 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 période au cours de laquelle le produit passe en version bêta. Un petit groupe d'utilisateurs expérimentés essaient le produit en version bêta et rendent compte des anomalies et défauts constatés. Les développeurs corrigent ensuite les problèmes signalés et incorporent certaines des améliorations suggérées dans une version générale destinée à un public plus large. La phase de transition suppose des activités telles que la fabrication, la formation des utilisateurs clients, la mise en œuvre d'un service d'assistance et la correction des anomalies identifiées après la livraison. L'équipe de maintenance répartit généralement ces anomalies en deux catégories : celles ayant un impact suffisant sur le fonctionnement pour justifier la sortie immédiate d'une version delta et celles pouvant attendre la version suivante pour être corrigées.

1.6 Un processus intégré Le Processus unifié est basé sur les composants. I l utilise le nouveau standard de tnodéli sation visuelle UML (Unified Modeling Language) et repose sur trois notions maîtresses : les cas d'utilisation, l'architecture et le développement itératif et incrémental. Pour mettre en pratique ces idées, i l faut recourir à un processus multi-facettes prenant en considération les cycles, les phases, les enchaînements d'activités, la réduction des risques, le contrôle qualité, la gestion de projet et la gestion de configuration. Le Processus unifié a mis en place un cadre général (framework) intégrant chacune de ces facettes. I l fonctionne comme une sorte de parapluie sous lequel éditeurs et développeurs peuvent créer des outils assurant l'automatisation du processus et les enchaînements d'activités 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

bâtir les différents modèles et d'intégrer les résultats du travail tout au long du cycle de vie et de l'élaboration des modèles.

i i-

L'objet de ce livre est de décrire le Processus unifié en insistant particulièrement sur les aspects d'ingénierie, les trois notions clés énumérées plus haut, la conception basée sur les composants et l'utilisation d'UML. Nous allons décrire les quatre phases et les différents enchaînements d'activités, mais nous n'aborderons que partiellement certaines questions telles que la planification du projet et des ressources, la réduction des risques, la gestion de configuration, la capture des métriques et le contrôle qualité. Enfin, nous ne traiterons que brièvement l'automatisation du processus.

2 Les quatre « P » du développement logiciel : personnes, projet, produit et processus L'objectif ultime de tout projet (Annexe C) logiciel est la livraison d'un produit façonné par les diverses personnes ayant œuvré à son développement. La contribution de ces personnes est guidée par un processus de développement logiciel, c'est-à-dire un modèle décrivant les étapes à suivre pour l'accomplissement du projet. Ce processus est, en général, automatisé par un ou plusieurs outils. Voir la figure 2.1.

r

Tout au long de cet ouvrage, nous emploierons les termes personnes, projet, produit, processus (Annexe C) et outils, que nous définissons de la façon suivante : • Personnes : les architectes, développeurs, testeurs avec la direction qui les soutient, ainsi que les utilisateurs, clients et autres intervenants sont les éléments moteurs de tout projet logiciel. Les « personnes » désignent de véritables êtres humains, par opposition au concept abstrait de travailleur, que nous présenterons plus loin. • Projet : élément d'organisation à travers lequel est géré le développement du logiciel. L'aboutissement d'un projet est le produit livré sous forme de version. • Produit : ensemble des artefacts créés au cours du cycle de vie du projet, tels que les modèles (Annexe A), le code source, les exécutables et la documentation.

r

!

H

• Processus : un processus d'ingénierie logicielle fournit une définition de l'ensemble des activités requises pour transformer en produit les besoins exprimés par les utilisateurs. Un processus offre un cadre générique (« template ») à la création de projets. • Outils : logiciels permettant d'automatiser les activités définies par le processus.


I

Figure 2.1 lês 4 x P » du développement logiciel.

Personnes

Processus Template

Projet

Participants

Automatisation

Résultat

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

|

QÏATÎTRÊFWÊ

significative, comme l'évaluation d'un risque particulier, le développement d'un soussystème (Annexe A) ou la réalisation d'une itération offrent cette possibilité. Une architecture rationnelle, dotée d'interfaces clairement définies (Annexe A ; voir également le chapitre 9) entre sous-systèmes et composants (Annexe A ; voir également le chapitre 10), autorise une telle répartition du travail. • Planification du projet : l'impression d'être confronté à un planning irréaliste est totalement démoralisante. Personne n'aime aller travailler en sachant pertinemment que, quels que soient les efforts fournis, i l sera impossible de produire les résultats attendus. Les techniques utilisées dans les phases de création et d'élaboration permettent aux développeurs de se faire une idée assez fidèle de ce que devra être le résultat final du projet, c'est-à-dire de ce que devra faire le produit. I l devient alors possible d'imaginer un plan de travail réaliste et d'éliminer le fameux « on n'y arrivera jamais ». • Clarté du projet : on apprécie, en général, 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 impliquée dans le projet.

Produit

• Sentiment d'accomplissement : un cycle de vie itératif assure de fréquents retours d'expérience qui, à leur tour, permettent des avancées. Cet échange constant se traduit par une accélération du rythme de travail et un sentiment d'accomplissement plus marqué.

2.1 Les personnes jouent un rôle crucial Diverses personnes sont impliquées dans le développement d'un produit logiciel tout au long de son cycle de vie. Certaines financent le produit, tandis que d'autres le planifient, le développent, le gèrent, le testent, l'utilisent ou en bénéficient. Le processus guidant le développement doit, par conséquent, être orienté vers les personnes, c'est-à-dire convenir parfaitement à ses utilisateurs.

2.1.1 Les processus de développement sur les personnes

ont un impact

La façon dont s'organise et se gère un projet logiciel affecte profondément 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 rôle important. • Faisabilité du projet : rares sont ceux qui aiment travailler sur des projets jugés infaisables. Personne n'est prêt à sombrer avec le navire. Comme nous l'avons vu au chapitre 1, une approche itérative du développement permet d'évaluer très tôt la faisabilité d'un projet. Les projets infaisables peuvent ainsi être rapidement abandonnés, ce qui évite une démoralisation générale. • Gestion des risques : de la même façon, le soupçon d'une analyse hasardeuse et d'une, réduction insuffisante des risques provoque un malaise. L'exploration des risques majeurs dès les phases initiales du projet permet d'atténuer ce problème. • Structure des équipes : le travail en petits groupes de six à huit personnes est indéniablement plus productif. Or, les processus qui attribuent à chaque groupe une tâche

2.1.2 Les rôles

changent

Les principales activités du développement logiciel étant exécutées par des personnes, il est nécessaire, pour améliorer leur efficacité, de se conformer à un processus de développement uniforme, soutenu par des outils et un langage de modélisation unifié (qui existe, aujourd'hui, avec UML) (Annexe C). Un tel processus autorise, non seulement, la fabrication de meilleurs logiciels en termes de délai de mise sur le marché, de qualité et de coûts, mais aussi la spécification d'exigences répondant plus fidèlement aux besoins des utilisateurs. Ce type de processus permet, en outre, de choisir l'architecture la plus propice à un développement respectueux des délais et des budgets alloués, et offre un autre avantage : celui de faciliter la construction de logiciels plus sophistiqués. Nous avons remarqué, dans le chapitre 1, que la complexité croissante du monde réel allait de pair avec l'exigence de systèmes logiciels de plus en plus complexes. Les processus métier et les logiciels les prenant en charge auront une durée de vie plus longue. Le monde réel ne cessant d'évoluer tout au long de ces cycles de vie, les systèmes logiciels doivent être conçus pour évoluer sur de longues périodes de temps. La compréhension et la prise en charge de ces processus métier plus complexes et leur implémentation sous forme de logiciels exigent la collaboration de nombreux développeurs. 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 développeurs de « travailler plus intelligemment », c'est-à-dire en limitant leurs efforts à ce qui crée une véritable valeur ajoutée pour le client. La modélisation 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 systèmes sur la durée. Enfin, l'achat ou la réutilisation d'un nombre maximal de logiciels s'inscrivent dans


I

cette même logique, mais sont conditionnés par une politique cohérente d'intégration de composants réutilisables avec les éléments nouvellement développés. Dans les prochaines années, la plupart des développeurs logiciels pourront se consacrer plus directement à leur mission et développer des logiciels plus complexes grâce à l'utilisation d'un processus automatisé et de composants réutilisables. L'avenir prévisible du développement logiciel accordera une place prépondérante aux personnes, car c'est bien dans le choix des collaborateurs que réside, enfinde compte, la clé du succès. Tout le problème est de leur permettre de donner le meilleur d'eux-mêmes et d'accomplir ce dont seuls les humains ont le secret : être créatifs, détecter de nouvelles opportunités, faire usage de leur faculté de jugement, communiquer avec les clients et les utilisateurs, et comprendre un monde en perpétuelle évolution.

Figure 2.2 tes travailleurs et les ressources qui les réalisent.

Travailleurs

Les quatre « P » du d é v e l o p p e m e n t logiciel CHAPITRE

o f~f

o £ J

Compte : Ingénieur de composants

Retirer de l'argent : Spécificateur de cas d'utilisation

2

Retirer de i'argent : Testeur d'intégration

G • Charles

Ressources

2.1.3 Des « ressources » aux « travailleurs » Il existe différentes fonctions au sein d'une organisation développant du logiciel. Vous devez, pour préparer vos collaborateurs à occuper ces fonctions, non seulement user de pédagogie et leur dispenser les formations adéquates, mais aussi faire preuve de discernement dans l'attribution des tâches et leur assurer un encadrement efficace et rassurant. Le passage du statut de « ressource » latente à celui de « travailleur » représente un défi pour tout service de développement informatique. Nous avons retenu le terme de « travailleur » (Annexe C) pour désigner les fonctions attribuées aux membres d'une équipe et que ceux-ci acceptent d'assumer [4], Le type de travailleur renvoie au rôle que joue un individu particulier dans le développement du logiciel, comme spécificateur de cas d'utilisation, architecte, ingénieur de composants ou testeur d'intégration. Nous n'utilisons pas le terme rôle (à la place de travailleur) pour deux raisons essentielles : d'abord, parce que ce terme a une signification précise différente dans UML, ensuite, parce que le concept de travailleur doit être très concret. I l est important de réfléchir aux fonctions occupées par chacun en termes de travailleurs individuels. Nous avons également besoin du terme « rôle » pour désigner les rôles que remplit chaque travailleur. Un travailleur peut ainsi jouer plusieurs rôles vis-à-vis des autres travailleurs dans les différents enchaînements d'activités. Par exemple, le travailleur ingénieur de composants pourra prendre part à différents enchaînements d'activités dans lesquels il jouera à chaque fois un rôle spécifique. Chaque travailleur (c'est-à-dire chaque instance de « travailleur ») a la responsabilité d'un ensemble d'activités, comme les activités impliquées par la conception d'un sous-système. Pour être efficaces, les travailleurs ont besoin des informations nécessaires à la réalisation de ces activités. Ils doivent comprendre la nature de leur rôle par rapport à celui des autres travailleurs, mais aussi disposer des outils appropriés. Les outils doivent, non seulement, les assister dans la réalisation de leurs tâches, mais aussi les préserver de toute information non pertinente. Pour atteindre ces objectifs, le Processus unifié décrit formellement les fonctions (c'est-à-dire les « travailleurs ») pouvant être assumées au cours du processus de développement.

Marie

La figure 2.2 illustre de quelle façon une personne peut incarner plusieurs travailleurs dans un projet. Un travailleur peut également être représenté par différentes personnes travaillant en collaboration. Par exemple, un travailleur « architecte » pourra désigner tout un service d'architecture. Chaque travailleur se voit confier un éventail de responsabilités et doit effectuer un ensemble d'activités dans le développement du logiciel. Pour affecter les ressources aux travailleurs, le chef de projet doit identifier les compétences de chacun et les croiser avec les compétences requises pour les travailleurs, ce qui n'est pas une mince affaire, surtout lors d'une première utilisation du Processus unifié. Les compétences des ressources (c'est-à-dire des personnes réelles) doivent correspondre aux compétences requises par les différents travailleurs pour la réalisation du projet. Si certaines de ces compétences peuvent être acquises par le biais de formations adaptées, d'autres doivent tout à l'expérience. C'est le cas, par exemple, des compétences nécessaires à l'élaboration des cas d'utilisation, par opposition à celles d'un architecte qui sont forcément le fruit d'une longue pratique. Une personne peut incarner plusieurs travailleurs au cours d'un projet : par exemple, Marie pourra débuter le projet comme rédactrice de cas d'utilisation et devenir, plus tard, ingénieur de composants. Lors de la répartition des ressources, le chef de projet doit veiller à limiter autant que possible les échanges d'artefacts d'une ressource à l'autre de façon à fluidifier au maximum le processus. Par exemple, l'ingénieur du cas d'utilisation Retirer de l'argent (Annexe A ; voir également le chapitre 7) va accumuler un grand nombre d'informations sur les responsabilités de la classe Compte (Annexe A). I l paraît donc logique qu'il soit aussi l'ingénieur de composants de la classe Compte. Une autre solution consisterait à former une autre personne à cette tâche, mais les déperditions d'informations, les risques de malentendu et autres méprises en compromettraient l'efficacité.


I

2.2 Tel projet, tel produit Un projet de développement débouche sur une nouvelle version d'un produit. Le premier projet du cycle de vie (c'est-à-dire le premier cycle de développement, parfois appelé « projet tout neuf ») permet de mettre au point et de livrer le système, ou produit, initial. Les cycles de projet successifs prolongent la vie du système sur plusieurs versions. Pour une présentation plus détaillée 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 itérations et du contexte dans lequel est mené le projet : • Une séquence de changements : si les projets de développement de systèmes aboutissent à la livraison de produits, le chemin qui y mène est ponctué d'une série de changements. A mesure qu'avancent les phases et les itérations, les travailleurs doivent bien garder à l'esprit ce fait établi de la vie du projet. Chaque cycle, chaque phase et, oui, chaque itération transforme le système d'un état à un autre. Le premier cycle du développement est un cas particulier, puisqu'il fait passer le système du néant à un état concret. Chaque cycle conduit à une version et, au-delà d'une séquence de cycles, l'évolution se poursuit sur plusieurs générations. • Une série d'itérations : les travailleurs effectuent les activités liées à chaque phase d'un cycle par une série d'itérations. Chaque itération met en œuvre un ensemble de cas d'utilisation ou contribue à la réduction de certains risques, et se décompose elle-même en une série d'enchaînements d'activités : besoins, conception, implémentation et tests. Le fait que les itérations accomplissent chacun de ces enchaînements d'activités nous permet de les envisager comme des mini-projets. • Un cadre pour l'organisation : tout projet implique la présence d'une équipe dont la mission est de produire un résultat dans le respect de certaines contraintes professionnelles de délais, de budgets et de qualité. Ces personnes sont employées sur le projet en tant que travailleurs. Le concept de « processus » offre un cadre humain pour la réalisation du projet. Ce cadre (ou « template ») indique les types de travailleurs nécessités par le projet et les artefacts à utiliser. Le processus fournit également tout un arsenal de principes et de conseils, de méthodes heuristiques et de pratiques présentés sous forme de documentation qui accompagnent dans leur tâche les différents 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 système logiciel. Le terme produit, tel qu'il est employé dans ces pages, ne renvoie pas seulement au code livré, mais au système dans son entier.

2.3.1 Qu'est-ce qu'un système


2

logiciel ?

Un système logiciel se résume-t-il au code machine et aux exécutables ? 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 système 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 réponse pourrait être jugée satisfaisante. On peut poursuivre ce petit jeu de questions-réponses sur la conception d'un système logiciel en termes de sous-systèmes, de classes, de diagrammes d'interaction (Annexe A), de diagrammes d'états-transitions (Annexe A) et d'autres artefacts. Constituent-ils le système ? 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 système ? Oui, ils font également partie du système. Un système se compose de tous les artefacts nécessaires à sa représentation 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, développeurs, testeurs, personnes du marketing, administrateurs et autres. Enfin, les « intervenants » représentent les personnes finançant le projet, les utilisateurs, les commerciaux, les chefs de projet, les responsables hiérarchiques, les équipes de production, les agences de réglementation, etc. Dans cet ouvrage, nous utiliserons le terme travailleur pour désigner ces catégories de façon collective, sauf mention contraire explicite.

2.3.2 Les artefacts « Artefact » (Annexe C) est un terme général désignant toute sorte d'information créée, produite, modifiée ou utilisée par les travailleurs dans la mise au point du système. 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 procédures de test (voir chapitre 11). Il existe principalement deux types d'artefacts : les artefacts d'ingénierie et les artefacts de gestion. Cet ouvrage s'attache essentiellement aux artefacts d'ingénierie créés lors des différentes phases du processus (c'est-à-dire les phases d'expression des besoins, d'analyse, de conception, d'implémentation et de tests). Le développement de logiciels nécessite, toutefois, l'utilisation d'artefacts de gestion. Certains de ces artefacts ont une durée de vie assez brève, puisqu'ils ne survivent pas au projet lui-même. C'est le cas de l'étude de rentabilité, du plan de développement (qui comprend les plans de versions et d'itérations), du plan d'affectation des personnes aux différents travailleurs (c'est-à-dire aux diverses fonctions ou responsabilités du projet) et de l'organisation des activités des travailleurs au sein de ce plan. Ces artefacts sont décrits sous forme de texte ou de diagrammes, à l'aide d'un quelconque mode de visualisation, nécessaire pour clarifier l'engagement de l'équipe du projet vis-à-vis de ses acteurs financiers. Les artefacts de gestion comprennent également les spécifications de l'environnement de développement :


I

les logiciels d'automatisation des processus, mais aussi la plate-forme matérielle indispensable aux développeurs et servant de référentiel pour les artefacts d'ingénierie.

2.3.3 Un système

dispose de plusieurs

modèles

Le type d'artefact le plus pertinent utilisé par le Processus unifié est le modèle. Chaque travailleur a besoin d'un point de vue unique sur le système (voir la figure 2.3). Lors de la conception du Processus unifié, nous avons identifié tous les travailleurs intervenant dans un projet et les différentes perspectives susceptibles de leur être utiles. Les points de vue ainsi réunis sont structurés en entités de niveau supérieur, c'est-à-dire en modèles, de telle sorte qu'un travailleur puisse retrouver n'importe quel point de vue à partir de l'ensemble des modèles. Figure 2.3

Travailleurs participant au

Utilisateurs

développement logiciel. (Certains simi des

travailleurs ftngletons ; d'autres sont imilii types et

Figure 2.4 Ensemble principal de modèles du Processus unifié .


Modèle d'analyse


Modèle de conception


Modèle d'implémentation

2

Modèle des tests

1

1. En termes UML, ces « paquetages » représentent les « unités métier » ou « unités de travail » dans le Processus unifié et non des éléments de modèle permettant de modéliser un système particulier. Voir également l'explicationfigurantdans l'encadré de la section 7.1.

2.3.4 Qu'est-ce qu'un modèle ? Un modèle est une abstraction d'un système, décrivant le système modélisé d'un certain point de vue et à un certain niveau d'abstraction [1]. Le «point de vue» peut être, par exemple, celui de la spécification ou de la conception du système. Ces abstractions du système sont élaborées par les architectes et les développeurs. Par exemple, les travailleurs chargés de modéliser les exigences fonctionnelles pensent le système comme ayant des utilisateurs en dehors du système lui-même et des cas d'utilisation en son sein. Ils ne se soucient pas de l'apparence extérieure du système, mais uniquement de ce qu'il peut faire pour ses utilisateurs. En revanche, les travailleurs élaborant la conception réfléchissent aux éléments structurels, tels que les sous-systèmes et les classes. Ils s'attachent au fonctionnement de ces éléments abstraits dans un contexte donné et à leur collaboration pour la production de cas d'utilisation, et en donnent une interprétation particulière.

inuiii objets).

2.3.5 Chaque modèle Concepteurs

Analystes

La fabrication d'un système procède donc de la construction de modèles généraux à partir de différents modèles décrivant tous les points de vue possibles sur le système. La sélection des modèles d'un système est, en ce sens, l'une des décisions stratégiques que doit prendre l'équipe de développement. Le chapitre 1 nous a permis de présenter les modèles fondamentaux du Processus unifié (voir la figure 2.4). Le Processus unifié fournit un ensemble de modèles soigneusement choisis pour le démarrage d'un projet, qui mettent en lumière le système pour tous les travailleurs, y compris les clients, utilisateurs et chefs de projet. Ces différents modèles ont été sélectionnés avec l'objectif de satisfaire au besoin d'informations de tous ces travailleurs.

est une vue autonome du

système

Un modèle est une abstraction sémantiquement fermée du système. C'est une vue autonome, en ceci que l'utilisateur d'un modèle n'a besoin d'aucune autre information (en provenance, par exemple, d'autres modèles) pour l'interpréter. L'idée d'autonomie signifie que les développeurs ne conçoivent leurs modèles que comme une interprétation unique de ce qui se produira dans le système lorsque sera déclenché un événement décrit par le modèle. Outre le système en question, un modèle doit décrire les interactions entre le système et son environnement. I l doit donc contenir, en plus du système en cours de modélisation, les éléments pertinents de son environnement, c'est-à-dire ses acteurs (Annexe A ; voir également chapitre 7). La plupart des modèles d'ingénierie sont définis par un sous-ensemble soigneusement sélectionné du langage UML. Par exemple, le modèle des cas d'utilisation se compose des cas d'utilisation et des acteurs. C'est fondamentalement tout ce qui permet de le comprendre. Le modèle de conception décrit les sous-systèmes et les classes du système et la façon dont ils interagissent pour réaliser les cas d'utilisation. L'un et l'autre de ces modèles livrent deux interprétations différentes, quoique cohérentes, des réactions du système face à des stimuli extérieurs émis par les acteurs. Ces interprétations divergent du simple fait qu'elles sont destinées à être utilisées par des travailleurs ayant des tâches et des missions différentes. Le modèle des cas d'utilisation présente une vue externe du système, contrairement au modèle de conception qui en offre une vision interne. De même, le modèle des cas d'utilisation saisit les usages du système, alors que le modèle de conception en représente la construction.

tfli

Le Processus unifié de développement logiciel

/ «\

Les quatre « P » du développement logiciel

pj

PARTIE I

2.3.6 Exploration d'un modèle Un modèle identifie toujours le système en cours de modélisation. Cet élément du système contient, par conséquent, d'autres éléments. Le sous-système de plus haut niveau (Annexe B) représente le système en cours de fabrication. Dans le modèle des cas d'utilisation, le système se compose de cas d'utilisation, tandis qu'il regroupe des sous-systèmes, interfaces et classes dans le modèle de conception. Il contient également des collaborations (Annexe A) identifiant tous les sous-systèmes ou classes participants, sans se limiter à ceuxci puisqu'on peut y trouver des diagrammes d'états-transitions ou des diagrammes d'interaction. Dans le modèle de conception, chaque sous-système peut, à son tour, englober des constructions de même type, ce qui implique une hiérarchisation des éléments figurant dans ce modèle. 2.3.7 Relations entre modèles Un système contient toutes les relations (Annexe A) et contraintes existant entre les éléments contenus dans différents modèles [1]. Il ne se résume donc pas à la simple juxtaposition de ses modèles, mais comprend également les relations qui les unissent. Par exemple, chaque cas d'utilisation du modèle des cas d'utilisation entretient une relation avec une collaboration du modèle d'analyse (et vice-versa). UML nomme ce type de relation dépendance de traçabilité, ou tout simplement trace (Annexe A). Consultez la figure 2.5, dans laquelle sont indiquées les traces dans une seule direction. Il existe aussi des traces entre, par exemple, les collaborations du modèle de conception et celles du modèle d'analyse, ou entre les composants du modèle d'implémentation et les sous-systèmes du modèle de conception. On peut ainsi utiliser les traces pour relier les éléments d'un modèle à ceux d'un autre modèle. Figure 2.5 sont

• itoiit-ment uni •

/,Il

liés les

aux autres , t ' A

mations ae

par

C—I Modèle des cas d'utilisation a

irnçubilité.

4hn N

dépendances de traçabilité avec d e s

— I —I Modèle d'analyse

N

a des dépendances de traçabilité avec

— I —I Modèle de conception

4B N

— f —1 Modèle d'implémentation

a des dépendances de traçabilité avec

Le fait que les éléments de deux modèles soient liés ne modifie en rien leur rôle à l'intérieur de leur propre modèle. Les relations de traçabilité entre éléments de différents modèles n'ajoutent aucune information sémantique permettant de mieux comprendre les modèles eux-mêmes. Elles ne font que relier les modèles les uns aux autres. La capacité de remonter d'un modèle à un autre est fondamentale dans le développement logiciel pour favoriser, entre autres, la clarté et la propagation des modifications.

2.4 Le processus dirige les projets Le terme processus souffre d'un usage excessif. On le rencontre dans bien des contextes différents (processus métier, processus de développement, processus logiciel, entre autres) sous des acceptions diverses. Dans le contexte du Processus unifié, il fait référence au principal processus « métier » de toute société de développement 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 société de développement logiciel, voir le [2]). On trouve également, 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ébute par une commande et aboutit à la livraison d'un produit. Toutefois, nous nous intéressons principalement, dans cet ouvrage, au processus de développement [3]. 2.4.1 Le processus : un cadre générique Dans le Processus unifié, le terme processus renvoie à l'idée de cadre (« template ») pouvant être réutilisé par la création d'instances de celui-ci. Il est comparable, dans le paradigme orienté objet, à un format de classe permettant de créer des objets. L'expression instance de processus est synonyme de projet. Dans cet ouvrage, un processus de développement logiciel définit les activités nécessaires à la transformation des besoins des utilisateurs en un ensemble cohérent d'artefacts constituant un produit logiciel et, plus tard, à la transformation des évolutions de ces besoins en un nouvel ensemble d'artefacts tout aussi cohérent. Le terme besoin désigne les besoins exprimés par les utilisateurs et sera parfois remplacé par exigence. Au départ, il n'est pas nécessaire de comprendre ces besoins dans leur intégralité. La saisie complète de ces besoins exigera, en général, une compréhension plus pointue de l'activité du client et du cadre de travail des utilisateurs. Ce processus aboutit à la production d'un ensemble cohérent d'artefacts, véritable référence représentant un système d'applications ou une famille de tels systèmes comprenant un produit logiciel. Un processus est donc la définition d'un ensemble d'activités, et non l'exécution de ces activités. Enfin, le processus ne couvre pas seulement le premier cycle du développement (la première version), mais les cycles ultérieurs les plus courants. Dans les versions suivantes, c'est une instance du processus qui prend en compte les modifications progressives des besoins et les répercute dans les artefacts. 2.4.2 Les relations entre activités constituent les enchaînement d'activités Nous décrivons un processus en termes d'enchaînements d'activités. Quelle est la source de ces enchaînements ? Ils ne résultent pas de la simple division du processus en un certain nombre de sous-processus en interaction. De même, nous n'utilisons pas les organigrammes classiques pour décrire la façon dont le processus se décompose en unités plus réduites. Ces diagrammes n'offrent pas une représentationfidèlede la structure des enchaînements d'activités.

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

logiciel

O O

Analyste système

Identifier les acteurs et les cas d'utilisation

Structurer le modèle des cas d'utilisation

La notation « en poisson » est le raccourci d'un

Définir l'ordre de priorité des cas d'utilisation

Détailler un cas d'utilisation

O

D

2

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

enchaînement d'activités.

Prenons, par exemple, l'enchaînement d'activités de l'expression des besoins. Celui-ci implique différents travailleurs : analyste système, architecte, spécificateur de cas d'utilisation et concepteur d'interface utilisateur, et, entre autres artefacts, le modèle des cas d'utilisation et les cas d'utilisation. On pourrait ajouter les ingénieurs de composants et les testeurs d'intégration, ainsi que des réalisations de cas d'utilisation (Annexe B ; voir aussi les chapitres 8 et 9), des classes, des sous-systèmes et des interfaces.

2.4.3 Spécialisation

O

O

Architecte


I

À la place, nous identifions dans un premier temps les différents types de travailleurs prenant part au processus. Puis, nous recensons les artefacts qu'il faudra créer au cours du processus pour chaque type de travailleur. Cette identification, bien sûr, n'est pas instantanée. Le Processus unifié capitalise sur une longue expérience pour la détection d'un ensemble réalisable d'artefacts et de travailleurs. Une fois cet ensemble identifié, nous pouvons décrire le flux du processus à travers les différents travailleurs et la façon dont ces derniers créent et produisent des artefacts ou utilisent ceux développés par les autres. La figure 2.6 montre un diagramme d'activités (Annexe A) décrivant l'enchaînement des activités de la modélisation des cas d'utilisation. Remarquez la présence de « travées » (Annexe A) : i l y en a une pour chaque travailleur. Le travail passe d'un travailleur à l'autre, chacun exécutant une ou plusieurs activités (symbolisées par des engrenages) de cet enchaînement. Figure 2.6 Enchaînement d'activités avec travailleurs et activités figurant dans des « travées ».

du

processus

Aucun processus de développement logiciel n'est universel ! Les processus varient parce qu'ils existent dans différents contextes, mettent au point différents types de systèmes et répondent à différents types de contraintes professionnelles (planification, coûts, qualité ou fiabilité, par exemple). C'est pourquoi, dans les faits, un processus de développement logiciel doit pouvoir être adapté et configuré afin de satisfaire aux besoins réels d'un projet ou d'une organisation en particulier. Le Processus unifié a été conçu pour être spécialisé (sur la conception d'un processus, voir [6]). I l s'agit, en effet, d'un processus générique, c'est-àdire d'un cadre général de processus. Chaque organisation utilisant le Processus unifié finira par le spécialiser pour l'adapter à sa propre situation (c'est-à-dire à son type d'application, de plate-forme, etc.) (sur la spécialisation d'un processus, voir [8]).

D Spécificateur de cas d'utilisation

Le Processus unifié peut donc être spécialisé pour convenir à différents besoins en termes d'application et d'entreprise. En même temps, i l est souhaitable que ce processus reste cohérent, tout au moins au sein d'une même entreprise. Cette cohérence permettra l'échange rapide de composants, de personnes et de responsables d'un projet à l'autre, et la comparaison des métriques évaluant le niveau de progression.

Prototyper l'interface utilisateur

Concepteur d'interface utilisateur

Il est alors facile d'identifier les activités que doivent exécuter ces travailleurs lorsque vient leur tour. Ces activités représentent un travail significatif pour une personne agissant comme travailleur. On peut, en outre, voir instantanément à partir de ces descriptions si une personne en particulier a besoin d'intervenir plus d'une fois dans l'enchaînement d'activités.

Plusieurs types de facteurs influent sur la modification du processus : • Les acteurs liés à l'organisation : structure de l'entreprise, culture interne, organisation el gestion des projets, compétences disponibles, expérience antérieure et systèmes logiciels existants.

L'ensemble du processus peut donc être décrit sous forme d'éléments appelés enchaînements d'activités (Annexe C). En termes UML, un enchaînement d'activités est le stéréotype (Annexe A) d'une collaboration à laquelle participent travailleurs et artefacts. I l est donc possible (et c'est généralement le cas) que les travailleurs et artefacts prenant part à un enchaînement d'activités soient impliqués dans d'autres enchaînements. Nous utiliserons, pour les enchaînements d'activités, la notation fournie dans la figure 2.7.

• Les facteurs liés au domaine : domaine d'application, processus métier à prendre en charge, communauté des utilisateurs et offres proposées par la concurrence. • Les facteurs liés au cycle de vie : délai de mise sur le marché, durée de vie prévue du logiciel, technologie et expertise mises en œuvre dans le développement du logiciel, plan de livraison des versions suivantes. • Les facteurs techniques : langage de programmation, outils de développement, base de données, frameworks et architectures « standard » sous-jacentes, communication et distribution.


I

Telles sont les causes. Mais quels sont leurs effets ? Vous pouvez, par exemple, décider de supprimer certains travailleurs et artefacts du Processus unifié pour refléter plus fidèlement l'organisation d'entreprises moins développées sur ce plan. Ou encore ajouter de nouveaux travailleurs et artefacts ne figurant pas encore dans le processus, pour en améliorer l'efficacité sur votre projet. I l n'est pas impossible, non plus, de remanier la description d'un artefact précis pour lui imposer une structure différente. Nous savons, pour en être régulièrement témoins, que les ingénieurs se conforment globalement à ce que suggère le Processus unifié sur les premiers projets, puis, l'expérience aidant, qu'ils se mettent à développer leurs propres extensions plus ou moins significatives. Quels sont les aspects de la conception même du Processus unifié qui en permettent la spécialisation [6] ? La réponse est simple, bien qu'elle exige quelque effort de compréhension. Le produit Objectory a, lui-même, été conçu à l'aide d'éléments qui sont, en réalité, 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 métier (c'est-à-dire des travailleurs et des artefacts) et peuvent être spécialisées ou échangées contre d'autres sans aucune modification de la conception du processus. Vous verrez, dans les chapitres suivants, que nous employons, pour la description des enchaînements d'activités, des objets : les travailleurs et les artefacts.

2.4.4 Les mérites

d'un

processus

L'utilisation d'un processus commun aux diverses équipes de développement procure de nombreux avantages : • Chaque membre de l'équipe de développement comprend quel est son rôle dans le développement du produit. • Les développeurs appréhendent mieux l'activité des autres développeurs, à des stades antérieurs ou postérieurs du même projet, sur des projets différents au sein de la même entreprise, sur des sites dispersés, ou même sur des projets se déroulant dans d'autres entreprises. • Les dirigeants et responsables, même s'ils sont incapables de lire du code, comprennent ce que font les développeurs par le biais des graphiques d'architecture. • Les développeurs, 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 standardisée à l'échelle de l'entreprise et dispensée sous forme de cursus complets ou de cours accélérés. • Le déroulement du développement logiciel est reproductible, ce qui signifie qu'il peut être planifié et budgété avec suffisamment de précision pour éviter les mauvaises surprises. Malgré tous ces avantages, certains maintiennent qu'un processus commun ne résout pas les « problèmes vraiment délicats ». Ce à quoi nous répondons tout simplement : « bien sûr que non ». Seules les personnes sont en mesure de résoudre les problèmes. Mais un processus rigoureux favorise et améliore considérablement le travail d'équipe. Prenez, à titre de comparaison, la mise sur pied d'une opération militaire. Certes, la conduite d'une bataille se résume, en fin de compte, à l'action des individus sur le terrain, mais l'issue dépend aussi de l'efficacité de leur organisation.

Les quatre « P » du d é v e l o p p e m e n t logiciel • • cTÎÂpTrRE2wM

.5 Les outils font partie intégrante du processus Les processus actuels de développement 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 livrés ensemble, les outils faisant partie intégrante du processus [5], [7].

2.5.1 Les outils influent sur le processus Le processus est nettement influencé par l'existence d'outils adaptés. Ceux-ci se révèlent particulièrement efficaces pour automatiser les tâches répétitives, préserver la structure des éléments, gérer de grandes quantités d'informations et vous guider le long d'un chemin de développement spécifique. Moins i l y a d'outils, plus le processus dépend d'une charge de travail manuel, ce qui en compromet le formalisme. En pratique, l'essentiel du travail formel doit alors être reporté aux activités d'implémentation. L'absence d'outils automatisant le maintien de la cohérence à travers tout le cycle de vie rendrait difficile la coordination des modèles et de l'implémentation, et compliquerait le développement itératif et incrémental. Soit on parviendrait à des incohérences, 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 contrôles de cohérence devraient être effectués à la main, tâche titanesque, pour ne pas dire impossible. Non seulement les artefacts mis au point ne seraient pas exempts de défauts, mais cette procédure prendrait beaucoup plus de temps. Il existe des outils permettant d'automatiser les activités de façon plus ou moins complète, d'améliorer la productivité et la qualité, et de raccourcir les délais. L'utilisation d'outils modifie le processus et le formalise. De nouvelles activités, difficilement réalisables sans outils, peuvent ainsi être intégrées, et le travail gagne en précision tout au long du cycle de vie, puisqu'il devient possible d'utiliser un langage de modélisation formel tel qu'UML pour garantir la cohérence interne de chaque modèle et sa cohérence par rapport aux autres modèles. On peut aussi utiliser un modèle unique et générer, à partir de celui-ci, diverses parties d'un autre modèle (par exemple, de la conception à l'implémentation et vice-versa).

2.5.2 Le processus

conditionne les outils

Le processus, qu'il soit explicitement ou implicitement défini, spécifie les fonctionnalités des outils, c'est-à-dire les cas d'utilisation des outils. Le fait même de l'existence d'un « processus » suffit à légitimer 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 idée parfaitement claire des cas d'utilisation qui seront nécessaires à chaque travailleur et des artefacts qu'il aura à gérer. L'automatisation du processus fournit le moyen, d'une part, de faire travailler simultanément plusieurs personnes et, d'autre part, de vérifier la cohérence de tous les artefacts produits.


I

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 réfléchir à la façon dont est mené le développement logiciel. Quelle sera, par exemple, l'approche qu'adoptera un travailleur face à telle tâche ? Comment se rendra-t-il compte de l'aide que peut lui procurer l'outil ? Quelles seront les tâches récurrentes et, partant, qu'il sera utile d'automatiser ? À l'inverse, quelles seront les tâches peu fréquentes, qui ne justifieront pas d'être automatisées par un outil ? De quelle façon un outil peut-il amener un travailleur à consacrer du temps aux tâches importantes qu'il est seul capable d'exécuter et à laisser à l'outil le soin d'effectuer les tâches répétitives dans lesquelles celuici montre toute son efficacité ? Pour répondre à 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 véritable bond de la productivité. Plusieurs raisons spécifiques plaident pour l'objectif de la simplicité d'utilisation. Les travailleurs doivent pouvoir essayer plusieurs solutions et comprendre aisément la conception d'entre elles. Si la solution essayée se révèle impraticable, i l faut qu'ils puissent passer directement à une autre approche. Les outils doivent aider à réutiliser autant d'éléments que possible, pour éviter de repartir de zéro à chaque nouvelle approche. En somme, i l est fondamental non seulement que les outils prennent en charge l'automatisation des tâches répétitives et la gestion des informations représentées par les différents modèles et artefacts, mais également qu'ils favorisent et accompagnent les activités créatives qui constituent le cœur de tout développement significatif.

2.5.3 Equilibre entre processus

et outils

Développer un processus sans s'interroger sur la façon dont il sera automatisé reste, par conséquent, une pure vue de l'esprit. À l'inverse, la mise au point d'outils sans connaissance préalable 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 côté, le processus déclenche le développement d'outils. De l'autre, les outils guident le processus de développement. La mise au point du processus et le développement 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 refléter cet équilibre. La réalisation d'un équilibre proche de l'idéal nécessitera plusieurs itérations, qui se nourriront régulièrement des retours d'expérience des utilisateurs. Cette relation entre processus et outil ressortit, elle aussi, au problème de l'œuf et de la poule. Lequel des deux préexiste à l'autre ? Dans les dernières décennies, c'est souvent l'outil qui venait en premier, le processus n'étant alors pas clairement défini. Du coup, les outils ne donnaient pas les résultats escomptés lorsque les utilisateurs les appliquaient à des processus de type « tout ou rien ». Constat qui a souvent ébranlé notre foi dans les outils. Le développement 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-mêmes prendre en charge un processus soigneusement pensé.


2

B

de développement 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 réaliste de prétendre développer le système informatique d'une banque sans comprendre la nature même des processus qui en régissent l'activité.

2.5.4 La modélisation

visuelle au service d'UML

Nous venons de démontrer 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 modélisation pour UML. UML est un langage visuel. En tant que tel, l'outil est censé présenter certaines caractéristiques 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 caractéristiques, U M L définit des règles syntaxiques spécifiant le mode d'utilisation simultanée des éléments du langage. L'outil doit donc garantir le respect de ces règles, ce qui dépasse les possibilités de la plupart des outillages de dessin, qui n'assurent pas ce genre de service. Malheureusement, l'application sans aucune exception de règles syntaxiques de ce type rendrait l'outil parfaitement inutilisable. En effet, le modèle en cours de modification présentera fréquemment des erreurs syntaxiques que l'outil devra temporairement autoriser. I l faudra, par exemple, que soit admise la présence d'un message dans un diagramme de séquence (Annexe A ; voir aussi le chapitre 9), alors même qu'aucune opération n'aura été définie pour la classe. UML comprend un certain nombre de règles sémantiques qui doivent également être prises en compte. Ces règles peuvent être intégrées à l'outil de modélisation, soit par le biais d'une application immédiate, soit sous forme de routines appelées à la demande et parcourant le modèle pour détecter les erreurs courantes ou rechercher les inexactitudes sémantiques ou syntaxiques. En somme, l'outil de modélisation doit aller au-delà de la simple prise en charge d'UML pour favoriser la créativité du développeur 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 modélisation. Cette ouverture s'explique par l'acuité de la définition d'UML, mais tient aussi au fait qu'UML est désormais un standard industriel largement utilisé. Au lieu de se résumer à une concurrence acharnée entre éditeurs d'outils pour la prise en charge de l'éventail le plus large possible de langages de modélisation, le jeu consiste désormais à déterminer qui assure la meilleure prise en charge d'UML. Cette nouvelle règle du jeu ne peut que bénéficier aux utilisateurs et consommateurs de logiciels. UML n'est qu'un langage de modélisation. I l ne définit pas le processus d'utilisation d'UML pour le développement de systèmes logiciels. L'outil n'a donc pas à appliquer un processus, mais si l'utilisateur en utilise un, il peut le prendre en charge.

Nous voulons affirmer avec conviction qu'une automatisation réussie du processus (à l'aide d'outils) n'est envisageable que si l'on mène, en parallèle, le développement du framework


I

Les quatre « P » du d é v e l o p p e m e n t logiciel i

M u

I

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, réviser les divers besoins ou exigences d'un projet logiciel, d'en assurer la traçabilité et la navigabilité. I l arrive que soit précisé 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 modélisation visuelle permettent d'automatiser l'utilisation d'UML, c'est-àdire de modéliser et d'assembler visuellement une application. Ils assurent, en outre, l'intégration dans des environnements de programmation et garantissent le maintien de la cohérence entre modèle et implémentation.

6 7

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.

GRADY BOOCH, Object Solutions: Managing the Object-Oriented MA: Addison-Wesley, 1996.

9

IVAR JACOBSON and STEN JACOBSON, "Building your own methodology by specializing a methodology framework," Object Magazine, November-December 1995.

8

Project, Reading,

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

• Les outils de programmation fournissent une large gamme d'outils, notamment des éditeurs, compilateurs, débogueurs, détecteurs d'erreurs et analyseurs de performances. • Les outils de contrôle qualité permettent de tester les applications et les composants, c'est-à-dire d'enregistrer et d'exécuter les cas de test guidant les tests d'une I H M et de l'interface d'un composant. Dans un cycle de vie itératif, les tests de non-régression sont encore plus stratégiques que dans le développement 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 résistance au stress et aux lourdes charges. Comment l'architecture de cette application se comportera-t-elle face à 10 000 utilisateurs simultanés ? I l n'est pas inutile de connaître la réponse à cette question avant de procéder au déploiement de l'application sur le 10 OOOème poste utilisateur. Outre ces outils dédiés à 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 détection des défauts, de documentation, de gestion de projet et d'automatisation du processus.

2.6 R é f é r e n c e s OMG Unified Modeling Language Spécification. 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 intégral support environment," Object Magazine, January 1995.

3 Un processus piloté par les cas d'utilisation L'objectif du Processus unifié est de guider les développeurs vers l'implémentation et le déploiement efficaces de systèmes répondant aux besoins des clients. Cette efficacité se mesure en termes de coût, de qualité et de délai de fabrication. Le passage de l'estimation des besoins du client à leur implémentation est loin d'être naturel. D'abord, parce que les besoins du client ne se laissent pas si facilement appréhender. I l faut disposer d'un moyen qui permette de les communiquer de façon claire à toute personne impliquée dans le projet. Il faut, ensuite, être en mesure de concevoir une implémentation opérationnelle répondant à ces besoins. I l faut, enfin, vérifier la pleine satisfaction de ces besoins en testant le système. En raison de sa complexité, le système est décrit sous forme d'enchaînements d'activités qui donnent peu à peu naissance à un système opérationnel. Comme nous l'avons indiqué au chapitre 1, le Processus unifié est piloté par les cas d'utilisation, centré sur l'architecture, itératif et incrémental. Nous allons l'examiner, dans ce chapitre, sous l'angle des cas d'utilisation, point de vue présenté dans [1] et approfondi dans [2]. L'importance décisive de l'architecture et les aspects itératif et incrémental feront respectivement l'objet des chapitres 4 et 5. Nous espérons, grâce à cette séparation des différents thèmes, simplifier la notion de développement piloté par les cas d'utilisation. C'est dans ce même esprit que nous ne faisons que survoler la préparation du modèle de déploiement, la conception de sous-systèmes à forte intégrité, le développement de composants d'implémentation appropriés (voir la section 10.3.2) et la réalisation 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 développement ; elles ne seront donc approfondies que dans la troisième partie de l'ouvrage. La figure 3.1 illustre la série d'enchaînements d'activités et de modèles du Processus unifié. Les développeurs commencent par saisir les besoins des clients sous forme de cas d'utilisation dans le modèle du même nom. Puis, ils analysent et conçoivent le système répondant à ces cas d'utilisation, et créent ainsi un modèle d'analyse, suivi d'un modèle de conception


I

et d'un modèle de déploiement. Vient ensuite l'implémentation du système dans un modèle d'implémentation qui comprend tout le code, c'est-à-dire les composants. Enfin, les développeurs élaborent un modèle des tests permettant de vérifier que le système offre les fonctionnalités décrites dans les cas d'utilisation. Tous les modèles sont liés les uns aux autres par des dépendances de traçabilité. Le modèle d'implémentation 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'exécutables, tandis que le modèle de cas d'utilisation, le moins formel de tous, est principalement exprimé en langage naturel. Figure 3.1 Le Processus unifié se compose d'une série d'enchaînements d'activités allant des besoins aux tests (à gauche, de haut en bas). Les enchaînements d'activités développent des modèles, du modèle des cas d'utilisation au modèle des lests.


Analyse • Modèle d'analyse

Conception Modèle de conception

Implémentation •

Modèle de développement


Modèle des tests

Si les cas d'utilisation se sont largement imposés pour la « capture » des besoins des systèmes logiciels en général, et pour les systèmes à base de composants en particulier [6], ils représentent davantage qu'un simple outil de saisie des besoins : ils orientent tout le processus de développement. Ces artefacts se révèlent un instrument inestimable pour l'identification et la spécification des classes, des sous-systèmes, des interfaces (Annexe A) et des cas de test, ainsi que pour la planification des itérations du développement et de l'intégration du système (voir le chapitre 10). Pour chaque itération, ils guident le déroulement des enchaînements d'activités, depuis l'expression des besoins jusqu'aux tests en passant par l'analyse, la conception et l'implémentation, et assurent la cohésion des différents enchaînements.

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

3

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 véritables besoins (voir le chapitre 6) et les exprimer de façon adaptée pour les utilisateurs, les clients et les développeurs. Par « véritables besoins », nous entendons les besoins qui, une fois implémentés, apporteront aux utilisateurs les avantages attendus. « Les exprimer de façon adaptée pour les utilisateurs, les clients et les développeurs » signifie que la description des besoins doit être compréhensible par les utilisateurs et les clients. C'est l'un des enjeux majeurs de cet enchaînement d'activités. Un système s'adresse en principe à différents types d'utilisateurs, chacun étant identifié en tant qu'acteur. Les acteurs utilisent le système selon les interactions décrites par les cas d'utilisation. Un cas d'utilisation est une séquence d'actions qu'effectue le système afin de produire des résultats satisfaisants pour l'acteur. L'ensemble des acteurs et des cas d'utilisation constituent le modèle des cas d'utilisation [3], [4]. / Les étapes-d'analyse et de conception transforment le modèle des cas d'utilisation d'abord en.un modèle d'analyse, puis en un modèle de conception. Disons, pour être bref, que le modëîë'3'analyse et le modèle de conception sont, l'un et l'autre, des structures composées de classificateurs (Annexe A) et d'un ensemble de réalisations (voir les chapitres 8 et 9) décrivant de quelle façon cette structure réalise les cas d'utilisation. Les classificateurs sont, enjjénéral, des éléments « assimilés,à.des classes ». Ils possèdent, notamment, des attributs et des opérations (Annexe A), et peuvent être décrits à l'aide de diagrammes d'états-transitions (Annexe A). Certains peuvent être instanciés, prendre part à des collaborations, etc. UML comprend différents types de classificateurs. Les sous-systèmes, classes et interfaces sont des exemples de classificateurs dans cette structure. Les acteurs, cas d'utilisation, composants et nœuds (Annexe A ; voir également la section 9.3.7) en sont d'autres. Le modèle d'analyse fournit une spécification détaillée des besoins et tient lieu de première ébauche du modèle de conception, tout en étant un modèle à part entière. I l permet une meilleure compréhension des cas d'utilisation décrits dans l'enchaînement d'activités des besoins en les précisant sous forme de collaborations entre classificateurs conceptuels (par opposition aux classificateurs de conception qui seront implémentés par la suite). Le modèle d'analyse sert également à la création d'un système réactif et robuste, doté d'une architecture et faisant une réutilisation massive de composants. I l se distingue du modèle de conception en ce qu'il est davantage un modèle conceptuel qu'un plan d'élaboration de l'implémentation. Il peut être transitoire et ne pas survivre aux deux ou trois premières itérations. Dans certains cas, toutefois, notamment pour les systèmes complexes d'envergure, le modèle d'analyse pourra être conservé et actualisé pendant toute la durée du système. Il existe, alors, une relation transparente (par le biais des dépendances de traçabilité) entre la réalisation d'un cas d'utilisation dans le modèle d'analyse et la réalisation correspondante dans le modèle de conception. Chaque élément du modèle d'analyse peut être retrouvé à partir de l'élément du modèle de conception le réalisant. (Le modèle d'analyse, son but et ses relations avec le modèle de conception sont abordés en détail dans les sections 8.1 à 8.3.)


I

Le modèle de conception présente les caractéristiques suivantes : • Bien que hiérarchique, i l contient des relations transcendant cette hiérarchie. Il s'agit des relations habituelles en U M L : associations, généralisations et dépendances (Annexe A). • Les réalisations de cas d'utilisation sont des stéréotypes de collaboration. Une collaboration exprime la participation et le rôle des classificateurs dans l'accomplissement d'une tâche utile, telle que la réalisation d'un cas d'utilisation. • Le modèle de conception est également un plan d'élaboration de l'implémentation. Une correspondance directe relie les sous-systèmes du modèle de conception aux composants du modèle d'implémentation. Le modèle d'analyse est créé à partir du modèle des cas d'utilisation [5]. Chaque cas d'utilisation du modèle des cas d'utilisation trouvera sa réalisation dans le modèle d'analyse. Le dualisme cas d'utilisation/réalisation assure une traçabilité parfaite entre la formulation des besoins et l'analyse. L'étude des cas d'utilisation l'un après l'autre permet de dégager les classes prenant part à leur réalisation. Par exemple, le cas d'utilisation Retirer de l'argent peut être réalisé par les classes d'analyse Retrait, Compte, Distributeur et quelques autres qu'il n'est pas nécessaire d'indiquer ici. Les développeurs attribuent des responsabilités (Annexe A) définies dans le cas d'utilisation en tant que responsabilités des classes. Dans notre exemple, la classe Compte assumerait des responsabilités telles que « retirer un montant du compte ». Cette méthode permet de faire apparaître un ensemble de classes qui, associées les unes aux autres, réaliseront les cas d'utilisation et rendront vraiment service aux utilisateurs. L'étape suivante consiste à concevoir les classes et les réalisations de cas d'utilisation de façon à exploiter au mieux les produits et les technologies (ORB, kits de construction d'IHM et systèmes de gestion de bases de données) permettant d'implémenter le système. Les classes de conception sont regroupées en sous-systèmes, entre lesquels peuvent être définies des interfaces. Les développeurs élaborent également le modèle de déploiement, qui leur permet de définir l'organisation physique du système sous forme de nœuds informatiques et de vérifier que les cas d'utilisation peuvent être implémentés en tant que composants s'exécutant sur ces nœuds. Ensuite, les développeurs implémentent les classes ainsi conçues en un ensemble de composants de fichiers (code source) dans le modèle d'implémentation, à partir duquel peuvent être produits (c'est-à-dire compilés et liés) les exécutables tels que les DLL, les JavaBeans ou les composants ActiveX. Les cas d'utilisation aident à déterminer l'ordre d'implémentation et d'intégration des composants. Enfin, les testeurs vérifient, au cours de l'enchaînement des activités de test, que le système met effectivement en œuvre les fonctionnalités décrites dans les cas d'utilisation et qu'il satisfait à la configuration exigée. Le modèle des test se compose des cas de test (et d'autres éléments qui seront abordés plus tard, au chapitre 11). Un cas de test définit un ensemble de données d'entrée, de conditions d'exécution et de résultats. Un grand nombre de ces cas de test peuvent être directement dérivés des cas d'utilisation. I l existe donc une dépendance de traçabilité entre le cas de test et le cas d'utilisation correspondant. Ce qui signifie que les testeurs vérifieront que le système fait bien ce que les utilisateurs attendent de lui, c'est-à-dire


3

WÊm

qu'il exécute les cas d'utilisation. Toute personne ayant testé un logiciel par le passé a, sans le savoir, testé des cas d'utilisation, même si cette activité n'était pas décrite dans les mêmes termes à l'époque [8]. La nouveauté, et la différence, c'est que le Processus unifié permet la planification des tests dans les premières phases du cycle de développement. Dès que les cas d'utilisation sont définis, i l est possible de spécifier les tests correspondants (tests « boîte noire ») et de déterminer l'ordre dans lequel ils seront réalisés, intégrés et testés. Les tests des cas d'utilisation pourront ensuite être détaillés (tests « boîte blanche »), à mesure qu'avancera la réalisation des cas d'utilisation pendant la conception. Chaque façon d'exécuter un cas d'utilisation, c'est-à-dire chaque chemin menant à la réalisation d'un cas d'utilisation, peut servir de cas de test (« cas de test candidat »). Nous avons, jusqu'à maintenant, présenté le Processus unifié comme une séquence d'étapes, très proche de l'ancienne approche en cascade. Notre unique souci était de rester aussi clair que possible. Nous verrons, au chapitre 5, une façon beaucoup plus intéressante de déployer ces diverses étapes selon une approche itérative et incrémentale. En fait, ce que nous avons décrit dans les pages précédentes correspond à une seule itération. Un projet de développement intégral se composera d'une série d'itérations, dont chacune (sauf peut-être la première) consistera à effectuer les enchaînements d'activités des phases de besoins, d'analyse, de conception, d'implémentation et de test. Examinons de plus près les avantages que présentent les cas d'utilisation avant d'aborder plus en détail les différents enchaînements d'activités.

3.2 Pourquoi les cas d'utilisation ? Plusieurs raisons expliquent l'intérêt et le succès des cas d'utilisation, dont l'usage s'est désormais imposé partout [6]. Nous retiendrons ici les deux principales raisons : \ Les cas d'utilisation offrent un moyen à la fois systématique et intuitif de saisir les besoins | fonctionnels (Annexe C ; voir également les chapitres 6 et 7) en insistant sur l'intérêt que doit en attendre l'utilisateur. • Ils orientent tout le processus de développement, puisque la plupart des activités telles que l'analyse, la conception et les tests sont effectuées à partir des cas d'utilisation. La conception et les tests peuvent, en effet, être planifiés et coordonnés en termes de cas d'utilisation. Cette caractéristique devient encore plus évidente lorsque l'architecture du projet s'est stabilisée, après la première série d'itérations.

3.2.1 Pour appréhender

les véritables

besoins

Selon Karl Wieger, « le point de vue qu'offrent les cas d'utilisation renforce l'objectif final du génie logiciel : créer 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 répondant aux objectifs des utilisateurs. Les cas d'utilisation représentent les fonctions que fournit un système pour rendre service à ses utilisateurs. I l devient possible, en se plaçant du point de vue de chaque type d'utilisateur, d'identifier les cas d'utilisation qui lui permettront de faire

M m


I

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

3

Wm

Les cas d'utilisation ne se bornent pas à lancer le processus de développement, ils en assurent aussi la cohésion, comme le montre la figure 3.2. (L'ellipse ombrée, à l'arrière-plan,

Les meilleurs cas d'utilisation sont ceux qui confèrent le plus de valeur ajoutée à l'entreprise à laquelle est destiné le système. Un cas d'utilisation apportant une valeur négative ou permettant à l'utilisateur d'accomplir une chose qui devrait lui être impossible ne peut être qualifié de cas d'utilisation. On parlerait plutôt de « cas d'abus », puisqu'il spécifie une utilisation du système 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 catégorie. Les cas d'utilisation qui ne présentent que peu ou pas du tout de valeur ajoutée seront moins souvent utilisés. Ce sont des « cas d'inutilité », totalement superflus.

cas d'utilisation. Les cas d'utilisation nous aident également à développer des interfaces qui simplifient les rapports qu'entretiennent les utilisateurs avec le système. Les réalisations des cas d'utilisation sont, par la suite, testées pour vérifier que les instances (Annexe A) des classes sont en mesure d'exécuter les cas d'utilisation [8].

son travail. Si, en revanche, on se met à envisager un ensemble de fonctions, sans réfléchir aux cas d'utilisation employés par les différents utilisateurs, i l sera difficile d'estimer la pertinence ou l'intérêt de ces fonctions. À qui sont-elles utiles ? A quels besoins métier répondent-elles ? Quels avantages procurent-elles à l'entreprise ?

Comme nous l'avons mentionné au chapitre 1, bien des gens estiment que le simple fait de se demander ce que doit faire le système ne suffit pas à obtenir les réponses adéquates. Ces personnes préfèrent disposer d'une liste de fonctions système qui, à première vue, peut sembler plus utile, mais qui, à y regarder de plus près, ne reflète pas nécessairement les besoins des utilisateurs. Si elle peut paraître insignifiante, la stratégie des cas d'utilisation qui consiste à reformuler la question en lui ajoutant trois mots (que voulez-vous que fasse le système pour chaque utilisateur ?) livre des résultats tout à fait différents. Cette méthode oblige à comprendre de quelle façon le système doit servir chacun de ses utilisateurs et guide les développeurs dans l'identification des fonctions qui leur sont nécessaires. Elle évite, également, de suggérer des fonctions superflues dont nul n'aura besoin. Autre avantage, les cas d'utilisation sont intuitifs. I l n'est pas nécessaire, pour les utilisateurs et les clients, d'apprendre à déchiffrer une notation complexe puisque les cas d'utilisation sont essentiellement formulés en français courant (c'est-à-dire en langage naturel), ce qui en simplifie la lecture et permet de suggérer des modifications. La formulation des besoins implique les utilisateurs, les clients et les développeurs. Et, en la matière, ce sont les utilisateurs et les clients qui sont les experts. Le rôle des développeurs consiste à favoriser leurs échanges et à les aider à exprimer leurs besoins. Le modèle des cas d'utilisation permet de s'accorder avec les utilisateurs et les clients sur les fonctions que doit remplir le système auprès de ses utilisateurs. On peut envisager le modèle des cas d'utilisation comme la spécification complète de tous les moyens possibles d'utiliser le système (les cas d'utilisation), et pouvant faire partie du contrat scellé avec le client. Ce modèle contribue à délimiter le système en définissant tout ce qu'il doit faire pour ses utilisateurs. Vous trouverez, dans [12], une approche intéressante de la structuration des cas d'utilisation, tandis que [11] fournit une bonne entrée en matière sur le sujet.

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 développement procède selon une série d'enchaînements d'activités initiés à partir des cas d'utilisation. Les classes se dégagent naturellement de la lecture des descriptions de cas d'utilisation, lorsque les développeurs cherchent les classes susceptibles de réaliser les

1

symbolise la façon dont les cas d'utilisation créent ce lien). Figure 3.2 Les cas d'utilisation lient les uns aux autres les principaux enchaînements d'activités.

Besoins

Analyse

L

jjljl

Conception

1

i

l

! 1 plémentation

Tests

1

Il faut également s'assurer que l'on saisit les « bons » cas d'utilisation, afin de fournir aux utilisateurs ceux dont ils ont réellement besoin. Le meilleur moyen de traiter ce problème est, évidemment, de travailler avec rigueur dans la phase de formulation des besoins. Mais ce n'est généralement pas suffisant. Un système en cours d'exécution permet de compléter la validation des cas d'utilisation par rapport aux besoins réels des utilisateurs. Les cas d'utilisation aident les chefs de projet à planifier, affecter et surveiller la plupart des tâches effectuées par les développeurs. Pour chaque cas d'utilisation, le chef de projet identifiera un certain nombre de tâches. La spécification de chaque cas d'utilisation représente, en soi, une tâche particulière. Tout comme la conception et les tests de chacun de ces cas d'utilisation. Le chef de projet peut même estimer le travail et les délais nécessaires à la réalisation de ces diverses tâches. Les tâches identifiées à partir des cas d'utilisation facilitent l'estimation de la taille du projet et des ressources nécessaires, et peuvent être attribuées à des développeurs particuliers, qui en seront responsables. Le chef de projet peut ainsi confier à une première personne la responsabilité de spécifier cinq cas d'utilisation pendant la formulation des besoins, à une deuxième personne la charge de concevoir trois cas d'utilisation et à une troisième la tâche de spécifier les cas de test pour deux cas d'utilisation. Les cas d'utilisation constituent un mécanisme essentiel de traçabilité entre modèles. Il est possible de suivre l'évolution d'un cas d'utilisation de la phase de besoins à sa réalisation dans l'analyse et la conception, à travers les classes qui participent à sa réalisation, (indirectement) à travers les composants et, enfin, à travers les cas de test qui en assurent la vérification. Cette traçabilité est un aspect fondamental de la gestion de projet. Lorsqu'un cas d'utilisation est modifié, i l faut vérifier les réalisations, classes, composants et cas de test qui lui correspondent, et ainsi de suite (voir [10]). La traçabilité entre les cas d'utilisation et les autres éléments des modèles permet de préserver la cohérence du système et de l'actualiser dans son ensemble en fonction de l'évolution des besoins. 1. Il s'agit là d'une simplification. En réalité, il est probable que chaque cas d'utilisation nécessite l'intervention de classes (sous-systèmes, etc.) déjà développées. Il faudra donc modifier les cas d'utilisation pour les adapter à ces briques de base existante. Cette question est abordée dans la section 4.3.


I

3.2.3 Pour mettre au point l'architecture et plus encore... Les cas d'utilisation favorisent la mise en œuvre d'un développement itératif. Chaque itération, à l'exception peut-être de la toute première du projet, est pilotée par les cas d'utilisation à travers tous les enchaînements d'activités, des besoins à la conception et aux tests, et donne lieu à un incrément (Annexe C). Chaque incrément de développement est ainsi la réalisation opérationnelle d'un ensemble de cas d'utilisation. En d'autres termes, un certain nombre de cas d'utilisation sont identifiés et implémentés à chaque itération.

:

Les cas d'utilisation aident également à la conception de l'architecture. La sélection d'un ensemble approprié de cas d'utilisation (c'est-à-dire ceux qui sont pertinents sur le plan architectural) à réaliser au cours des premières itérations permet l'implémentation d'un système ayant une architecture stable et qui servira de socle aux cycles de développement suivants. Nous reviendrons sur ce sujet au chapitre 4.

»

: ;

Les cas d'utilisation constituent, par ailleurs, un excellent point de départ pour la rédaction du manuel d'utilisation et la description des interactions entre l'utilisateur et le système, puisque chacun d'eux décrit une façon d'utiliser le système. linlin, il est possible, en estimant la fréquence d'exécution de certains chemins des cas d'utilisation, de déterminer quels sont ceux qui exigent les meilleures performances. De telles estimations permettent, à leur tour, de prévoir la capacité des processeurs du matériel sousjacent ou encore d'optimiser le schéma de base de données pour certaines utilisations. Elles peuvent également servir à améliorer l'utilisabilité, c'est-à-dire à sélectionner les chemins auxquels se consacrer en priorité lors de la conception de l'interface utilisateur.

3.3 « Capture » des cas d'utilisation Nous allons maintenant examiner le déroulement du travail au sein des différents enchaînements d'activités. Nous nous attacherons essentiellement, comme nous l'avons indiqué précédemment, à l'aspect « piloté par les cas d'utilisation ». La section suivante ne s'intéressera qu'à l'expression des besoins fonctionnels sous forme de cas d'utilisation, même lorsque d'autres types de besoins devront également être recensés. Durant cet enchaînement, nous identifions les exigences des utilisateurs et des clients en tant que besoins. Les besoins fonctionnels sont exprimés sous forme de cas d'utilisation regroupés dans un modèle du même nom, tandis que les autres besoins peuvent être « joints » aux cas d'utilisation concernés, figurer dans une liste à part ou encore être décrits d'une autre façon.

3.3.1 Le modèle des cas d'utilisation les besoins fonctionnels

représente


3

WÊm

forme le modèle des cas d'utilisation [2], [3]. Un diagramme de cas d'utilisation (Annexe A ; voir également la section 7.4.1) décrit une partie du modèle 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

Modèle de cas d'utilisation du système de DAB L'acteur Client de la banque utilise le système de DAB pour effectuer des retraits et des dépôts sur des comptes et pour virer de l'argent d'un compte à un autre. Ces actions sont représentées par les trois cas d'utilisation de la figure 3.3, qui indique les interactions par le biais d'associations vers l'acteur.

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

Retirer de l'argent

Déposer de l'argent

Effectuer des virements entre comptes

3.3.2 Les acteurs constituent l'environnement du

système

Les acteurs ne représentent pas forcément tous des êtres humains. Il peut s'agir d'autres systèmes ou de matériel externe destinés à dialoguer avec le système. Chaque acteur endosse un ensemble cohérent de rôles lors de ses interactions avec le système. Un utilisateur physique peut agir en tant qu'un ou plusieurs acteurs et jouer le rôle de ces différents acteurs dans leurs interactions avec le système, tandis que plusieurs utilisateurs peuvent agir en tant qu'occurrences diverses d'un même acteur. Des milliers de personnes pourront, par exemple, se comporter en acteur Client de la banque. Les acteurs communiquent avec le système par le biais de messages (Annexe A) échangés pendant le déroulement des cas d'utilisation. La définition du comportement des acteurs et de celui du système crée une séparation nette entre les responsabilités des acteurs et celles du système, séparation qui contribue à la délimitation de la portée du système. Il suffit, pour identifier et spécifier tous les acteurs, d'examiner quels sont, d'une part, les personnes qui utiliseront le système et, d'autre part, les autres systèmes qui devront dialoguer avec lui. Chaque catégorie de ces utilisateurs ou systèmes est ensuite représentée sous la forme d'un acteur.

Le modèle des cas d'utilisation aide le client, les utilisateurs et les développeurs à s'accorder sur l'utilisation du système. Un système s'adresse en général à plusieurs types d'utilisateurs, chacun étant représenté en tant qu'acteur. Les acteurs utilisent le système comme ils dialoguent avec les cas d'utilisation. L'ensemble des acteurs et des cas d'utilisation d'un système

H


I

3.3.3 Les cas d'utilisation spécifient

le

système

Les cas d'utilisation sont façonnés pour répondre aux besoins des utilisateurs dans leur utilisation du système. Le modèle des cas d'utilisation saisit tous les besoins fonctionnels du système. Voici notre définition précise d'un cas d'utilisation : Un cas d'utilisation spécifie une séquence d'actions, avec ses variantes, effectuée par le système et produisant un résultat satisfaisant pour un acteur

pouvant être particulier.

Le meilleur moyen d'identifier les cas d'utilisation est d'observer la façon dont les utilisateurs ont besoin du système pour faire ce qu'ils ont à faire (pour découvrir un moyen de structurer les cas d'utilisation à partir des objectifs, consultez [10]). Chaque type d'utilisation du système apportant un avantage à l'utilisateur est potentiellement un cas d'utilisation (« cas d'utilisation candidat »). Ces cas d'utilisation potentiels seront ensuite améliorés, modifiés, scindés en plusieurs cas d'utilisation plus limités, ou intégrés à d'autres cas d'utilisation plus complets. On peut considérer le modèle des cas d'utilisation comme pratiquement terminé lorsque tous les besoins fonctionnels ont été correctement identifiés sous une forme compréhensible pour le client, les utilisateurs et les développeurs. La séquence d'actions effectuée par un cas d'utilisation au cours de son déroulement (c'est-àdire une instance de cas d'utilisation) constitue un chemin spécifique de ce cas d'utilisation. Un grand nombre de chemins sont possibles, dont beaucoup sont presque identiques ; chacun représente une variante dans l'exécution de la séquence d'actions spécifiée par le cas d'utilisation. Pour accroître la lisibilité d'un modèle de cas d'utilisation, i l convient de regrouper au sein d'un même 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 véritablement l'identification et la description des divers chemins pouvant être réunis en un seul et même cas d'utilisation. BUfflH

Cas d'utilisation Retirer de l'argent Voici la séquence d'actions (très simplifiée) 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 spécifie le montant du retrait. 3. Le système déduit le montant du compte et délivre l'argent.

Les cas d'utilisation servent également d'« emplacement réservé » pour les besoins non fonctionnels (Annexe C ; voir également le chapitre 6), tels que les exigences de performances, de disponibilité, de précision et de sécurité, spécifiques à un cas d'utilisation. Par exemple, l'exigence suivante peut être associée au cas d'utilisation Reti rer de l'argent : le temps de réponse à un Client de la banque, entre la sélection du montant à retirer et la délivrance a^sJ)HJets „dojt~^ secondes dans 95% des cas. J

Pour être clair, tous les besoinsloTn^ônhéls sont délimités sous forme de cas d'utilisation, auxquels peuvent être associés une grande partie des besoins non fonctionnels. En fin de compte, le modèle des cas d'utilisation permet de présenter les besoins en un format simple à gérer. I l est parfaitement compréhensible aux clients et utilisateurs qui peuvent s'en servir pour communiquer leurs besoins de façon cohérente et sans redondances. Les développeurs,


3

de leur côté, peuvent se répartir la tâche de saisir les besoins, puis utiliser les résultats (essentiellement les cas d'utilisation) comme données d'entrée pour l'analyse, la conception, l'implémentation et les tests du système.

3.4 L'analyse, la conception et l'implémentation pour la réalisation des cas d'utilisation L'analyse et la conception conduisent à la transformation du modèle des cas d'utilisation en un modèle d'analyse, puis de conception, c'est-à-dire en une structure de classificateurs et de réalisations de cas d'utilisation. Le but est de rentabiliser la réalisation des cas d'utilisation, afin que le système offre des performances appropriées 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 réalisation des cas d'utilisation. Dans les chapitres 4 et 5, nous verrons en quoi l'architecture et le développement itératif et incrémental contribuent à la mise au point d'un système rentable, capable de répondre à l'évolution des besoins.

3.4.1 Création

du modèle

d'analyse à partir des cas d'utilisation

Le modèle d'analyse s'enrichit de l'analyse d'un nombre croissant de cas d'utilisation. On sélectionne, pour chaque itération, un ensemble de cas d'utilisation à réaliser dans le modèle d'analyse. Le système est élaboré comme une structure de classificateurs (classes d'analyse) et de relations entre ces classificateurs. On décrit également les collaborations réalisant les cas d'utilisation, c'est-à-dire les réalisations de cas d'utilisation. Puis on choisit, dans l'itération suivante, un autre groupe de cas d'utilisation à réaliser, qui viennent s'ajouter à ceux de l'itération précédente. Les sections 5.3 et 12.6 expliquent comment identifier et sélectionner les groupes les plus « importants » de cas d'utilisation pour les premières itérations, et bâtir ainsi une architecture stable dès le début du cycle de vie du système. Une méthode pratique consiste à identifier et décrire les cas d'utilisation d'une itération dans un premier temps, puis à lire intégralement la description de chaque cas d'utilisation (comme l'illustre la section 3.3.3) et à suggérer les classificateurs et associations nécessaires à sa réalisation. Opération qui se répète en un effort coordonné pour tous les cas d'utilisation d'une itération. Selon le stade du cycle de vie auquel on se trouve et le type d'itération en cours, i l est possible qu'une architecture soit déjà en place et guide l'identification de nouveaux classificateurs et la réutilisation de classificateurs existants (voir la section 4.3). Chaque classificateur joue un ou plusieurs rôles dans la réalisation d'un cas d'utilisation, rôles qui spécifient les responsabilités, attributs, etc., dont doit disposer le classificateur pour prendre part à cette réalisation. Ces rôles peuvent être envisagés comme des « embryons » de classificateurs. En fait, en UML, un rôle est également un classificateur en lui-même. On peut, par exemple, se représenter le rôle d'une classe comme une vue de cette classe. Cette vue comprend, par conséquent, tout le contenu de la classe, c'est-à-dire ses responsabilités, attributs, etc., mais uniquement ceux qui présentent un intérêt pour son rôle dans la réalisation d'un cas d'utilisation. Le rôle d'une classe peut également être décrit 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

logiciel

I

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

reste de la classe une fois qu'a été appliqué un filtre éliminant tous les rôles de cette classe n'ayant pas de responsabilités partagées. Le concept de rôle n'est décrit que brièvement ici et, pour des raisons de clarté, ne sera pas développé dans la 2 partie qui aborde en détail tous les classificateurs. è m e

li'jj.'JJU

Exemple : La réalisation d'un cas d'utilisation dans le modèle d'analyse La figure 3.4 indique de quelle façon le cas d'utilisation est réalisé par une collaboration (c'est-à-dire une réalisation de cas d'utilisation), l'un et l'autre étant reliés par une dépendance de « traçabilité » (la traçabilité est un stéréotype de dépendance signalée par des guillemets à la française), et fait apparaître que quatre classes prennent part à cette réalisation en y jouant un rôle. Comme on peut le voir sur cette figure, la réalisation d'un cas d'utilisation, ou collaboration, est représentée par une ellipse en pointillés.

Figure 3.4


( 'lasses d'analyse participant à la réalisation du cas • l'utilisation Retirer de l'argent. 1rs classes

M o d è l e d'analyse i traçabilité >

Retirer de l'argent

Retirer de l'argent

Participant

i Hstributeur et Interface guichet \<>ni des classes

O

frontières, la classe Retrait est une . lasse de contrôle et la classe Compte est une classe entité.

Distributeur

O

Ô Q

Interface guichet

Compte

On commence généralement par examiner quelques cas d'utilisation, à en créer la réalisation et à identifier les rôles des classificateurs. Puis, on renouvelle le processus pour d'autres cas d'utilisation et l'on suggère de nouveaux rôles de classificateurs. Certains de ces rôles plus tardifs peuvent être spécifiés en tant que rôles inédits ou modifiés de classificateurs existants, ou exiger la création 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 modèle d'analyse stable. Chaque classificateur peut ainsi participer et jouer des rôles dans plusieurs réalisations de cas d'utilisation.

3

Stéréotypes d'analyse Le modèle d'analyse utilise trois types de stéréotypes pour les classes : les « classes frontières », les « classes de contrôle » et les « classes entités ». Les classes Distributeur et interface guichet sont des classes frontières, qui servent en général à modéliser les interactions entre le système et ses acteurs (c'est-à-dire les utilisateurs et les systèmes externes). La classe Retrait est une classe de contrôle qui permet en principe de représenter la coordination, le séquencement, les transactions et le contrôle d'autres objets. On emploie également ce type de classe pour encapsuler le contrôle lié à un cas d'utilisation spécifique (ici, le cas d'utilisation Retirer de l'argent). La classe Compte est une classe entité, normalement utilisée pour modéliser les informations durables et souvent persistantes. Chacun de ces trois stéréotypes de classe encapsule, par conséquent, différents types de comportement (ou fonctionnalité, si vous préférez) et contribue à l'élaboration d'un système robuste, qui sera détaillée au chapitre 8. Ces stéréotypes favorisent aussi l'identification d'éléments réutilisables, puisque les classes entités sont génériques pour un grand nombre de cas d'utilisation et, donc, d'applications différentes. La répartition des classes d'analyse selon ces trois catégories (abordée plus en détail dans [2]) est pratiquée depuis de nombreuses années, maintenant. Son usage s'est larirgement répandu et a été adopté par UML [12].

nHHHHHHIBHHI

mm

Une classe participant à plusieurs réalisations de cas d'utilisation dans le modèle d'analyse Le côté gauche de la figure 3.5 montre un ensemble de cas d'utilisation pour un système de DAB (le même que celui de la figure 3.3), tandis que le côté droit dévoile la structure du système correspondante, c'est-à-dire, dans ce cas, les classes d'analyse réalisant les cas d'utilisation. La structure du système est modélisée dans un diagramme de classes (Annexe A). Si l'on utilise généralement des diagrammes de classes pour représenter les classes et leur relations, ceux-ci peuvent également montrer des sous-systèmes 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 différents pour indiquer les réalisations de cas d'utilisation auxquelles prend part une classe et dans lesquelles elle joue un rôle. (Les classes interface guichet et Compte prennent part et jouent des rôles dans les trois réalisations d'utilisation.

Les autres classes ne participent

tion, c'est-à-dire Figure 3.5 Le diagramme montre la réalisation 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 réalisation du cas d'utilisation Retirer de l'argent.

qu'elles ne jouent qu'un seul

qu'à la réalisation

de cas

d'un seul cas

d'utilisa-

rôle.)

Modèle d'analyse


Retirer d e l'argent

Effectuer d e s virements entre comptes

D é p o s e r d e l'argent


I

• Il a fallu, pour tracer le diagramme de classes du système DAB (figure 3.5), lire les descriptions des trois cas d'utilisation, puis examiner les différents moyens de les réaliser. On aurait pu procéder de la sorte : • La réalisation des trois cas d'utilisation, Retirer de l'argent, Effectuer des virements entre comptes et Déposer de l'argent, implique la classe frontière Interface guichet etla classe entité Compte. Le déroulement 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 contrôle 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 délivrer un montant et à l'objet Compte de débiter le compte.


3

Figure 3.6 Diagramme de collaboration pour la réalisation du cas d'utilisation Retirer de l'argent dans le modèle d'analyse.

: Retrait

• L'objet Vi rement demande aux deux objets Compte impliqués dans la réalisation du cas d'utilisation Effectuer des virements entre comptes d'actualiser leur solde.

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 opérations fournies par les classes de conception correspondantes (comme nous le verrons dans la section 3.4.3).

Jusqu'à présent, nous avons tenté de définir une structure de système stable pour l'itération en cours. Nous avons identifié les responsabilités des classificateurs participants et déterminé les relations les unissant les uns aux autres. Mais nous n'avons toujours pas identifié en détail l'interaction qui doit avoir lieu lors de la réalisation du cas d'utilisation. Nous avons la structure ; i l nous faut maintenant lui imposer les différentes modalités d'interaction nécessaires à la réalisation de chaque cas d'utilisation.

Le diagramme montre le déplacement du point de vue d'objet en objet, à mesure que s'exécute le cas d'utilisation et que sont échangés les messages entre objets. L'envoi d'un message depuis un objet fait passer l'objet récepteur au premier plan et l'amène à assumer l'une des responsabilités de sa classe.

• L'objet Dépôt accepte l'argent par l'intermédiaire du Récepteur d'espèces et demande à l'objet Compte d'augmenter son solde.

Comme nous l'avons indiqué précédemment, chaque cas d'utilisation fait l'objet d'une réalisation, disposant elle-même d'un ensemble de classificateurs participants, qui jouent différents rôles. La compréhension des modèles d'interaction signifie que l'on décrit de quelle façon est effectuée ou exécutée (ou encore instanciée) la réalisation 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 exécute un cas d'utilisation Retirer de l'argent. Nous savons que les classes Interface guichet, Retrait, Distributeur et Compte participeront à la réalisation de ce cas d'utilisation. Nous savons également quelles seront leurs responsabilités. En revanche, nous ne savons toujours pas comment ces classes (ou, plus exactement, comment les objets de ces classes) vont dialoguer pour exécuter la réalisation du cas d'utilisation. C'est maintenant ce qu'il faut déterminer. On utilise principalement des diagrammes de collaboration (Annexe A) pour modéliser les interactions entre objets au cours de l'analyse. (UML fournit aussi des diagrammes de séquence, 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) plutôt que les classes et les associations. Ce type de diagramme signale les interactions séquentielles ou parallèles des objets en numérotant les messages échangés. Bgjfl

Le diagramme de collaboration peut également être complété par du texte expliquant de quelle façon les objets dialoguent pour exécuter le flot d'événements du cas d'utilisation. Il existe d'autres moyens de décrire une réalisation de cas d'utilisation, comme l'emploi de texte structuré ou de pseudo-code.

Efflfl

Description du flot d'événements de la réalisation d'un cas d'utilisation Nous allons maintenant décrire la réalisation 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 spécifie le montant du retrait et le compte à débiter (1). L'Interface guichet vérifie l'identité du Client de la banqueetdemandeàun 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 spécifiée. L'objet Rc t r a i t confirme en demandant à l'objet Compte de valider la requête et, si celle-ci est correcte, de débiter le compte (3).

Utilisation d'un diagramme de collaboration pour décrire la réalisation d'un cas d'utilisation dans le modèle d'analyse

L'objet Retrait autorise ensuite le Di stri buteur à délivrer le montant demandé par le Client de la banque (4). Enfin, le Client de la banque reçoit le montant demandé (5).

Dans la figure 3.6, nous utilisons un diagramme de collaboration pour décrire la façon dont la réalisation du cas d'utilisation Retirer de l'argent est exécutée par une société d'objets d'analyse.

Remarquez que cet exemple simple ne montre qu'un chemin de réalisation 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.

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

À ce stade, nous aurons analysé chaque cas d'utilisation et identifié ainsi tous les rôles des classes participant à la réalisation de chaque cas d'utilisation. Nous allons maintenant aborder la façon d'analyser chaque classe.

3.4.2 Chaque classe doit assumer tous ses rôles de collaboration

Figure 3.7 Réalisation d'un cas d'utilisation dans différents modèles.

Les responsabilités d'une classe sont une simple compilation de tous les rôles qu'elle joue dans toutes les réalisations de cas d'utilisation. Le regroupement de ces rôles et la suppression des éventuels chevauchements permet de dégager une spécification de toutes les responsabilités et de tous les attributs de la classe. Les développeurs chargés d'analyser et de réaliser les cas d'utilisation doivent également spécifier les rôles des classes. Chaque développeur responsable d'une classe recense tous les rôles de celle-ci au sein d'un ensemble complet de responsabilités de la classe, puis les intègre à un ensemble cohérent de responsabilités. Les développeurs chargés d'analyser les cas d'utilisation doivent s'assurer que les classes réalisent correctement les cas d'utilisation. Si une classe change, le développeur qui en est responsable doit vérifier que celle-ci peut toujours remplir ses rôles dans les réalisations de cas d'utilisation. Si c'est un rôle qui évolue, le développeur du cas d'utilisation doit en informer le développeur de la classe. Les rôles aident ainsi les développeurs de classes, comme les développeurs de cas d'utilisation, à préserver l'intégrité de l'analyse.

3.4.3 Création du modèle d'analyse

de conception à partir du

modèle

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


M o d è l e d'analyse

traçabilité » o Retirer de l'argent

Retirer de l'argent

3

M o d è l e de conception

•< traçabilité ».-"•"», Retirer de l'argent

Les réalisations de cas d'utilisation dans les différents modèles obéissent à 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 réalisation du cas d'utilisation Reti rer de l'argent dans le modèle d'analyse. Mais une fois conçues, elles spécifient et donnent toutes lieu à des classes de conception plus sophistiquées, adaptées à l'environnement d'implémentation, comme l'illustre la figure 3.8. Figure 3.8 Classes de conception du modèle de conception remontant vers des classes d'analyse du modèle d'analyse.

Modèle d'analyse Interface

Distributeur

ô

Û

Retrait

A /S

A


Compte

A. A A

n traçabilité »

Chargeur d u distributeur

Le modèle de conception est d'abord créé à partir du modèle d'analyse, avant d'être adapté à l'environnement d'implémentation choisi, comme un ORB, un kit de construction d'IHM ou un système de gestion de base de données. Ce modèle peut également être modifié de façon a réutiliser des systèmes existants (Annexe C) ou d'autres cadres généraux développés pour le projet. Le modèle d'analyse constitue donc une première ébauche du modèle de conception, qui servira lui-même de plan d'élaboration à l'implémentation.

Lecteur de carte

Classe persistante

Gestionnaire de clients

Guichet espèces

Gestionnaire de comptes

Gestionnaire de transactions

Par exemple, la classe d'analyse Interface guichet est conçue par quatre classes de conception : Écran, Clavier, Lecteur de carte et Gestionnaire de cl ients (qui est une classe active et entourée, à ce titre, d'une bordure épaisse ; voir l'Annexe A).

A l'instar du modèle d'analyse, le modèle de conception définit des classificateurs (classes, sous-systèmes et interfaces), des relations entre ces classificateurs et des collaborations réalisant les cas d'utilisation (c'est-à-dire les réalisations de cas d'utilisation). Toutefois, les éléments définis dans le modèle de conception sont les « équivalents en conception » des éléments plus conceptuels spécifiés dans le modèle d'analyse, en ce sens que les premiers (les éléments de conception) sont adaptés à l'environnement d'implémentation, contrairement aux seconds. En d'autres termes, le modèle de conception est plus « physique » par nature, tandis que le modèle d'analyse est plus « conceptuel ».

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, spécifiques à une application et conçues pour prendre en charge une ou plusieurs applications. La structure du système définie par le modèle d'analyse est donc naturellement préservée pendant la conception, bien que quelques compromis puissent se révéler nécessaires (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) représentent des processus organisant le travail des autres classes (non actives), une fois le système distribué (nous reviendrons sur cette question dans la section 4.5.3).

Il est possible de remonter jusqu'à la réalisation d'un cas d'utilisation dans le modèle d'analyse à partir de la réalisation correspondante dans le modèle de conception. EXEMPLE

Réalisations de cas d'utilisation dans les modèles d'analyse et de conception La figure 3.7 décrit la réalisation du cas d'utilisation Retirer de 1 ' a rgent à la fois dans le modèle d'analyse et dans le modèle de conception.

Ira

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

En conséquence, la réalisation du cas d'utilisation Retirer de l'argent dans le modèle de conception doit décrire la façon dont est réalisé le cas d'utilisation en termes de classes de conception correspondantes. La figure 3.9 illustre un diagramme de classes faisant partie de la réalisation du cas d'utilisation. i i(|iin' :i.9

Compte

a alisatton du cas

Classe persistante

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

Figure 3.10 Diagramme de séquence faisant partie d'une réalisation du cas d'utilisation Retirer de l'argent dans le modèle de conception.


Insérer la carte

: Écran


Gestionnaire

3

: Gestionnaire de transactions

Carte insérée (ID) Demander le code secret

Montrer la requête Spécifier le code secret Code secret (PIN)

Exiger la validation du code secret (PIN)

Demander le montant à retirer Montrer la requête Préciser le montant

Montant (M)

Exiger la disponibilité du montant (M) Exiger le retrait du montant (M)

d'utilisation dans i.h/ui-lle elle joue des Mes.

Il est clair que ce diagramme de classes introduit, par rapport au diagramme du modèle d'analyse (figure 3.5), un niveau supérieur de détail, nécessaire à l'adaptation du modèle de conception à l'environnement d'implémentation. Comme dans l'analyse (figure 3.6), il faut identifier en détail l'interaction entre objets de conception se produisant lors de la réalisation du cas d'utilisation dans le modèle de conception. On utilise principalement des diagrammes de séquence pour modéliser les interactions entre objets de conception, comme le montre la figure 3.10. Le diagramme de séquence montre le déplacement du point de vue d'objet en objet, depuis le coin supérieur gauche, au fur et à mesure de l'exécution du cas d'utilisation et des échanges de messages entre objets. L'envoi d'un message depuis un objet fait passer l'objet récepteur au premier plan et l'amène à assumer l'une des responsabilités de sa classe. Vous pouvez vous livrer à un exercice intéressant, qui consiste à comparer ce diagramme de séquence à 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 conçus par tous les messages du diagramme de séquence de la figure 3.10, ce qui donne une idée de la complexité et du niveau de détail introduit dans le modèle de conception par rapport au modèle d'analyse.

L'exemple choisi le montre bien : le modèle de conception est susceptible de contenir de nombreuses classes. I l faut donc trouver le moyen de les hiérarchiser. Les sous-systèmes, que nous abordons dans la section ci-dessous, offrent cette possibilité.

3.4.4 Les sous-systèmes

regroupent les classes

Prenons le cas d'un système contenant plusieurs centaines ou milliers de classes. Sans un niveau de regroupement supérieur, le système serait impossible à appréhender. Les classes sont donc réparties en sous-systèmes, qui permettent le regroupement sémantique de classes et d'autres sous-systèmes. Chaque sous-système fournit et utilise lui-même un ensemble d'interfaces, qui en définissent le contexte (acteurs, autres sous-systèmes et classes). Les sous-systèmes de bas niveau sont appelés sous-systèmes de service (Annexe B ; voir également le chapitre 9), car les classes qu'ils contiennent rendent un service (pour une description plus précise du concept de service, consultez la section 8.4.5.1). Les sous-systèmes de service constituent une unité gérable de fonctionnalités facultatives (ou potentiellement facultatives), et ne doivent pouvoir être installés dans un système client que dans leur intégralité. Ils permettent également de modéliser des groupes de classes ayant tendance à changer en même temps. Les sous-systèmes peuvent être déterminés en procédant de bas en haut ou de haut en bas. Dans le premier cas, les développeurs suggèrent les sous-systèmes à partir des classes déjà identifiées ; ils proposent alors des sous-systèmes qui regroupent les classes en unités de fonctions clairement définies. S'ils choisissent, en revanche, de procéder de haut en bas, c'est l'architecte qui détermine les sous-systèmes de haut niveau et leurs interfaces, avant même qu'aucune des classes n'ait été identifiée. Les développeurs sont ensuite chargés de travailler sur des sous-systèmes particuliers pour trouver et concevoir les classes qu'ils contiendront. Les sous-systèmes ont été présentés au chapitre 1 et seront abordés plus en détail dans les chapitres 4 et 9.

j r y ^ H

1

° 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


Les sous-systèmes regroupent les classes Les développeurs répartissent les classes dans les trois sous-systèmes que montre la figure 3.11. Ces sous-systèmes ont été choisis de façon à regrouper toutes les classes en fonction de leur rôle : celles fournissant l'interface utilisateur sont placées dans un premier sous-système, celles concernant les comptes dans un deuxième, et celles spécifiques à l'application dans un troisième. L'intérêt de placer toutes les classes de l'interface utilisateur dans le sous-système I nterf ace du DAB est que ce sous-système peut ensuite être remplacé par un autre offrant au sous-système Gestion des transactions les mêmes fonctionnalités. Un autre sous-système Interface du DAB pourra avoir une implémentation très différente de l'interface utilisateur, destinée, par exemple, à recevoir et à délivrer des pièces plutôt que des billets. Les classes spécifiques à l'application, telles que la classe Retrait, placées dans le soussystème Gesti on de transactions se retrouvent toutes dans un sous-système de service différent. Chacun de ces sous-systèmes de service détiendrait en réalité plusieurs classes, qu'il n'est pas utile de faire figurer dans cet exemple simple. La figure 3.11 montre également les interfaces entre les sous-systèmes. Un cercle représente une interface. La ligne continue reliant une classe à une interface indique que la classe fournit l'interface. La présence d'une flèche en pointillés 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 utilisées par l'acteur ; nous optons, ici, pour des associations ordinaires. Figure 3.11 lYot3 sous-systèmes , / un sous-système de service (en grisé dans le sous\ Gestion ,/
« sous-système »

Interface du DAB

; sous-système •

Gestion des transactions

3.4.5 Création du modèle de conception


* sous-système de service » Gestion des comptes

Classe persistante


d'implémentation

à partir du

3

modèle

Au cours de l'enchaînement d'activités de l'implémentation, sont développés tous les éléments exécutables nécessaires à la production d'un système exécutable : les composants, les composants fichiers (code source, shell scripts, etc.), les composants tables (éléments de base de données), et ainsi de suite. Un composant est une partie physique et remplaçablc d'un système, conforme à la réalisation d'un ensemble d'interfaces qu'elle doit fournir. Le modèle d'implémentation intègre les composants, qui comprennent tous les exécutables (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 modèle d'implémentation La figure 3.12 montre les composants qui implémentent les classes de conception à partir du modèle de conception (tel qu'il est présenté dans la section 3.4.3)

Figure 3.12 Composants implémentant classes de conception.



les

< exécutable : client.exe ,."7 A ,<'« compilation »

Gestionnaire de clients ^- -.^ « traçabilité * Alimentation distributeur

« sous-système i

Gestion des retraits

« fichier» client.c

Chargeur du « traçabilité » distributeur <-

Lecteur de carte

Gestionnaire de clients Chargeur du distributeur

Guichet espèces

Capteur du distributeur

Guichet

I « fichier» I distributeur.o

<-

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

Compte

L'interface Vi rements définit les opérations permettant d'effectuer des retraits, des dépôts et des virements entre comptes, et l'interface Retraits celles nécessaires pour effectuer des retraits d'un compte. Enfin, l'interface Dél i vrance spécifie les opérations qu'utilisent les autres sous-systèmes, tels que le sous-système Gesti on des transacti ons, pour délivrer la somme demandée au client de la banque.

Un composant suppose un contexte architectural défini par ses interfaces. Il est également remplaçable, ce qui signifie que les développeurs peuvent le remplacer par un autre, éventuellement meilleur, tant que ce dernier fournit et exige les mêmes interfaces. I l y a généralement un moyen direct d'implémenter un sous-système de service du modèle de conception en composants pouvant être alloués à des nœuds dans le modèle de déploiement. Chaque sous-système de service est implémenté par un seul composant si celui-ci est toujours alloué à un seul type de nœud dans le modèle de déploiement. Si le composant est alloué à plusieurs nœuds, le sous-système de service peut être scindé (en général, par la division de cer-


I

taines classes) en autant de parties qu'il y aura de types de nœuds. Chaque partie du soussystème de service sera, dans ce cas, implémentée par un composant.

Ijgg

Un sous-système de service implémenté 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-système de service Ges t i on des ret rai ts (figure 3.11) contient la classe Retrai t, déployée à la fois sur le client et sur le serveur. Le sous-système de service Gesti on des retraits serait donc implémenté par deux composants : « Retrait sur le cl ient » et « Retrait sur le serveur ».

Si les composants sont implémentés dans un langage de programmation orienté objet, l'implémentation des classes est également directe. Chaque classe de conception correspond à une classe de l'implémentation, telle qu'une classe C++ ou Java. Chaque composant fichier peut implémenter plusieurs classes de ce type, selon les conventions propres à chaque langage de programmation. Mais l'implémentation ne se borne pas au développement du code nécessaire à la création d'un système exécutable. Les développeurs chargés d'implémenter un composant doivent également le tester unité par unité avant de le soumettre aux tests d'intégration et aux tests système.

3.5 Tests des cas d'utilisation Les tests permettent de vérifier que le système implémenté correctement sa spécification. On met au point un modèle des test composé de cas de test et de procédures de test (Annexe C ; voir également le chapitre 11), que l'on exécute ensuite pour s'assurer que le système fonctionne comme prévu. Un cas de test est un ensemble d'entrées de test, de conditions d'exécution et de résultats attendus déterminé dans un objectif précis, comme de tester un chemin de cas d'utilisation particulier ou de vérifier le respect d'une exigence spécifique. Une procédure de test spécifie la façon de procéder à l'installation, à l'exécution d'un cas de test précis, et à l'évaluation de ses résultats. Les procédures de test peuvent également être dérivées des cas d'utilisation. Les anomalies détectées sont ensuite analysées afin de localiser le problème. Enfin, les problèmes sont hiérarchisés et corrigés par ordre d'importance.

I

Après avoir commencé à déterminer les cas d'utilisation dans la section 3.3, nous avons analysé, conçu et implémenté un système réalisant ces cas d'utilisation. Nous allons maintenant voir comment contrôler leur implémentation. En un sens, i l n'y a là rien de nouveau. De tout temps, les développeurs ont testé des cas d'utilisation sans le savoir. Vérifier que le système fonctionne d'une façon compréhensible aux utilisateurs constitue depuis toujours le moyen pratique de tester les fonctions d'un système. 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'enchaînements d'activités des besoins) avant même de commencer la conception du système et que l'on vérifie ensuite que la conception met réellement en œuvre les cas d'utilisation.


3

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. Figure 3.13 Un cas de test du modèle des tests indiquant le moyen de tester un cas d'utilisation (Retirer de l'argent) dans le modèle de cas d'utilisation.

M o d è l e des cas d'utilisation

M o d è l e des

tests

< traçabilité »

o Retirer de l'argent

Retirer de l'argent -Flot de base

Remarquez que nous introduisons là un nouveau stéréotype pour les cas de test : un symbole de cas d'utilisation revêtu d'une croix. Ce symbole permet de désigner les cas de test dans les diagrammes (voir le chapitre 11). Le cas de test précise les entrées, le résultat attendu et les autres conditions pertinentes pour la vérification du flot de base du cas d'utilisation Retirer de l'argent : Entrées : 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. Résultat : Le solde du compte 12-121-1211 du Cl ient de la banque descend à 1 500 FF. Le Cl ient de la banque reçoit 2 000 FF du DAB. Conditions : Aucun autre cas d'utilisation (instance) n'est autorisé à accéder 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 dès le début du processus permet très tôt de planifier les activités de test et de suggérer des cas de test utiles. Ces cas de test peuvent ensuite être améliorés au cours de la conception, lorsqu'on en sait plus sur la façon dont le système exécutera les cas d'utilisation. Certains outils génèrent des cas de test à partir d'un modèle de conception ; les seuls éléments à entrer à la main sont les données nécessaires pour l'exécution des tests. Les tests des cas d'utilisation peuvent être effectués soit du point de vue d'un acteur traitant le système comme une boîte noire, soit d'un point de vue propre à la conception ; le cas de test est alors élaboré pour vérifier que les instances des classes participant à la réalisation du cas d'utilisation font bien ce qu'elles doivent faire. Les tests « boîte noire » peuvent être identifiés, spécifiés et planifiés dès que les besoins sont à peu près stables. Il existe d'autres types de tests, comme les tests système, les tests d'acceptation et les tests de la documentation utilisateur. Nous en dirons plus à ce sujet au chapitre 11.


3.6

I

Résumé Les cas d'utilisation pilotent le processus. Pendant l'enchaînement d'activités des besoins, les développeurs expriment ces besoins sous forme de cas d'utilisation, sur lesquels s'appuient les chefs de projet pour planifier le développement. Au cours de l'analyse et de la conception, les développeurs créent les réalisations de cas d'utilisation en termes de classes ou de sous-systèmes, puis ils implémentent les composants. Les composants sont intégrés dans des incréments qui réalisent chacun un ensemble de cas d'utilisation. Enfin, les testeurs vérifient que le système implémenté les cas d'utilisation nécessaires aux utilisateurs. En d'autres termes, les cas d'utilisation assurent la cohésion de toutes les activités de développement et guident le processus de développement dans son ensemble. C'est peut-être là le premier intérêt de l'approche pilotée 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

Références 1 IVAR JACOBSON, "Object-oriented development in an industrial environment," Proceedings ofOOPSIA'87, Spécial 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, Conférence 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 Spécification. Object Management Group, Framingham, MA, 1998. Internet: www.omg.org.

fl

4

Un processus centré sur l'architecture Nous avons ouvert le chapitre 3 par une simplification, en prétendant que les cas d'utilisation allaient, à eux seuls, vous frayer un chemin à travers la spécification des besoins, l'analyse, la conception, l'implémentation et les tests jusqu'à la production d'un système. Mais le développement logiciel ne se résume pas à un parcours aveugle à travers les enchaînements d'activités, guidé par les seuls cas d'utilisation. Les cas d'utilisation ne suffisent pas. Pour échafauder un système opérationnel, i l faut quelque chose de plus. Ce « plus », c'est l'architecture. On peut se représenter l'architecture d'un système comme la vision commune sur laquelle doivent s'accorder tous les travailleurs (c'est-à-dire les développeurs et les autres intervenants), ou qu'ils doivent au moins accepter. L'architecture offre une perspective claire de tout le système, indispensable pour en maîtriser le développement. Il nous faut une architecture capable de décrire les éléments de modèle qui comptent le plus à nos yeux. Comment déterminer quels sont ces éléments ? Leur importance tient au fait qu'ils orientent notre travail sur le système, aussi bien dans le cycle en cours que pour l'ensemble du cycle de vie. Ces éléments de modèle significatifs sur le plan architectural comprennent une partie des sous-systèmes, des dépendances, des interfaces, des collaborations, des nœuds et classes actives (Annexe A ; voir également la section 9.3.2) et décrivent les fondements du système qui permettront d'abord de le comprendre, puis de le développer et de le faire évoluer à moindre coût. 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 tête ? Supposons qu'il veuille également se servir du garage comme atelier personnel. Cette demande devra amener l'entrepreneur à fournir une source de lumière : quelques fenêtres et un éclairage électrique. Un grand

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 QÏÂprr}ÎE~4mm\

nombre d'outils fonctionnent à l'électricité ; i l faudra donc aussi prévoir une demi-douzaine de prises de courant et une puissance en watts suffisante pour les prendre en charge. D'une certaine façon, l'entrepreneur met au point une architecture simple. I l peut le faire de tête, parce qu'il a déjà vu un garage auparavant. De même, i l a déjà 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 connaît déjà l'architecture typique d'un garage. I l ne lui reste qu'à assembler les diverses parties de façon à répondre 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 bâtiment. I l ne doit donc pas s'arrêter exclusivement à sa fonction, mais en considérer la forme. La construction d'une maison de dix pièces et celle d'une cathédrale, d'un centre commercial ou d'un gratte-ciel sont des entreprises très différentes. Les méthodes permettant d'édifier des bâtiments d'une telle envergure ne manquent pas et leur conception nécessite l'intervention d'une équipe d'architectes, qui doivent s'informer mutuellement de la progression de l'architecture. Ce qui signifie qu'ils doivent présenter cette dernière sous une forme non seulement compréhensible aux autres membres de l'équipe, mais également accessible aux profanes, c'est-à-dire le propriétaire, les utilisateurs et les autres intervenants. Enfin, cette architecture doit être communiquée aux entrepreneurs et fournisseurs de matériaux par le biais de plans de construction. De la même façon, le développement des systèmes logiciels (ou d'un système logiciel et du matériel sur lequel i l s'exécute) réclame de la prévoyance et la conservation des réflexions liminaires sous une forme exploitable par les développeurs et par les autres intervenants. De plus, ces réflexions, cette architecture, ne sortent pas toutes armées du front de Zeus : i l faut plusieurs itérations, dans les phases de création 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 référence (Annexe C) exécutable. On dispose alors de bases solides pour aborder la phase de construction et procéder à l'édification du système dans son ensemble.

Mais la phase de construction d'un bâtiment implique d'autres professionnels : charpentiers, ouvriers, maçons, couvreurs, plombiers, électriciens, etc. Chacun d'entre eux a besoin de dessins techniques du bâtiment plus détaillés et spécialisés qui, tous, doivent être cohérents les uns avec les autres. Les circuits d'aération et d'adduction d'eau, par exemple, ne doivent pas se trouver au même emplacement physique. Le rôle de l'architecte consiste à traiter les aspects les plus significatifs de la conception globale du bâtiment. I l élabore ainsi un ensemble de dessins décrivant les parties essentielles du bâtiment, telles que les fondations enfouies. Un ingénieur de structure détermine ensuite la taille des poutres qui devront soutenir la structure, formée des murs, des planchers et du toit. La structure comprend aussi les systèmes d'ascenseurs, de conduite d'eau, d'électricité, de climatisation, d'assainissement, etc. Ces dessins architecturaux manquent, toutefois, des détails suffisants pour servir de base de travail aux équipes chargées de la construction. On confie donc à des dessinateurs d'architecture spécialisés dans différents domaines le soin de préparer les plans et les spécifications qui fourniront toutes les informations nécessaires sur le choix des matériaux, les sous-systèmes d'aération, les sous-systèmes électriques, d'adduction d'eau, etc. L'architecte a la responsabilité globale du projet, mais ce sont ces concepteurs qui lui apportent tous les détails. En général, l'architecte est expert dans l'intégration des divers aspects du bâtiment, mais i l n'est spécialiste d'aucun de ces domaines. Une fois que tous ces dessins détaillés sont prêts, on constate que les dessins architecturaux ne couvrent que les parties significatives du bâtiment : ils se contentent d'offrir une vue de tous les autres dessins, avec lesquels ils restent parfaitement cohérents. Au cours de la construction, un grand nombre de professionnels utiliseront les dessins architecturaux (c'est-à-dire les vues des plans détaillés) pour se forger une image fidèle du bâtiment, mais ils se baseront plutôt sur les plans détaillés pour effectuer leur travail. Comme un bâtiment, un système logiciel est une entité unique, même si l'architecte logiciel et les développeurs préfèrent le présenter depuis différents points de vue afin d'en mieux saisir la conception. Ces différents points de vue constituent des vues (Annexes A et C) plus claires des modèles du système. Ensemble, elles dévoilent l'architecture. L'architecture logicielle englobe toutes les décisions d'importance sur les sujets suivants :

4.1 L'architecture en bref Il nous faut une architecture. Soit. Mais qu'entend-on précisément par « architecture de systèmes logiciels » ? I l suffit de se plonger dans la littérature existant sur le sujet pour repenser à la parabole des aveugles et de l'éléphant. Un éléphant est la somme de ce que chacun des aveugles a rencontré isolément : un grand serpent (la trompe), un bout de corde (la queue) et un petit arbre (la patte). De même, l'idée d'architecture, tout au moins si l'on veut la définir 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 bâtiments. Du point de vue du client, un bâtiment forme, en général, une seule unité. I l peut être intéressant, pour l'architecte, de créer un modèle à l'échelle, ainsi que des dessins du bâtiment de différents points de vue. En principe peu détaillés, ces dessins sont compréhensibles par le client.

• l'organisation d'un système logiciel ; • les éléments structurels et leurs interfaces qui comprendront le système, ainsi que leur comportement tel qu'il est spécifié dans les collaborations entre ces éléments ; • la composition des éléments structurels et comportementaux au sein de sous-systèmes dont la taille augmente de façon progressive ; • le style architectural (Annexe C) que suit cette organisation : les éléments et leurs interfaces, leurs collaborations et leur composition. Mais l'architecture logicielle ne s'intéresse pas seulement à la structure et au comportement ; elle se soucie également de l'usage, des fonctionnalités, des performances, de la capacité de réaction (resilience), des possibilités de réutilisation, de la clarté, des contraintes et compromis économiques et technologiques, enfin de l'esthétique. La section 4.4 nous donnera l'occasion d'aborder le concept d'architecture logicielle en termes plus concrets et de décrire la façon de le représenter à l'aide du Processus unifié.


I

Nous allons, toutefois, avancer ici une première définition de la description de l'architecture (Annexe C). Nous avons indiqué que l'architecture est représentée sous forme de vues des modèles : vue du modèle des cas d'utilisation, vue du modèle d'analyse, vue du modèle de conception, etc. Cet ensemble de vues concorde parfaitement avec les 4+1 vues évoquées dans [3]. Étant donné qu'une vue d'un modèle est un extrait, ou une coupe, de celui-ci, une vue du modèle des cas d'utilisation, par exemple, ressemblera au modèle des cas d'utilisation lui-même : elle montrera les acteurs et les cas d'utilisation, mais uniquement ceux qui auront une signification sur le plan architectural. De la même façon, la vue architecturale du modèle de conception s'apparentera à un modèle de conception, mais elle n'affichera que les éléments de conception réalisant 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 complète du système avec tous ses modèles (il existe quelques différences 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 matière, de règle absolue. Toutefois, d'après notre expérience de systèmes assez divers, nous estimons qu'elle doit comprendre de 50 à 100 pages. Cette indication s'applique aux systèmes à une seule application (système d'applications, voir Annexe C) ; les descriptions d'architecture de suites de systèmes d'applications (Annexe C) seront plus volumineuses.

4.2 Pourquoi il nous faut une architecture Un système logiciel vaste et complexe exige la présence d'un architecte, qui seul pourra mener les développeurs vers une vision commune. Il est toujours difficile de se faire une idée d'un système logiciel, car celui-ci n'existe pas dans notre monde en trois dimensions. I l est souvent sans précédent ou unique sous un certain angle ; i l utilise des technologies non éprouvées ou une association inédite de technologies ; i l pousse des technologies existantes jusqu'à leurs limites ultimes. I l doit, en plus, être conçu pour accueillir tout un ensemble de changements à venir. Avec la complexité croissante des systèmes, « le problème de la conception va au-delà des algorithmes et des structures de données du calcul : la conception et la spécification de la structure globale du système s'imposent comme un nouveau type de problème » [1]. Il n'est pas rare, en outre, qu'un système existant remplisse déjà certaines fonctions du système proposé. Le fait qu'il faille déterminer ce que fait le système, souvent avec une documentation partielle ou inexistante, et quelle part du code pourra être réutilisée ne fait qu'ajouter à la complexité du développement. Il nous faut une architecture pour : • comprendre le système ; • organiser le développement ; • favoriser la réutilisation ; • faire évoluer le système.

4.2.1 Comprendre le

Un processus c e n t r é sur l'architecture CHAPITRE

4

système

Pour qu'une société puisse développer un système, i l faut que celui-ci soit compréhensible à tous ceux qu'il va concerner. Rendre les systèmes modernes compréhensibles constitue un défi majeur pour plusieurs raisons : • ces systèmes ont un comportement complexe ; • ils fonctionnent dans des environnements complexes ; • ils sont complexes sur le plan technologique ; • ils associent souvent informatique distribuée, plates-formes et produits commerciaux (comme les systèmes d'exploitation et les systèmes de gestion de base de données), et des composants et frameworks réutilisables ; • ils doivent répondre aux besoins de personnes et d'organisations exigeantes ; • dans certains cas, ils sont si tentaculaires que les responsables doivent en scinder le développement en un grand nombre de projets, éclatés géographiquement 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 développement sur l'architecture (Annexe C) est le seul moyen de ne pas être confronté à une totale incompréhension. La première exigence d'une description d'architecture est, par conséquent, de permettre aux développeurs, responsables, clients et autres intervenants de comprendre avec suffisamment de détails ce qui doit être fait et de favoriser ainsi leur participation. Les modèles et diagrammes mentionnés au chapitre 3 y contribuent et peuvent servir à décrire l'architecture. En se familiarisant avec UML, chacun trouvera l'architecture plus facile à appréhender lorsqu'elle modélisée avec ce langage.

4.2.2 Organiser le

développement

Plus l'équipe du projet logiciel est importante, plus on dépensera de temps dans les communications nécessaires à la coordination des efforts des développeurs. Ce temps supplémentaire augmente avec la dispersion géographique du projet. La scission du système en soussystèmes ayant des interfaces clairement définies, dont la responsabilité sera attribuée à un groupe ou à un individu, permet de réduire la charge des communications entre les divers groupes, que ces derniers se trouvent dans le même bâtiment ou sur différents continents. Une « bonne » architecture doit explicitement définir ces interfaces afin de rendre possible la réduction des communications. Lorsqu'elle est bien définie, une interface « communique » efficacement aux développeurs de toutes parts ce qu'ils doivent savoir du travail des autres équipes. La stabilité des interfaces permet aux logiciels situés de part et d'autre de celles-ci d'évoluer de façon indépendante. La présence d'une architecture appropriée, d'un côté, et les patterns de conception (Annexe C), de l'autre, aident à identifier les meilleures interfaces entre soussystèmes. Nous en avons un exemple avec le pattern Frontière-Contrôle-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


section 3.4.1), qui nous a permis de répartir les problèmes entre comportement spécifique aux cas d'utilisation, classes frontières et classes génériques.

4.2.3 Favoriser la

réutilisation

Ayons recours à une analogie pour expliquer l'importance de l'architecture pour la réutilisation. L'industrie de la plomberie est depuis longtemps standardisée. Les plombiers bénéficient de composants standard. Ainsi, au lieu de se démener pour trouver les joints correspondant aux dimensions de composants « créatifs » issus de sources diverses, le plombier choisit, parmi un ensemble standardisé, des pièces qui s'emboîteront sans problème. Tout comme le plombier, les développeurs « formés à la réutilisation » connaissent le domaine du problème (Annexe C) et les composants que l'architecture définit comme étant appropriés. C'est aux développeurs de trouver le moyen de relier ces composants de sorte qu'ils obéissent à la configuration système exigée et réalisent le modèle des cas d'utilisation. S'il existe des composants réutilisables, c'est ceux-là qu'ils choisissent. À l'instar des joints de plomberie standard, les composants logiciels réutilisables sont conçus et testés pour s'imbriquer, ce qui réduit le coût et les délais de construction et donne des résultats prévisibles. Comme dans l'industrie de la plomberie où la standardisation a pris des siècles pour s'imposer, la standardisation des composants logiciels nécessite une certaine expérience, mais on peut espérer l'avènement, d'ici quelques années, d'une « composantisation » massive. Celle-ci est, en fait, déjà en cours. Certes, i l reste à l'industrie du logiciel à accéder au niveau de standardisation qu'a déjà atteint le domaine du matériel 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 développeurs un socle stable sur lequel échafauder leur travail. Le rôle de l'architecte consiste à définir ce socle et les sous-systèmes qui devront en faire partie. Pour être réutilisables, les composants doivent être conçus de façon à être parfaitement intégrables les uns aux autres [2]. Une architecture bien pensée doit rentabiliser la recherche de composants réutilisables et permettre de trouver facilement ceux qui sont le plus appropriés. I l ne fait aucun doute que la généralisation d'UML va accélérer le processus de composantisation, ta présence d'un langage de modélisation standard étant un préalable à la fabrication de composants spécifiques au domaine susceptibles d'être réutilisés.

4.2.4 Faire évoluer

le

système

S'il y a une chose dont on peut être sûr, c'est que tout système de taille relativement importante évolue. Il évoluera même au cours du développement. Par la suite, quand i l sera opérationnel, les changements d'environnement appelleront d'autres évolutions. Dans les deux cas, le système doit être facile à modifier : les développeurs doivent pouvoir remanier des parties de la conception et de l'implémentation sans avoir à se soucier des répercussions inattendues que pourraient avoir ces changements sur l'ensemble du système. I l faut, d'une manière générale, qu'ils puissent implémenter dans le système de nouvelles fonctions (c'està-dire des cas d'utilisation) sans constater d'effet spectaculaire sur la conception et l'implé-

4

WM

mentation existantes. En d'autres termes, le système lui-même doit savoir réagir aux changements, les tolérer. On pourrait aussi dire que le système doit savoir évoluer avec élégance. À l'inverse, les systèmes mal charpentés se dégradent avec le temps et supportent difficilement l'ajout de correctifs. I l arrive un moment où leur actualisation n'est plus rentable. Le système AXE d'Ericsson - De l'importance de l'architecture Le système de commutation téléphonique AXE d'Ericsson a été développé au début des années 1970 sur la base d'une des premières versions de nos principes d'architecture. Artefact fondamental, la description de l'architecture logicielle a guidé tout le travail de développement pendant la durée de vie du système. L'architecture reposait sur un certain nombre de principes désormais intégrés au Processus unifié. L'un de ces principes était celui de la modularité des fonctions. Les classes, ou leurs équivalents en conception, étaient regroupées en blocs fonctionnels, ou sous-systèmes de service, que les clients pouvaient considérer comme facultatifs (même si ces éléments étaient livrés à tous les clients). Chaque sous-système de service présentait une forte cohésion interne. Les changements apportés au système étaient en général locaux à un service et affectaient rarement plus d'un sous-système de service. Un autre principe consistait à séparer la conception des interfaces de la conception des soussystèmes de service. Le but était de tendre vers des conceptions par éléments interchangeables (« plug-able »), dans lesquelles plusieurs sous-systèmes de service pourraient prendre en charge la même interface. Il devenait alors possible d'échanger un sous-système de service contre un autre sans modifier les clients du sous-système en question (clients qui ne dépendent que des interfaces et non du code réel du sous-système). Un troisième principe imposait d'assurer la correspondance directe d'un sous-système de conception vers un ou plusieurs composants d'implémentation. Les composants du soussystème de service pouvaient être distribués sur différents nœuds de calcul du réseau. Il y avait exactement un composant pour chaque nœud de traitement sur lequel devait s'exécuter le sous-système de service. De la sorte, si le sous-système de service devait s'exécuter sur l'ordinateur central (disons, un serveur), il y avait exactement un composant pour ce soussystème de service. Si le sous-système devait être implémenté à 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 différentes installations. Mais un autre principe préconisait un faible couplage entre sous-systèmes de service. Les signaux étaient les seuls moyens de communication entre ces sous-systèmes. Comme ces signaux étaient asynchrones (c'est-à-dire qu'ils appliquaient une sémantique « envoisans-attente »), ils prenaient en charge non seulement l'encapsulation, mais également la distribution. 1

i . Ou « répartition »


i

.

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

H|

I

Grâce à un développement initial et ultérieur guidé par une architecture bien conçue, le système 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 décennies.

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 développer, en principe, un système fournissant à ses utilisateurs les cas d'utilisation dont ils ont besoin. Si le système propose les cas d'utilisation appropriés (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 réponse, comme nous l'avons déjà suggéré, consiste à bâtir une architecture permettant d'implémenter de façon rentable les cas d'utilisation, dans le présent et à l'avenir. Clarifions, maintenant, les modalités 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. Figure 4.1 Différents types de besoins et de produits influencent l'architecture, et non pas seulement les cas d'utilisation. L'expérience acquise sur des travaux antérieurs et les structures que l'on peut identifier comme patterns d'architecture se révèlent également utiles pour la mise au point de l'architecture.

C a s d'utilisation

• les produits logiciels système sur lesquels devra reposer la construction, notamment le système d'exploitation ou un système spécifique de gestion de base de données relationnelle ; • les produits de middleware (couche de middleware ; Annexe C) choisis. I l faudra, par exemple, sélectionner un ORB, c'est-à-dire un mécanisme de mise à plat (marshalling) et d'acheminement transparents des messages aux objets distribués dans des environnements hétérogènes [6], ou un framework indépendant de la plate-forme, c'est-à-dire un système « préfabriqué », pour créer les interfaces utilisateur graphiques ; • les systèmes existants qu'intégrera le système. La conservation, au sein de l'architecture, d'un système existant tel qu'un système bancaire permet de réutiliser un grand nombre de fonctionnalités, mais elle nécessite é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 définition d'interfaces (IDL) de l'OMG [7] pour spécifier toutes les interfaces de classes, ou le standard de télécommunications TMN [8] pour définir les objets dans le système ; • les besoins non fonctionnels généraux (c'est-à-dire non spécifiques aux cas d'utilisation), tels que les besoins en termes de disponibilité, de temps de récupération ou d'utilisation de la mémoire ;

Contraintes et facteurs favorables

I

Logiciel système

• les besoins en distribution spécifient le modèle de distribution du système, par exemple à travers une architecture client-serveur.

Middleware (y compris les frameworks)

Les éléments du côté droit de lafigure4.1 peuvent être envisagés comme des contraintes et des facteurs favorables menant à un certain type d'architecture.

- Systèmes existants Architecture

- Standards et politiques

L'architecture est mise au point en plusieurs itérations dans la phase d'élaboration. On pourrait imaginer, comme modèle de pensée, l'approche simplifiée et quelque peu naïve qui suit. On commence par opter pour une conception de haut niveau, telle qu'une architecture en couches (Annexe C). Puis, on façonne l'architecture par quelques constructions (Annexe C ; voir aussi le chapitre 10) au cours de la première itération.

- Besoins non fonctionnels - Besoins de distribution

Expérience :

• Architectures précédentes • Patterns d'architecture

Comme nous l'avons déjà mentionné, l'architecture est influencée par les cas d'utilisation que nous voulons faire prendre en charge par le système. Ces cas d'utilisation agissent, en effet, comme des pilotes pour l'architecture. Après tout, on veut obtenir une architecture adaptée à l'implémentation des cas d'utilisation retenus. On sélectionne, dans les premières itérations, quelques cas d'utilisation jugés indispensables à la création 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 :

La première construction s'attarde sur les parties générales aux applications (Annexe C), c'est-à-dire aux parties générales au domaine en question et non spécifiques au système envisagé : on sélectionne le logiciel système (couche de logiciel système ; Annexe C ; voir aussi la section 9.5.1.2.2), le middleware, les systèmes existants, les standards et les poli tiques à utiliser. C'est le moment où l'on décide des nœuds quifigurerontdans le modèle de déploiement et de leurs interactions. I l faut, enfin, trancher sur la façon de traiter les exi gences non fonctionnelles générales, telles que les exigences de disponibilité. Pour celle pK mière passe, une compréhension générale de l'application suffit. La deuxième construction, en revanche, s'intéresse aux aspects spécifiques aux applications (couche spécifique à l'application ; Annexe C). On choisit un ensemble de cas d'utilisation pertinents sur le plan de l'architecture, puis on procède à la « capture » des besoins, qui sont ensuite analysés, conçus, implémentés et testés. Ce processus aboutira à la création de soussystèmes implémentés sous forme de composants prenant en charge les cas d'utilisation retenus. I l se peut également que quelques changements interviennent dans les composants


I

significatifs sur le plan architectural implémentés lors de la première construction (à un moment où l'on ne réfléchissait pas en termes de cas d'utilisation). Les composants modifiés et les nouveaux composants sont mis au point pour réaliser les cas d'utilisation, ce qui permet d'adapter au mieux l'architecture aux cas d'utilisation. On procède ensuite à une autre construction, et ainsi de suite, jusqu'à ce que soit terminée l'itération. Si l'itération s'achève à 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 implémenter les fonctionnalités complètes en réalisant le reste des cas d'utilisation pendant la phase de construction. Les cas d'utilisation implémentés durant cette phase sont essentiellement développés à 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. ligure 4.2 / n i us d'utilisation peuvent être I laborés à partir des entrées fournies Ml 1rs clients et les utilisateurs. i . pendant, ils sont également influencés 1:11 l'architecture déjà en place.

E n t r é e s des clients E n t r é e s des utilisateurs J -

->

C a s d'utilisation

A

Architecture

On utilise, lors de l'identification de nouveaux cas d'utilisation, la connaissance que l'on a de l'architecture déjà en place, à l'aune de laquelle seront évalués l'intérêt et le coût de chaque suggestion de cas d'utilisation. Certains de ces cas d'utilisation seront plus faciles à implémenter que d'autres.

ITffiHIl

Adaptation des cas d'utilisation à l'architecture déjà en place Le client a exigé une fonction de supervision de la charge du processeur. Cette fonction a été spécifiée sous la forme d'un cas d'utilisation mesurant la charge à un niveau de haute priorité de l'ordinateur. L'implémentation de ce cas d'utilisation aurait, en principe, nécessité quelques modifications du système d'exploitation temps réel utilisé. Mais l'équipe a préféré implémenter la fonctionnalité désirée par un dispositif externe indépendant effectuant des appels au système et mesurant le temps de réponse. Le client obtenait ainsi des mesures plus fiables et l'équipe de développement n'avait pas besoin de modifier l'architecture sous-jacente, beaucoup plus stratégique.

Après avoir négocié avec le client, on détermine s'il n'y a pas moyen de simplifier l'implémentation en alignant davantage les cas d'utilisation et la conception qui en résulte sur l'architecture en place. Cela signifie qu'il faut considérer quels sont les sous-systèmes, interfaces, cas d'utilisation, réalisations de cas d'utilisation, classes, et ainsi de suite, qui existent déjà. Cet alignement des cas d'utilisation sur l'architecture permet de rentabiliser la création de nouveaux cas d'utilisation, sous-systèmes et classes en exploitant ce dont on dispose. Par conséquent, d'un côté, l'architecture est influencée par le choix des cas d'utilisation que l'on souhaite faire prendre en charge par le système : 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).

Figure 4.3 Ces cas d'utilisation orientent le développement de l'architecture, tandis que l'architecture guide la réalisation des cas d'utilisation.

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

4

Cas f d'utilisation Gui* f

\t

Ar-chitecture '

Qui vient en premier : les cas d'utilisation ou l'architecture ? Voilà un exemple typique du problème de l'œuf et de la poule. Le meilleur m o y e n de résoudre ce type de problème consiste à procéder par itérations. On construit d'abord une architecture provisoire à partir d'une bonne compréhension du domaine (AnnaeC), sans toutefois considérer le détail des cas d'utilisation. Puis, on choisit quelques cai d'utilisation significatifs et l'on adapte l'architecture pour qu'elle prenne en charge les cas d'utilisation en question. On prend ensuite d'autres cas d'utilisation, en fonction desquels on améliore encore l'architecture, et ainsi de suite. A chaque itération, on sélectionne et on implémenté un ensemble de cas d'utilisation afin de valider et, si nécessaire, d'améliorer l'architecture. Ces itérations successives permettent également de poursuivre l'implémentation des parties de l'architecture spécifiques aux applications à partir des cas d'utilisation sélectionnés. Les cas d'utilisation contribuent, par conséquent, à l'amélioration progressive de l'architecture à mesure qu'on s'achemine vers le système complet. Ce n'est pas le moindre des avantages du développement piloté par les cas d'utilisation. Nous reviendrons sur cette approche itérative au chapitre 5. En résumé, une bonne architecture est une architecture qui permet de déterminer, de façon rentable, les cas d'utilisation qui conviennent, pour le présent et l'avenir.

4.4 Étapes d'élaboration de l'architecture L'architecture est mise au point par itérations successives, essentiellement pendant la phase d'élaboration. Chaque itération se déroule selon la description fournie au chapitre 3, en partant des besoins, suivis de l'analyse, de la conception, de l'implémentation et des tests, mais se concentre sur les cas d'utilisation et les autres besoins pertinents pour l'architecture. Cette phase d'élaboration débouche alors sur une architecture de référence, c'est-à-dire un squelette du système épaissi de quelques « muscles ». 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 réduire les risques les plus importants, ceux qui comptent le plus pour les utilisateurs et ceux qui aident à couvrir les principales fonctionnalités afin que rien ne reste dans l'ombre. L'implémentation, l'intégration et les tests de l'architecture de référence 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 référence opérationnelle fournit donc une démonstration à laquelle peuvent réagir les différents travailleurs.


I

4.4.1 L'architecture de référence

est un système

« petit et maigre »

À l'issue de la phase d'élaboration, nous avons développé les modèles du système qui représentent, d'un point de vue architectural, les cas d'utilisation les plus importants et leurs réalisations. Nous avons également décidé, comme l'explique la section 4.3, « Cas d'utilisation et architecture », quels sont les standards à respecter, les logiciels système et middleware à utiliser, les systèmes existants à réutiliser et quels sont les besoins en matière de distribution. Nous disposons, ainsi, des premières versions du modèle des cas d'utilisation, et des modèles d'analyse, de conception, etc. Cet agrégat de modèles (voir la figure 4.4) constitue l'architecture de référence ; c'est un « petit » système « maigre » . Celui-ci comprend tous les modèles que comportera le système abouti à la fin de la phase de construction, ainsi que le squelette des sous-systèmes, composants et nœuds qui figureront dans le système final, sans toutefois que la musculature ne soit totalement en place. Mais ces éléments ont un comportement et se constituent de code exécutable. Ce système bien maigre se transforme ensuite en un système complet, avec quelques changements éventuels de structure et de comportement, changements forcément mineurs puisqu'on dispose par définition 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

vi II lion interne du rystime centrée l,i description i

D

Modèle des cas d'utilisation 1

1

D

Modèle d'analyse 1

1

Lt3


D

D

Modèle de • • Modèle déploiement d'implémentation

. . . . . .

Q

MModèle ^Holo des tests

sur de

hitecture.

Dans la figure 4.4, la zone ombrée de chaque modèle représente la version du modèle mise au point à la fin de la phase d'élaboration, c'est-à-dire la version du modèle faisant partie de l'architecture de référence. Le rectangle dans son entier (zones ombrée et non ombrée) reflète la version du modèle qui émergera à l'issue de la phase de transition, c'est-à-dire la référence représentant la version destinée au client (le lecteur devra se garder de tirer des conclusions hâtives à partir de la taille des zones ombrées dans la figure 4.4, qui n'apparaissent ici qu'à titre indicatif). Entre l'architecture de référence et la version client de référence, plusieurs références intermédiaires représentent les versions internes (Annexe C) des modèles remaniés. Nous aurions pu illustrer ces nouvelles versions par une succession d'incréments échafaudés les uns au-dessus des autres, à partir de l'architecture de référence. I Ceci n'est pas tout à fait exact. À l'issue de la phase d'élaboration, nous disposons d'une version du modèle des cas d'utilisation contenant à la fois les cas d'utilisation significatifs pour l'architecture et ceux (disons, jusqu a K<)%) qui sont nécessaires à la création d'une étude de rentabilité. Ainsi, le modèle des cas d utilisation et le modèle d'analyse de l'architecture de référence sont-ils plus complets que ne l'indique lafigure4.4. Nous nous permettons, toutefois, cette simplification pour la clarté de notre propos.


4

Chaque version évoluerait à partir de la version précédente. Les différents modèles de la figure 4.4 ne sont évidemment pas développés indépendamment les uns des autres. Chaque cas d'utilisation du modèle des cas d'utilisation correspond, par exemple, à une réalisation de cas d'utilisation dans les modèles d'analyse et de conception et à des cas de test dans le modèle des tests. Le processus et la structure des nœuds doit satisfaire au niveau de performances exigé par les cas d'utilisation. (Sinon, i l faut modifier les cas d'utilisation ou le modèle de déploiement, par exemple en changeant le mode d'affectation des classes actives aux nœuds pour obtenir de meilleures performances. De telles modifications du modèle de déploiement ou du modèle de conception sont susceptibles de conduire à des remaniements dans le modèle des cas d'utilisation, si ces changements nécessitent de modifier certains cas d'utilisation. Les éléments des différents modèles sont, comme nous l'avons dit dans la section 2.3.7, liés les uns aux autres par des dépendances de « traçabilité ». Toutefois, l'architecture de référence, c'est-à-dire la version interne du système telle qu'elle existe à la fin de la phase d'élaboration, ne se limite pas à des artefacts de modèles. Elle comprend également une description de l'architecture. En réalité, cette description s'élabore au fur et à mesure (et parfois même en amont) des activités qui donnent naissance aux versions des modèles faisant partie de l'architecture de référence. Le rôle de la description de l'architecture consiste à guider l'équipe de développement tout au long de la durée de vie du système, non seulement pour les itérations du cycle en cours, mais pour tous les cycles à venir. Cette description constitue le standard qui devra être suivi par les développeurs, aujourd'hui et dans le futur. L'architecture devant être stable, le standard doit l'être aussi. La description de l'architecture peut revêtir diverses formes. I l peut s'agir d'un extrait des (versions des) modèles faisant partie de l'architecture de référence, ou de la réécriture 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, néanmoins, des extraits (ou vues) des modèles de l'architecture de référence, qui seront actualisés au gré de l'évolution du système et de l'enrichissement des modèles dans les phases plus tardives. Si l'on admet que l'architecture de référence a donné heu à une architecture stable, c'est-à-dire que les éléments de modèles significatifs sur le plan architectural sont stables et ne bougeront pas dans les itérations à venir, on peut considérer que la description de l'architecture est, elle aussi, stable et qu'elle inclura à tout moment les vues des modèles du système. 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 même que seuls quelque 30% de la première version du produit ont été investis. Cette architecture servira de fondations au système pendant toute sa durée de vie. Comme chaque modification de ce socle coûtera cher et sera, dans certains cas, très douloureuse, i l est important de parvenir à une architecture stable dès les premiers stades du travail de développement. D'une certaine façon, la mise au point d'une architecture pour un système particulier revient à créer quelque chose de nouveau. D'un autre côté, i l y a des années que l'on développe des architectures. Expérience et connaissances se sont donc accumulées dans ce domaine. I l existe de nombreuses « solutions » génériques (structures, collaborations et architectures physiques) ayant évolué avec les années que tout architecte expérimenté doit connaître. On désigne généralement ces solutions du nom de « patterns », comme les patterns d'architecture décrits dans

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

I

|4] et les patterns de conception traités en détail dans [5]. Ces patterns génériques constituent des ressources dans lesquelles l'architecte pourra puiser.

4.4.2 Utilisation des patterns d'architecture Les idées avancées par l'architecte Christopher Alexander sur la façon dont les « langages de patterns » permettent de systématiser les principes et pratiques fondamentaux de la conception de bâtiments et de l'aménagement de lieux publics ont inspiré plusieurs spécialistes de l'objet qui ont, à leur tour, défini, collecté et testé un ensemble de patterns logiciels [10]. I ,cs spécialistes définissent un pattern comme « une solution à un problème récurrent de Conception». La plupart de ces patterns de conception sont amplement décrits dans des ouvrages qui les présentent à l'aide de canevas de documents standard. Ces canevas génériques donnent un nom au pattern et présentent un résumé du problème 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 résumé des avantages et des effets de son utilisation, et des références à d'autres patterns proches. Alexander exhorte les ingénieurs logiciels à retenir le nom et l'intention d'un grand nombre de patterns standard et à s'en servir pour la création de conceptions plus saines et compréhensibles. Certains, tels que les patterns Façade, Décorateur, Observateur, Mandataire, Stratégie et Visiteur, sont largement cités et utilisés. I .es spécialistes ont également utilisé le concept de pattern, sous un modèle de document légèrement différent, pour regrouper des solutions standard à des problèmes architecturaux récurrents. Citons, entre autres, les patterns Couches, Canaux & filtres (Pipes & Filters), broker, Tableau noir (Blackboard), Méta-données horizontales & verticales, MVC (ModèleVue-Contrôleur). D'autres ont mis au point des patterns à utiliser pendant l'analyse (« patterns d'analyse »), l'implémentation (« idiomes » faisant correspondre des structures orientées objet courantes à des aspects spécifiques à certains langages tels que C++ et Smalltalk), et d'autres destinés à optimiser la structure des équipes («patterns organisationnels »). En principe, les patterns de conception assurent une correspondance assez directe avec les langages de programmation orientés objet. On en trouve des exemples en C++, Java et Smalltalk, tandis que les patterns d'architecture se préoccupent essentiellement des systèmes ou sous-systèmes et des interfaces, et présentent des exemples ne comportant généralement pas de code. Pour découvrir un schéma de classification intéressant, consultez [9]. De notre point de vue déterminé par les modèles, nous définirons un pattern comme une collaboration générique pouvant être spécialisée, selon la définition 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 génériques, car elles proposent des solutions conçues pour être suffisamment générales. L'héritage, l'extension et d'autres mécanismes permettent ensuite de spécialiser le pattern (par exemple, en spécifiant le nom des classes, leur nombre, etc., apparaissant dans la collaboration générique). Dans bien des cas, les collaborations génériques, une fois spécia-


4

Usées, donnent lieu à des collaborations concrètes dont on peut retrouver directement la trace dans les cas d'utilisation. Les patterns de conception sont traités en détail dans [5]. S'ils s'utilisent de la même façon, les patterns d'architecture s'intéressent principalement à la structure à plus large granularité et aux interactions des sous-systèmes et même des systèmes eux-mêmes. I l existe de nombreux patterns d'architecture, dont nous n'évoquerons ici que les plus intéressants. Le pattern Broker [4] est un mécanisme générique de gestion de la distribution des objets. Il permet aux objets d'appeler d'autres objets distants par l'intermédiaire d'un courtier (« broker ») qui transmet l'appel au nœud et au processus détenant l'objet désiré. 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 fréquent du pattern de conception Proxy, qui fournit un objet mandataire local ayant la même interface que l'objet distant, afin de rendre parfaitement transparents le style et les détails de la communication distribuée. D'autres patterns facilitent la compréhension du matériel et simplifient la conception des systèmes au-dessus de ce matériel : les patterns Client-serveur, à Trois niveaux (Three-Tier) et d'Egal à égal (Peer-to-peer), entre autres. Ils définissent une structure pour le modèle de déploiement et suggèrent le mode d'affectation des composants sur les nœuds. Nous illustrerons, dans la section 4.5, la façon dont on peut appliquer le pattern Client-serveur au système de DAB décrit au chapitre 3. Dans notre exemple, la distribution client-serveur comprend un nœud client exécutant tout le code des interfaces utilisateur et une partie du code de la logique métier (classes de contrôle) pour chaque DAB physique. Le nœud serveur détient les comptes réels et les règles métier par rapport auxquelles sont vérifiées toutes les transactions. Figure 4.5 L'architecture en couches organise les systèmes par couches de soussystèmes.

Couche spécifique à l'application

Couche générale aux applications

Couche de middleware

Couche de logiciel système Le pattern Couches (Layers) peut être appliqué à une multitude de systèmes. I l définit l'organisation du modèle de conception en couches, selon laquelle les composants d'une couche ne peuvent faire référence qu'aux composants de la couche située immédiatement au-dessous. Ce pattern est d'une importance déterminante, car i l simplifie la compréhension et l'organisation du développement de systèmes complexes. I l réduit les dépendances en



I

faisant en sorte que les couches inférieures ignorent les détails ou les interfaces des couches supérieures. I l facilite, enfin, l'identification de ce qui peut être réutilisé et fournit une structure d'aide à la prise de décisions sur ce qui doit être acheté ou construit. Les systèmes à architecture en couches disposent, en leur sommet, de sous-systèmes d'applications individuels, élaborés à partir de sous-systèmes des couches inférieures, tels que des frameworks ou des bibliothèques de classes (voir la figure 4.5). La couche générale aux applications contient des sous-systèmes qui ne sont pas spécifiques à une seule application, mais peuvent être réutilisés pour diverses applications du même domaine ou du même métier. L'architecture des deux couches inférieures peut être élaborée sans prendre en compte les détails des cas d'utilisation, car ces couches ne sont pas spécifiques au métier, alors que l'architecture des deux couches supérieures est, quant à elle, créée à partir des cas d'utilisation pertinents sur le plan architectural (ces couches sont spécifiques au métier). Une couche (Annexe C) est un ensemble de sous-systèmes partageant le même degré de généralité et de volatilité des interfaces : les couches inférieures sont générales à plusieurs applications et doivent bénéficier d'interfaces plus stables, contrairement aux couches supérieures, plus spécifiques aux applications et pouvant, par conséquent, disposer d'interfaces plus mouvantes. Parce qu'elles ont des interfaces moins changeantes, les couches inférieures peuvent servir de base à l'élaboration des couches supérieures. Les sous-systèmes des différentes couches peuvent réutiliser des cas d'utilisation, d'autres sous-systèmes de niveau inférieur, des classes, interfaces, collaborations et composants issus de couches inférieures. On peut appliquer de nombreux patterns d'architecture au sein d'un même système. Les patterns structurant le modèle de déploiement (c'est-à-dire les patterns Client-serveur, À trois niveaux et Égal à égal) peuvent être associés au pattern Couches, qui contribue à la structuration du modèle de conception. Les patterns concernant les questions de structure des différents modèles sont souvent orthogonaux les uns par rapport aux autres. Même les patterns qui traitent du même modèle peuvent parfaitement s'associer, comme, par exemple, le pattern Broker et le pattern Couches, qui sont tous deux utilisés dans le modèle de conception. Le pattern Broker traite du mode de distribution transparente des objets, tandis que le pattern Couches suggère l'organisation de l'ensemble de la conception. Dans les faits, le pattern Broker serait réalisé en tant que sous-système de la couche de middleware. Il arrive qu'un pattern prédomine sur les autres. Par exemple, dans un système à couches, le pattern Couches définit l'architecture globale et la décomposition du travail (attribution des couches à différents groupes), tandis qu'on pourra utiliser le pattern Canaux & filtres dans l'une ou l'autre de ces couches. À l'inverse, dans un système à canaux et filtres, l'architecture globale sera représentée comme un flot entre filtres, alors même que l'organisation en couches sera explicitement utilisée pour certains de ces filtres.

4.4.3 Description de l'architecture L'architecture de référence 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 différents modèles 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 réécrites pour plus de lisi-

bilité) des modèles contenus dans l'architecture de référence et comprenant les éléments significatifs sur le plan architectural. Bien sûr, un grand nombre des éléments de modèles faisant partie de l'architecture de référence apparaîtront dans la description de l'architecture. Mais tous n'y figureront pas, car, pour obtenir une architecture de référence opérationnelle, il sera peut-être nécessaire de développer certains éléments de modèles peu intéressants sur le plan architectural, mais indispensables à la production de code exécutable. Étant donné que l'architecture de référence ne sert pas seulement à développer une architecture, mais aussi à spécifier les besoins du système au point qu'un plan détaillé peut être défini, i l est possible que le modèle 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 actualisée tout au long de la durée de vie du système, afin de refléter 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 fonctionnalités à des sous-systèmes existants ; • la mise à niveau, par de nouvelles versions, de composants réutilisables ; • le réaménagement de la structure des processus. Il est possible que la description de l'architecture elle-même doive en être modifiée, mais i l n'est pas nécessaire de l'étoffer. Elle doit simplement être actualisée pour rester pertinente (voir lafigure4.6). Comme nous l'avons dit plus haut, la description de l'architecture présente les vues des modèles et comprend ainsi des cas d'utilisation, des sous-systèmes, des interfaces, certains composants et classes, des nœuds et des collaborations. Elle intègre également les besoins significatifs sur le plan architectural qui ne sont pas décrits par les cas d'utilisation. Les autres besoins, non fonctionnels, sont formulés en tant qu'exigences supplémentaires, comme celles concernant la sécurité et les principales contraintes en matière 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 brève description de la plate-forme, des systèmes existants et des logiciels commerciaux à utiliser, comme Java RMI (Remote Method Invocation) pour la distribution des objets. Par ailleurs, i l convient de décrire les frameworks mettant en œuvre les mécanismes génériques (Annexe C ; voir également la section 9.5.1.4), tels que les mécanismes de stockage et de récupération des objets à partir d'une base de données relationnelle. Ces mécanismes ayant été conçus pour réaliser des collaborations réutilisables, ils peuvent être réutilisés par plusieurs réalisations 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 lumière les principales questions de conception afin que chacun puisse les examiner et livrer ses réactions. Ces questions doivent ensuite faire l'objet de discussions, être analysées etfinalementtranchées. I l pourra s'agir, par exemple, d'estimer la charge sur les performances ou les besoins en mémoire, et d'imaginer les exigences futures, susceptibles de briser l'architecture.


I

Architecture de référence Modèle des cas d'utilisation

Modèle d'analyse

Modèle Modèle do de conceptlon déploiement


Modèle des tests

Architecture de référence à la fin de la construction Modèle des cas d'utilisation

Modèle d'analyse

Modèle Modèle Modèle d'implémende de conceplion déploiement tation

Modèle des tests

I Description de l'architecture Version de la phase de construction

Description de l'architecture Version de la phase d'élaboration Modèle des cas d'utilisation

Modèle d'analyse

Modèle Modèle de de conceplion déploiement

Modèle de

Modèle d'Implémentation

.

Modèle d'implémen-

-

Figure 4.6 Pendant la construction, les différents modèles sont portés à leur terme (rectangles pleins dans le coin supérieur droit). La description de l'architecture, toutefois, ne s'étoffe pas de façon significative (en bas à droite), puisque l'essentiel de l'architecture a été défini au cours de la phase d'élaboration. Quelques changements mineurs (indiqués par un remplissage différent) viennent effectivement modifier l'architecture.

Bien que détaillée lorsque c'est nécessaire, la description de l'architecture demeure une vue de haut niveau. D'un côté, elle ne prétend pas à l'exhaustivité ; i l n'est pas question de noyer les participants sous un déluge de détails. C'est une feuille de route, et non une spécification complète du système. D'un autre côté, elle doit présenter tout ce qui est susceptible d'intéresser l'un ou l'autre des participants. I l sera donc assez courant qu'elle atteigne une centaine de pages. Les gens n'hésiteront pas à consulter un document volumineux s'il contient tout ce qu'ils ont besoin de savoir sous une forme immédiatement compréhensible. Après tout, c'est le rôle de la description de l'architecture : contenir tout ce qui permettra aux développeurs de faire leur travail. On peut avoir l'impression, en Usant une description d'architecture, qu'elle se contente de survoler certains sous-systèmes, alors qu'elle se répand en détails sur les interfaces et les collaborations d'une poignée d'autres sous-systèmes. La raison de cette différence de traitement tient au fait que les sous-systèmes hautement spécifiés sont ceux qui comptent sur le plan de l'architecture et qu'ils doivent rester sous le contrôle direct de l'architecte (voir les sections 12.4.2 et 14.4.3.1).


4

Il peut être utile de s'interroger sur ce que n'est pas l'architecture. La plupart des classes, dont les opérations, interfaces et attributs sont privés aux sous-systèmes ou aux sous-systèmes de service (invisibles au reste du système), ne sont pas pertinentes sur le plan architectural. Les sous-systèmes qui sont des variantes d'autres sous-systèmes n'ont aucun intérêt du point de vue de l'architecture. L'expérience 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 système. Les changements qu'elles peuvent subir n'affectent rien de primordial en dehors du sous-système de service. De même, la plupart des réalisations de cas d'utilisation sont-elles insignifiantes pour l'architecture, puisqu'elles n'imposent aucune contrainte supplémentaire au système. 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 réalisations de cas d'utilisation ne représenlenl qu'un comportement subsidiaire, facile à implémenter, même si ces réalisations constituent l'essentiel des fonctions offertes par le système. Et c'est bien là que nous voulons en venir : la plupart des fonctionnantes du système sont simples à implémenter une fois que l'architecture est en place. La description de l'architecture ne comprend pas les informations uniquement nécessaires à la validation ou à la vérification de l'architecture. On n'y trouve donc pas de cas, ni de procédures de tests, et elle ne Uvre aucune vue architecturale du modèle des tests. Ces questions ne relèvent pas de l'architecture. Toutefois, comme l'indique lafigure4.6, l'architecture de référence contient une version de tous les modèles, y compris une version du modèle des tests. La référence sous-jacente à la description de l'architecture a donc subi des tests. Comme toutes les références.

4.4.4 C'est l'architecte qui crée l'architecture C'est l'architecte, entouré de quelques développeurs, qui crée l'architecture. Ensemble, ils conjuguent leurs efforts pour mettre au point un système qui devra présenter des performances et un niveau de qualité élevés, ainsi que les caractéristiques suivantes : utilité, capacité de tests, convivialité, fiabilité, haute disponibilité, précision, extensibilité, tolérance aux changements, robustesse, facilité de maintenance, portabilité, sécurité, sûreté et rentabilité. Ils savent, néanmoins, que le respect de ces contraintes exige des compromis, ce qui justifie la présence de l'architecte : c'est lui, en effet, qui détient la plus haute responsabilité technique sur ces questions. C'est lui qui choisit parmi les patterns d'architecture, sélectionne les produits existants et organise les dépendances de sous-systèmes de façon à sérier les problèmes. « Sérier les problèmes » signifie, dans ce cas, créer une conception évitant qu'un changement intervenant sur un sous-système ne se répercute sur plusieurs autres soussystèmes. Le véritable objectif est de répondre aux besoins de l'application en utilisant les meilleurs moyens disponibles dans l'état actuel de la technologie, à un coût supportable pour l'application. En d'autres termes, d'être capable d'implémenter de façon rentable les fonctionnaUtés (c'est-à-dire les cas d'utiUsation) de l'application aujourd'hui et à l'avenir. L'architecte reçoit, dans cette tâche, 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

propose des principes et conseils sur ce qui constitue l'essence même d'une bonne architecture. Mais, en fin de compte, même avec l'aide de ces outils, l'architecture choisie résulte d'un jugement fondé sur l'expérience et la compétence. C'est l'architecte qui doit porter ce jugement. Lorsque, à la fin de la phase d'élaboration, il présente une description de l'architecture au responsable du développement, ce geste a la signification suivante : «je sais, maintenant, que nous pouvons construire le système sans rencontrer de surprises techniques majeures ». Un architecte compétent 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 développeurs. L'autre est la connaissance du développement logiciel, jusqu'à l'écriture même du code, car l'architecte doit communiquer l'architecture aux développeurs, coordonner leurs efforts et comprendre leurs réactions. L'expérience acquise sur des systèmes semblables au système en cours de développement se révélera également précieuse. L'architecte occupe un poste délicat dans l'équipe de développement logiciel. I l est préférable qu'il ne soit pas le chef de projet, car ce poste implique de nombreuses responsabilités autres que celles de l'architecture. I l faut absolument, en revanche, qu'il bénéficie du soutien sans faille de la direction, à la fois pour créer l'architecture et pour veiller à son application. Il doit, en même temps, faire preuve d'assez de souplesse pour accepter les retours utiles des développeurs et des autres intervenants. Voilà donc le portrait sommaire de l'architecte. Pour les systèmes d'envergure, i l est possible qu'un seul architecte ne suffise pas ; i l pourra être plus judicieux de désigner un conseil d'architectes chargé de développer l'architecture et d'en assurer la maintenance.

•—

W


mm*

section 12.6.2), alors que le modèle lui-même regroupe tous les cas d'utilisation. I l en va de même pour la vue architecturale du modèle de conception : elle a l'apparence d'un modèle de conception, mais elle ne réalise que les cas d'utilisation intéressants pour l'architecture. Autre raison pour laquelle i l est délicat de présenter un exemple de description : l'architecture n'offre d'intérêt que pour les systèmes réels. Or, si l'on veut ici parler d'un système en détail, i l faudra que ce soit un système minuscule. Cela étant, nous allons maintennni uli liser l'exemple simple du DAB tiré du chapitre 3 pour illustrer les conséquences de ces vues architecturales. Nous procéderons en comparant le contenu des vues et celui des modèles complets du système. La description de l'architecture s'articule en cinq sections et consacre chacune d'elles a un modèle différent. I l y a donc une vue du modèle des cas d'utilisation, une vue du modèle d'analyse (qui n'est pas toujours maintenue), une vue du modèle de conception, une vue du modèle de déploiement et une vue du modèle d'implémentation. I l n'y a pas de vue du modèle des tests, car celui-ci ne joue aucun rôle dans la description de l'architecture et ne sert qu'à tester l'architecture de référence.

4.5.1 Vue architecturale du modèle

des cas d'utilisation

La vue architecturale du modèle des cas d'utilisation présente les principaux acteurs et cas d'utilisation (ou scénarios de ces cas d'utilisation). Au sujet du modèle des cas d'utilisation du système de DAB, voir la section 3.3, « Capture des cas d'utilisation ». J^BR

Vue architecturale du modèle des cas d'utilisation du système de DAB Dans l'exemple du DAB, Reti rer de l'argent est le cas d'utilisation le plus important. Sans lui, lesystèmede DAB n'auraitaucun sens. Les cas d'utilisation Déposer de l'argent et Effectuer des virements entre comptes sont jugés moins importants pour le client moyen de la banque.

La mise au point de l'architecture nécessite un temps considérable. Ce laps de temps, fixé à l'avance sur le planning, risque de gêner certains responsables (chefs de projet), habitués à voir le temps de développement largement consacré à l'implémentation et aux tests. Pourtant, l'expérience nous montre, là encore, que la durée totale du développement décroît nettement lorsqu'une architecture saine guide les phases plus tardives. Nous aborderons ce point dans le chapitre 5.

Pour définir l'architecture, l'architecte suggère donc de procéder à l'implémentation intégrale 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é intéressant dans la perspective architecturale. (En pratique, une telle décision serait preuve d'une grande perspicacité, mais elle , n'est là que pour servir notre propos.)

4.5 Enfin, une description de l'architecture ! Après avoir discuté, dans les pages précédentes, de ce qu'est une architecture sans en donner la moindre illustration, nous allons maintenant présenter un exemple concret de description d'architecture. Mais i l nous faut, d'abord, expliquer la difficulté de l'entreprise. Rappelez-vous qu'une description d'architecture n'est qu'un extrait des modèles du système (c'est-à-dire qu'elle n'ajoute rien de nouveau). La première version de la description de l'architecture est un extrait de la version des modèles dont on dispose à la fin de la phase d'élaboration du premier cycle de vie. Comme on ne cherche pas à créer une version plus lisible de ces extraits, la description de l'architecture ressemble de près aux modèles ordinaires du système, ce qui signifie que la vue architecturale du modèle des cas d'utilisation évoque un modèle de cas d'utilisation normal. La seule différence 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 modèle des cas d'utilisation devra donc montrer la description complète du cas d'utilisation Retirer de l'argent.


de conception

La vue architecturale du modèle de conception présente les classificateurs de ce modèle ayant une importance cruciale pour l'architecture : les principaux sous-systèmes et interfaces, ainsi que quelques-unes des classes primordiales, essentiellement les classes actives. Cette vue expose également la façon dont les principaux cas d'utilisation sont réalisés en termes de classificateurs, c'est-à-dire les réalisations des cas d'utilisation. Nous retrouverons


I

les classes actives dans la section 4.5.3, en évoquant la vue du modèle de déploiement (dans lequel les classes actives sont affectées à des nœuds).

«sous-système* Interface

MWffl

Vue architecturale du modèle de conception du système 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 modèle de conception.

Figure 4.7 Structure statique de la vue architecturale du modèle de conception pour le système de DAB. Diagramme de classes décrivant les classes actives.

Gestionnaire de clients <

Gestionnaire

> de transactions

^


Client de la banque

DAB

K)<

Délivrance


4

Retrait «sous-système»

->CH I

Gestion des transactions

ô

Virements

Virements

ô

Dépôts

«sous-système» Gestion des comptes

Historique

Figure 4.8 Structure statique de la vue architecturale du modèle de conception pour le système classes décrivant les sous-systèmes et les interfaces qui les relient.

de DAB. Diagramme de

La structure statique ne suffit pas. Il faut également montrer la façon dont les sous-systèmes du modèle de conception réalisent les cas d'utilisation signifiants pour l'architecture. Nous allons, donc, à nouveau décrire le cas d'utilisation Reti rer de l'argent, cette fois par les interactions entre sous-systèmes 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-systèmes dialoguent les uns avec les autres pour exécuter une instance de cas d'utilisation. Ces objets échangent des messages, comme l'indique le diagramme. Les messages portent des noms qui spécifient, grâce à la notation « :: », les opérations que détiennent les interfaces des soussystèmes. Par exemple : Retrait: .effectuer (montant, compte). Retrait désigne l'interface fournie par une classe du sous-système Gesti on des transactions.

Par ailleurs, la section 3.4.4 nous a appris l'existence de trois sous-systèmes : I nterf ace du DAB, Gestion des transactions et Gestion des comptes ; voir la figure 4.8. Ces soussystèmes étant nécessaires à la réalisation du cas d'utilisation Reti rer de l'argent, ils sont donc signifiants sur le plan de l'architecture. Le modèle de conception comprend bien d'autres sous-systèmes qui ne seront pas pris en compte ici. Le sous-système Interface du DAB gère toutes les entrées émises par le client de la banque et les sorties qui lui sont adressées, comme l'impression de reçus et l'acceptation des commandes effectuées. Le sous-système 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-système Gestion des transacti ons contient les classes de comportement spécifique aux cas d'utilisation, notamment le comportement spécifique au cas d'utilisation Reti rer de l'argent. Dans l'exemple de la section 3.4.4, nous avions mentionné que les classes spécifiques aux cas d'utilisation se retrouvaient souvent, en fin de compte, dans différents sous-systèmes de service : par exemple, un sous-système de service différent pour chacune des classes Ret ra i t, Vi rement et Dépôt du sous-système Gesti on des transactions (n'apparaissant pas dans la figure 4.8). En fait, chaque sous-système de service de ce type contient en général plusieurs classes, mais notre exemple est extrêmement simple.

Figure 4.9 Sous-systèmes collaborant à l'exécution du cas d'utilisation Retirer de l'argent.

1 : Identifier(montant) 2 : Retrait: effectuer 3 : Virements: : valider et (montant, compte) retirer(montant, compter*" 1 1 1 «sous-système» «sous-système» «sous-système» Interface Gestion des Gestion des DAB transactions comptes 4 : Délivrance::autoriserDél!vrance (montant)

Client de la banque'* 5 : argent!)

Les points suivants expliquent brièvement le flot de la réalisation du cas d'utilisation Le texte en est presque identique à celui de la section 3.4.1 (description de la réalisation du cas d'utilisation), mais il est ici présenté sous l'angle des sous-systèmes et non sous celui des classes.

Les sous-systèmes 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-système Gest i on des comptes. Les interfaces Vi rements, Retrait et Dél i vrance sont décrites dans la section 3.4.4. Il existe également des interfaces Vi rement, Dépôts et Historique ; mais comme elles sont pas impliquées dans le cas d'utilisation évoqué dans cet exemple, nous n'en donnons pas d'explication.

Pré-condition : le client de la banque dispose d'un compte en banque opérationnel pour le

L'acteur Cl ient de la banque choisit de retirer de l'argent et s'identifie auprès de l'I nterf ace du DAB, par exemple en utilisant une carte magnétique ayant un numéro et un code secret. Le Cl i ent de • Ta b a n q u e indique également le montant du retrait et le compte à partir duquel il souhaite l'effectuer. Nous supposons, ici, que le sous-système 1 nterf ace du DAB est en mesure de valider l'identité du client. Interface du DABdemandeausous-systèmeGestion des transactions d'effectuer le retrait. Ce sous-système est chargé d'effectuer toute la séquence de retrait comme une transaction atomique, de façon que le montant soit à la fois déduit du compte et délivré au Cl ient de la banque.


I

3. Gestion des transactionsdemandeau sous-système Gestion des comptes d'effectuer le retrait. Le sous-système Gestion des comptes détermine si le montant peut ou non être retiré et, si oui, déduit la somme du compte et renvoie un message indiquant que le retrait est possible. 4. Gestion des transactions autorise le sous-système Interface du DAB à délivrer la somme. 5. Interface du DAB délivre la somme au Cl ient de la banque.


de

déploiement

Figure 4.10 Le modèle de déploiement définit trois nœuds : Client du DAB, Serveur d'applications du DAB et Serveur de données du DAB.


Client du DAB

Internet

Client de la banque

4

Serveur d'applications du DAB

/

Le modèle de déploiement définit l'architecture physique du système en termes de nœuds connectés. Ces nœuds sont des unités matérielles sur lesquelles s'exécutent les composants logiciels. I l est fréquent que l'on sache à quoi ressemblera l'architecture physique du système avant de commencer à développer le système. Les nœuds et connexions peuvent alors être modélisés dans le modèle de déploiement dès l'enchaînement d'activités des besoins.

Serveur de données du DAB

C'est au cours de la conception que l'on décide quelles classes seront actives, c'est-à-dire quelles sont celles qui seront des threads ou des processus. On détermine également le rôle et le cycle de vie de chaque objet actif, mais aussi le mode de communication, de synchronisation et de partage des informations entre ces différents objets. Les objets actifs sont affectés aux nœuds du modèle de déploiement en fonction, d'une part, des capacités de ces nœuds, notamment leur capacité de traitement et la taille de leur mémoire, et, d'autre part, des caractéristiques des connexions, comme leur largeur de bande ou leur disponibilité. Les nœuds et connexions du modèle de déploiement et l'affectation des objets actifs à ces nœuds peuvent être décrits par le biais de diagrammes de déploiement (Annexe A), qui peuvent également indiquer la façon dont les composants exécutables sont alloués aux nœuds. Le système de DAB de notre exemple est distribué sur trois nœuds différents.

Une fois les nœuds définis, il est possible de déployer dessus les fonctionnalités. Par souci de simplicité, nous déployons chaque sous-système (voir la figure 4.8) dans son entier sur un seul nœud. Le sous-système Interface du DAB est ainsi déployé sur le nœud Cl ient du DAB, le sous-système Gestion des transactions sur le nœud Serveur d'applications du DAB, et le sous-système Gesti on des comptes sur le nœud Serveur de données du DAB. Chaque classe active de ces sous-systèmes (voir la section 3.4.4 et la figure 3.10) est donc déployée sur le nœud correspondant et représente un processus s'exécutant sur le nœud. Chaque processus entretient et conserve dans son espace de processus les objets des autres classes (les classes ordinaires, non actives) du sous-système. La figure 4.11 montre le déploiement des objets actifs. (Les objets actifs apparaissent sous forme de rectangles entourés

I f l l f l f l Vue architecturale du modèle de déploiement du système de DAB Le Cl i ent de la banque accède au système par l'intermédiaire d'un nœud Cl i ent du DAB, qui accède au Serveur d'applications du DAB pour effectuer les transactions (figure 4.10). Le Serveur d'applications du DAB utilise, à son tour, le Serveur de données du DAB pour effectuer des transactions spécifiques 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 Déposer de l'argent ou Effectuer des virements entre comptes. Dans la section 3.4.3, nous décrivons les classes sélectionnées pour la réalisation du cas d'utilisation Retirer de l'argent.

Figure 4.11 Vue architecturale du modèle de déploiement. Les classes actives du système de DAB sont distribuées entre les nœuds.

de larges

bordures.)

: Gestionnaire de comptes

: Gestionnaire de transactions

: Gestionnaire

: Serveur de données du DAB

: Serveur d'applications du DAB

: Client du DAB

Il s'agit là d'un exemple naïf de distribution du système. Dans un véritable système, la distribution serait, évidemment beaucoup plus complexe. On aurait pu, comme solution alternative à ce problème, utiliser un middleware de distribution des objets tel qu'un ORB.


d'implémentation

Le modèle d'implémentation présente une correspondance directe avec les modèles de conception et de déploiement. Chaque sous-système de service du modèle de conception se traduit généralement par un composant pour chaque type de nœud sur lequel il doit être ins-

•


I

tallé. Mais pas toujours. I l arrive qu'un même composant (par exemple, un composant gestionnaire de mémoire tampon) soit instancié et exécuté sur plusieurs nœuds. Certains langages fournissent des constructions, telles que les JavaBeans, permettant de regrouper les composants. Sinon, les classes sont réparties en fichiers de code représentant l'ensemble de composants choisi.

4.7

Nous avons mentionné, dans la section 3.4.5, que le sous-système de service Gestion des retraits pouvait éventuellement être réalisé 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 implémenter la classe Retrait, tandis que le composant « R e t r a i t s sur le client » implémenterait une classe Mandataire de retraits. Dans notre exemple simple, ces composants n'implémenteraient chacun qu'une seule classe. Dans un véritable système, en revanche, les sous-systèmes de service comprendraient davantage de classes, si bien que chaque composant en implémenterait plusieurs.

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

4

tm |

Références

ERICH GAMMA, RICHARD HELM, RALPH JOHNSON, and JOHN VLISSIDES, Design Patterns: Eléments of Reusable Object-Oriented Software, Reading, MA: AddisonWesley, 1994.

5

F. BUSCHMANN, R. MEURIER, H. ROHNERT, P. SOMMERLAD, M . STAL, A System of Patterns, New York: John Wiley and Sons, 1996.

4

P.B. KRUCHTEN. "The 4+1 view model of architecture," IEEE 1995.

3

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.

2

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.

1

7

4,6.1 Qu'est-ce que l'architecture ?

6

4.6 Trois concepts intéressants C'est ce que l'architecte spécifie dans une description d'architecture. La description de l'architecture laisse à l'architecte la maîtrise technique du développement du système. L'architecture logicielle s'intéresse à la fois aux éléments structuraux significatifs du système, tels que les sous-systèmes, les classes, les composants et les nœuds, et aux collaborations se produisant entre ces éléments par l'intermédiaire des interfaces.

Software, November

OMG, Inc. The Common Object Request Broker: Architecture and Spécification (CORBA), Framingham, MA. 1996. ISO/IEC International Standard 10165-4 = ITU-T Recommendation X.722.

THOMAS J. MOWBRAY and RAPHAËL C. M A LVEAU, CORBA Design Patterns, New York: John Wiley and Sons, 1997.

9

ITU-T Recommendation M.3010, Principles for a Télécommunication Management Network.

8

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.

Les cas d'utilisation orientent l'architecture de telle sorte que le système offre les usages et fonctionnalités désirés 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 réutilisation de logiciels existants.

4.6.2. Comment l'obtient-on ? L'architecture est développée de façon itérative au cours de la phase d'élaboration au travers de l'expression des besoins, de l'analyse, de la conception, de l'implémentation et des tests. Les cas d'utilisation signifiants sur le plan de l'architecture, ainsi que certaines entrées d'un autre type, permettent d'implémenter l'architecture de référence, ou « squelette », du système. Cet ensemble d'entrées supplémentaires comprend les besoins logiciels du système, les middleware, les systèmes existants à réutiliser, les besoins non fonctionnels, et ainsi de suite.

4.6.3 Comment la décrit-on

?

La description de l'architecture est une vue des modèles du systèmes : modèles des cas d'utilisation, d'analyse, de conception, d'implémentation et de déploiement. Elle décrit les parties du système qu'il est important, pour les développeurs et les autres intervenants, de comprendre.

5

Un processus itératif et incrémental Pour être efficace, un processus logiciel doit comporter une séquence de jalons (Annexe C) clairement articulés fournissant aux responsables et à l'équipe de développement les critères nécessaires au passage d'une phase à l'autre du cycle de vie d'un produit. Le processus parcourt chaque phase par une série d'itérations et d'incréments (Annexe C) qui conduisent à ces critères. Dans la phase de création, le critère essentiel est celui de la viabilité, accessible au travers des activités suivantes : • l'identification et la réduction des risques (Annexe C ; voir également la section 12.5) pesant sur la viabilité du système ; • la transformation, par le biais de la modélisation des cas d'utilisation, d'un sous-ensemble de besoins clés en une architecture candidate ; • une première estimation approximative du coût, des efforts, du calendrier de développement 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 vérifier, là encore de façon approximative, la rentabilité économique du projet. Dans la phase d'élaboration, le critère essentiel est celui de la capacité à construire le système au sein d'une infrastructure économique, accessible au travers des activités suivantes : • l'identification et la réduction des risques affectant de façon significative la construction du système ; • la spécification de la plupart des cas d'utilisation représentant les fonctions à développer ; • l'extension de l'architecture candidate aux proportions d'une architecture de référence exécutable ;

PARTIE

m m M


wwmm

I

• la préparation d'un plan de projet (Annexe C) suffisamment détaillé pour guider la phase de construction ; • la réalisation d'une estimation suffisamment précise 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 critère essentiel est celui d'un début de fonctionnement du système dans l'environnement utilisateur, critère accessible au travers des activités suivantes : • une série d'itérations menant régulièrement à des constructions et à des incréments, afin de démontrer la viabilité du système de façon exécutable tout au long de cette phase. Dans la phase de transition, le critère essentiel est celui du fonctionnement complet du système, accessible au travers des activités suivantes : • la modification du produit afin d'éliminer les problèmes non identifiés dans les phases antérieures ; • 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, développeurs et intervenants d'une manière générale de saisir l'importance des premières phases. Nous ne pouvons, en ce sens, que rappeler les conseils prodigués par Barry Boehm, i l y a déjà plusieurs années [1] : Je ne puis insister davantage sur l'importance décisive que revêt le jalon Architecture du cycle de vie (LCA) [qui correspond à notre jalon definde la phase d'élaboration] pour votre projet et votre carrière. Si vous ne satisfaites pas au critère du jalon LCA, inutile de poursuivre le développement. Réunissez à nouveau les intervenants et élaborez ensemble un nouveau plan de projet qui répondra à ce critère. Les phases, et les itérations qui les constituent, font l'objet d'une étude plus détaillée dans la troisième partie de l'ouvrage.

5.1 Le d é v e l o p p e m e n t itératif et incrémental en bref Comme nous l'avons fait remarquer dans les chapitres 3 et 4, le fait que le processus de développement 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 résultant du processus. L'influence capitale qu'exercent les cas d'utilisation signifie que chaque phase conduisant à la livraison finale du produit se réfère à ce que font réellement les utilisateurs, ce qui permet de s'assurer que le système répond à leurs véritables besoins. Par ailleurs, la place centrale accordée à l'architecture induit une orientation du travail de développement vers la réalisation d'un pattern architectural qui guidera la construction du système dès les premières phases, et garantira ainsi une progression en douceur non seulement vers la livraison de la version en cours, mais aussi vers toute la durée de vie du produit.

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

^

cTÎAPn^REJmW

Parvenir à un juste équilibre entre cas d'utilisation et architecture revient, grosso modo, à harmoniser forme et fond dans le développement d'un produit. Seul le temps le permet. Savoir ce qui vient en premier nous ramène, encore et toujours, au problème de l'œuf et de la poule, comme nous l'avons indiqué dans la section 4.3. Ce sont d'interminables itérations, survenues au cours du long processus d'évolution, qui ont donné naissance à la poule et à l'œuf. De la même façon, aufilde ce processus plus court qu'est le processus de développement logiciel, les développeurs recherchent consciencieusement cet équilibre (entre cas d'utilisation et architecture) à travers une série d'itérations. L'approche itérative-el-in< \v mentale du développement constitue bien, par conséquent, le troisième pivot du Processus unifié.

5.7.1 Procéder

par étapes

modestes

Ce troisième aspect propose une stratégie de développement d'un produit logiciel par petites étapes faciles à gérer : • on planifie un peu ; • on spécifie, on conçoit et on implémenté un peu ; • on intègre, on teste et on exécute un peu chaque itération. Dès 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 prévues, vous avez mis au point un produit livrable aux clients et utilisateurs. Les itérations des premières phases cherchent essentiellement à délimiter la portée du projet, à éliminer les risques majeurs et à esquisser l'architecture de référence. Puis, à mesure qu'avance le projet, que sont peu à peu écartés les derniers risques et que sont implémentés les composants, la forme des itérations change et se traduit par des incréments. Un projet de développement 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 itérative et incrémentale, l'accommodation se fait petit à petit. En d'autres termes, on scinde le projet en une série de mini-projets, dont chacun constitue une itération. Chaque itération se présente de la même façon que n'importe quel projet de développement logiciel : planification, enchaînements d'activités (besoins, analyse et conception, implémentation, tests) et préparation de la version. Mais une itération n'est pas une entité totalement indépendante : c'est une étape d'un projet. Elle tire d'ailleurs beaucoup de cette appartenance à un projet. Nous qualifions les itérations 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 modèle en cascade, car i l met en œuvre les activités de ce type de modèle. On pourrait dire de chaque itération que c'est une « mini-cascade ». Le cycle de vie itératif livre des résultats tangibles sous forme de versions internes (quoique préliminaires). Chacune de ces versions ajoute un incrément et prouve qu'elle a procédé à la

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 itératif et i n c r é m e n t a l CHAPITRE

réduction des risques dont elle était chargée. Ces versions peuvent être présentées aux clients et aux utilisateurs et susciter ainsi des retours précieux pour la validation du travail. Les personnes chargées de la planification tentent d'ordonner les itérations de façon à tracer une voie directe entre itérations et de permettre à chacune d'entre elles d'exploiter la base de connaissances que constituent les itérations précédentes. Les premières itérations du projet dévoilent un pan inexploré des besoins, des problèmes, des risques et du domaine de la solution (Annexe C), tandis que les itérations plus tardives se traduisent par des incréments successifs qui finissent par constituer la version externe (Annexe C), c'est-à-dire le produit destiné au client. La véritable réussite, pour les planificateurs, c'est de parvenir à une séquence d'itérations en perpétuelle avancée : ne jamais avoir à revenir en arrière pour colmater le modèle après avoir appris quelque chose de nouveau au cours d'une itération ultérieure. L'idée, 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 arrière. En résumé, un cycle de vie se compose d'une séquence d'itérations. Certaines, en particulier les premières, aident à appréhender 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 incréments jusqu'à ce que l'on parvienne à un produit livrable au client. Les itérations contribuent à la planification, à l'organisation, à la surveillance et au contrôle du projet. Réparties dans les quatre phases du développement, elles présentent chacune leurs propres besoins en termes de ressources humaines, de financement, de calendrier et de critères d'entrée et de sortie. Au début de chaque phase, les responsables peuvent décider du mode d'exécution de chaque itération, des résultats qu'elle devra livrer et des risques qu'elle devra atténuer.

!> 1.2 Ce que n'est pas une

itération

Certains responsables pensent que l'expression « itératif ou incrémental » est un charmant euphémisme pour « bidouillage ». Es craignent que les mots ne servent qu'à jeter un voile pudique sur le fait que les développeurs ne savent pas ce qu'ils font. On peut concéder, dans la phase de création et même au début de la phase d'élaboration, que cette crainte n'est pas totalement dénuée de fondement. Si, par exemple, les développeurs n'ont pas résolu les risques majeurs ou significatifs, i l faut alors reconnaître que cette position se défend. S'ils n'ont pas encore démontré la viabilité du concept sous-jacent, ni établi une architecture de référence, là encore, cette affirmation est exacte. Si, enfin, ils n'ont toujours pas déterminé de quelle façon implémenter les besoins décisifs, 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 prétendre qu'ils savent quand même ce qu'ils font ? De faire reposer un plan sur des informations insuffisantes ? De suivre un plan auquel on ne pourra se fier ? Bien sûr que non.

5

• ce n'est pas un phénomène ne concernant que les développeurs ; • ce n'est pas une tentative indéfiniment renouvelée jusqu'à ce que les développeurs tombent par hasard sur quelque chose qui fonctionne ; • ce n'est pas un processus imprévisible ; • ce n'est pas une excuse pour l'absence de plan et une gestion inexistante. En fait, l'itération contrôlée est loin d'être exécutée au hasard. Elle est planifiée. C'est un outil qui permet aux responsables de maîtriser le projet. Elle permet de réduire, dès les premiers stades du cycle de vie, les risques susceptibles de menacer la progression du développement. A l'issue des itérations, les versions internes (Annexe C) ouvrent la voie aux retours des intervenants, qui permettent, à leur tour, de rectifier très tôt l'orientation du projet.

5.2 Pourquoi un d é v e l o p p e m e n t itératif et incrémental ? La réponse tient en quatre mots : pour de meilleurs logiciels. En une phrase, pour atteindre les jalons majeurs et mineurs qui permettent de maîtriser le développement. Enfin, pour être un peu plus précis : • pour prendre en main très tôt les risques importants ; • pour proposer une architecture qui guidera le développement logiciel ; • pour fournir une infrastructure préfabriquée (framework) capable de mieux prendre en compte les exigences incontournables et les autres changements ; • pour élaborer progressivement le système, de façon incrémentale, au lieu de tout faire d'un coup, vers la fin, lorsque les changements coûtent cher ; • pour offrir un processus de développement favorisant la productivité de l'équipe.

5.2.1 Réduire

les risques

Comme toute autre activité d'ingénierie, le développement logiciel est soumis à des risques. « Le risque est inhérent à l'engagement de ressources actuelles vers des attentes futures », selon le prophète du management Peter F. Drucker [2]. Dans le développement logiciel, on s'accommode de cette réalité en identifiant les risques dès que l'on peut et en les traitant le plus tôt possible. Un risque est une exposition pouvant conduire à une perte ou à un dommage. Le risque est un facteur, un phénomène, un élément ou une évolution constituant un danger dont le degré reste incertain. En matière de développement logiciel, on peut définir un risque comme un problème ayant quelque probabilité de compromettre la réussite d'un projet. Par exemple : • i l est possible que l'ORB (Object Request Broker) (Annexe C) initialement prévu ne soit pas en mesure de gérer 1 000 recherches distantes à la seconde d'objets de comptes clients ;

À titre indicatif, insistons sur ce que n'est pas un cycle de vie itératif : • ce n'est pas un bidouillage de fortune ; • ce n'est pas une attraction pour développeurs ;

• i l est possible qu'un système temps réel doive acquérir des données d'entrée dont le volume n'a pas été spécifié dans la phase de création. I l est également possible qu'il ait à traiter les données par d'importants calculs qui, toutefois, ne sont pas expliqués en détails.


I

Il est possible, enfin, qu'il ait à émettre un signal de commande dans un laps de temps court, mais non précisé ; • il est possible qu'un système de commutation téléphonique ait à répondre à diverses entrées en un nombre de millisecondes spécifié par l'opérateur de télécommunications client. Ce qu'il faut au domaine logiciel, écrivait Barry Boehm i l y a de nombreuses années, c'est un modèle de processus capable de « créer une approche du processus logiciel orientée vers la réduction des risques, au lieu d'un processus essentiellement guidé par la production documents ou la création de code » [3]. Le Processus unifié satisfait à ces critères en traitant les principaux risques dans les deux premières phases, celles de création et d'élaboration, et tous les autres risques par ordre d'importance, dès le début de la phase de construction. I l permet d'identifier, de gérer et de réduire les risques dès les premières phases au moyen des itérations. Ce qui évite le surgissement tardif de risques non identifiés ou ignorés de nature à menacer tout le projet. L'approche itérative de la réduction des risques n'a qu'une très lointaine parenté avec l'approche en cascade (Annexe C). Le modèle en cascade montre le déroulement du développement dans une seule direction, à travers une série d'étapes : besoins, analyse, conception, implémentation et tests. Cette approche mobilisait tous les développeurs du projet au moment de l'implémentation, de l'intégration (Annexe C) et des tests. Et c'est au cours de l'intégration et des tests que les problèmes commençaient à fuser de toutes parts. Le chef de projet était alors obligé de réaffecter certains membres de l'équipe (en général, les développeurs les plus chevronnés) pour qu'ils résolvent ces problèmes avant que le travail puisse reprendre son cours. Mais, i l paraissait délicat, alors que les développeurs étaient déjà tous occupés, de « dégager » les plus compétents d'entre eux pour traiter les problèmes nouvellement identifiés. En plus, pour aggraver la situation, la réaffectation des développeurs les plus expérimentés aux tâches de « nettoyage » entraînait souvent l'immobilisation des développeurs moins qualifiés qui n'avaient plus qu'à attendre, assis sur leur chaise. Les délais arrivaient à échéance, les coûts 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 développement, comme dans la figure 5.1, on s'aperçoit que le développement itératif commence à réduire les risques les plus graves dès les premières itérations. Quand arrive le moment de la construction, i l reste peu de risques sérieux et le travail peut se poursuivre en toute quiétude. Avec l'approche en cascade, en revanche, les risques sérieux ne sont pas traités avant le « big bang » de l'intégration du code.

Figure 5.1 Les risques graves sont identifiés et réduits très tôt dans le développement itératif, contrairement à ce qui se passe dans le développement en cascade. Là, les risques les plus sérieux persistent jusqu 'à ce qu 'ils soient traités par l'intégration et les tests du système (ligne pointillée). Les itérations indiquées au bas de la figure ne sont, évidemment, pertinentes que pour l'approche itérative et incrémentale.

Gravité des risques


5

Cascade

Période d'intégration et de tests de l'approche / en cascade

Création

Itératif, incrémental

^Construction

iter. #n-1

iter.

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 première étape consiste à s'attaquer aux risques très tôt dans le processus de développement.

5.2.2 Obtenir une architecture robuste La mise en place d'une architecture robuste est, en soi, le résultat des itérations menées dans les premières phases du développement. Dans la phase de création, par exemple, on cherche à élaborer une architecture de base capable de satisfaire aux exigences majeures, de surmonter les risques décisifs et de résoudre les principaux problèmes du développement. L'investissement consenti dans ces phases reste modeste et l'on peut se permettre d'effectuer ces itérations pour s'assurer de la solidité de l'architecture. Par exemple, on se trouve, après la première itération de la phase d'élaboration, en mesure de faire une première évaluation de l'architecture. A ce moment-là, i l est toujours temps de modifier cette architecture, si besoin est, pour répondre 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 découvre qu'il est nécessaire de modifier l'architecture, les efforts engagés dans le développement sont déjà tels que le moindre changement entraîne une lourde sanction financière. En plus, on se trouve, à ce moment-là, tout près de la date de livraison prévue. Écartelé entre coûts et délais, il est probable qu'on hésitera à se lancer dans une réorientation architecturale majeure. La prépondérance accordée à l'architecture dès la phase d'élaboration permet d'éviter ce genre de dilemme. On stabilise ainsi l'architecture à un niveau de référence très tôt dans le cycle de vie, lorsque les coûts sont encore faibles et que les délais de livraison restent un horizon lointain.


Un processus itératif et i n c r é m e n t a l

••

I

5.2.3 Gérer les exigences de changement Les utilisateurs ont plus de facilité à comprendre un système qui fonctionne, même s'il ne fonctionne pas parfaitement, qu'un système qui n'existe que sur le papier. De la même façon, ils ont du mal à admettre la progression d'un projet si l'on n'a rien d'autre à leur présenter 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 série de versions exécutables, ou « constructions », que de présenter des piles de documentation sibylline. Une construction est une version opérationnelle d'une partie d'un système faisant la démonstration d'un sous-ensemble des fonctions du système. Chaque itération peut procéder par une série de constructions pour approcher du résultat prévu, c'est-à-dire de l'incrément. Le fait de disposer d'un système en état de fonctionnement partiel dès les premières phases permet aux utilisateurs et aux autres intervenants de suggérer des améliorations et de signaler des besoins ayant pu être négligés. Le plan (budget et calendrier) n'étant, à ce moment-là, pas encore gravé dans le marbre, les développeurs peuvent plus facilement prendre en compte les révisions. Dans le modèle en cascade à sens unique, les utilisateurs ne voient aucun système en état de marche avant l'intégration et les tests. A ce stade, les changements, même ceux qui ont de l'importance ou ceux pouvant paraître modestes, entraînent presque inévitablement des rallonges budgétaires et temporelles. Le cycle de vie itératif permet donc aux utilisateurs de détecter plus tôt dans le cycle de développement la nécessité d'ajouter ou de modifier des exigences, et aux développeurs de les intégrer. En fin de compte, l'élaboration du système se faisant par une série d'itérations, la prise en compte des remarques et l'intégration des révisions ne représentent guère qu'un changement incrémental.

5.2.4 Permettre des changements tactiques L'approche itérative et incrémentale permet aux développeurs de résoudre les problèmes et les questions soulevés par les premières constructions et d'intégrer les changements afin de les corriger presque immédiatement. Grâce à cette approche, les problèmes sont régulièrement mis au jour, à un rythme que les développeurs n'éprouvent aucune difficulté à soutenir. À l'inverse, l'avalanche de rapports d'anomalies qui s'abat au moment du « big bang » de l'intégration dans l'approche en cascade a souvent pour effet de désorganiser la progression du projet. Désorganisation qui peut aller jusqu'à l'interruption pure et simple du projet : les développeurs ploient sous la pression, les chefs de projet se rongent les sangs et les autres responsables sont pris de panique. Une série de constructions opérationnelles, à l'inverse, procure à chacun un agréable sentiment d'accomplissement. Les testeurs, rédacteurs de manuels, développeurs 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 très tôt des retards prévus, au moment même où les développeurs rencontrent les problèmes qui les susciteront, ce qui leur laisse le temps d'adapter leur planning. En revanche, lorsque les problèmes restent dissimulés jusqu'aux tests, il est trop tard pour se réorganiser de façon efficace.

Une fois que l'équipe d'assurance qualité a testé une itération, les chefs de projet, architectes et autres intervenants peuvent l'évaluer en fonction de critères prédéfinis. Ils déterminent si l'itération a, ou non, produit l'incrément voulu et si les risques ont, ou non, été correctement traités. Cette évaluation permet aux responsables d'estimer la réussite ou l'échec de l'itération. Si c'est un succès, ils peuvent autoriser le passage à l'itération suivante. Si l'itération n'est que partiellement réussie, ils peuvent la prolonger ou différer les questions non résolues et le travail de fignolage à l'itération suivante. Dans le cas extrême où l'évaluation serait totalement négative, il reste possible d'annuler tout le projet.

5.2.5 Parvenir à une intégration

continue

À l'issue de chaque itération, l'équipe du projet démontre qu'elle a procédé à la réduction de certains risques et livre un nombre croissant de fonctions aux intervenants, qui peuvent ainsi constater l'évolution du projet. La livraison fréquente de constructions oblige les développeurs à conclure régulièrement leur travail par une partie de logiciel exécutable. I l devient difficile, dans ces conditions, de soutenir mordicus que le projet est à « 90% terminé ». On rencontre ce genre d'optimisme exagéré lorsque le décompte 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 tâche la plus ardue reste à venir. D n'est pas exclu que certains problèmes n'aient pas encore été révélés par des tentatives d'intégration et de test du système. A l'inverse, étant donné que les itérations successives fonctionnent, elles produisent des résultats indiquant très précisément l'état d'avancement du projet. Même si les développeurs n'atteignent pas les résultats escomptés dans les premières itérations, il leur reste suffisamment de temps pour réessayer et améliorer les modèles dans les versions internes suivantes. Le fait de travailler d'abord sur les problèmes les plus délicats leur donne maintes occasions d'améliorer les solutions proposées. La ligne épaisse de la figure 5.2 (présentée à l'origine dans [5]) illustre le fonctionnement du développement itératif. Un incrément (ou construction) est assemblé dès les premiers stades du calendrier, alors que seuls 2 à 4% du projet sont ici codés. Cette tentative fait apparaître certains problèmes, indiqués par les petits creux de la ligne de progression, mais qui sont rapidement surmontés et n'empêchent donc pas la reprise de la progression. À partir de là, le projet crée de fréquentes constructions, chacune pouvant mener à une interruption temporaire du projet. Les incréments étant relativement modestes par rapport à l'intégration finale du produit entier (sur la ligne du bas), la récupération peut être assez rapide.

>


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

I

Tests finals de q u a l i t é j

Progression (% c o d é )

D é b u t de l'intégration de l'approche en cascade

construction.' construction \j,''

'•construction

10080-

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 péril la progression à long terme du projet, puisqu'elle apparaît dès la tentative de construction suivante. L'approche itérative aide aussi à la prise en charge des risques non techniques, tels que les problèmes d'organisation. I l est possible, par exemple, que les développeurs n'apprennent pas assez vite : • à construire des applications à l'aide d'un ORB ;

9070-

Développement en cascade

605040-

• à utiliser les outils de test ou de gestion de configuration (Annexe C) ; Rupture tardive de la conception,

Développement itératif

3020-

construction 10V 10

20

25

30

40

35

45

Temps (mois) Figure 5.2 Dans l'approche en cascade (ligne claire), les développeurs ne débutent pas l'implémentation avant d'avoir finalisé l'expression des besoins, l'analyse et la conception. Les problèmes demeurent, à un niveau très bas jusqu'à l'intégration et aux tests qui les révèlent en bloc (Rupture tardive de la conception). Dans le développement itératif, l'implémentation débute plus tôt et les constructions fréquentes permettent de mettre au jour très tôt les problèmes.

Dans l'approche en cascade, comme le suggère le diagramme, c'est une intégration unique proche de la date de livraison qui révèle une pléiade de problèmes. L'ampleur des problèmes et l'inévitable précipitation qui règne à ce stade signifient que la plupart des corrections ne seront pas sérieusement préparées. La découverte des problèmes et leur correction diffèrent souvent la livraison au-delà de la date prévue. Ce qui revient à dire que le développement itératif prend, enfinde compte, moins de temps que le développement en cascade. En plus, le produit issu d'un « projet en cascade » risque d'être fragile, c'est-à-dire difficile à maintenir.

5.2.6 Accéder

très tôt à la connaissance

Après une ou deux itérations, tous les membres de l'équipe se font une idée assez claire de la nature des différents enchaînements d'activités. Ils savent ce qui vient après 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 atténué. L'intégration de nouveaux collaborateurs est, en outre, facilitée puisque ceux-ci peuvent être formés sur le tas. Il n'est plus nécessaire 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 tâches directement liées au projet. A condition qu'ils reçoivent la formation adéquate et qu'ils soient entourés de personnes expérimentées, ils rattraperont

• à se conformer au processus de développement logiciel. Au fil des itérations, une petite équipe se familiarise avec ces nouvelles technologies, outils et processus, les utilise de plus en plus fréquemment et gagne en compétence. À mesure que le projet avance, l'équipe s'étoffe et peut ainsi passer de 5 à 10 personnes, puis à 25 et finalement à une centaine. Grâce à cette évolution mesurée, le noyau dur de l'équipe peut guider les nouveaux venus au rythme de leur arrivée. L'approche itérative permet à l'équipe d'origine d'optimiser le processus et les outils avant que la masse des développeurs ne se joignent à eux. En travaillant par phases et par itérations, les développeurs ont de meilleures chances de satisfaire aux besoins réels des clients et de réduire les risques. La construction d'incréments permet à chacun d'observer son niveau de progression, tandis que la réduction des difficultés tardives raccourcit le délai de mise sur le marché. Enfin, cette approche itérative bénéficie non seulement aux développeurs et, en fin de compte, aux utilisateurs, mais également à leurs responsables. Ceux-ci peuvent, en effet, prendre la mesure des véritables progrès en prenant acte des itérations achevées.

5.3 L'approche itérative est guidée par la réduction des risques Un risque est une variable d'un projet qui met en danger, voire compromet totalement, la réussite du projet en question. C'est « la probabilité selon laquelle un projet peut être confronté à des événements indésirables, comme des retards de calendrier, des dépassements de budget ou une annulation pure et simple » (voir le glossaire dans [4]). Les itérations sont identifiées, hiérarchisées et menées 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 premières 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 itérations de façon à réduire au maximum les risques. D'autres risques relèvent des performances (vitesse, capacité, précision), de la fiabilité, de la disponibilité, de l'intégrité de l'interface du système, 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

les fonctions sous-jacentes n'a pas été implémenté et testé. C'est pourquoi il est nécessaire tic mener des itérations d'exploration des risques tout au long du développement jusqu'au codage et aux tests, et même dans les phases de création et d'élaboration. L'objectif est d'épingler le risque le plus tôt possible. Il est intéressant de constater que, en principe, tous les risques techniques peuvent être reliés à un cas d'utilisation ou à un scénario d'un cas d'utilisation. Ici, reliés signifie que le risque est atténué si le cas d'utilisation est réalisé avec ses besoins fonctionnels et non fonctionnels. ( 'ette observation ne s'avère pas seulement pour les risques relevant des besoins ou de l'architecture, mais aussi pour la vérification du matériel et des logiciels sous-jacents. Une sélection attentive des cas d'utilisation permet de tester toutes les fonctions de l'architecture sous-jacente. I .a réduction des risques est cruciale pour les itérations menées dans les phases de création et d'élaboration. Dans la phase plus tardive de construction, les risques ont, dans l'ensemble, été ramenés à un niveau normal, ce qui signifie qu'ils donnent lieu à des pratiques de développement ordinaires. Les itérations doivent, si possible, être ordonnées de telle sorte que chacune se nourrisse de celle qui précède. Dans cette phase, on essaie, en particulier, d'éviter d'avoir à reprendre plusieurs itérations dans le cas où leur ordre n'ait pas été judicieusement établi.

5.3.1 Les itérations

atténuent

les risques techniques

Les risques ont fait l'objet de nombreuses classifications (voir [3] et [4]). I I suffira, pour notre propos, de suggérer quelques pistes sans prétendre à l'exhaustivité. Nous avons, pour notre part, identifié quatre grandes catégories de risques. 1. Les risques liés aux nouvelles technologies : • i l peut être nécessaire de répartir les processus sur un grand nombre de nœuds, ce qui risque de créer des problèmes de synchronisation ; • i l est possible que certains cas d'utilisation dépendent 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. 2. Les risques liés à l'architecture. Ces risques sont tellement importants que c'est pour standardiser leur résolution que nous avons conçu le Processus unifié. En effet, la phase d'élaboration du Processus et les itérations architecturales qui la composent prévoient une place explicite pour les prendre en compte. La mise en place, très tôt, 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 résistante aux risques est robuste. La prise en charge fluide des changements est caractéristique de la robustesse architecturale (Annexe C). L'autre avantage de disposer très tôt d'une architecture solide est d'indiquer les possibilités d'intégration de composants réutilisables, ce qui permet assez vite d'envisager d'avoir recours à des produits du commerce, plutôt que de les fabriquer. Cela évite également de découvrir trop tard qu'un système sera trop cher à construire. Par exemple :


5

• les cas d'utilisation initialement sélectionnés n'aident pas à trouver la structure de soussystèmes capable de faire évoluer le système par l'intégration de cas d'utilisation plus tardifs. Dans les premières itérations, disons dans la phase d'élaboration, nous n'avons peut-être pas remarqué que plusieurs acteurs allaient utiliser le même cas d'utilisation par le biais d'interfaces différentes. On trouvera un exemple de ce type de situation avec la présence de plusieurs interfaces pour le retrait d'argent liquide : la première emploie une interface utilisateur graphique et un ordinateur personnel ; la seconde un protocole de communication sur un réseau. Si l'on ne prévoit, dans la conception, que de répondre à 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 système soit difficile à faire évoluer ; • certaines infrastructures préfabriquées (frameworks) (Annexe C) prévues pour être réutilisées n'ont jamais été utilisées 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 réutilisation ne sera pas des plus simples ; • i l est possible que la nouvelle version du système d'exploitation que l'on prévoit 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 système d'exploitation. 3. Les risques liés à la construction du système attendu, c'est-à-dire d'un système capable de prendre en charge la mission qui lui est confiée 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 déterminer très tôt quelles sont les fonctions les plus importantes et de s'assurer qu'elles sont rapidement implémentées. Nous classons ici les cas d'utilisation par ordre d'importance pour la satisfaction des besoins des clients et des exigences de performances. Nous considérons à la fois le comportement et les capacités telles que les performances. L'ordre dans lequel sont traités les cas d'utilisation, au moment de leur sélection, est fonction du degré et du type de risque qu'ils présentent : par exemple, la possibilité de risques entraînés par l'exécution même du cas d'utilisation. Il existe, en particulier dans les phases de création et d'élaboration, une corrélation étroite entre certains besoins (et les cas d'utilisation qui les expriment) et les risques qu'ils comportent. Les cas d'utilisation que sélectionne l'équipe ont un impact sur l'architecture qu'ils développent. Par exemple : • le cas d'utilisation Transfert d'appel s permet à un abonné au téléphone de basculer ses appels sur un autre numéro. Cette redirection doit-elle s'appliquer à tous les appels ? Qu'en est-il d'un appel de réveil ? L'abonné sera probablement sur le lieu de son numéro habituel et ne souhaitera pas que l'appel soit redirigé. 4. Certains risques sont liés aux performances. Par exemple : • le temps de réponse d'un cas d'utilisation doit être inférieur à une seconde ; • le nombre d'instances de cas d'utilisation concurrentes dépasse 10 000 par jour.


I

L'identification de zones de problèmes telles que celles-ci dépend largement de l'expérience. Personne ne pouvant sérieusement prétendre disposer de toute l'expérience nécessaire, i l faut qu'un petit groupe d'individus examinent le système proposé, dressent des listes de problèmes susceptibles de se produire et se rendent ensemble aux réunions d'identification des risques. Ces réunions ne sont pas destinées à résoudre les problèmes, mais simplement à les identifier et à établir l'ordre dans lequel ils seront étudiés plus en détail, lors des itérations des phases de création et d'élaboration.

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 détecter et d'écarter. Les exemples suivants entrent dans cette catégorie : • le service manque de personnel ayant de l'expérience sur certains aspects inhabituels du projet ; • les membres du service envisagent d'implémenter certaines parties du système proposé dans un langage qu'ils découvrent seulement ; • le calendrier proposé par le client semble trop serré et ne pourra être tenu que si chaque étape se déroule sans le moindre problème ; • le respect du calendrier proposé est conditionné par la livraison, aux dates prévues, de sous-systèmes développés par des sous-traitants utilisés pour la première fois ; r—

• i l est possible que le client ne puisse pas toujours donner son approbation dans les délais nécessaires pour pouvoir livrer en temps et en heure. Les risques de ce type dépassent 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 développements dans chaque zone de risque et s'assurer que les responsables entreprennent les actions nécessaires lorsque l'un de ses risques se matérialise.

5.3.3 Traiter les risques Une fois les risques identifiés et hiérarchisés, l'équipe doit décider du traitement à appliquer à chacun d'entre eux. I l y a, en gros, quatre attitudes possibles : l'évitement, le confinement, la réduction ou la surveillance. • Certainsrisquespeuvent et doivent être évités, par exemple en révisant la planification du projet ou en modifiant les exigences. • D'autres risques doivent être confinés, c'est-à-dire que leur portée doit être réduite de façon à n'affecter qu'une petite partie du projet ou du système. • Il est possible de réduire certains risques en essayant de voir s'ils se matérialisent ou s'ils disparaissent. L'avantage, si un risque se matérialise, c'est que l'équipe en sait plus à son sujet. Elle est alors plus à même de trouver un moyen de l'éviter, de le confiner ou de le surveiller. • Certainsrisques,toutefois, sont rebelles à toute tentative de réduction. L'équipe n'a plus, dès lors, qu'à les surveiller et à regarder s'ils se matérialisent. Dans une telle hypothèse,


5

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 itérations tôt dans le développement. On peut,finalement,se réjouir d'avoir détecté un risque d'une telle ampleur avant d'impliquer tous les développeurs dans le projet. Il faut du temps pour traiter un risque. La solution de l'évitement ou du confinement exige une révision du planning ou du travail déjà effectué, tandis que la réduction peut nécessiter la construction d'un élément permettant de mettre au jour ce risque. La surveillance, enfin, suppose le choix, l'installation et l'exécution d'un mécanisme approprié. Ces deux dernièrei options (la réduction et la surveillance) exigent, l'une et l'autre, un véritable effort de déve loppement, c'est-à-dire du temps. Le traitement des risques réclame du temps ; or, il esl rare que l'équipe d'un projet puisse traiter tous les risques à la fois. I l est, par conséquent, pri mordial de hiérarchiser les itérations. C'est ce que nous entendons par « développement itératif guidé par la réduction des risques ». Une gestion saine des risques, en somme.

5.4 L'itération g é n é r i q u e Comme nous l'avons vu, les itérations se distinguent nettement les unes des autres dans les différentes phases du développement, tout simplement parce les défis auxquels sont confrontés les développeurs diffèrent dans chaque phase. Notre propos, dans cette section, est de présenter le concept d'itération à un niveau générique : qu'est-ce qu'une itération ? Comment la prévoit-on ? Comment est-elle séquencée ? Quel résultat produit-elle ? Dans la troisième partie de l'ouvrage, les itérations de chacune des quatre phases font l'objet de chapitres séparés.

5.4.1 Qu'est-ce qu'une itération

?

Une itération est un mini-projet, c'est-à-dire un déroulement plus ou moins complet des principaux enchaînements d'activités, aboutissant à une version livrée en interne. Cette définition donne une compréhension intuitive de ce qu'est une itération. I l nous faut maintenant l'approfondir pour décrire le travail qui s'effectue véritablement au cours d'une itération et ne pas rester à la surface. On peut se représenter une itération comme un enchaînement d'activités, c'est-à-dire une collaboration entre travailleurs (Annexe C) utilisant et produisant des artefacts. Dans te Pro cessus unifié, nous faisons la distinction entre enchaînement d'activités principal et enchaînement d'activités d'itération (Annexe C). Les cinq enchaînements d'activités principaux nous sont désormais familiers : besoins, analyse, conception, implémentation et tests. Leur présence n'obéit, en fait, qu'à des raisons strictement pédagogiques, afin de nous aider à décrire les enchaînements d'activités des itérations. I l n'y a donc rien de magique dans ce qui constitue un enchaînement d'activités principal ; on aurait aussi bien pu utiliser un autre ensemble d'enchaînements d'activités principaux, comme celui qu'intègrent l'analyse et la conception . Cet enchaînement principal simplifie la description d'enchaînements d'acti1


___

^

Besoins ^ ^

Analyse ^ ^ Conception ^ ^ Implémentatio^ ^

Une itération

Tests

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

cTtATnmWwk

I

Chaque itération fait l'objet d'une évaluation, à son terme. L'un des objectifs de cette évaluation consiste à déterminer si de nouveaux besoins sont apparus ou si des besoins existants ont subi des modifications susceptibles d'affecter les itérations ultérieures. La planification des détails de l'itération suivante inclut également l'étude de l'impact que peuvent avoir les risques subsistants sur la suite du travail.

vités plus concrets, de la même façon qu'une classe abstraite aide à la description de classes concrètes. Ces enchaînements plus concrets sont les enchaînements d'activités des itérations. Les enchaînements principaux sont traités en détail dans les chapitres 6 à 11 et servent à la description des enchaînements d'activités des itérations, objet des chapitres 12 à 16. Figure 5.3 Chaque itération parcourt les cinq enchaînements d'activités principaux. Elle débute par une activité de planification et s'achève par une évaluation.

Il est nécessaire, à ce stade, d'insister particulièrement sur la fonction des tests de nonrégression (Annexe C). Avant de terminer une itération, i l faut s'assurer qu'aucune partie du système qui fonctionnait dans les itérations précédentes n'a été endommagée. Les tests de non-régression revêtent une importance décisive dans un cycle de vie itératif et incrémental, car chaque itération produit un résultat substantiel s'ajoutant à l'incrément précéduii n entraîne un certain nombre de changements. Notons qu'il est malaisé de procéder à tics testa de non-régression à une telle échelle (chaque construction de chaque itération) sans dispose] d'outils adéquats.

^

Comprend en plus : • la planification de l'itération et • l'évaluation de l'itération et • quelques activités spécifiques

La figure 5.3 décrit les éléments génériques de chaque enchaînement d'activités d'une itération. Les itérations parcourent les cinq enchaînements d'activités principaux, débutent par une activité de planification et s'achèvent par une évaluation. Nous décrivons, dans la troisième partie de l'ouvrage, quatre archétypes d'itération, un pour chaque phase du Processus unifié. Chaque type d'itération réutilise à sa façon les descriptions des enchaînements d'activités principaux.

Les chefs de projet ne doivent pas donner le feu vert à l'itération suivante avant qu'aient été atteints les objectifs de l'itération en cours. Si ce n'est pas le cas, le plan devra être modifié pour prendre en compte la nouvelle situation.

5.4.2 Planifier les

itérations

S'il faut bien admettre une chose, c'est que le cycle de vie itératif réclame plus de planification et de réflexion que l'approche en cascade. Dans le modèle en cascade, tout est planifié à l'avance, souvent avant que les risques aient été réduits et l'architecture établie. Les plans qui en résultent reposent donc sur une grande part d'incertitude et ne sont guère fidèles à la réalité. L'approche itérative, en revanche, ne planifie pas tout le projet en détail au cours de la phase de création ; elle s'engage simplement sur les premières é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 premières phases, mais qui n'entre pas dans les détails. En principe (sauf au tout début d'un projet), la planification prend en compte les résultats des itérations précédentes, le choix des cas d'utilisation pertinents pour l'itération suivante, le statut actuel des risques concernant l'itération à venir, et l'état de la dernière version des différents modèles. Elle se conclut par la préparation 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 détaillé pour chaque itération de la phase de cous traction. Le plan de la première itération sera très clair. Celui des itérations suivantes coin portera moins de détails, sera sujet à d'éventuelles modifications et reposera sur l'issue dei itérations précédentes et les connaissances qui s'en seront dégagées. De même, on devra dis poser d'un plan de la phase de transition qui sera susceptible, toutefois, de changer à la lueui de ce que révéleront les itérations de la phase de construction. Ce type de planification permet de mener un développement itératif contrôlé.

Quelle est donc la différence avec un classique modèle en cascade ? Chaque enchaînement d'activités principal est une collaboration entre un ensemble de travailleurs et d'artefacts. Mais on constate des chevauchements entre itérations. Des travailleurs et des artefacts peuvent, en effet, collaborer à plusieurs enchaînements d'activités principaux. Par exemple, l'ingénieur de composants participe à trois enchaînements d'activités : ceux de l'analyse, de la conception et de l'implémentation. Enfinde compte, l'enchaînement des activités de l'itération se crée par la superposition d'un sous-ensemble choisi d'enchaînements d'activités principaux, auquel s'ajoutent des éléments supplémentaires comme la planification et l'évaluation. Les premières itérations s'attachent à la compréhension du problème et de la technologie. Dans la phase de création, les itérations visent à produire une étude de rentabilité , tandis que les itérations de la phase d'élaboration ont pour objectif le développement de l'architecture de référence. Enfin, les itérations de la phase de construction sont tout entières dédiées à la mise au point du produit par une série de constructions au sein de chaque itération, jusqu'à la réalisation d'un produit livrable aux utilisateurs. Malgré ces différences, chaque itération suit le même modèle, comme l'indique lafigure5.3.

1. Il est important de ne pas confondre « enchaînements d'activités » et « processus concurrents ». Les enchaînements d'activités sont des collaborations utiles pour la création de descriptions. 1. Au cours de la phase de création, une itération peut suivre une variante simplifiée des enchaînements d'activités pour l'étude de certains problèmes technologiques précis.

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

logiciel

Un processus itératif et

I

5.4.3 Séquencer

les

incrémental CHAPITRE

itérations

Dans la nature, l'évolution se déroule sans plan préalable. Ce n'est pas le cas pour les itérations 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 développeurs planifient la séquence de production du développement. Les planificateurs tentent d'ordonner les itérations de façon à tracer une voie directe entre itérations, les premières servant de base de connaissances aux suivantes. Les premières itérations du projet jettent une lumière nouvelle sur les besoins, les problèmes, les risques et le domaine de la solution, tandis que les itérations ultérieures aboutissent à des incréments successifs qui finissent par constituer la version externe, c'est-à-dire le produit livré au client. Le comble de la réussite, pour les planificateurs, est de trouver une séquence d'itérations qui permette d'aller constamment de l'avant, sans jamais avoir à revenir aux résultats d'une itération antérieure pour reprendre le modèle en fonction d'informations livrées par une itération plus tardive. Hgure 5.4 1rs itérations fuitrourent les i m hatnements d'activités, de la •< capture » des besoins aux tests.

Itération 1

^ Besoins^ Analyse^ Conceptio^lmplement^ Tasls ^ Itération 2

^ Besoins

Analyse^ ConcepliQÎmplément^ Tests ^ Itération 3

Besoins

Analyse ^Conceptio^lmplénien^ Tesls ^

Les itérations peuvent se chevaucher dans le sens où une itération débute alors que la précédente est sur le point de s'achever, comme le montre la figure 5.4. La planification et le travail d'une itération peuvent débuter alors même que se termine l'itération précédente et que l'on prépare la version qui en résultera. I l ne faut pas, cependant, que ces chevauchements aillent trop loin, car une itération constitue toujours le fondement de l'itération suivante. N'oubliez pas qu'une itération s'achève lorsque les développeurs ont terminé ce qu'ils avaient à faire ; le logiciel créé par l'itération est intégré et peut être livré sous forme de version interne. L'ordre dans lequel sont prévues les itérations dépend largement de facteurs techniques. Néanmoins, l'objectif majeur est d'échelonner le travail de sorte que les décisions les plus importantes, c'est-à-dire celles concernant les nouvelles technologies, les cas d'utilisation et l'architecture, soient prises très tôt.

5

WÊm

À la fin d'une itération, l'ensemble des modèles représentant le système se trouve dans un état particulier. Cet état, ou état d'avancement, est appelé référence. Chaque modèle a atteint une référence ; chaque élément de modèle essentiel se trouve dans un état de référence. Par exemple, le modèle des cas d'utilisation contient, à la fin de chaque itération, un ensemble de cas d'utilisation qui reflètent le degré de réalisation des besoins. Certains de ces cas d'utilisation sont menés à leur terme, tandis que d'autres ne sont que partiellement pris en compte. Dans le même temps, le modèle de conception a atteint un état de référence cohérent avec celui du modèle des cas d'utilisation. Les sous-systèmes, interfaces et ivali sations de cas d'utilisation du modèle de conception se trouvent également dans des états de référence cohérents les uns avec les autres. Travailler efficacement avec plusieurs références au sein d'un même projet nécessite de veiller à préserver la cohérence et la compatibilité des versions de tous les artefacts d'une référence. On ne peut que souligner, dans le cadre d'un développement itératif, l'importance cruciale de l'utilisation d'outils de gestion de conligu ration efficaces. 1

À un point quelconque de la séquence d'itérations, certains sous-systèmes arrivent à maturité : ils contiennent toutes les fonctions prescrites, et ont été implémentés et testés. D'autres ne sont que partiellement constitués, tandis que d'autres encore restent vides, même s'ils disposent des « bouchons » (stubs) nécessaires à leur fonctionnement et à leur intégration avec d'autres sous-systèmes. En somme, et pour être plus précis, un incrément est la différence entre deux références successives. Comme nous l'avons déjà indiqué, l'architecture de référence 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 réalise sous forme de collaborations. C'est ainsi que sont identifiés la plupart des sous-systèmes et interfaces, tout au moins ceux qui sont intéressants sur le plan de l'architecture. Une fois qu'on les a identifiés, i l convient d'étoffer ces sous-systèmes et interfaces, c'est-à-dire d'écrire le code permettant de les implémenter. Cette tâche est, en partie, effectuée avant la livraison de l'architecture de référence et se poursuit tout au long des enchaînements d'activités, mais principalement au cours des itérations de la phase de construction. L'approche de la phase de transition s'accompagne d'une amélioration de la cohérence interne des modèles et de leur cohérence mutuelle. Les incréments naissent de l'étoffement progressif des modèles, jusqu'à l'intégration de l'incrément final qui donne lieu au système tel qu'il est livré.

5.6 Itérations dans le cycle de vie Chacune des quatre phases se conclut par un jalon majeur, comme l'illustre la figure 5.5 111 • création : objectifs du cycle de vie

5.5 Une itération se traduit par un incrément

• élaboration : architecture du cycle de vie

Un incrément est la différence entre la version interne d'une itération et la version interne de l'itération suivante.

1. Tous les cas d'utilisation n'ayant pas besoin d'être conçus, le terme cohérent ne se réfère 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é opérationnelle initiale • transition : livraison du produit L'objectif de chaque jalon majeur est de s'assurer que les modèles des différents enchaînements d'activités évoluent de façon équilibrée sur l'ensemble du cycle de vie du produit. Par « équilibrée », nous entendons que les décisions essentielles influant sur ces modèles et celles concernant les risques, les cas d'utilisation et l'architecture doivent être prises au début du cycle de vie. Sur ces bases, le travail peut ensuite se poursuivre et s'enrichir d'un degré croissant de détails avec un niveau de qualité supérieur. Jalons

Jalon des objectifs du cycle de vie Création

lter.1

Jalon de l'architecture du cycle de vie

Jalon de capacité opérationnelle Initiale Construction

Élaboration

Jalon de livraison du produit Transition

iter. #n-1

Iter. 2

iter. #n

Figure 5.5 Agrégation des itérations de chaque phase aboutissant aux jalons majeurs, au cours desquels sont prises les principales décisions stratégiques.

Les principaux objectifs de la phase de création consistent à définir la portée et le rôle du produit, à réduire les risques les plus sérieux et à préparer une première étude de rentabilité démontrant 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 à créer l'architecture de référence, à saisir l'essentiel des besoins et à réduire 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 coûts, de prévoir le calendrier du développement et de planifier en détail la phase de construction. I l devient possible, à ce stade, de faire une offre. Les principaux objectifs de la phase de construction consistent à développer le système complet et à s'assurer que le produit peut commencer à être utilisé par les clients, c'est-àdire qu'il a atteint une capacité opérationnelle initiale. Les principaux objectifs de la phase de transition consistent à s'assurer que l'on dispose d'un produit prêt à être livré à l'ensemble des utilisateurs, qui sont formés à ce moment-là à l'utilisation du logiciel.

déploiement, d'implémentation et des tests. Cet incrément est ensuite intégré au résultat de l'itération précédente pour créer une nouvelle version des modèles. Comme nous l'avons indiqué dans les sections précédentes, les jalons mineurs sont l'occasion, pour responsables et développeurs, de déterminer la façon de passer aux itérations suivantes. En revanche, les jalons majeurs, qui clôturent chaque phase, représentent le moment où les responsables prennent la décision cruciale d'accorder ou non leur feu vert et de définir le planning, le budget et les exigences. Un jalon mineur (au moment de la livraison d'une version interne, à lafind'une itération) est une étape prévue vers un jalon majeur marquant la conclusion d'une phase. La principale différence qui oppose un jalon majeur à un jalon mineur se situe au niveau de l'organisation. Les développeurs traitent les risques de façon itérative et construisent des artefacts logiciels jusqu'à ce qu'ils atteignent le jalon majeur. À chaque jalon majeur, les responsables évaluent le travail accompli par les développeurs. Le passage d'un jalon majeur représente donc une importante décision de gestion et suppose un engagement financier pour la phase suivante (au moins) selon ce qui est prévu. On peut envisager ces jalons majeurs comme les points de convergence des domaines technique et de gestion. Ces divisions aident les responsables et les autres intervenants concernés à évaluer le travail effectué dans les phases peu coûteuses de création et d'élaboration, avant de s'engager dans la phase de construction, beaucoup plus onéreuse. On peut, grosso modo, découper un projet de développement logiciel en deux grandes parties : d'un côté, les phases de création et d'élaboration, de l'autre, les phases de construction et de transition. Les phases de création et d'élaboration sont consacrées à la réalisation de l'étude de rentabilité, à la réduction des risques les plus importants, à la création de l'architecture de référence et à la planification plus précise 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 réaliser des économies d'échelle. Le nombre de personnes impliquées dans le projet augmente. Ensemble, elles mettent au point la grande masse des fonctions du système, qu'elles développent à partir de l'architecture de référence créée pendant la phase d'élaboration. On réutilise autant que possible les logiciels existants. Si toutes les itérations parcourent tous les enchaînements d'activités des besoins, de l'analyse, de la conception, de l'implémentation et des tests, chacune insiste sur différents points selon les phases abordées, comme l'illustre la figure 5.6. Au cours des phases de création et d'élaboration, les efforts se portent principalement sur l'expression des besoins, ainsi que sur l'analyse et la conception préliminaires, tandis que l'on insiste surtout, dans les phases de construction et de transition, sur la conception détaillée, l'implémentation 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 premières phases.

Chaque phase comporte aussi des jalons de moindre importance (ou « mineurs »), précisément des critères applicables à chacune des itérations. Chaque itération produit des résultats : des artefacts de modèle. Lafinde chaque itération ajoute, par conséquent, un nouvel incrément au modèle des cas d'utilisation, aux modèles d'analyse, de conception, de

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

i

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

Enchaînements d'activités principaux

In iiiin.t aux tests en IHiuuml pur l'analyse, lu , mu rption et I impli'menlalion.

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

5

Dans la phase d'élaboration, la zone sombre, qui indique le niveau d'accomplissement du travail, augmente de façon substantielle. Pourtant, à l'issue de cette phase, alors que l'équipe a formulé environ 80% des cas d'utilisation (U) et une partie du modèle de conception (C), moins de 10% de ces éléments ont été « construits dans » le système et se traduisent par des fonctions implémentées (I) et testées (T). Les modèles des cas d'utilisation et de déploiement doivent avoir atteint ce niveau d'avancement à l'issue de la phase d'élaboration. Sinon, on ne connaîtra pas suffisamment les besoins et les pré-conditions de l'implémentation (y compris en matière d'architecture) pour planifier avec précision la phase de construction. 1

La phase de construction voit le quasi-achèvement des enchaînements d'activités U, A, C, D, I et T, ce qui n'est guère surprenant puisque le critère de sortie de cette phase est une impie mentation complète du système pouvant être transmise aux utilisateurs. I l sera toujours possible ensuite, lorsque le système passera en mode opérationnel dans la phase de transition, de l'optimiser et de lui apporter quelques corrections mineures.

Itérations

r , .7 Les modèles é v o l u e n t à partir des itérations Incrément par incrément, les itérations construisent les modèles qui en résultent. Chaque itération enrichit les modèles l'un après l'autre, en en parcourant tous les enchaînements d'activités. Comme l'indique le diagramme de la figure 5.7, certains de ces modèles, tel que le modèle des cas d'utilisation, focalisent en grande partie l'attention dans les premières phases, tandis que d'autres, tel que le modèle d'implémentation, sont l'objet d'une étude plus approfondie dans la phase de construction. Dans la phase de création, l'équipe pourra, par exemple, créer les parties des modèles nécessaires à la prise en charge d'un prototype de mise à l'épreuve du concept, c'est-à-dire les principaux éléments du modèle des cas d'utilisation (U), du modèle d'analyse (A) et du modèle de conception (C), ainsi qu'une partie des modèles de déploiement (D), d'implémentation (I) et de tests (T). À ce stade, l'essentiel de l'implémentation est encore à l'état préparatoire. Comme on le voit sur la figure 5.7, i l reste encore beaucoup à faire. figure 5.7

Création

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

Élaboration

| Construction |

Transition

UAC D I T U AC D I T

5.8 Les itérations remettent en question l'organisation Les équipes de développement logiciel souvent ne résistent 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 guère à réutiliser le produit d'analyses, de conceptions ou de codes antérieurs, car seul le code fraîchement écrit est pris en compte par les responsables. Le passage à un développement itératif remet en question les pratiques en vigueur dans ces services. Il exige un changement d'attitude. L'attention du service doit, en effet, se détourner du nombre de lignes de code pour se porter sur la réduction des risques et la création de fonctions architecturales de référence. Les chefs de projet doivent, quant à eux, poser un regard neuf sur ce qui doit être mesuré, et démontrer, par leurs actions, qu'ils mesurent la progression en termes de traitement des risques, de préparation des cas d'utilisation et de réalisation sous forme de composants. Sinon, les développeurs ne tarderont pas à revenir à ce qui leur valait encouragements et félicitations : la production de lignes de code. L'adoption de l'approche itérative et incrémentale s'accompagne de quelques conséquences majeures : • pour réaliser l'étude de rentabilité dans la phase de création, le service se concentre sur la réduction des risques et la démonstration de la viabilité technique du projet ; • pour soumettre une offre rentable à lafinde la phase d'élaboration, le service doit connaître les éléments dont il est chargé d'effectuer la construction (représentée par l'architecture de référence plus les besoins) et s'assurer qu'ils ne dissimulent aucun risque

r

m

I. Dans le chapitre 4, nous avons indiqué que les modèles des cas d'utilisation et d'analyse avaient atteint, à la fin de la phase d'élaboration, un niveau de réalisation plus faible que ne le montre lafigure5.7. Ce décalage s'explique par le fait que, dans le chapitre 4, nous nous étions exclusivement intéressé à l'architecture sans prendre en compte le reste (en l'occurrence, la nécessité d'avoir une compréhension plus aiguë des cas d'utilisation pour établir une étude de rentabilité).

Conception Développement

i •

fi.M

OHKUS

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

11 in exemple, des facteurs incertains, susceptibles d'alourdir les budgets et de rallonger tel délais) ; • pour réduire les coûts, éviter les anomalies et raccourcir les délais de mise sur le marché, Il service doit employer des composants réutilisables (émanation des premiers développements de l'architecture fondés sur l'étude du domaine auquel ressortit le système proposé) ;

Partie

II

d ' a c t i v i t é s

• pour éviter de fabriquer un produit déjà dépassé à la livraison, on ne peut plus s'obstiner à n i user tout changement. L'approche itérative par phases permet d'intégrer les i hangements de façon progressive tout au long du processus de développement.

L e s

• | » nu éviter les retards de livraison, les dépassements de budget et les produits de mauvaise qualité, il est nécessaire de « faire le sale boulot en premier » ;

e n c h a î n e m e n t s

i i développement itératif et incrémental ne réclame pas seulement une nouvelle façon de l'an les projets, mais aussi des outils prenant en charge cette nouvelle approche. I l est pratiqunnenl impossible de gérer tous les artefacts d'un système soumis en permanence à des changements concomitants à chaque construction et à chaque itération sans le secours I . mi ils appropriés. Les services qui adoptent ce mode de développement ont besoin d'outils prenant en charge les différents enchaînements d'activités, et d'autres assurant la gestion de . • onflguration et le contrôle de version.

6.9 Références PETER F. DRUCKER, Management:

2

HARRY BOEHM, "Anchoring the software process," IEEE Software, July 1996, pp. 73-82.

1

Tasks, Responsibilities,

Practices,

p r i n c i p a u x

Expression des besoins sous forme de cas d'utilisation

Chapitre 7

Expression des besoins : de la vision aux besoins

Chapitre 6

Chapitre 8 Chapitre 9

Analyse Conception

New York:

Chapitre 10

Harper & Row, 1973.

WALKER ROYCE, "TRW'S Ada process model for incrémental development of large software Systems," Proceedings, 12th International Conférence on Software

5

CAPERS JONES, Assessment and Control of Software Risks, Upper Saddle River, NJ: Prentice-Hall, 1993.

4

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.)

3

Engineering,

Chapitre 11

Implémentation Tests

Maintenant que nous avons compris les notions élémentaires qui soustendent les pratiques essentielles du Processus unifié, nous allons décrire en détail chacun des enchaînements d'activités. La troisième partie traitera des itérations et des phases. Dans la deuxième partie, les enchaînements d'activités 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'implémentation et le chapitre 11 des tests. Le terme enchaînement d'activités principal est une abstraction, décrite en détail dans le chapitre 5. Nous nous attachons, au cours des itérations, au déploiement concret de ces enchaînements d'activités, thème auquel est consacrée la troisième partie.

1990, pp. 2-11.

Le fait d'évoquer séparément les enchaînements d'activités principaux, comme nous nous apprêtons à le faire, peut être trompeur pour le lecteur ; nous tenons à dissiper toute confusion éventuelle. Premièrement, en décrivant les enchaînements d'activités principaux l'un

après l'autre, nous donnons l'impression que le processus global de développement logiciel ne traverse cette séquence d'enchaînements d'activités qu'une seule fois entre le début et la fin du projet. Le lecteur risque de rester sur l'idée que les enchaînements d'activités principaux constituent un processus à sens unique se déroulant une fois pour toutes, comme le vieux processus en cascade. Deuxièmement, un lecteur non préparé pourrait déduire de ces pages que chaque enchaînement d'activités principal est une étape monolithique du processus. Aucune de ces deux impressions n'est exacte. La description des enchaînements d'activités principaux sous forme de chapitres séparés n'obéit qu'à un objectif strictement pédagogique : ce choix formel nous permet de traiter à fond l'intégralité de chaque enchaînement d'activités. En ce qui concerne la première interprétation (le rapprochement avec le développement en cascade), i l est vrai que l'on traverse les cinq enchaînements d'activités de façon séquentielle, mais ce parcours se produit à chaque itération, et non pas une seule fois pour tout le projet. Par exemple, si l'on a sept itérations sur quatre phases, on parcourra vraisemblablement sept fois chaque enchaînement d'activités. I l convient, néanmoins de nuancer ce propos pour reconnaître que l'on n'utilisera peut-être pas les cinq enchaînements d'activités au début de la phase de création. I l est probable, en effet, que l'on n'aille pas jusqu'aux derniers enchaînements d'activités, tels que l'implémentation et les tests, au cours des premières itérations. Le principe est clair : le parcours des enchaînements d'activités est soumis aux particularités de chaque itération. Pour ce qui est de la seconde interprétation (l'étape monolithique), nous décrivons, en effet, chaque enchaînement d'activités principal indépendamment des autres enchaînements d'activités. Mais ces enchaînements 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 enchaînement d'activités en nous concentrant sur ses activités fondamentales, là encore pour des raisons pédagogiques. Nous n'abordons pas les allers-retours entre ces activités et celles des autres enchaînements d'activités. Cet échange est, bien sûr, essentiel à un processus de développement logiciel itératif et sera évoqué en détail dans la troisième partie. Tout en travaillant sur une conception particulière, un développeur peut, par exemple, juger souhaitable d'aller et venir entre les enchaînements d'activités d'analyse et de conception. La troisième partie illustre l'association de ces divers enchaînements, décrits séparément dans les pages suivantes, au sein d'un projet réel. Ainsi, un ensemble limité d'enchaînements d'activités pourra suffire dans les premières phases, tandis que l'ensemble complet des enchaînements d'activités sera indispensable à la phase de construction.

6 Expression des besoins : de la vision aux besoins Pendant des générations, certaines tribus amérindiennes ont construit un type de pirogue, appelé « dugout », littéralement « creusé dans un tronc d'arbre ». On commençait, pour construire ces pirogues, par rechercher un arbre de plus d'un mètre de diamètre, déjà tombé à proximité du cours d'eau. Puis, on allumait tout près un feu et l'on dispersait le charbon de bois brûlant sur le tronc. Le bois ainsi carbonisé était plus facile à évider avec des outils de pierre. Après plusieurs jours passés à sculpter le tronc, le canoë était prêt et mis à l'eau dans une zone peu profonde. Le plus souvent, la première ébauche ne faisait que se retourner sur elle-même. 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 considéré comme terminé. Ce savoir s'est transmis de génération en génération, au point de s'inscrire dans le subconscient des constructeurs. Lorsqu'une « tribu » de développeurs logiciels entend l'appel du développement d'un nouveau système, elle se trouve confrontée à une situation totalement différente. Premièrement, les développeurs ne sont pas les futurs utilisateurs du système. Ils n'obtiendront pas de retours immédiats sur le comportement de leur « pirogue ». Deuxièmement, les besoins et les contraintes du système n'ont pas imprégné les couches profondes de leur subconscient par un usage continu du produit depuis l'enfance. Ils devront, au contraire, découvrir par eux-mêmes ce qui est nécessaire. Nous nommons cet acte de découverte 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 tâche est tellement délicate 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é).

nehainements d ' a c t i v i t é s principaux i m III II

Pourquoi l'expression des besoins est-elle délicate ? l . . professionnels du développement logiciel construisent, en général, des systèmes pour .1. tiers : les utilisateurs du logiciel, et non pour eux-mêmes. « Bah », avaient coutume de . lamer les développeurs, « les utilisateurs doivent savoir ce qu'il leur faut ». Mais i l iiiin d'avoir, à quelques reprises, tenté de recueillir les exigences auprès des utilisateurs I u u u savoir qu'ils se révèlent bien souvent une source d'informations très imparfaite. I > «bord, parce qu'un système a en général 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 amélioré. La plupart d'entre eux ne savent pas quels aspects de leur travail i u 11 M - I I I cire dévolus à un logiciel. Pour être tout à fait franc, il est assez courant que les utiII Meurs ne sachent pas quels sont les besoins, ni comment les exprimer de façon précise. I ,'ipproche traditionnelle, face à ce problème, consistait à confier à des intermédiaires, les m ilvsles, le soin de tirer de chaque utilisateur une liste de besoins, en espérant qu'ils parI lendl aienl à dégager une vision d'ensemble et à mettre au point une spécification complète, lnlrli- cl cohérente de ces besoins. En général, 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 cohéi i n i c cl pertinente de milliers d'exigences en se disant : « alors, le système devra... ». En spécifications de besoins ne se transformaient pas facilement en spécifications de et d'implémentation. plus, ces

i

6.2

Expression des besoins : de la vision aux besoins mm

cTiÂpnvËWmm Même en faisant preuve de perspicacité, l'expression des besoins reste difficile et l'industrie cherche depuis longtemps un processus à la fois efficace et systématique pour y parvenir. C'est ce thème qui fait l'objet de ce chapitre et du suivant.

Objectif de l'enchaînement

d'activités

des besoins

Le principal objectif de l'enchaînement d'activités des besoins est d'orienter le développement en direction du système le plus approprié. La satisfaction de cet objectif suppose de décrire les exigences qui pèsent sur le système (c'est-à-dire des conditions ou des moyens que doit respecter le système) avec suffisamment de précision pour parvenir à un accord entre le client (y compris les utilisateurs) et les développeurs sur ce que doit faire ou ne pas faire le système. Le défi qui se pose là est que le client, que l'on peut supposer a priori non spécialiste de l'informatique, doit être capable de lire et de comprendre les résultats de la « capture » des besoins. I l convient donc d'employer le langage du client pour décrire ces résultats et d'être particulièrement vigilant lorsqu'on y introduira formalisme et structure, ainsi que les détails sur le fonctionnement interne du système. Les résultats de l'enchaînement d'activités aident aussi le chef de projet à planifier les itérations et les versions destinées au client (ces questions sont traitées dans la troisième partie).

6.3

mu option

Présentation

générale

de l'expression des besoins

Chaque projet logiciel est unique. Cette singularité s'explique par la diversité des types de système, des clients, de l'organisation du développement, des technologies, etc. De même, l'expression des besoins repose sur différents points de départ. On commencera, dans certains cas, par élaborer un modèle du métier, ou bien on exploitera un modèle de ce type en cours d'élaboration par une autre société (voir la section 6.6.1, « Qu'est-ce qu'un modèle du métier ? »). Dans d'autres cas, le logiciel sera un système embarqué ne prenant pas directement en charge un métier spécifique. On pourra aussi ne disposer, comme entrée, que d'un simple modèle objet, tel qu'un modèle du domaine (voir la section 6.5.1, « Qu'est-ce qu'un modèle du domaine ? »). I l arrivera aussi que le client ait établi une spécification complète et détaillée des besoins ne reposant pas sur un modèle objet, mais qui servira de base de négociation aux futures modifications.

i. Ii m. avec l'aide des analystes, les utilisateurs ne parvenaient pas totalement à comprendre i c que devait faire le système avant que celui-ci ne soit pratiquement achevé. À mesure qu'avançaient les projets et que les utilisateurs, intermédiaires et développeurs eux-mêmes , icnçaient à entrevoir l'allure générale du système et à mieux appréhender les véritables lu-soins, les suggestions de changement pleuvaient. Nombre de ces changements étaient, d'ailleurs, souhaitables, mais leur implémentation avait un grave retentissement sur les délai) cl les coûts. Pendant toutes ces années, 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 systèmes développés sont censés 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 systèmes remplissent la mission qui a motivé leur consn notion. Le système doit, par exemple, apporter une valeur spécifique à l'entreprise utilisaIrice ainsi qu'à ses clients. Il est souvent difficile d'identifier ou de comprendre la véritable nature de cette valeur, et parfois impossible de mettre au point le système susceptible de la prendre en charge. Pire, dans le contexte d'un monde réel en perpétuelle évolution, i l y a de fortes chances pour que cette valeur insaisissable change au cours du projet : l'entreprise elle-même risque de changer, la technologie disponible pour la construction du système risque de changer, les ressources (personnel, budget) dégagées pour le projet risquent de changer, etc.

On rencontrera, à l'opposé, des clients n'ayant qu'une idée très vague de ce que doit être leur système, dont l'idée émanera parfois d'une simple déclaration d'intention des responsables supérieurs. Entre ces extrêmes, toutes sortes de variations sont possibles. Nous avons choisi, comme point de départ, le cas d'une « idée vague » et présentons maintenant l'exemple qui traversera tout le livre. liMUM

Le Consortium interbancaire envisage la création d'un système informatique Le Consortium interbancaire, institution financière fictive, se trouve confronté à des changements majeurs suscités par la dérégulation, un nouveau type de concurrence et des prestations innovantes rendues possibles par le World Wide Web. Le Consortium envisage de développer de nouvelles applications pour prendre rapidement en charge des marchés finan-

i •

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

ciers en pleine évolution, dont elle a confié la mise au point à sa filiale de développement logiciel, Interbank Software. Interbank Software a décidé de concevoir le Système de facturation et de règlement en collaboration avec quelques-uns de ses principaux clients bancaires. Le système utilisera l'Internet pour l'envoi des commandes, des factures et des règlements entre vendeurs et acheteurs. La banque souhaite, par la mise au point de ce système, attirer de nouveaux clients en proposant des frais de traitement des règlements très faibles. Elle veut également réduire ses frais salariaux en traitant les demandes de règlements automatiquement par l'Internet plutôt que manuellement par des guichetiers. L'objectif des vendeurs et des acheteurs est de réduire les coûts, la paperasserie et le temps de traitement. Par exemple, il ne sera plus nécessaire d'envoyer les commandes ou les factures par courrier. Le règlement des factures sera pris en charge par les systèmes informatiques de l'acheteur et du vendeur, qui bénéficieront en outre d'une meilleure visibilité du statut de leurs factures et règlements. i éventualité de points de départ aussi différents qu'une déclaration d'intention assez vague . »i une spécification des besoins suggère que l'analyste doit être capable d'adapter à chaque Situation son approche de l'expression des besoins. Et comme les risques induits diffèrent en fonction de ces points de départ, i l faut donc qu'il choisisse l'approche qui permettra au mieux de réduire ces risques. La réduction des risques est traitée en détail dans la troisième partie. I n dépit de ces différences, certaines étapes restent valables dans la plupart des cas, ce qui u..u autorise à proposer un archétype d'enchaînement d'activités. Celui-ci comprend les étapes suivantes, qui, en réalité, ne sont pas séparables : • recenser les besoins potentiels ; • comprendre le contexte du système ; • appréhender les besoins fonctionnels ; • appréhender les besoins non fonctionnels. I .es paragraphes suivants décrivent brièvement ces étapes. Recenser les besoins potentiels - Au cours de la vie d'un système, clients, utilisateurs, analystes et développeurs avancent des idées susceptibles de révéler de véritables besoins. On dresse alors une liste de ces suggestions, que l'on pourra considérer comme un ensemble d'exigences potentielles à implémenter ou non dans une version future du système. Cette liste de fonctions (ou de caractéristiques) augmente avec l'ajout de nouveaux éléments et s'allège à mesure que ces fonctions sont retenues comme besoins et transformées en d'autres artefacts, comme les cas d'utilisation. Elle ne sert, en fait, qu'à planifier le travail. Chaque caractéristique porte un nom court et s'assortit d'une brève explication ou définition comportant suffisamment d'informations pour permettre l'évocation précise 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 éléments suivants :

Expression des besoins : de la vision aux besoins Wgf

• un état d'avancement (par exemple : proposé, approuvé, intégré ou validé) : • une estimation du coût d'implémentation (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'implémentation de la fonction (par exemple : majeur, significatif ou ordinaire ; voir le chapitre 5). Ces valeurs de planification permettent, en conjonction avec d'autres aspects (abordés au chapitre 12), d'estimer la taille du projet et de décider de la façon de le scinder en une séquence d'itérations. Les niveaux de priorité et de risque associés à une fonction servent, par exemple, à déterminer dans quelle itération mettre en œuvre la fonction (comme l'explique la troisième partie). Par ailleurs, lorsque sera prévue l'implémentation d'une fonction, on pourra établir une relation de traçabilité entre cette fonction et des cas d'utilisation ou des exigences supplémentaires (thème abordé d'ici peu). Comprendre le contexte du système - Parmi les personnes impliquées dans le développement d'un logiciel, nombreux sont les spécialistes de questions strictement informatiques. Il est pourtant nécessaire, pour appréhender les véritables besoins et construire le système approprié, que les principaux développeurs (l'architecte en particulier, et certains des analystes seniors) aient une réelle compréhension du contexte dans lequel se déploiera le système. Il existe au moins deux approches pour exprimer le contexte d'un système sous une forme utilisable par les développeurs logiciels : la modélisation du domaine et la modélisation du métier. Un modèle du domaine décrit, en les reliant les uns aux autres, les concepts essentiels du contexte sous forme d'objets du domaine. Une fois identifiés et nommés, ces objets permettent d'arrêter un glossaire qui favorisera la communication entre les diverses personnes travaillant sur le système. Ces objets faciliteront, ensuite, l'identification de certaines des classes au cours de l'analyse et de la conception du système. Comme vous le verrez, on peut définir un modèle du métier comme un sur-ensemble d'un modèle du domaine, comprenant plus que les simples objets du domaine. L'objectif de la modélisation du métier est de décrire les processus, existants ou perçus, afin de les comprendre. C'est la seule partie de l'ingénierie du métier que nous utiliserons dans cet ouvrage [3]. Nous nous bornerons, pour l'instant, à dire que l'ingénierie du métier est très proche de la modélisation du métier, mais qu'elle vise en plus à améliorer les processus métier de l'entreprise. En modélisant le métier, les analystes en apprennent beaucoup sur le contexte du système logiciel, qu'ils décrivent dans un modèle du métier. Celui-ci spécifie quels sont les processus métier qui devront être pris en charge par le système. Outre l'identification des objets du métier ou du domaine impliqués dans l'activité professionnelle, la modélisation du métier établit également les compétences requises par chaque processus : les travailleurs, leurs responsabilités et les tâches 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 systématise au plus haut point le processus de « capture » des besoins pour les applications professionnelles [3].

RHfflH

•

_

Exigences particulières du cas d'utilisation Régler la facture Exigences te performances

Lorsqu'un acheteur émet une facture pour règlement, le système doit répondre par une vérification de la requête en 1 seconde maximum dans 90% des cas. Le délai de vérification ne doit jamais excéder 10 secondes, sauf si la connexion est interrompue (auquel cas l'utilisateur doit en être informé).

Ensemble, l'architecte et le chef de projet décident s'il y a lieu d'élaborer un modèle du domaine qui servira de base à la préparation d'un modèle complet du métier, ou si aucun de ces deux modèles ne serafinalementétabli. Appréhender les besoins fonctionnels - L'approche permettant d'identifier directement les besoins du système s'appuie sur les cas d'utilisation (traités en détail dans le chapitre 7). Ces derniers expriment les besoins fonctionnels et non fonctionnels propres à chacun d'entre eux. Rappelons brièvement par quels moyens les cas d'utilisation favorisent l'appréhension des véritables besoins du système. Chaque utilisateur demande au système de lui rendre service d'une façon ou d'une autre, c'est-à-dire d'exécuter certains cas d'utilisation. Pour l'utilisateur, un cas d'utilisation représente une façon d'utiliser le système. Par conséquent, s'ils peuvent décrire tous les cas d'utilisation exigés par les utilisateurs, les analystes sauront exactement ce que doit faire le système. Nous avons donc dit que chaque cas d'utilisation représente une façon d'utiliser le système (par exemple, d'assister un utilisateur pendant le déroulement d'un processus métier). Or, chaque utilisateur a besoin de plusieurs cas d'utilisation pour désigner les différentes façons dont i l emploiera le système. I l est donc indispensable, pour dégager les cas d'utilisation exigés de la part du système, notamment ceux permettant l'exercice même de l'activité et ceux que les utilisateurs estiment nécessaires à leur propre « confort », de connaître à fond les besoins des utilisateurs et du client. I l faut, pour cela, comprendre le contexte du système, interroger les utilisateurs, débattre des diverses propositions, etc. En complément des cas d'utilisation, les analystes doivent également indiquer l'apparence générale qu'aura l'interface utilisateur une fois les cas d'utilisation exécutés. Le meilleur moyen d'élaborer cette spécification de l'interface utilisateur consiste à en esquisser plusieurs versions spécifiant les informations à transférer, à discuter de ces propositions avec les utilisateurs et à créer des visualisations concrètes ou des prototypes que ces derniers pourront tester. Appréhender les besoins non fonctionnels - Les besoins non fonctionnels spécifient les propriétés du systèmes, notamment les contraintes d'environnement et d'implémentation, les performances, les dépendances de plate-forme, la capacité de maintenance, l'extensibilité et la fiabilité. D'une manière générale, tout ce qui se termine par « ilité ». La fiabilité renvoie aux caractéristiques telles que la disponibilité, la précision, 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 débit, le temps de réponse et l'utilisation de la mémoire. Elles ne sont, en général, pertinentes que pour certains cas d'utilisation et doivent donc être liées (en tant que valeurs marquées) aux cas d'utilisation concernés (Annexe A). Cela signifie, en pratique, que ces exigences seront décrites dans le contexte approprié, c'est-à-dire dans la description du cas d'utilisation (éventuellement dans une section à part, nommée « Exigences particulières »).

Certaines exigences non fonctionnelles renvoient à des éléments du monde réel, comme lei comptes d'un système bancaire. Ces exigences peuvent, dans un premier temps, être intégrées à l'objet du métier ou du domaine concerné dans le modèle décrivant le contexte du système. Puis, une fois que les cas d'utilisation et les « concepts » sur lesquels elles agissent ont été déterminés, ces exigences non fonctionnelles sont reliées 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 façon plus formelle, les classes d'un modèle d'analyse (voir le chapitre 8). Pour plus de simplicité, nous adoptons dans ce chapitre la première hypothèse, c'est-à-dire que ces exigences sont reliées aux concepts du glossaire. Enfin, certaines exigences non fonctionnelles sont plus génériques et ne peuvent être reliées à un cas d'utilisation en particulier, ni à une classe spécifique du monde réel. Elles doivent donc être gérées séparément, dans une liste d'exigences supplémentaires (Annexe C). Résumé - Pour appréhender efficacement les besoins, les analystes doivent recourir à un ensemble de techniques et d'artefacts qui leur permettront de se faire une idée claire du système et de passer aux enchaînements d'activités suivants. Nous désignons collectivement ces artefacts sous le nom d'ensemble des exigences. La spécification classique des besoins est donc désormais remplacée par un ensemble d'artefacts comprenant le modèle des cas d'utilisation et les exigences supplémentaires. Les artefacts nécessaires à la définition du contexte du système sont les modèles du métier et du domaine, comme l'illustre la figure 6.1. (Notez que les cas d'utilisation tionnels spécifiques aux cas d'utilisation.) Figure 6.1

L'ensemble de tous les besoins se compose des différents artefacts indiqués dans la colonne de droite, tandis que le travail à effectuer influe sur un ou plusieurs de ces artefacts.

Travail à effectuer

contiennent

également

les besoins

non fonc-

Artefacts obtenus

Exigences supplémentaires ou cas d'utilisation individuels (pour les besoins spécifiques aux cas d'utilisation)

Appréhender les besoins non fonctionnels


Appréhender les besoins fonctionnels

Modèle du métier ou du domaine

Comprendre le contexte du système

Liste des fonctions

Recenser les besoins potentiels

Définit une spécification tradltlonnnollo des besoins

Etant donné les changements constants auxquels sont soumis les besoins, i l faut absolument disposer d'un moyen de les actualiser de façon contrôlée. Ce moyen nous est offert par les itérations, dont chacune reflétera 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

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 détail là-dessus dans la section 6.4, avant de décrire le contexte du système sous forme de modèle du domaine (section 6.5) ou de modèle du métier (section 6.6). Puis, nous traiterons des exigences supplémentaires 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.

Figure 6.2

la « capture » des Enchaînements besoins s'effectue d ' a c t i v i t é s principaux principalement au ^ — — — — —

cours des phases de création et d'élaboration.

Expression des besoins : de la vision aux besoins CHAPITRE

6

Phases x—,

r

Création , Elaboration ,

Construction

, Transition

| Besoins A n

— — — — ., y s e

Conception

4 Rôle des besoins dans le cycle de vie du logiciel

Implémentation

Le modèle des cas d'utilisation s'élabore sur plusieurs incréments de développement, chaque itération apportant de nouveaux cas d'utilisation ou détaillant les cas d'utilisation existants.

Tests

La figure 6.2 illustre la façon dont l'enchaînement d'activités de l'expression des besoins et les artefacts qui en résultent adoptent des formes diverses au cours des différentes phases et de leurs itérations (voir le chapitre 12). • Pendant la phase de création, les analystes identifient la plupart des cas d'utilisation afin de délimiter le système et de cibler le projet, et détaillent les plus importants d'entre eux (moins de 10%). • Pendant la phase d'élaboration, les analystes mettent au jour la plupart des besoins restants afin de permettre aux développeurs d'estimer l'effort de développement nécessaire. L'objectif est d'avoir appréhendé environ 80% des besoins et décrit 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 implémentés dans l'architecture de référence.) • Le reste des besoins est formulé (et implémenté) 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.

Itérations

iter. #1

Iter. #2

iter. iter. iter. #n #n+1 #n+2

Iter. #m

Iter. #m+1

Itérations

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 modèle du domaine 6.5.1 Qu'est-ce qu'un modèle

du domaine ?

Un modèle du domaine saisit les types d'objets les plus importants dans le contexte du système. Les objets du domaine représentent les « choses » qui existent ou les événements qui se produisent dans l'environnement au sein duquel fonctionne le système [2, 5]. On trouvera un grand nombre de ces objets ou (pour utiliser une terminologie plus précise) de ces classes du domaine dans la spécification des besoins ou en interviewant les experts du domaine. Les classes du domaine se présentent généralement sous trois formes : • les objets métier représentant les éléments mis en œuvre dans une activité professionnelle, tels que les commandes, les comptes ou les contrats ; • les objets et concepts du monde réel dont un système doit garder la trace, tels que les avions ennemis, les missiles et les trajectoires ; • les événements s'étant produits ou devant se produire, tels que l'arrivée, le départ d'un avion, ou la pause déjeuner. Le modèle du domaine est décrit dans les diagrammes UML (en particulier dans les diagrammes de classes). Ces diagrammes illustrent, pour les clients, les utilisateurs, les réviseurs et les autres développeurs, les classes du domaine et la façon dont elles sont liées 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

Les classes du domaine Commande, Facture, Article et Compte Le système utilisera l'Internet pour envoyer les commandes, factures et règlements entre acheteurs et vendeurs. Il assistera l'acheteur dans l'établissement des commandes et le vendeur dans l'évaluation des commandes et l'expédition des factures, puis il aidera l'acheteur à valider les factures et à effectuer les règlements 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 règlement envoyée par un vendeur à un acheteur en réponse à 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 règlement, et peut constituer la demande de règlement de plusieurs commandes. Une facture est réglée 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 possédant le compte. lluiiinU.3 lUnninmnie i lusses issu modèle

Commande

Article

de d'un

tltt

dumume,

saisissant

date d'émission adresse de livraison

W

U

1..'

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

du

vstïme.

1..*

description photo prix

payable

Facture

vendeur

montant date d'émission date limite de règlement

1

Compte

Acheteur solde titulaire


6

Notation UML Les classes sont représentées par des rectangles, les attributs figurent dans la partie inférieure des rectangles de classe, et les associations sont désignées par tes lignes reliant les rectangles de classe). Le texte placé au bout d'un chemin d'association explique le rôle d'une classe par rapport à une autre, c'est-à-dire le rôle 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 située à cette extrémité qui sont liés à un objet situé à l'autre extrémité. Par exemple, l'association reliant les classes Facture et Commande dans la figure 6.3 affiche une multiplicité de 1..* décorant l'extrémité Commande. Ce qui signifie que chaque objet Facture peut constituer une requête de règlement pour un ou plusieurs objets Commande, comme l'indique le. rôle d'association « payable » (Annexe A).

6.5.2 Élaboration

d'un modèle

du domaine

La modélisation du domaine est généralement effectuée en ateliers, par des analystes du domaine utilisant UML et d'autres langages de modélisation pour la documentation des résultats. Pour former une équipe vraiment efficace, ces ateliers doivent associer experts du domaine et personnes compétentes en matière de modélisation. L'objet de la modélisation du domaine est de comprendre et de décrire les classes essentielles dans le contexte du domaine. Les domaines de taille modeste nécessiteront, en moyenne, entre 10 et 50 de ces classes, mais ce nombre pourra être nettement plus élevé pour des domaines plus vastes. Les centaines d'autres classes candidates qu'auront pu découvrir les analystes pour le domaine seront conservées sous forme de définitions dans un glossaire ; sinon, le modèle du domaine deviendrait trop important et nécessiterait plus d'efforts qu'il ne convient à ce stade du processus. Parfois, notamment pour des domaines professionnels très limités, i l ne sera pas nécessaire de mettre au point un modèle objet pour le domaine. Un glossaire pourra suffire. Le glossaire et le modèle du domaine offrent aux utilisateurs, aux clients, aux développeurs et aux autres intervenants un vocabulaire commun, indispensable au partage des connaissances. Là où règne la confusion, i l est difficile, voire impossible d'effectuer un véritable travail d'ingénierie. Et la construction d'un système logiciel, quelles qu'en soient les dimensions, exige la « fusion » des langages utilisés par les divers participants en un seul et même langage cohérent.

1

Enfin, un mot d'avertissement sur la modélisation du domaine. Il est parfois plus simple de commencer la modélisation des parties internes d'un système en ne se préoccupant pas du contexte [7]. Il arrive, par exemple, que certains objets du domaine aient une représentation directe dans le système, et que les analystes du domaine tombent dans le piège qui consiste à spécifier les détails de cette représentation. Il est primordial, dans des cas comme celui-ci, de garder à l'esprit que l'objectif de la modélisation du domaine est de contribuer à une

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

meilleure compréhension du contexte du système et, par là-même, des besoins du système à mesure qu'ils émergent de ce contexte. En d'autres termes, la modélisation du domaine doit favoriser la compréhension du problème qu'est censé résoudre le système par rapport à son contexte. La solution qu'apporte le système à ce problème sera traitée dans les enchaînements d'activités d'analyse, de conception et d'implémentation (voir les chapitres 8, 9 et 10).

8.5.3 Utilisation du modèle

du domaine

Les classes du domaine et le glossaire se révèlent utiles au moment de l'élaboration du modèle des cas d'utilisation et du modèle d'analyse :

6.6.1 Qu'est-ce qu'un modèle

Expression des besoins : de la vision aux besoins

wm

cTÏATnmWWm

du métier ?

D'abord, un modèle des cas d'utilisation métier décrit les processus métier d'une entreprise à l'aide de cas d'utilisation métier et d'acteurs métier qui correspondent respectivement aux processus métier et aux clients. Tout comme le modèle des cas d'utilisation d'un système logiciel, le modèle des cas d'utilisation métier présente un système (ici, le système métier) du point de vue de son utilisation et indique la façon dont il rend service à ses utilisateurs (ici, ses clients et partenaires) [3, 4, 6].

Bfflfll

Cas d'utilisation métier L'exemple du Consortium interbancaire offre un cas d'utilisation métier impliquant l'envoi de commandes, de factures et de règlements entre un acheteur et un vendeur: Ventes : de la commande à la l ivraison. Dans ce cas d'utilisation métier, un acheteur sait ce qu'il veut acheter et à qui il veut l'acheter. Dans la séquence 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 sûrs pour le règlement des factures :

• 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 système pendant l'analyse, thème qui sera traité au chapitre 8. Il existe, toutefois, un moyen encore plus systématique d'identifier les cas d'utilisation et de imuver les classes d'un système: l'élaboration d'un modèle du métier. Comme nous le verrons, un modèle du domaine est un cas particulier d'un modèle du métier plus complet. I A mise au point d'un modèle du métier constitue, par conséquent, une alternative puissante au développement d'un modèle du domaine.

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.

Dans ce contexte, l'acheteur et le vendeur sont les acteurs métier du Consortium interbancaire et utilisent les cas d'utilisation métier que procure le Consortium.

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 modèle du métier I .a modélisation du métier est une technique permettant de comprendre les processus métier d'une entreprise. Mais qu'en est-il lorsqu'on travaille sur un système n'ayant rien à voir avec ce que la plupart d'entre nous considèrent comme un métier ? Par exemple, comment procéder au développement d'un stimulateur cardiaque, d'un système de freinage anti-verrouillage, d'un contrôleur de caméra ou d'un système de télécommunications ? Dans de tels cas, on peut également modéliser le système englobant le système logiciel qu'il s'agit de développer. Ce système (une partie du corps humain, une partie d'une voiture, la caméra, le commutateur) constitue le « système métier » du système logiciel intégré. I l prend part aux cas d'utilisation du système de plus haut niveau qu'il convient d'esquisser brièvement. L'objectif étant d'identifier les cas d'utilisation du logiciel et les entités métier pertinentes devant être prises en charge par ce logiciel, i l suffit de modéliser les éléments strictement nécessaires à la compréhension du contexte. Cette activité se traduit par un modèle du domaine issu de la compréhension du fonctionnement du « système métier » qui l'englobe. La modélisation du métier est prise en charge par deux types de modèles UML : le modèle des cas d'utilisation et le modèle objet [6]. L'un et l'autre sont définis dans l'extension d'UML spécifique au métier.

Une entreprise fournit normalement un grand nombre de cas d'utilisation métier. Le Consortium interbancaire ne fait pas exception à cette généralité. Nous allons décrire ici deux de ces cas d'utilisation dans le seul but de déterminer le contexte approprié. En revanche, nous ne traiterons pas des autres processus. Dans le cas d'utilisation Gestion des prêts : de la demande au déblocage des fonds, un client de la banque soumet une demande de prêt au Consortium interbancaire et reçoit les fonds de la banque. Le client de la banque représente le client générique. L'acheteur et le vendeur sont des types plus spécifiques de clients. Le cas d'utilisation métier Virer, retirer et déposer de l'argent permet à un client de la banque d'effectuer des virements entre comptes, de retirer ou déposer de l'argent. Ce cas d'utilisation permet également à un client de définir de futurs virements automatiques. Le modèle des cas d'utilisation est décrit par les diagrammes de cas d'utilisation (voir les chapitres 4 et 7). Un modèle objet métier est un modèle interne du métier. I l décrit la façon dont chaque cas d'utilisation du métier est réalisé par un groupe de travailleurs utilisant un ensemble d'entités

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

métier et d'unités de travail. Chaque réalisation de cas d'utilisation métier peut être montrée sous forme de diagrammes d'interactions (voir les chapitres 4 et 9) et de diagrammes d'activités (tels que les diagrammes d'enchaînements d'activités des chapitres 7 à 11). Une entité métier représente une chose, telle qu'une facture, à laquelle accèdent les travailleurs, qu'il peuvent inspecter, manipuler, produire ou utiliser dans un cas d'utilisation métier. Une unité de travail est un ensemble de telles entités formant un tout reconnaissable pour un utilisateur final. Les entités métier et les unités de travail permettent de représenter les mêmes types de concepts que les classes du domaine, telles que Commande, Article, Facture et Compte. On pourrait donc élaborer un diagramme des entités métier très proche de la figure 6.3. On ajouterait ensuite d'autres diagrammes, tels que la figure 6.4, pour décrire les travailleurs, leurs interactions et la façon dont ils utilisent les entités métier et les unités de travail. Chaque travailleur, chaque entité métier et chaque unité de travail peut prendre part à la réalisation de plusieurs cas d'utilisation métier. Il est très probable, par exemple, que la classe Compte participera aux réalisations des trois cas d'utilisation métier suivants : • dans Gestion des prêts : de la demande au déblocage des fonds, le montant du prêt sera versé sur un compte ;


6

Figure 6.4 Acheteur, Vendeur et Gestionnaire de règlements participent au cas d'utilisation métier Ventes : de la commande à la livraison. Le Gestionnaire de règlements vire l'argent d'un compte à un autre, selon les indications de la Facture.

L'acheteur et le vendeur utilisent le travailleur gestionnaire (automatisé) de règlements parce qu'il leur rend service à tous les deux : au vendeur, en adressant la facture à l'acheteur et en gardant la trace des factures impayées ; à l'acheteur, en simplifiant les règlements et en offrant une meilleure visibilité et disponibilité du règlement des factures.

6.6.2 Élaboration

d'un modèle

du

métier

L'élaboration d'un modèle du métier s'articule donc selon deux étapes :

• dans Virer, retirer et déposer de l'argent : l'argent est tiré d'un compte, déposé sur un compte ou viré d'un compte à l'autre ;

1. les personnes chargées de la modélisation métier doivent d'abord dresser un modèle des cas d'utilisation métier identifiant les acteurs du métier et les cas d'utilisation métier auxquels ils prennent part ;

• 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

2. il faut ensuite mettre au point un modèle objet métier intégrant les travailleurs, les entités métier et les unités de travail qui, ensemble, réalisent les cas d'utilisation métier. Les règles du métier et toute autre réglementation s'appliquant en la matière sont associées à ces différents objets. Le but est de créer des travailleurs, des entités métier et des unités de travail réalisant au mieux les cas d'utilisation métier, c'est-à-dire rapidement, précisément et à moindre frais.

Le cas d'utilisation métier Ventes : de la commande à la livraison Le cas d'utilisation Ventes : de la commande à la l i v r a i son se déroule selon les étapes suivantes (voir la figure 6.4) : 1. Un acheteur commande des marchandises ou des services en contactant le vendeur. 2. Le vendeur envoie une facture à l'acheteur par l'intermédiaire du gestionnaire de règlements. 3. Le vendeur livre les marchandises à l'acheteur ou effectue la prestation de service. 4. L'acheteur paie par l'intermédiaire du gestionnaire de règlements, ce qui implique le virement du montant du compte de l'acheteur sur le compte du vendeur. Le gestionnaire de règlements est un employé de la banque contribuant aux étapes 2 et 4. Ces tâches peuvent être automatisées par un système d'information.

La modélisation du métier et la modélisation du domaine se ressemblent sous bien des aspects. On peut, en fait, envisager la modélisation du domaine comme une variante simplifiée de la modélisation du métier, ne s'attachant qu'aux « choses », c'est-à-dire aux classes du domaine ou aux entités métier, nécessaires aux travailleurs. Les classes du domaine et les entités métier étant, par conséquent, des concepts très semblables, nous utilisons indifféremment ces deux termes. 1

Quelques différences majeures séparent, toutefois, la modélisation du métier de la modélisation du domaine, qui plaident nettement en faveur d'une modélisation du métier plus complète : • 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 spécifications des besoins, etc.) provenant de systèmes semblables au 1. Un modèle du domaine étant une variante simplifiée du modèle du métier, nous ne citons que ce dernier parmi les entrées des enchaînements d'activités principaux ultérieurs, tels qu'ils sont présentés 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


système en cours de développement. Pour trouver les entités mélici, en revanche, on pari des clients du métier, puis on identifie les cas d'utilisation métier, d'où se dégagent enfin les entités. Dans l'approche de la modélisation du métier, chaque entité doit être justifiée par sa participation à un cas d'utilisation métier. Ces deux approches aboutissent généralement à des ensembles différents de classes, d'associations, d'attributs et d'opérations. L'approche de la modélisation du domaine permet de faire remonter les classes à l'expérience des experts du domaine, tandis que l'approche de la modélisation du métier attribue la nécessité de chaque élément du modèle aux clients eux-mêmes. • Les classes du domaine ont des attributs, mais généralement peu ou pas d'opérations. I l n'en va pas de même pour les entités métier. L'approche de la modélisation du métier identifie non seulement les entités, mais les travailleurs qui prennent part à la réalisation des cas d'utilisation métier impliquant ces entités. Cette approche permet, en outre, de déterminer l'usage que font les travailleurs de ces entités à travers les opérations que chacune d'entre elles doit fournir. En ce qui concerne les entités elles-mêmes, ces opérations proviendront également des clients, dont la trace restera identifiable. • Les travailleurs recensés par la modélisation métier servent de point de départ à la mise au jour d'un premier groupe d'acteurs et de cas d'utilisation pour le système d'information à construire. Ce procédé permet de faire remonter chaque cas d'utilisation du système d'information aux clients, par le biais des travailleurs et des cas d'utilisation métier. Nous reviendrons plus en détail là-dessus au chapitre 7. I l est possible, à partir de chaque cas d'utilisation, de remonter jusqu'aux composants mettant en œuvre le système, comme le décrit le chapitre 3. On peut donc en conclure que l'association de la modélisation métier et de l'approche du génie logiciel proposée par le Processus unifié permet de suivre la trace des besoins du client à travers les processus, les travailleurs et les cas d'utilisation métier, jusqu'au code logiciel. Néanmoins, la seule utilisation d'un modèle du domaine n'offre pas de traçabilité directe entre ce modèle et les cas d'utilisation du système.

6

Utilisation de l'approche de la modélisation métier pour décrire le Processus unifié (première partie) L'approche de la modélisation métier présentée pour la modélisation de la société cliente est fondamentalement la même que celle choisie dans ces pages pour la description du Processus unifié de génie logiciel. Nous utilisons donc, pour cela, l'extension d'UML spécifique au métier (voir le chapitre 2). Outre un soubassement théorique solide, celte extension présente une grande utilité pratique et constitue une sorte d'auto-amorçage ou de travail de réflexion : elle expose les forces et les faiblesses de cette approche. Le Processus unifié est donc un cas d'utilisation métier de l'activité de développement logiciel. Au sein de cette activité, le processus s'organise ou, comme nous le disons, •• se réalise » à travers une séquence d'enchaînements d'activités liés 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'implémentation (chapitre 10) et les tests (chapitre 11). Chaque enchaînement d'activités constitue la réalisation d'une partie du cas d'utilisation métier Processus unifié, décrit en termes : de travailleurs, tels que l'analyste système et les spécificateurs de cas d'utilisation ; d'entités métier (ou, selon notre terminologie, d'artefacts), telles que les cas d'utilisation ou les cas de test ; d'unités de travail (qui sont également des artefacts), telles que le modèle des cas d'utilisation et la description de l'architecture. Les travailleurs, entités métier et unités de travail du Processus unifié sont également décrits dans les diagrammes de classes UML, avec les principales relations les associant les uns aux autres. (Suite de l'encadré au chapitre 7.)

6.6.3 Identification des cas d'utilisation à partir d'un du métier

modèle

L'utilisation, comme entrée, d'un modèle du métier offre une technique systématique pour la création d'un modèle des cas d'utilisation provisoire. L'analyste identifie d'abord un acteur pour chaque travailleur et chaque acteur métier (c'est-à-dire chaque client) destiné à devenir un utilisateur du système d'information. 1

RflfflH

L'acteur Acheteur L'acheteur utilise le Système de facturation et de règlement pour commander des marchandises ou des services et pour régler les factures. L'acheteur est donc à la fois un client et un acteur, car il utilise le système pour effectuer ses commandes et ses règlements par le biais de deux cas d'utilisation : Commander des marchandises ou des services et Régler les factures.

L

N

r c ï ï : ^ t r

e

acteur pour désigner un acteur du

^

•> -

—

*

-

»

*

co

n f u

-


II

Chaque travailleur (et acteur métier) destiné à devenir un utilisateur du système d'information doit être pris en charge par celui-ci. I l faut, pour cela, s'arrêter sur chaque travailleur, un par un, et identifier à chaque fois toutes les réalisations de cas d'utilisation métier auxquelles i l participera. Le travailleur joue un rôle dans chaque réalisation, tout comme une classe. Une fois que l'on a trouvé tous les rôles d'un travailleur ou d'un acteur métier, c'est-à-dire un rôle par réalisation de cas d'utilisation métier, on peut passer aux cas d'utilisation des acteurs système. Chaque travailleur et chaque acteur du métier correspond à un acteur du système d'information. Pour chaque rôle d'un travailleur ou d'un acteur métier, l'acteur système correspondant aura besoin d'un cas d'utilisation. Le moyen le plus direct d'identifier un ensemble possible de cas d'utilisation consiste donc à créer un cas d'utilisation pour l'acteur correspondant à chaque rôle de chaque travailleur et de chaque acteur métier. Si bien que l'on aura, pour chaque cas d'utilisation métier, un cas d'utilisation par travailleur et par acteur métier. Aux analystes, ensuite, de détailler et d'adapter ces propositions de cas d'utilisation. Les analystes doivent également décider, parmi les tâches des travailleurs ou des acteurs métier, quelles sont celles qui seront automatisées par les systèmes d'information (en tant que cas d'utilisation) et réorganiser les cas d'utilisation afin qu'ils répondent mieux aux besoins des acteurs. Notez que toutes les tâches ne sont pas susceptibles d'être automatisées. REKH

Identification des cas d'utilisation à partir d'un modèle du métier Pour reprendre l'exemple précédent, on pourrait suggérer un cas d'utilisation nommé Achat de marchandises ou de services, qui prendrait en charge l'acteur Acheteur lorsqu'il se comporte en acteur métier dans le cas d'utilisation métier Ventes : de la commande à la 1 i vrai son. Une analyse plus poussée laisse apparaître que le cas d'utilisation Achat de marchandises ou de services serait mieux réalisé par plusieurs cas d'utilisation distincts, tels que Commander des marchandises ou des servi ces et Régler la facture. La raison d'une telle scission est qu'un acheteur ne souhaitera pas exécuter un cas d'utilisation Achat de marchandises ou de servi ces en une seule séquence ininterrompue d'actions. Il préférera attendre la livraison des marchandises ou la réalisation de la prestation avant de procéder au règlement de la facture. C'est pourquoi la séquence de règlement est présentée sous la forme d'un cas d'utilisation à part, Régi er la facture, qui sera exécuté une fois les marchandises livrées.

Nous avons vu, dans les pages précédentes, comment modéliser le contexte d'un système à l'aide d'un modèle du domaine ou d'un modèle du métier. Puis, nous avons découvert comment dériver un modèle des cas d'utilisation d'un modèle du métier, c'est-à-dire un modèle des cas d'utilisation regroupant tous les besoins fonctionnels d'un système, ainsi que la plupart des exigences non fonctionnelles. Certaines de ces exigences, ne pouvant être associées à un cas d'utilisation particulier, sont appelées exigences supplémentaires.


6

6.7 Exigences s u p p l é m e n t a i r e s Les exigences supplémentaires comprennent principalement les exigences non fonctionnelles qui ne peuvent être associées à 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 matière de performances, d'interfaces et de conception physique en sont des exemples, de même que les contraintes d'architecture, de conception ou d'implémentation [1]. L'appréhension de ces exigences supplémentaires s'apparente à la spécification tradi tionnelle des besoins, puisque les exigences sont regroupées sous forme de liste. On les utilise ensuite au cours de l'analyse et de la conception, en association avec le modèle îles cas d'utilisation. Une exigence d'interface spécifie l'interface d'un article externe avec laquelle un système doit dialoguer ou exprime des contraintes de formats, des obligations temporelles ou d'autres facteurs pertinents dans ce type d'interaction. Une exigence physique précise les caractéristiques physiques que doit présenter un système, telles que le type de matériel, la forme, la taille ou le poids. Ce type d'exigence peut permettre, par exemple, de représenter les exigences matérielles telles que la configuration du réseau physique nécessaire. MHH

Exigences de plate-forme matérielle Serveurs

SUN SPARC 20 ou PC Pentium Clients

PC (équipés au minimum de processeurs Intel 486) ou Sun Sparc 5 Une contrainte de conception influe sur la conception d'un système. I l peut s'agir de contraintes d'extensibilité ou de capacité de maintenance, ou encore de contraintes concernant la réutilisation de systèmes existants ou de certaines parties de ces systèmes. Une contrainte d'implémentation spécifie ou impose le code ou la construction d'un système. Les exemples en sont multiples : standards exigés, directives et langages d'implémentation, politiques d'intégrité des bases de données, limites des ressources et environnements de fonctionnement. BfflgH

Contraintes de format de fichiers La version 1.2 du Système de facturation et de règlement prendra en charge les noms de fichier longs. Contraintes de plate-forme logicielle Logiciel

système

Systèmes d'exploitation des clients : Windows NT 4.0, Windows 95 ou Solaris 2.6 Systèmes d'exploitation des serveurs : Windows NT 4.0 ou Solaris 2.6


II


6

Magazine,

Netscape Communicator 4.0 ou Microsoft Internet Explorer 4.0

IVAR JACOBSON, "Business process reengineering with object technology " Obiect

Logiciel de navigation sur Internet

À ces exigences, s'en ajoutent bien souvent d'autres, comme les exigences légales et réglementaires. Blffll

Autres exigences

May 1994.

145

J

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 Spécification. Object Management Group Framtngham, MA, 1998. Internet: www.omg.org. Cliffs, N J : Prentice Hall, 1993.

La transmission doit être sûre, c'est-à-dire que seules les personnes autorisées doivent pouvoir accéder aux informations. Les seules personnes autorisées sont le client de la banque titulaire des comptes et les acteurs administrateurs de système.

A L A N M . DAVIS, Software Requirements:

Sécurité

Objects, Functions, and States, Englewood

Disponibilité

Le Système de facturation et de règlement 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 système) permettant de soumettre des commandes simples et de régler des factures simples ne doit pas excéder 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 règlement d'une seule commande.

6.8 R é s u m é À ce stade, nous sommes parvenus à une bonne compréhension de l'expression des besoins. Nous avons découvert en quoi les modèles du métier et du domaine contribuent à la définition du contexte du système et de quelle façon les cas d'utilisation pouvaient être dérivés d'un modèle du métier. 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 supplémentaires aident à analyser le système, à en créer l'architecture, à le concevoir, à l'implémenter et à le tester, de façon à satisfaire aux exigences des clients.

6.9 R é f é r e n c e s IVAR JACOBSON, MAGNUS CHRISTERSON, PATRIK JONSSON, and GUNNAR ÔVERGAARD, Object-Oriented Software Engineering: A Use-Case-Driven Approach,

2

I E E E Std 610.12.1990.

1

Reading, MA: Addison-Wesley, 1992 (Revised fourth printing, 1993). IVAR JACOBSON, M A R I A ERICSSON, and AGNETA JACOBSON, The Object Advantage: Business Process Reengineering with Object Technology, Reading, MA: Addison-

3

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 modèle du système à construire. L'emploi des cas d'utilisation constitue un excellent moyen de procéder à la création de ce modèle, car les besoins fonctionnels sont naturellement structurés comme des cas d'utilisation. Par ailleurs, la plupart des besoins non fonctionnels étant spécifiques à un cas d'utilisation unique, ils sont également traités dans le cadre précis de ce cas d'utilisation. Les autres besoins non fonctionnels, ceux qui sont communs à une partie ou à la totalité des cas d'utilisation, sont consignés dans un document à part et désignés sous le nom d'exigences supplémentaires. Ces exigences ont été décrites au chapitre 6 et ne seront pas réexaminées avant leur intervention dans les enchaînements d'activités de l'analyse, de la conception, de l'implémentation et des tests. Les cas d'utilisation offrent un moyen à la fois systématique et intuitif de saisir les besoins fonctionnels sous l'angle particulier de l'intérêt qu'ils présentent pour chaque utilisateur ou chaque système externe. Le recours aux cas d'utilisation oblige les analystes à réfléchi] a l'identité des utilisateurs et aux besoins professionnels, généraux ou spécifiques à 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'adhésion générale si leur intérêt s'arrêtait là. Le rôle essentiel qu'ils jouent dans le pilotage du travail de développement a largement contribué à leur intégration au sein des principales approches de l'ingénierie logiciellecontemporaine [8]. Dans ce chapitre, nous allons approfondir notre compréhension des cas d'utilisation et des acteurs et préciser les définitions avancées au chapitre 3. La description de l'enchaînement d'activités des besoins s'articulera autour de trois axes (nous procéderons de même pour les autres enchaînements d'activités dans les chapitres 8 à 11) :


II

• les artefacts créés dans l'enchaînement d'activités des besoins ; • les travailleurs prenant part à cet enchaînement d'activités ; • une vision plus détaillée de chaque activité de l'enchaînement d'expression des besoins. Nous allons, pour commencer, examiner les travailleurs et artefacts qu'illustre la figure 7.1

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

Approche de la modélisation métier utilisée pour décrire le Processus unifié (deuxième partie) Nous identifions ici les travailleurs et artefacts prenant part à chaque enchaînement d'activités. Un travailleur représente une fonction pouvant être attribuée à une personne ou à une équipe et spécifie les responsabilités et capacités que celle-ci suppose (voir également la section 2.1.3). Artefact est un terme générique désignant 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 système. Il peut s'agir d'un modèle, d'un élément de modèle ou d'un document. Dans l'enchaînement d'activités des besoins, par exemple, les artefacts se limitent essentiellement au modèle des cas d'utilisation et aux cas d'utilisation qui le composent. Notez que dans le modèle du métier du Processus unifié, un artefact est une entité métier 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 nommée 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 spéciaux pour la plupart des artefacts : les artefacts représentant des documents sont désignés par un symbole de document, tandis que les modèles ou éléments de modèles s'affichent avec le symbole UML qui les identifie. Remarquez que pour pouvoir utiliser ces symboles spéciaux dans le modèle du métier du Processus unifié, nous introduisons des stéréotypes de documents, de modèles et d'éléments de modèle. Chacun de ces stéréotypes est un sous-type des stéréotypes « e n t i t é métier » ou « unité de t r a v a i l » . Nous décrivons les modalités de la collaboration des travailleurs à un enchaînement d'activités en insistant sur la façon dont le point de vue se déplace de travailleur en travailleur et en expliquant la manière dont ils utilisent les artefacts pour mener à bien leurs différentes activités (voir également la section 2.4.2). C'est dans ce contexte que nous allons aussi examiner plus précisément chaque activité. Une activité est une tâche qu'effectue un travailleur pendant l'enchaînement d'activités, c'est-à-dire l'exécution de l'une des opérations liées au travailleur.


Expression des besoins sous forme de cas d'utilisation CHAPITRE

O O

Spécificateur de cas d'utilisation responsable de

o

7

O

D


I

O Archltoctu

roN|>
responsable de

i

o

Û

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 modèle 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. Déjà sommairement présentés au chapitre 3, ces artefacts reçoivent ici des définitions plus précises, concordant avec celles livrées dans [12]. Nous en assouplirons ensuite le formalisme pour montrer l'application réelle de ces constructions dans le Processus unifié. Ces définitions permettent d'établir des fondations solides, mais i l n'est pas obligatoire de respecter un tel formalisme dans la pratique. Nous les intégrons ici pour les raisons suivantes : • i l peut être important de les connaître lors de la description formelle de certains cas d'utilisation, comme l'emploi de diagrammes d'activités ou d'états-transitions, particulièrement appréciables pour les cas d'utilisation comportant de nombreux états, eux-mêmes reliés par des transitions complexes ; • elles facilitent l'identification des cas d'utilisation adéquats et la cohérence de leur description. En fait, même 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 résultat complet et cohérent ; • i l faut aussi pouvoir expliquer les constructions acteur et cas d'utilisation par rapport à d'autres constructions UML.

7.2.1 Artefact : modèle


Le modèle des cas d'utilisation permet de parvenir à un accord entre le client et les développeurs sur les besoins [6], c'est-à-dire sur les conditions que le système doit respecter et les possibilités qu'il doit offrir. Ce modèle sert de contrat et fournit les entrées principales pour l'analyse, la conception et les tests. Un modèle des cas d'utilisation est un modèle d'un système 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

Hum» t.2 i

1

.i.l,-des cas IM

non cl son /,

fi

r~l+

Modèledes cas d'utilisation

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

7 '

Figure 7.3 L'acteur Acheteur.

Systèmedes cas d'utilisation

• \'Hir des cas d utilisation lr)itfMille le tagr de niveau supérieur

.

O

Acteur

Cas d'utilisation

Un acteur joue un rôle différent dans chaque cas d'utilisation auquel i l collabore. À chaque fois qu'un utilisateur particulier (un humain ou un autre système) dialogue avec le système, c'est l'instance correspondante de l'acteur qui joue ce rôle. Une instance d'un acteur esl donc un utilisateur spécifique dialoguant avec le système. Toute entité obéissant à la défi nition d'un acteur peut agir en tant qu'instance de cet acteur.

7.2.3 Cas d'utilisation Chaque usage que les acteurs font du système est représenté par un cas d'utilisation. Les cas d'utilisation sont des « parcelles » de fonctionnalités qu'offre le système afin de produire un résultat satisfaisant pour ses acteurs. De façon plus stricte, un cas d'utilisation spécifie une séquence d'actions (accompagnée des autres séquences possibles) que le système pcul effectuer en dialoguant avec les acteurs du système.

I .c modèle des cas d'utilisation pouvant s'étoffer au point d'être difficile à « digérer » en une Seule fois, il faut trouver un moyen de l'appréhender morceau par morceau. UML permet de présenter ce modèle sous forme de diagrammes faisant apparaître les acteurs et les cas d'utilisation de différents points de vue et selon des intentions diversifiées. Notez également que si le modèle 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 gérer la taille. Il s'agit là d'une extension plus ou moins triviale du modèle des cas d'utilisation, qui n'est pas traitée dans cet ouvrage.

7.2.2

Un cas d'utilisation constitue donc une spécification, en ce qu'il définit le comportement d'« éléments » dynamiques, en l'occurrence les instances de cas d'utilisation. fifflfl

Le cas d'utilisation Retirer de l'argent Nous avons décrit, 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'intermédiaire d'un guichet automatique de banques (GAB) (figure 7.4).

Artefact : acteur Le modèle des cas d'utilisation décrit le rôle que joue le système pour chaque type d'utilisaleur, représenté par un ou plusieurs acteurs. Chaque système externe avec lequel dialogue le système est également représenté par un ou plusieurs acteurs. Sont considérées comme externes au système toutes les unités autonomes, telles que les horloges. Les acteurs représentent par conséquent les parties extérieures au système qui collaborent avec celui-ci. Une fois que l'on a identifié tous les acteurs d'un système, on a identifié l'environnement externe du système. Comme l'explique le chapitre 6, les acteurs correspondent souvent aux travailleurs (ou acteurs métier) d'une entreprise. N'oubliez pas que chaque rôle (d'un travailleur) définit ce que fait ce travailleur au sein d'un processus métier spécifique. On peut ensuite utiliser les différents rôles que peut jouer un travailleur pour dériver (ou générer, si l'on dispose des outils appropriés) les rôles que jouera l'acteur système correspondant. Puis, comme le suggère le chapitre 6, on fournit à chaque travailleur un cas d'utilisation du système pour chacun de ses rôles. Ce cas d'utilisation présente un intérêt pour l'acteur lorsqu'il incarne le rôle du travailleur.

Figure 7.4 Cas d'utilisation Retirer de l'argent.

O Retirer de l'argent

Le cas d'utilisation Reti rer de l'argent indique les possibles instances de ce cas d'utilisation, c'est-à-dire les différentes façons dont il peut être légitimement exécuté par le système et l'interaction nécessaire 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 système effectue alors l'une des instances du cas d'utilisation. Si, en revanche, Patrick saisit le même code secret, demande 400 francs puis récupère l'argent, le système exécute une autre instance du cas d'utilisation. On obtient F exécution d'une troisième instance du cas d'utilisation si Patrick demande à retirer 700 francs et que le système rejette cette demande en raison d'un solde insuffisant ou d'un code secret incorrect ; ainsi de suite.

Acteur Le Système de facturation et de règlement dinterbankdialogue avec un type d'utilisateur qui emploiera le système pour commander des marchandises, confirmer des commandes, régler des factures, etc. Ce type d'utilisateur est ensuite représenté par l'acteur Acheteur (figure 7.3).

Dans la terminologie UML, un cas d'utilisation est un classificateur, ce qui signifie qu'il esl doté d'opérations et d'attributs. Une description de cas d'utilisation peut donc comprendre des diagrammes d'états-transitions, d'activités, de collaboration et de séquence (pour de plus amples détails, voir l'annexe A, « Présentation générale d'UML »).


II

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

Les diagrammes d'états-transitions spécifient le cycle de vie des instances de cas d'utilisation sous forme d'états et de transitions entre ces états. Chaque transition est une séquence d'actions. Les diagrammes d'activités représentent plus précisément ce cycle de vie en décrivant également la séquence d'actions se produisant entre deux transitions. Enfin, les diagrammes de collaboration et de séquence servent à décrire 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 nécessaire d'être aussi formel pour la représentation des cas d'utilisation, comme nous le dirons dans la section 7.4.3, « Détailler un cas d'utilisation ». Le fait d'avoir en tête cette compréhension plus précise des cas d'utilisation peut toutefois se révéler utile lors de la structuration des descriptions de cas d'utilisation. Une instance de cas d'utilisation est l'exécution d'un cas d'utilisation. En d'autres termes, c'est ce qu'effectue le système lorsqu'il « obéit à un cas d'utilisation ». Lorsqu'une instance de cas d'utilisation est exécutée, elle dialogue avec les instances des acteurs et effectue la séquence d'actions décrite par le cas d'utilisation sous la forme d'un diagramme d'étatstransitions ou d'activités. Cette séquence constitue l'un des chemins possibles du cas d'utilisation. De nombreux chemins peuvent être empruntés, dont beaucoup sont très proches les uns des autres. Ce sont les solutions de rechange à la séquence d'actions du cas d'utilisation. Un tel chemin pourrait se dérouler de la façon suivante :

Elle est (de nouveau) invoquée 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.

5.

Elle attend (dans ce nouvel état) un autre message externe d'un acteur.

4.

Elle passe à un autre état en effectuant une autre séquence d'actions pouvant contenir des calculs internes, la sélection d'un chemin et l'émission de messages (à l'intention d'un acteur).

3.

Elle est invoquée par un message externe émanant d'un acteur.

2.

L'instance de cas d'utilisation est lancée et placée en état de début.

1.

7

autres conflits potentiels (tels que le partage d'objets) entre différentes instances de cas d'utilisation. Les instances de cas d'utilisation sont envisagées comme étant atomiques : chacune est exécutée de façon complète ou pas du tout, sans aucune interférence avec d'autres instances du cas d'utilisation. Le comportement de chaque cas d'utilisation peut donc être interprété indépendamment des autres cas d'utilisation, ce qui simplifie considéri blement la modélisation des cas d'utilisation. Le fait de considérer que les cas d'utilisation sont atomiques n'a rien à voir avec la présence éventuelle d'un gestionnaire de transaiItioni sous-jacent aux cas d'utilisation, qui serait chargé de régler les conflits. Il ne s'agit ici que de s'assurer que le modèle des cas d'utilisation est lisible et compréhensible. Il faut néanmoins admettre que l'on risque d'être confronté à certains problèmes d'interfl rences entre les différentes utilisations d'un système. La résolution de ces problèmes ne pourra pas être prise en charge par la modélisation des cas d'utilisation, mais sera différée aux phases d'analyse et de conception (décrites respectivement dans les chapitres 8 et 9), ou les cas d'utilisation seront réalisés sous forme de collaborations entre classes et/ou sou tèmes. Par exemple, le modèle d'analyse permet de décrire très clairement la façon dont une seule classe peut participer à plusieurs réalisations de cas d'utilisation et le moyen de résoudre les problèmes d'interférences qui risquent d'en résulter.

Modélisation

de vastes

systèmes

ans cet ouvrage, nous allons insister sur la modélisation d'un seul et même système Ma, dans bien des cas, les systèmes à développer sont plus vastes coZses enTait s

tèmes

63 S y S t è m 6 S

' ° 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 ? * . ?

•

L'un des plus grands systèmes au monde Le plus grand système jamais construit par des humains compte près d'un milliard d'utilisateurs : il s'agit du réseau mondial de télécommunications. Lorsque vous téléphonez, par exemple, de San Francisco à Stockholm, votre appel passe sans doute par une vingtaine de systèmes de commutation locaux et internationaux, de systèmes de liaison par satellite, de systèmes de transmission, etc. Le développement de chacun de ces types de système a coûté environ 1 000 années-homme, investissement dont l'aspect logiciel représente une part essentielle.

C'est le plus souvent une instance d'acteur qui invoque une instance de cas d'utilisation, comme nous l'avons décrit plus haut, mais ce peut aussi être un événement interne au système, comme le déclenchement d'une horloge réglée à cet effet (si l'horloge est considérée comme interne au système). Les cas d'utilisation, comme tous les classificateurs, ont des attributs qui représentent les valeurs qu'utilise et que manipule une instance de cas d'utilisation pendant l'exécution de son cas d'utilisation. Ces valeurs sont locales à l'instance du cas d'utilisation, c'est-à-dire qu'elles ne peuvent être utilisées 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.

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 impliqués, comment est-ce possible ? La principale explication tient à la standardisation de l'ensemble des interfaces du réseau (c'està-dire de l'architecture du réseau) par un seul et même organisme : l'ITU (International Télécommunications Union).

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 modèle des cas d'utilisation relie les instances d'acteurs aux instances de cas d'utilisation [10]. I l faut, en effet, que le modèle des cas d'utilisation reste simple et intuitif afin de susciter des discussions fructueuses, et qui ne se perdent pas dans les détails, avec les utilisateurs finals et les autres intervenants. I l n'est pas question de se préoccuper des interfaces entre cas d'utilisation, de la concurrence et des

L'ITU a spécifié les interfaces entre tous les types de nœuds du réseau et défini précisément la sémantique utilisée par ces interfaces.

(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 gérées dans les enchaînements d'activités ultérieurs comme ceux d'analyse, de conception et d'implémentation. La construction de systèmes de systèmes s'appuie sur des techniques semblables à celles qui ont servi à élaborer le réseau de télécommunications mondial [9]. L'ensemble du système est d'abord spécifié avec ses cas d'utilisation et conçu sous forme de collaborations entre sous-systèmes. La somme des cas d'utilisation du système global est ensuite détaillée en cas d'utilisation des sous-systèmes collaborant, eux-mêmes reliés par l'intermédiaire d'interfaces. La définition précise de ces interfaces permet de faire développer indépendamment chaque sous-système (comme un système à part entière) 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 systèmes [13]. En fait, les cas d'utilisation permettent de spécifier non seulement des systèmes, mais aussi des entités plus modestes, telles que des sous-systèmes ou des classes. Un soussystème, ou une classe, peut alors comprendre deux parties décrivant chacune un point de vue différent : une spécification et une implémentation. La spécification décrit en termes de cas d'utilisation ce que produit le sous-système ou la classe pour son environnement, tandis que la partie implémentation en présente la structure interne, qui permettra de réaliser la spécification. Cet environnement se compose généralement d'autres sous-systèmes et classes. Mais si l'on veut le traiter de façon anonyme, on peut également le faire représenter par ses acteurs. Le choix de cette approche s'impose lorsque l'on veut traiter un sous-système comme un système à part entière, par exemple : lorsque l'on veut développer le sous-système à l'aide d'une technologie différente de celle utilisée pour les autres sous-systèmes. Cette possibilité existe à condition que les cas d'utilisation appropriés soient proposés et que les interfaces spécifiées soient prises en charge ; lorsque l'on souhaite gérer le sous-système séparément des autres sous-systèmes, éventuellement sur des sites géographiquement dispersés. 7.2.3.1 Flot d ' é v é n e m e n t s I ,c Ilot d'événements de chaque cas d'utilisation peut être exprimé sous forme de description textuelle de la séquence d'actions du cas d'utilisation. Il indique ce que fait le système et la façon dont il dialogue avec les acteurs lors de l'exécution de ce cas d'utilisation. I )u point de vue de la gestion, une description de flot d'événements comprend un ensemble de séquences d'actions susceptibles d'être modifiées, révisées, conçues, implémentées et lestées ensemble, et de faire l'objet d'une même section ou sous-section du manuel de l'utilisateur. Nous donnerons quelques exemples de descriptions de flots d'événements liées à des cas il'utilisation dans la section 7.4.3, « Activité : détailler un cas d'utilisation ». 7.2.3.2 Exigences particulières Les exigences particulières se présentent 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-

Nous donnons des exemples d'exigences particulières liées à un cas d'utilisation dans la section 7.4.3, « Activité : détailler un cas d'utilisation ».

7.2.4 Artefact : description de l'architecture (vue du modèle des cas d'utilisation) La description de l'architecture contient une vue architecturale du modèle des ras il'uiili sation qui présente les cas d'utilisation significatifs sur ce plan (figure 7.5). Figure 7.5 Description de l'architecture.

Description de l'architecture vue architecturale

Modèle des cas d'utilisation La vue architecturale du modèle des cas d'utilisation doit inclure les cas d'utilisation décrivant des fonctionnalités stratégiques ou impliquant certaines exigences fondamentales qui doivent être prises en charge au début du cycle de vie du logiciel. Cette vue architecturale sert d'entrée lors de la définition de l'ordre de priorité des cas d'utilisation à développer (c'est-à-dire à analyser, concevoir et implémenter) au sein d'une itération. Ce sujet est traité plus précisément dans les première et troisième parties de l'ouvrage (voir le chapitre 4, section 4.3, et le chapitre 12, section 12.6). Les réalisations correspondantes des cas d'utilisation se trouveront en principe dans les vues architecturales des modèles 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 définir les termes qu'utilisent les analystes (et les autres déve loppeurs) pour décrire le système, et de parvenir ainsi à un consensus entre développeurs NUI la définition des divers concepts et notions, tout en limitant les risques de malentendu. On peut, en général, dériver un glossaire d'un modèle du métier ou d'un modèle 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

I


II

^ ^ ^ ^ ^ CHAPITRE

plus ciblé sur le système à construire que sur le conlexle île ce système, contrairement au modèle du métier ou du domaine.

7

Figure 7.6

O

Responsabilités

a

d'un analyste

.2.6 Artefact : prototype d'interface utilisateur Les prototypes d'interface utilisateur contribuent, au cours de l'expression des besoins, à faciliter la compréhension et la spécification des interactions entre les acteurs humains et le système. Ces prototypes ne contribuent pas seulement à la mise au point d'une meilleure interface utilisateur ; ils aident aussi à mieux appréhender les cas d'utilisation. D'autres artefacts, tels que des modèles d'interfaces utilisateur et des esquisses d'écran, peuvent également être utilisés lors de la spécification de l'interface utilisateur.

système

au moment

de l'expression des besoins sous forme de cas

d'utilisation.

/

Analyste système

I ~

responsable de


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.

Glossaire

Bien qu'il ait la charge du modèle des cas d'utilisation et des acteurs que contient celui ci, l'analyste système n'est pas responsable de chaque cas d'utilisation en particulier II s'agit lit d'une responsabilité à part, confiée au travailleur spécificateur de cas d'utilisation (section 7.3.2). L'analyste système dirige, cependant, la modélisation et coordonne l'expression des besoins.

.3 Les travailleurs Nous avons décrit, un peu plus haut dans ce chapitre, les artefacts produits au cours de la modélisation des cas d'utilisation. L'étape suivante nous conduit maintenant à examiner les travailleurs chargés de ces artefacts. Comme nous l'avons vu au chapitre 2, un travailleur est un poste auquel peut être affectée une personne « réelle ». Chaque travailleur s'accompagne d'une description des responsabilités qui lui sont attribuées et du comportement qui en est attendu. Travailleur n'est pas synonyme d'individu ; une personne peut être affectée à plusieurs travailleurs au cours d'un projet. De même, 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 capacités nécessaires à un cas d'utilisation métier, en l'occurrence le Processus unifié d'ingénierie logicielle. Dans le cadre de l'affectation du personnel à un projet, un travailleur représente les connaissances et les capacités dont une personne doit disposer pour incarner ce travailleur sur le projet. On peut identifier trois types de travailleurs prenant part à la modélisation des cas d'utilisation, chacun ayant un éventail différent de compétences et de responsabilités : l'analyste système, le spécificateur de cas d'utilisation et le concepteur d'interface utilisateur. Tous ces travailleurs seront désignés collectivement sous le nom d'« analystes » dans cet ouvrage. D'autres travailleurs qui interviennent également, comme les réviseurs, ne seront pas évoqués ici.

'.3.1 Travailleur : analyste

Il y a un analyste système par système. Néanmoins, la pratique montre que ce travailleur est généralement pris en charge par une équipe comprenant un grand nombre d'analystes (répartis en ateliers, par exemple).

7.3.2 Travailleur : spécificateur

de cas d'utilisation

La plupart du temps, la tâche qui consiste à formuler les besoins ne peut être accomplie par une seule personne. L'analyste système s'entoure donc d'autres travailleurs, chacun étant responsable de la description détaillée d'un ou de plusieurs cas d'utilisation. On appelle ces travailleurs spécificateurs de cas d'utilisation (figure 7.7). Figure 7.7

O

Responsabilités d'utilisation

de cas

spécificateur

d'un

O

Spécificateur de cas d'utilisation

au moment de

I

l'expression des besoins sous forme de cas

responsable de

d'utilisation.

l û

système

Cas d'utilisation

L'analyste système a la responsabilité de l'ensemble des besoins modélisés en tant que cas d'utilisation, y compris des besoins fonctionnels et non fonctionnels spécifiques à un cas d'utilisation. L'analyste système est chargé de délimiter le système, d'identifier les acteurs et les cas d'utilisation et de s'assurer que le modèle des cas d'utilisation est à la fois complet et cohérent. Pour le respect de cette cohérence, l'analyste système peut avoir recours à un glossaire, qui permettra de fixer les termes, notions et concepts employés dans le projet une fois les besoins exprimés. La figure 7.6 illustre les responsabilités qu'assume l'analyste système.

Ï

S

S

S

ï

ï

*

-

*

-

*

^



7

II

7.3.3 Travailleur : concepteur d'interface utilisateur Les concepteurs d'interface utilisateur façonnent' l'aspect visuel de l'interface utilisateur. Cette tâche peut nécessiter la création de prototypes d'interface utilisateur pour certains cas d'utilisation, en général 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. O

I Igure7.8

Responsabilités Jim concepteur il interface

D

Concepteur d'Interface utilisateur

I

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

responsable de

1

7.4 E n c h a î n e m e n t d'activités Après avoir décrit, dans la section précédente, l'enchaînement des activités permettant la prise en compte des besoins en termes statiques, nous allons désormais en présenter le comportement dynamique sous forme de diagramme d'activités (figure 7.10). Figure 7.10

„

Enchaînement d'activités d'expression des besoins sous forme de cas d'utilisation, avec les travailleurs y prenant part et leurs activités.

vue architecturale

...

^

...

O

O Analyste système

Identifier les acteurs et les cas d'utilisation


O

a

Assigner un ordre de priorité aux cas d'utilisation ^

^

1

/

/ / /

Détailler un cas d'utilisation

O


turale du modèle des cas d'utilisation (figure 7.9).

O Architecte responsable de

4

V

Architecte O

Q

n

Prototype d'interface utilisateur

Spécificateur de cas d'utilisation O

7 34 Travailleur : architecte L'architecte prend part à l'enchaînement d'activités des besoins pour décrire la vue architec-

O

Figure 7.9

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


Description de l'architecture

La vue architecturale du modèle des cas d'utilisation est une entrée ^portante ™ fication des itérations, comme le décrit la section 7.4.2, «Activtté: defimr un ordre de priorité pour les cas d'utilisation ».

Prototyper l'interface utilisateur

Le diagramme matérialise la répartition des activités entre les divers intervenants grâce à des travées pareilles à des couloirs de natation. Chaque activité (représentée par un engrenage) est ainsi placée dans la même zone que le travailleur chargé de l'effectuer. L'exécution de ces activités conduit à la création, puis à la modification de divers artefacts. Nous décrivons cet enchaînement comme une séquence d'activités ordonnées de sorte que chacune d'entre elles produise un résultat qui servira de point de départ à l'activité suivante. Le diagramme d'activités ne présente toutefois qu'un flux logique. Dans la réalité, i l n'est pas indispensable de mener ces activités de façon séquentielle du moment que l'on parvient à un résultat 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é Créer 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 séquence strictement définie), et ainsi de suite. Une activité peut ainsi être reprise plusieurs fois, chacun de ces passages n'aboutissant qu'à la réalisation 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 conséquent à illustrer la séquence logique des activités en utilisant les résultats issus d'une activité terminée comme point de départ de l'exécution d'une autre activité.

de conception et d'implémentation.

Mm

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

Dans un premier temps, l'analyste système (une personne entourée d'une équipe d'analystes) effectue l'activité Identifier les acteurs et les cas d'utilisation pour élaborer une première version d'un modèle des cas d'utilisation dont les acteurs et les cas d'utilisation sont identifiés. I l doit ensuite s'assurer que le modèle des cas d'utilisation en cours de développement prend en compte les besoins à l'origine de l'enchaînement d'activités, c'està-dire la liste des fonctionnalités et le modèle du domaine ou du métier. 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'itération en cours. En partant de ces éléments, les spécificateurs de cas d'utilisation (différentes personnes) décrivent tous les cas d'utilisation identifiés comme prioritaires. À peu près en même temps, les concepteurs des interfaces utilisateur (différentes personnes) se fondent sur ces descriptions pour suggérer des interfaces utilisateur appropriées pour chaque acteur. Enfin, l'analyste système remanie le modèle des cas d'utilisation pour le rendre aussi compréhensible que possible en établissant des généralisations entre cas d'utilisation. (Les généralisations induites par l'activité Structurer le modèle des cas d'util i sati on sont brièvement justifiées.) U s résultats de la première itération menée sur cet enchaînement d'activités constituent une première version du modèle des cas d'utilisation, des cas d'utilisation eux-mêmes et de tout prototype d'interface utilisateur associée. Les itérations suivantes produiront, à leur tour, de nouvelles versions de ces artefacts. Gardez à l'esprit que tous les artefacts seront finalisés et améliorés de façon incrémentale, au fil des itérations. Les diverses activités liées à la modélisation des cas d'utilisation revêtent des formes différentes 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 création, l'analyste système détectera un grand nombre de nouveaux acteurs et cas d'utilisation. En revanche, lorsqu'il exécutera cette même 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 création de nouveaux diagrammes reflétant le modèle des cas d'utilisation selon un point de vue spécifique. Nous décrirons plus loin ces activités telles qu'elles apparaissent typiquement dans une itération 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 délimiter le système par rapport à son environnement ; • de faire apparaître les personnes et les éléments (acteurs) interagissant avec le système, ainsi que les fonctionnalités (cas d'utilisation) attendues de la part du système ; • de saisir et de définir dans un glossaire les termes essentiels à la création de descriptions détaillées des fonctionnalités du système (par exemple, les cas d'utilisation). Cette identification est l'activité cruciale pour une appréhension exacte et fidèle des besoins. C'est pourquoi elle est confiée à l'analyste système (figure 7.11). Celui-ci ne peut toutefois effectuer cette tâche seul. I l lui faut des éléments fournis par une équipe constituée du client,


7

de ses utilisateurs et d'autres analystes prenant part aux ateliers de modélisation dirigés par l'analyste système. Figure 7.11 Entrées et résultats de l'identification des acteurs et des cas d'utilisation.

O

n Modèle du métier [ou modèle du domaine]

Analyste système

> Exigences supplémentaires

Modèle des cas d'utilisation [esquisse]

-v Identifier les acteurs et les cas d'utilisation Glossaire

Liste des fonctionnalités

Il arrive que l'on dispose d'un modèle du métier comme point de départ. Cette opportunité permet à l'équipe de créer, de façon plus ou moins « automatique », une première esquisse du modèle des cas d'utilisation. I l faudra, dans d'autres cas, se fonder sur un modèle du domaine ou encore se contenter d'une ébauche très sommaire ou d'une spécification détaillée des besoins comprenant les fonctions générales exigées de la part du système. Enfin, l'équipe d'analyse pourra se voir remettre une liste d'exigences supplémentaires n'ayant pu être allouées à des cas d'utilisation individuels. Pour en savoir plus sur ces différents artefacts fournis comme points de départ, consultez le chapitre 6. Cette activité se décompose en quatre étapes : • identifier les acteurs ; • identifier les cas d'utilisation ; • décrire brièvement chacun des cas d'utilisation ; • décrire de façon globale le modèle des cas d'utilisation (cette étape comprend également l'élaboration d'un glossaire). Il n'est pas nécessaire de respecter un ordre particulier pour l'exécution de ces étapes, qui sont d'ailleurs souvent concomitantes. Les diagrammes de cas d'utilisation pourront, par exemple, être actualisés à chaque fois qu'un nouvel acteur ou qu'un nouveau cas d'utilisation sera identifié. Cette activité aboutit à une nouvelle version du modèle des cas d'utilisation, enrichie d'acteurs et de cas d'utilisation inédits ou modifiés. Ce modèle doit donner lieu à une des-

1

1. I l s'agit ici, en réalité, de « la personne agissant en tant qu'analyste système ». S'il est un peu maladroit, à la longue, de faire une distinction entre la personne réelle et le travailleur qu'elle incarne, la description s'en trouve néanmoins clarifiée. Nous adoptons la m ê m e approche pour tous les autres travailleurs é v o q u é s .

PARTIE

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

• A

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

II

cription superficielle sous forme de texte et de diagrammes n'entraiil pas dans le détail 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 itérations). Une description plus précise en sera donnée plus loin. figure 7.12 Cat d'utilisation Système de turation et de M tlement prenant en t barge le cas • i utilisation métier ites : de la . nmande à la livraison. Le rôle d'initiateur, taché aux lociations, indique quel acteur est à " rtgtne du cas

.

respect de ce critère permettra de ne retenir que les acteurs pertinents et d'écarter ceux qui ne sont que pur produit de notre imagination. Deuxièmement, le chevauchement entre les rôles que jouent les instances des différents acteurs par rapport au système doit être limité au strict minimum. I l n'est pas question de conserver plusieurs acteurs ayant à peu près le même rôle. Si c'est le cas, i l faut essayer soit de regrouper ces rôles en un ensemble unique pris en charge par un seul acteur, soit de trouver un autre acteur plus général auquel sont attribués les rôles communs à ces différents acteurs. Ce nouvel acteur peut ensuite être spécialisé à l'aide de généralisations. Par exemple, Acheteur et Vendeur seront des spécialisa tions de l'acteur Cl ient de la banque. I l n'est pas rare, au début, de déterminer un nombre trop important d'acteurs dont les tâches se recoupent largement. I l faut souvent plusieurs réunions avant de parvenir à un ensemble correct et stable d'acteurs et de généralisations. L'analyste système baptise les acteurs et décrit brièvement leurs différents rôles ainsi que l'utilisation que chacun fait du système. I l est important d'attribuer aux acteurs des noms évocateurs, qui véhiculeront la signification souhaitée. La courte description qui accompagne chaque acteur doit permettre d'en délimiter les besoins et les responsabilités. Bfflfij

Les acteurs Acheteur, Vendeur et Système de comptabilité Acheteur

Un Acheteur représente une personne chargée d'acheter des biens ou des services comme le décrit le cas d'utilisation métier Ventes : de la commande à la livraison. Il peut s'agir d'un particulier (c'est-à-dire non employé par une société) ou d'un membre d'une entreprise. L'Acheteur de biens et de services a besoin du Système de facturation et de règl ement pour passer les commandes et régler les factures.

ililisation.

Il»

Vendeur

Un Vendeur représente une personne chargée de vendre et de livrer des biens ou des services. Le Vendeur utilise le système pour vérifier s'il y a de nouvelles commandes et pour envoyer des confirmations de commande, des factures et des relances. Envoyer des relances

Système de comptabilité

Le Système de facturation et de règlement envoie les justificatifs des transactions au Système de comptabilité.

7.4.1.1 Identifier les acteurs La tâche consistant à identifier les acteurs dépend largement du point de départ. Lorsqu'il existe un modèle du métier, l'identification des acteurs est directe. L'analyste système peut suggérer la présence d'un acteur par employé de l'entreprise, et d'un acteur par acteur métier (c'est-à-dire chaque client de l'entreprise) devant utiliser le système d'informations (voir également le chapitre 6, section 6.6.3). Sinon, avec ou sans modèle du domaine, l'analyste système identifie les utilisateurs avec l'aide du client et tente de les répartir en différentes catégories représentant les acteurs. Dans l'un et l'autre cas, i l faut déterminer les acteurs figurant les systèmes externes et ceux qui désignent les personnes chargées de maintenir ou de faire fonctionner le système. Deux critères se révèlent 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

Cette étape donne lieu à une nouvelle version du modèle des cas d'utilisation, dotée d'un ensemble d'acteurs actualisé et d'une brève description de chacun d'entre eux. Ces acteurs sommairement décrits peuvent alors servir de point de départ à l'identification des cas d'un lisation. 7.4.1.2 Identifier les c a s d'utilisation Lorsque l'on part d'un modèle du métier, on identifie les acteurs et les cas d'utilisation selon la procédure décrite au chapitre 6, dans la section 6.6.3, « Identification des cas d'utilisation à partir d'un modèle du métier ». On suggère un cas d'utilisation pour chaque rôle de chaque travailleur qui prendra part à la réalisation d'un cas d'utilisation et se servira du système d'information. Sinon, l'analyste système peut identifier les cas d'utilisation par le biais


II

d'ateliers réunissant 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 création de story-boards peuvent aider à déterminer les cas d'utilisation nécessaires ; voir [16]. L'acteur aura le plus souvent besoin de cas d'utilisation pour prendre en charge les tâches consistant à créer, à modifier, à suivre, à supprimer ou à étudier les objets métier, tels que Commandes et Comptes, intervenant dans les cas d'utilisation métier. Il est possible, également, que l'acteur informe le système de certains événements externes ou, à l'inverse, que l'acteur ait besoin d'être informé par le système de la survenue d'un événement donné, tel que l'arrivée à échéance d'une facture. I l se peut aussi que d'autres acteurs assurent le démarrage, l'interruption ou la maintenance du système. Certains des candidats ne deviendront pas eux-mêmes des cas d'utilisation mais feront partie d'autres cas d'utilisation. N'oubliez pas que le but est de créer des cas d'utilisation faciles à modifier, à réviser, à tester et à gérer en tant qu'unités individuelles. Le choix du nom de chaque cas d'utilisation doit nous amener à réfléchir à la séquence d'actions susceptible de satisfaire aux attentes de l'acteur. Les noms de cas d'utilisation commencent souvent par un verbe et doivent refléter la nature de l'interaction entre l'acteur et le système. Dans notre exemple, nous avons utilisé des cas d'utilisation tels que Régi er 1 a facture et Commander des marchandises ou des services. Il est parfois difficile de définir la portée d'un cas d'utilisation. Une séquence d'interactions entre l'utilisateur et le système peut être spécifiée par un ou plusieurs cas d'utilisation que l'acteur invoque les uns après les autres. Pour déterminer si un cas d'utilisation candidat doit finalement devenir un cas d'utilisation à part entière, il faut se demander s'il est autonome ou s'il fait systématiquement 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 précis, un cas d'utilisation doit livrer un résultat observable et satisfaisant aux attentes d'un acteur particulier. Ce conseil pragmatique peut aider à délimiter au mieux la portée du cas d'utilisation. Notez que deux expressions clés, résultat satisfaisant et acteur particulier, constituent des critères utiles pour l'identification des cas d'utilisation : • Résultat satisfaisant : chaque cas d'utilisation exécuté avec succès 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 téléphonique, peut impliquer plusieurs acteurs. Le critère du « résultat observable et satisfaisant » doit alors s'appliquer à l'acteur qui est à l'origine du cas d'utilisation. Ce critère de « résultat satisfaisant » permet d'écarter les cas d'utilisation dont la portée serait trop limitée. • Acteur particulier : l'identification de cas d'utilisation satisfaisants pour des utilisateurs individuels réels permet de conserver les cas d'utilisation dans des proportions raisonnables.

BfflH

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

Portée du cas d'utilisation Régler la facture Le Système de facturation et de règlement propose un cas d'utilisation appelé Régi er la facture, qui permet à un acheteur de programmer le règlement de marchandises commandées et reçues. Le cas d'utilisation Régler la facture effectue ensuite le paiement à la date prévue. Le cas d'utilisation Régi er la facture comprend à la fois la planification et l'exécution d'un règlement. Si l'on divisait ce cas d'utilisation en deux parties, l'une pour la planification, l'autre pour l'exécution du paiement, Planifier le règ 1 ement n'apporterait aucune valeur en soi. Cette valeur ne s'ajouterait qu'au moment du règlement de la facture (stade auquel on n'a pas à se préoccuper des relances que l'on reçoit).

En ce qui concerne les acteurs, il faut souvent restructurer et réévaluer plusieurs fois les cas d'utilisation identifiés au début avant que le modèle des cas d'utilisation ne se stabilise. Comme nous l'avons évoqué au chapitre 4, les cas d'utilisation et l'architecture d'un système s'échafaudent au fil des itérations. Une fois que l'on dispose d'une architecture, i l convient d'y adapter les cas d'utilisation nouvellement identifiés. I l faut alors modifier les cas d'utilisation qui ne s'intègrent pas à l'architecture choisie (il peut également être nécessaire de réformer l'architecture pour améliorer la production de nouveaux cas d'utilisation). Par exemple, le début de la spécification d'un cas d'utilisation peut avoir tablé sur un certain type d'interaction avec l'utilisateur. Une fois que l'on se sera décidé pour un cadre générique d'IHM, i l faudra peut-être modifier les cas d'utilisation en conséquence, mais ces adaptations sont généralement très limitées. Il arrive toutefois que des modifications plus radicales soient nécessaires. L'analyste système peut suggérer un moyen de surveiller la charge d'un système en spécifiant un simulateur agissant comme un acteur important, c'est-à-dire un acteur exigeant du système des cas d'utilisation. Cette option permet de mesurer les temps de réponses et autres exigences de performances. On peut aussi mesurer le temps d'immobilisation des cas d'utilisation dans les files d'attente internes du système. Ces deux approches peuvent livrer des résultats similaires, mais le coût de leur implémentation risque de varier considérablement en fonction de l'architecture existante. I l est possible que l'analyste système soit amené à renégocier les exigences (cas d'utilisation, etc.) avec le client, afin de s'orienter vers un système plus simple à implémenter et à maintenir. Le client aura, lui aussi, tout à y gagner et obtiendra peut-être des fonctionnalités de meilleure qualité, plus tôt que prévu et à un moindre coût. 7.4.1.3 Décrire brièvement 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 décrivent ensuite brièvement chaque cas d'utilisation, d'abord en quelques phrases en résumant les actions, puis à travers une description pas à pas de ce que le système a besoin de faire lors des interactions avec ses acteurs.



7

167

II

IfflfflB

Description initiale du cas d'utilisation Régler la facture Brève description

Le cas d'utilisation Régi er la facture permet à un Acheteur de programmer le règlement des factures, puis effectue le paiement à la date prévue. Description pas à pas initiale

Préalablement au déclenchement de ce cas d'utilisation, l'Acheteur a reçu une facture (délivrée par un autre cas d'utilisation appelé Facturer l'acheteur) et les marchandises ou services commandés. Ensuite : 1. L'Acheteur étudie la facture à régler et vérifie qu'elle correspond à la commande d'origine. 2. L'Acheteur programme le règlement de la facture par la banque. 3. Lorsque la date d'échéance arrive, le système vérifie que le compte de l'Ache teu r est provisionné. Si c'est le cas, la transaction est effectuée. Jusqu'à présent, nous avons décrit brièvement les acteurs et les cas d'utilisation. Mais i l ne suffit pas de décrire et de comprendre chaque cas d'utilisation isolément. Il faut aussi en avoir une vision d'ensemble, expliquer les relations liant les cas d'utilisation aux acteurs et la façon dont ils constituent le modèle des cas d'utilisation. 7.4.1.4

Décrire 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 modèle des cas d'utilisation comme un tout et d'examiner de plus près les relations que les cas d'utilisation entretiennent entre eux d'une part, avec les acteurs d'autre part. Aucune règle stricte n'impose ce qui doit figurer dans un diagramme. Il convient plutôt de sélectionner l'ensemble de diagrammes qui décriront le système le plus clairement. Par exemple, on peut tracer des diagrammes pour montrer les cas d'utilisation participant à un cas d'utilisation métier (voir la figure 7.12) ou pour illustrer les cas d'utilisation exécutés par un acteur. La mise au point d'un glossaire offre un moyen pratique de rester cohérent lors de la description parallèle de plusieurs cas d'utilisation. Les termes que contient ce glossaire peuvent être issus de classes (dont la trace reste identifiable) d'un modèle du domaine ou d'un modèle du métier (décrits au chapitre 6). Il n'est pas nécessaire que le modèle des cas d'utilisation soit un modèle à plat, comme celui décrit ici. I l peut également se structurer sous forme de groupes de cas d'utilisation, appelés paquetages de cas d'utilisation [12]. Cette étape aboutit également à une description d'ensemble du modèle des cas d'utilisation, qui présente le modèle comme un tout. Cette description expose les interactions entre acteurs et cas d'utilisation et les relations entre cas d'utilisation. Dans la représentation que livre UML du modèle des cas d'utilisation, la description d'ensemble est une valeur marquée du modèle lui-même (voir annexe A, section A. 1.2).

Description d'ensemble La description d'ensemble du modèle des cas d'utilisation du Système de facturation et de règl ement (voir la figure 7.12) pourrait ressembler à ce qui suit. Nous y avons intégré des commentaires numérotés, qui sont développés à la fin de l'exemple. « L'acheteur Utilise le cas d'Utilisation Commandei: des marchandises ou des servi ces pour rechercher les articles commandés et leur prix, pour compiler une commande, puis la soumettre. À ce moment-là, peut-être, ou plus tard, les marchandises ou les services sont livrés à l'acheteur, accompagnés d'une facture. L'acheteur active le cas d'utilisation Régler la facture pour approuver la facture reçue et programmer une demande de paiement. Lorsque la date prévue arrive, le cas d'utilisation Régler la facture vire automatiquement le montant concerné du compte de l'acheteut à celui du vendeur, (commentaire 1) En plus, le cas d'utilisation Régler la facture est étendu parle cas d'utilisation Payer des agios si le compte présente un découvert, (commentaire 21 Abordons maintenant la façon dont le vendeur peut utiliser le système. Il peut examiner les commandes reçues, suggérer 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'exécution des services (ceci est effectué en dehors du Système de facturation et de règlement et ne figure pas dans notre exemple de modèle des cas d'utilisation). Puis, une fois que les marchandises ou les services ont été livrés, le vendeur facture l'acheteur par l'intermédiaire du cas d'utilisation Facturer l'acheteur. Lors de la facturation, le vendeur peut appliquer un taux de décompte et choisir de regrouper plusieurs factures en une seule. Si l'acheteur n'a pas payé à la date prévue, le vendeur en est informé et peut utiliser le cas d'utilisation Envoyer des relances. Le système pourrait envoyer automatiquement des relances, mais nous avons opté pour une solution qui donne au vendeur la possibilité de vérifier les relances avant qu'elles ne soient expédiées, pour éviter d'importuner les clients. » (commentaire 3} Commentaires 1. Souvenez-vous que le modèle des cas d'utilisation est plus qu'une simple liste de cas d'utilisation : il décrit aussi les généralisations entre ces cas d'utilisation. Par exemple, la séquence d'actions nécessaire aux transactions de paiement du cas d'utilisation R é g l e r la f a c t u r e peut être partagée par de nombreux cas d'utilisation (même si seule une généralisation apparaît dans la figure 7.12). Ce partage peut être représenté par un cas d'utilisation séparé, appelé E f f e c t u e r l a t r a n s a c t i on, qui sera réutilisé par plusieurs cas d'utilisation, tels que Régi er la f a c t u r e , par le biais de généralisations. La généralisation implique que la séquence d'actions décrite dans le cas d'utilisation Effectuer l a t r a n s a c t i o n est insérée dans la séquence décrite dans Régi er 1 a f a c t u r e . Lorsque le système exécutera une instance du cas d'utilisation Régi e r la f actu r.e, celle-ci suivra également le comportement décrit dans Effectuer l a t r a n s a c t i o n .


II

2. Au moment où le système exécute une instance du cas d'utilisation R é g l e r la f a c t u r e , la séquence peut être étendue pour intégrer la séquence d'actions du cas d'utilisation Payer des agios. Nous avons mentionné, en passant, les relations de généralisation et d'extension pour montrer qu'il est possible de structurer le modèle des cas d'utilisation pour faciliter la spécification et la compréhension 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 métier. Ces chemins correctifs contribuent à « remettre le processus sur les rails » en vue d'éviter, par exemple, qu'un léger souci dans l'interaction avec un client ne devienne un réel problème. Les acteurs ont donc également besoin de cas d'utilisation (ou de cas d'utilisation de rechange) capables de les aider à corriger les déviations des chemins de processus. Ce type de cas d'utilisation représente souvent une part importante des responsabilités du système complet permettant de traiter les nombreux écarts possibles. Discussion Il existe plusieurs méthodes pour élaborer un modèle 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 immédiate ? Serait-il encore nécessaire de disposer d'un cas d'utilisation Conf i rmer la commande ? La réponse 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 analysée, soit elle est confirmée, soit le vendeur suggère une autre possibilité. Le vendeur peut par exemple proposer un autre ensemble de marchandises tout aussi utiles, mais moins chères ou livrables plus rapidement. La séquence réelle d'actions effectuées au passage d'une commande pourra, dans ce cas, comprendre plusieurs étapes dans lesquelles le vendeur suggérera une commande différente 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 définitive. Le vendeur envoie à l'acheteur une confirmation de commande.

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 différents, ou au contraire un seul ? Voyons d'abord pour quelle raison ces étapes ne seront pas décrites par un seul et même cas d'utilisation : il n'est pas question d'obliger le vendeur et l'acheteur à dialoguer en temps réel. Il vaut mieux qu'ils puissent se soumettre mutuellement des requêtes sans avoir à s'attendre, ni à se synchroniser. On peut imaginer qu'un vendeur souhaitera recueillir plusieurs nouvelles commandes émises par différents acheteurs, prendre le temps de les analyser et les confirmer toutes en même temps. Ceci ne serait pas possible si les quatre étapes ne formaient qu'un seul cas d'utilisation, chaque cas d'utilisation étant considéré comme atomique et devant toujours être achevé avant qu'un autre


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 différents, mais les nuances entre une commande initiale et une commande définitive 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. Après tout, l'idée est de contenir l'ensemble des cas d'utilisation dans des proportions maîtrisables. Un nombre trop important de cas d'utilisation compromet la lisibilité du modèle des cas d'utilisation et le rend difficilement utilisable comme entrée pour l'analyse et la conception. De la même façon, 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 exprimées 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 modèle des cas d'utilisation est prête, les personnes extérieures à l'équipe de développement (c'est-à-dire les utilisateurs et les clients) sont invitées à approuver ce modèle en le révisant de façon informelle en vue de déterminer : • si tous les besoins fonctionnels ont bien été exprimés sous forme de cas d'utilisation ; • si la séquence d'actions de chaque cas d'utilisation est correcte, complète et compréhensible ; • si des cas d'utilisation sans véritable intérêt ont été identifiés. I l convient, dans ce cas, de les réexaminer.

7.4.2 Activité : définir d'utilisation

un ordre de priorité

pour les cas

L'objectif de cette activité est de produire des entrées pour définir l'ordre de priorité des cas d'utilisation afin de déterminer ceux qu'il faut développer (c'est-à-dire analyser, concevoir, implémenter, etc.) dès les premières itérations et ceux qui peuvent attendre des itérations 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

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

II

If* 7.13 icsullal i df/lnillon lie de

de

priorité

•Modèle des "• cas d'utilisation [esquisse]

Exigences supplémentaires

O

£7 Architecte

: détailler

Description de l'architecture [vue du modèle des cas d'utilisation]

Spécificateur de cas d'utilisation " > # * .--7 Détailler un 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 nécessaire.

Figure 7.15 Un cas d'utilisation peut être envisagé comme ayant un état de départ (rectangle arrondi à l'extrême gauche), des états intermédiaires (rectangles arrondis suivants), un état de fin (dernier rectangle arrondi à l'extrême droite) et des transitions d'un état à un autre.

Chaque spécificateur de cas d'utilisation a besoin de travailler en collaboration étroite avec les véritables 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 réviser les descriptions des cas d'utilisation. Cette activité s'achève par la description détaillée de chaque cas d'utilisation sous forme de texte et de diagrammes.

un cas d'utilisation

O

n Modèle des cas d'utilisation [esquisse]

En prenant comme point de départ le modèle des cas d'utilisation et les diagrammes de cas d'utilisation qui lui sont associés, les spécificateurs de cas d'utilisation peuvent maintenant décrire chaque cas d'utilisation en détail. Ils enrichissent la description étape par étape de chaque cas d'utilisation et créent une spécification détaillée de la séquence d'actions. Dans cette section, nous verrons : • comment structurer la description de façon à spécifier tous les chemins possibles du cas d'utilisation ;

,,-7Définir l'ordre de priorité des cas d'utilisation

Les résultats sont exprimés sous la forme d'une vue architecturale du modèle des cas d'utilisation. Cette vue est ensuite examinée en compagnie du chef de projet et sert d'entrée à la planification des développements à mener au cours de chaque itération. Notez que cette planification doit également prendre en considération d'autres aspects non techniques du système à développer (voir le chapitre 12, section 12.4.2).

I

La vue architecturale du modèle des cas d'utilisation doit dépeindre les cas d'utilisation pertinents sur le plan architectural. Pour plus de détails, reportez-vous à la section 7.2.4, « Artefact : description de l'architecture (vue du modèle des cas d'utilisation) ».

i

r..4.3 Activité

Le principal objectif recherché, lorsque l'on détaille chaque cas d'utilisation, est de décrire le flot d'événements qui le constitue, en précisant les modalités de début et defindu cas d'utilisation ainsi que ses interactions avec les acteurs (figure 7.14). |ure7.14 nées et résultat |i la description I, faillie de chaque \


->o

Cas d'utilisation [détaillé]

7.4.3.1 Structurer la description du c a s d'utilisation Nous avons mentionné le fait qu'un cas d'utilisation définit 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 séquence d'actions effectuée par une instance de cas d'utilisation lorsqu'elle est déclenchée par un événement tel qu'un message. Le graphe des transitions d'états illustré par la figure 7.15 risque de devenir très complexe ; or, i l nous faut décrire les possibilités de transitions d'états (les séquences d'actions) de manière simple et précise. Une technique éprouvée consiste à choisir un chemin de base complet (indiqué par les flèches rectilignes de la figure 7.15) de l'état de départ à l'état de fin et à consacrer à ce chemin une section de la description. On peut ensuite décrire, dans une section à part, chacun des autres chemins (indiqués par les flèches 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 déviations soient assez mineurs pour que leur explication figure « en ligne », dans la description même 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


II

précise, mais parfaitement lisible. Quelle que soit la technique choisie, i l faut décrire toutes les possibilités, sinon on ne peut considérer le cas d'utilisation comme étant spécifié. Les solutions de rechange, déviations ou exceptions par rapport au chemin de base peuvent trouver diverses origines : • l'acteur peut choisir de prendre des chemins différents au fil du cas d'utilisation. Pendant le cas d'utilisation Régi er 1 a facture, par exemple, l'acteur peut décider de régler une facture ou de la rejeter ; • si plusieurs acteurs sont impliqués 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 système peut détecter des entrées erronées de la part de l'acteur ; • i l est possible que certaines ressources système fonctionnent mal et empêchent le système de faire son travail correctement. Le chemin de base choisi doit être un chemin « normal », c'est-à-dire un chemin perçu par les utilisateurs comme étant à la fois le plus courant et le plus satisfaisant pour l'acteur. Ce chemin de base comprendra, en général, peu d'exceptions et de particularités auxquelles le système n'est guère habitué à faire face. B

U

Chemins du cas d'utilisation Régler la facture Remarquez l'évolution du texte par rapport au premier jet, rédigé 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, « Décrire brièvement chaque cas d'utilisation »). Ce changement reflète les détails ajoutés peu à peu aux cas d'utilisation au cours de leur modélisation. Il y a de fortes chances, néanmoins, pour que les descriptions réelles de cas d'utilisation soient plus volumineuses et traitent un plus grand nombre de chemins. Pré-condition : l'acheteur a reçu les marchandises ou les services commandés et au moins une facture de la part du système. L'acheteur envisage maintenant de planifier le règlement de la ou des factures. Flot d'événements Chemin de base 1. L'acheteur invoque le cas d'utilisation en commençant à parcourir les factures reçues par le système. Celui-ci vérifie que le contenu de chaque facture correspond aux confirmations de commandes reçues précédemment (dans le cadre du cas d'utilisation Con f i rmer la commande) et livre le résultat de cette vérification à l'acheteur. La confirmation de commande décrit les articles qui vont être livrés, la date et le lieu de livraison, ainsi que le prix des articles. 2. L'acheteur décide de planifier le règlement d'une facture par la banque et le système génère une demande de règlement permettant de virer la somme sur le compte du vendeur. Notez qu'un acheteur ne peut pas programmer deux fois le paiement d'une même facture. 3. Plus tard, si le compte de l'acheteur est suffisamment provisionné, une transaction de

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

QHÂprTkTJmm paiement est effectuée à la date programmée. Au cours de la transaction, le montant est viré depuis le compte de l'acheteur sur celui du vendeur, comme le décrit 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 informés du résultat de la transaction. La banque facture des frais pour la transaction, qui sont prélevés par le système sur le compte de l'acheteur. 4. L'instance du cas d'utilisation se termine. Chemins de rechange Dans l'étape 2, l'acheteur peut, à la place, demander au système 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 règlement et en avertira l'acheteur. Post-condition : l'instance du cas d'utilisation se termine une fois que la facture a été payée ou que son règlement a été annulé et qu'aucune somme d'argent n'a été virée. Étant donné que les cas d'utilisation doivent être compris aussi bien par les clients et les utilisateurs que par les développeurs, i l faut absolument qu'ils soient rédigés en français courant, comme l'illustre notre exemple. Que faut-il inclure dans une description de cas d'utilisation ? - Une description de cas d'utilisation doit définir : • l'état de début (voir la figure 7.15) comme précondition ; • les modalités et le moment de ce début (c'est-à-dire la première action à effectuer ; étape 1); • l'ordre (s'il y en a un) dans lequel les actions doivent se dérouler. Ici, l'ordre est défini par la séquence numérotée (étapes 1 à 4) ; • les modalités et le moment defindu cas d'utilisation (étape 4) ; • les possibles états de fin (voir la figure 7.15) comme postcondition ; • les chemins d'exécution qui ne sont pas autorisés. 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 représente une action qui n'est exécutée 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 système et les acteurs et entre les acteurs euxmêmes (étapes 2 et 3). Exemples typiques de ces interactions : lorsque l'acheteur décide de programmer le paiement de la facture à l'étape 2 et lorsque l'acheteur et le vendeur

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

sont informés des résultats de cette transaction à l'étape 3. En d'autres termes, nous avons décrit la séquence d'actions du cas d'utilisation, les modalités d'invocation de ces actions par les acteurs et la façon dont leur exécution se traduit par des requêtes aux acteurs ; • l'usage des objets, valeurs et ressources du système (étape 3). En d'autres termes, nous avons décrit la séquence 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 décrire ce que font, d'une part, le système (les actions qu'il exécute) et, d'autre part, l'acteur. I l faut pouvoir séparer les responsabilités du système de celles des acteurs, sinon la description des cas d'utilisation manquera de précision et ne pourra servir de spécification du système. Par exemple, il est écrit, dans l'étape 1, que « le système vérifie que le contenu de chaque facture correspond aux confirmations de commandes reçues précédemment » et, dans l'étape 3, que « les frais sont prélevés par le système 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, suggérer la création d'une classe de conception appelée Facture, dérivée 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 nécessaire de considérer dans le modèle des cas d'utilisation. On s'efforcera (comme l'évoque la section 7.2.3, « Cas d'utilisation ») de préserver la simplicité du modèle des cas d'utilisation en interdisant les interactions entre instances de cas d'utilisation et en empêchant chaque instance d'accéder aux attributs de ses homologues. Pour l'instant, nous avons essentiellement parlé des besoins fonctionnels et des moyens de les représenter sous forme de cas d'utilisation ; mais i l nous faut également spécifier les exigences non fonctionnelles. La plupart des exigences non fonctionnelles sont liées à un cas d'utilisation en particulier, comme celles indiquant la vitesse, la disponibilité, la précision, les temps de réponse et de récupération, ou l'usage de la mémoire. C'est en fonction de ces exigences que le système doit effectuer un cas d'utilisation donné. Elles sont associées en tant qu'exigences particulières (valeurs marquées en UML) au cas d'utilisation en question, et peuvent être documentées dans une section à part de la description du cas d'utilisation. RflfflH

Exigence particulière de performances Lorsqu'un acheteur envoie une facture au règlement, le système doit répondre par une vérification de la requête en 1 seconde maximum dans 90 % des cas. Le temps de vérification ne doit jamais dépasser 10 secondes, sauf en cas d'interruption de la connexion (qui doit être notifiée à l'utilisateur).


7

l'architecture, cette spécification doit être effectuée dès les premières itérations, dans la phase d'élaboration. Les descriptions de cas d'utilisation sont terminées lorsqu'elles sont jugées compréhensibles, correctes (elles expriment les véritables besoins), complètes (elles décrivent tous les chemins possibles) et cohérentes. L'organisation de réunions de révision, à 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 vérifier 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 façon dont les transitions font passer les instances des cas d'utilisation d'un état à l'autre. Souvent, comme lorsque le cas d'utilisation ne présente que quelques états, i l n'est pas indispensable de décrire explicitement chaque état. On peut choisir, à la place, d'utiliser le style employé dans l'exemple Régler la facture. Il n'est toutefois pas inutile de garder à l'esprit l'image de la machine à états lorsqu'on décrit un cas d'utilisation, au moins pour s'assurer que tous les cas possibles sont envisagés. Mais il arrive, comme dans les systèmes temps réels complexes, que les cas d'utilisation présentent un tel degré de complexité qu'il soit indispensable de recourir à une technique de description plus structurée. 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 préserver la cohérence de la description textuelle des cas d'utilisation. Il sera alors utile de disposer d'une technique de modélisation visuelle pour décrire ces cas d'utilisation. Ces techniques peuvent aider l'analyste système à mieux comprendre les cas d'utilisation : • les diagrammes d'états-transitions d'UML peuvent être utilisés pour décrire les états du cas d'utilisation, ainsi que les transitions entre états ; voir la figure 7.16 ; • les diagrammes d'activités peuvent être utilisés pour décrire plus en détail les transitions entre états sous forme de séquences d'actions. On peut envisager les diagrammes d'activités comme une forme généralisée des diagrammes états transitions (state transition diagrams) de SDL [15], technique éprouvée et largement utilisée dans le secteur des télécommunications ; • les diagrammes d'interaction peuvent être utilisés pour décrire la façon 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 vités, voir [2, 11, 12, 17]. BfflH

Si le système dialogue avec un autre système quelconque (acteur non humain), i l faut spécifier cette interaction (par exemple, en se référant à un protocole de communication standard). La réalisation de la communication entre systèmes ayant un retentissement sur

Utilisation des diagrammes d'états-transitions pour décrire les cas d'utilisation La figure 7.16 montre un diagramme d'états-transitions pour le cas d'utilisation Régi er 1 a facture. Le point noir situé au sommet du diagramme indique le début du cas d'utilisation. C'est là que commence la machine à états et c'est à partir de là qu'est instanciée une instance du cas d'utilisation. La flèche partant du point noir indique l'état dans lequel passe la machine à états lorsqu'elle est instanciée dans le premier état, ici, à Expl orati on (browsing). Les états sont représentés sous forme de rectangles arrondis, et les transitions entre états par des flèches reliant un état à un autre.


II

D'abord, l'utilisateur parcourt (browses) les factures (cf. l'étape 1 de l'exemple Régi er 1 a facture précédent), puis décide de programmer (cf. étape 2) ou de rejeter (cf. étape 5) une facture. Le cas d'utilisation passe de l'état Facture pour règlement à Facture payée lorsque la facture programmée est réglée à la date convenue (cf. étape 3). Le cas d'utilisation prend fin (la fin est symbolisée par le point noir entouré d'un cercle) immédiatement après avoir atteint l'état Facture payée ou Facture annulée.

1 R g u r e 7.16 'iagramme , ^états-transitions pour le cas d'utilisation Régler i facture montrant F quelle façon une ' instance de ce cas d'utilisation -"averse plusieurs ats ( rectangles ». rrondis) par une série de transitions entre états lèches).

Exploration programmer Facture pour règlement payer à la date prévue Facture payée


7

diagrammes de cas d'utilisation, des descriptions d'ensemble du modèle des cas d'utilisation et des descriptions détaillées pour chaque cas d'utilisation. Il nous faut maintenant concevoir des interfaces utilisateur permettant à l'utilisateur d'exécuter les cas d'utilisation. Nous allons procéder 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 procéder à la conception de l'interface utilisateur logique. On crée ensuite la conception de l'interface uii lisateur physique et l'on développe des prototypes illustrant la façon dont les utilisateurs peuvent employer le système pour exécuter les cas d'utilisation [1]. Le fait de comment N par spécifier ce qui est nécessaire avant de décider de la façon dont l'interface utilisaient sera réalisée oblige à bien comprendre les besoins avant de chercher à les satisfaire 111. Le résultat final de cette activité se compose d'un ensemble d'esquisses et de proloi\i d'interfaces utilisateur spécifiant l'apparence générale des interfaces utilisateurs destinées aux principaux acteurs. Figure 7.17 Entrées et résultat du prototypage de l'interface utilisateur.

O

Modèle des cas^ d'utilisation [esquisse]

Facture annulée

D

Concepteur de l'interface utilisateur


O-"

Prototyper rf l'interface utilisateur

Û

Prototype de l'interface utilisateur

Cas d'utilisation [décrit] Notez que ces diagrammes, utilisés dans un contexte de cas d'utilisation, risquent de s'étoffer et de se complexifîer à 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 façon significative, problème particulièrement délicat si des intervenants autres que des développeurs logiciels sont amenés à lire ces diagrammes. En plus, l'élaboration de diagrammes détaillés et la préservation de leur cohérence avec les autres modèles du système finissent par revenir cher. Nous vous recommandons, d'une façon générale, d'utiliser avec précaution ce type de diagrammes et de vous limiter le plus souvent à des descriptions purement textuelles (c'est-àdire des descriptions de flots d'événements). Dans bien des cas toutefois, descriptions textuelles et diagrammes se compléteront avantageusement.

.4.4 Activité

: prototyper l'interface utilisateur

7.4.4.1

Créer une conception de l'interface utilisateur logique

Pour dialoguer avec le système, les acteurs utilisent et manipulent des éléments d'interface utilisateur représentant des attributs (des cas d'utilisation). I l s'agit souvent de termes issus du glossaire (par exemple, solde du compte, date d'échéance ou t i t u l a i r e du compte). Ces éléments se présentent aux acteurs, qui les manipulent en les sélectionnant, en les faisan) glisser ou en leur parlant, sous forme d'icônes, d'éléments de liste, de dossiers ou d'objets d'une carte en 2 D . Le concepteur de l'interface utilisateur spécifie ces éléments un pal Ml pour chaque acteur, en parcourant tous les cas d'utilisation auxquels peut accéder l'acteur et en identifiant à chaque fois les éléments propres à l'interface utilisateur. Un même élément d'interface utilisateur peut participer à de nombreux cas d'utilisation , en jouant un rôle dans 1

L'objectif de cette activité est de construire un prototype de l'interface utilisateur (voir la figure 7.17). A ce stade, l'analyste système a mis au point un modèle des cas d'utilisation spécifiant l'identité des utilisateurs et l'usage qu'ils feront du système, éléments présentés à travers des

ma

1.

De la m ê m e manière que lorsqu'une classe participe à plusieurs collaborations pour réaliser différents cas

d'utilisation, elle joue un rôle dans chacune de ces collaborations.


II

chacun d'entre eux. L'élément d'interface utilisateur doit donc être conçu pour assurer tous ces rôles. Pour chaque acteur, i l convient de répondre aux questions suivantes : • Quels sont les éléments d'interface utilisateur nécessaires à l'exécution du cas d'utilisation ? • Quels doivent être leurs liens ? • Comment seront-ils utilisés dans les différents cas d'utilisation ? • Quelle doit être leur apparence ? • Comment doivent-ils être manipulés ? Pour déterminer les éléments d'interface utilisateur nécessaires à chaque cas d'utilisation accessible à l'acteur, on peut se poser les questions suivantes : .

Figure 7.18 Éléments de l'interface pour Facture et Compte, avec quelques-uns de leurs attributs.


7

(comme l'indique l'association compte acheteur, dérivée 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 prévisible dans le temps au rythme du règlement des factures sont indiqués dans la figure 7.18 par l'attribut compte et par l'association facture à régi er reliant les éléments d'interface utilisateur Compte et Facture. Compte

solde prévu dans le temps (affecté par le règlement des factures) compte de l'acheteur

• Parmi les classes du domaine, les entités métier et les unités de travail, lesquelles sont susceptibles de constituer des éléments d'interface utilisateur pour le cas d'utilisation ?

A facture à régler V Facture

• Quels éléments d'interface utilisateur l'acteur va-t-il utiliser ?

• • •

• Quelles sont les actions que peut invoquer l'acteur et les décisions 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 système ?

date d'échéance montant à payer compte de destination

Il est assez pratique de représenter les éléments 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 façon à esquisser l'apparence de l'interface utilisateur. Vient ensuite le moment de décrire la façon dont les acteurs peuvent utiliser ces éléments dans leur exploitation des cas d'utilisation. L'avantage d'utiliser des Post-it est de se limiter au volume suffisant de données. Et le fait que, par nature, ils ne sont pas permanents (il est facile de les déplacer ou de s'en débarrasser) encourage les utilisateurs à proposer les changements qu'ils estiment nécessaires. Les concepteurs de l'interface utilisateur peuvent donc s'assurer que chaque cas d'utilisation est bien accessible par le biais de ses éléments d'interface utilisateur. Mais i l faut aussi veiller à ce que l'ensemble complet des cas d'utilisation accessibles à l'acteur présente une interface utilisateur bien intégrée, facile à utiliser et cohérente. 1

• Quelles informations le système doit-il fournir à l'acteur ? • Quelles sont les valeurs moyennes de tous les paramètres d'entrée 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 destinées à optimiser l'interface utilisateur graphique (même s'il est impératif de prévoir une marge assez importante).

BfflHH •••»•"•

Éléments d'interface utilisateur employés par le cas d'utilisation Régler la facture En nous appuyant sur le cas d'utilisation Régi er la facture, nous allons maintenant illustrer la recherche des éléments d'interface utilisateur nécessaires à l'acteur pour travailler sur écran, ainsi que les indications dont il pourra avoir besoin au cours de sa tâche. L'acteur va certainement exploiter des éléments d'interface utilisateur tels que des factures (issues d'une classe du domaine ou d'une entité métier). Facture est, par conséquent, un élément d'interface utilisateur, comme l'illustre la figure 7.18. Notez que les factures ont une date d'échéance, un montant à régler et un compte de destination. Tous ces attributs sont nécessaires à l'acteur et lui permettent de décider s'il faut ou non payer la facture. Au moment de décider s'il convient ou non de régler la facture, l'acteur peut désirer jeter un œil au solde du compte, afin d'éviter les découverts. 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'échéance, et montrer l'impact qu'aura leur règlement sur le solde du compte

Jusqu'à présent, nous n'avons examiné que ce que les acteurs exigent de l'interface utilisateur. I l nous faut maintenant étudier la façon dont l'interface utilisateur physique peut répondre à cette demande. 7.4.4.2 Créer une conception et un prototype de l'interface utilisateur physique Les concepteurs de l'interface utilisateur préparent d'abord des esquisses de la constellation des éléments qui formeront des interfaces satisfaisantes pour les utilisateurs. Puis ils ajoutent les éléments supplémentaires qui permettront d'agencer les divers éléments d'interface en 1. Pour plus de formalisme, on peut envisager ce type de Post-it comme un stéréotype de classe au sein d ' U M L . I l n'appartient pas, toutefois, au présent ouvrage de s'attarder sur un m o d è l e (objet) formel des éléments d'interface utilisateur.

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

vue de constituer des interfaces complètes. Parmi ces éléments supplémentaires peuvent se glisser des conteneurs d'éléments d'interface utilisateur (par exemple, îles dossiers), des fenêtres, des outils et des commandes ; voir la figure 7.19. Ces esquisses peuvent être élaborées après (ou en parallèle avec) les Post-it créés pendant la conception de l'interface utilisateur logique.

Modélisation

MHH

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

Conception et prototype de l'interface utilisateur physique Le concepteur d'interface utilisateur esquisse la conception physique suivante de l'évolution visuelle du solde du compte en fonction des règlements de factures. Les factures sont représentées par des trapèzes blancs, qui vont entamer le solde du compte au moment de leur échéance. Le concepteur d'interface utilisateur a choisi une forme trapézoïdale non seulement parce que sa largeur la rend bien visible, mais aussi parce qu'elle présente une pointe qui poi met d'indiquer le moment précis du règlement. Les factures programmées pour le règlonient. telles que la facture du loyer, vont provoquer une baisse du solde du compte à leur date d'échéance, comme l'illustre la figure 7.19. Parallèlement, le dessin montre l'augmentation du solde lors, par exemple, du virement de la paie. Cette figure représente également les ciiin mandes d'interface utilisateur telles que les boutons de défilement et de zoom.

des cas d'utilisation essentiels

Les descriptions détaillées des cas d'utilisation constituent un excellent point de départ pour la conception de l'interface utilisateur, parfois môme un peu trop parfait. En effet, le problème est que ces descriptions contiennent souvent des décisions implicites sur les interfaces utilisateur, qui risquent ensuite de contraindre les concepteurs d'interface utilisateur lorsqu'ils suggéreront des interfaces adaptées aux cas d'utilisation. Or, pour créer la meilleure interface utilisateur possible pour les cas d'utilisation, il faut à tout prix éviter cet écueil. Par exemple, le cas d'utilisation Régler la facture commence par la phrase suivante : « Lacheteur invoque le cas d'utilisation en commençant par parcourir les factures reçues... ». Une telle description risque d'égarer le concepteur en l'incitant à créer une interface utilisateur comprenant une liste des factures reçues que l'acteur pourra parcourir. Mais ce n'est pas forcément le meilleur moyen d'examiner les factures reçues. Les acheteurs préfèrent peut-être parcourir les factures d'une façon moins triviale: par exemple par le biais d'icônes classées horizontalement en fonction de la date de règlement et verticalement en fonction du montant à payer.

Figure 7.19 Suggestion d'interface utilisateur pour les éléments d'interface Compte et Facture. L'interface montre la façon dont le règlement de factures et la réception de dépôts se traduisent par des baisses ou des hausses du solde du compte. Les boutons de défilement gauche et droit permettent de parcourir la « fenêtre du temps » dans laquelle l'acteur peut étudier le solde de son compte. Les boutons de zoom avant et arrière modifient l'échelle du diagramme.

Il peut y avoir plusieurs prototypes, par exemple un par acteur, afin de vérifier que chaque acteur peut exécuter les cas d'utilisation dont i l a besoin. L'effort consacré au prototypage doit être proportionnel à la valeur de retour attendue. On ne développe des prototypes d'IHM exécutables 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 séquence d'entrées de l'acteur, comme la saisie d'un attribut avant un autre ; les dispositifs nécessaires aux entrées et aux sorties, comme l'utilisation de la souris pour sélectionner un élément ou de l'écran pour présenter quelque chose. Ensuite, si c'est nécessaire, les spécificateurs de cas d'utilisation peuvent effectuer une seconde passe dans les descriptions de cas d'utilisation afin d'ajouter les détails négligés dans les descriptions allant à l'essentiel.

Nous voilà donc prêts à bâtir des prototypes exécutables pour les principales constellations d'éléments d'interface utilisateur. On pourra utiliser, à cet effet, un outil de prototypage rapide.

Larry Constantine propose un remède au problème des décisions implicites aux interfaces utilisateur [14]. Il suggère que les spécificateurs de cas d'utilisation rédigent d'abord des descriptions allégées des cas d'utilisation (les cas d'utilisation essentiels) ne contenant aucune décision implicite de ce type. L'exemple précédent pourrait alors être reformulé de la façon suivante : « L'acheteur invoque le cas d'utilisation Régi er l a facture en commençant à étudier les factures reçues... » Les concepteurs d'interfaces utilisateur pourront alors employer ces cas d'utilisation essentiels comme entrées pour la création de l'interface utilisateur sans être assujettis à des décisions implicites quelles qu'elles soient. Cet exemple propose une illustration naïve de ce que peut entraîner la réduction d'une description de cas d'utilisation à sa substantifique moelle. En réalité, il ne suffit pas de remplacer un mot pour en arriver là. Mais l'important est d'éviter de prendre des décisions prématurées dans les domaines suivants : la technique à utiliser pour présenter un élément d'interface utilisateur, comme l'utilisation d'une liste ou d'un champ de texte ;

La validation de l'interface utilisateur à travers la révision des prototypes et des esquisses très tôt dans le développement évite de nombreuses erreurs dont la correction tardive risquerait de coûter cher. Les prototypes permettent également de révéler des omissions dans


II

J W î ! ? Q * « ^ i r * ^ c ^

c

a

s

d

.

u

t

i

l

j

s

a

t

J

o

n

CHAPh^mTmmY

les descriptions de cas d'utilisation et d'y remédier avant que les cas d'utilisation n'entrent en phase de conception. Les réviseurs doivent vérifier que chaque interface utilisateur : • permet à l'acteur une navigation appropriée ; • offre une apparence et un fonctionnement cohérents, 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.

relation de généralisation d'un cas d'utilisation A vers un cas d'utilisation R ™* mstance du cas d'utiltsation A présentera aussi le c o r a ^ Z ^ T Z T** Figure 7.20 Entrées et résultat de l'identification des généralisations dans le modèle des cas d'utilisation.

Notez que l'implémentation de la véritable interface utilisateur (par opposition au prototype développé ici) se construit en parallèle avec le reste du système, c'est-à-dire pendant les enchaînements d'activités d'analyse, de conception et d'implémentation. Le prototype d'interface utilisateur mis au point ici fonctionnera donc comme une spécification de l'interface utilisateur qui sera réalisée en termes de composants de qualité de production.

7.4.5 Activité

: structurer le modèle

^

O

Modèle des cas'', d'utilisation [esquisse]

a

Analyste système


o-

Cas d'utilisation [décrit]


" Structurer s7 le modèle des cas d'utilisation

Modèle des cas d'utilisation [structuré]

Le modèle des cas d'utilisation est structuré afin de : • dégager les descriptions (de cas d'utilisation) générales et partagées de fonctionnalités qui pourront être utilisées par des descriptions (de cas d'utilisation) plus spécifiques ;

Généralisation entre cas d'utilisation

• extraire des descriptions (de cas d'utilisation) supplémentaires ou facultatives de fonctionnalités qui étendront des descriptions (de cas d'utilisation) plus spécifiques. Avant de procéder à cette activité, l'analyste système a identifié les acteurs et les cas d'utilisation, qu'il a décrits sous forme de diagrammes, et présenté le modèle des cas d'utilisation comme un tout, tandis que les spécificateurs de cas d'utilisation ont rédigé une description détaillée de chaque cas d'utilisation. À ce stade, l'analyste système peut restructurer l'ensemble des cas d'utilisation afin de le rendre plus compréhensible et plus simple à utiliser (voir la figure 7.20). I l doit rechercher les comportements partagés et les extensions. 7.4.5.1 Identifier les descriptions p a r t a g é e s de fonctionnalités Tout en identifiant et en décrivant brièvement les actions de chaque cas d'utilisation, il faut aussi rechercher les actions complètes ou partielles communes ou partagées par plusieurs cas d'utilisation. Afin de limiter les redondances, ce partage doit être extrait et décrit sous la forme d'un cas d'utilisation à part susceptible d'être ensuite réutilisé par les cas d'utilisation originaux. Cette relation de réutilisation est indiquée à l'aide d'une généralisation (appelée relation d'utilisation dans [7]). La généralisation entre cas d'utilisation est une sorte d'héritage, puisque les instances des cas d'utilisation généralisés peuvent exécuter tout le comportement décrit dans le cas d'utilisation de généralisation. En d'autres termes, une

Revenez à la figure 7.12, un peu plus haut dans ce chapitre, dans laquelle le cas d'utilisation Régler la facture est généralisé par le cas d'utilisation Effectuer la r r a n s a c t Ï Ï n o S séquence aecnte dans Effectuer la transaction (figure 7.21).

Figure 7.21 Relation de généralisation entre les cas d'utilisation Régler la facture et Effectuer la transaction.

Payer la facture

Effectuer la transaction On emploie la généralisation pour simplifier l'exploitation et la compréhension du modèle des cas d'utilisation et pour réutiliser des cas d'utilisation « semi-manufacturés » lors de l'assemblage des cas d'utilisation complets exigés par les clients. Ces cas d'utilisation complets sont appelés cas d'utilisation concrets. Ils sont lancés par un acteur et leurs instances forment une séquence complète d'actions effectuées par le système. Les cas d'utilisation « semi-manufacturés » n'existent que pour être réutilisés par d'autres cas d'utilisation et sont appelés cas d'utilisation abstraits. En lui-même, un cas d'utilisation abstrait ne sera pas instancié ; mais une instance de cas d'utilisation concret présentera également le comportement spécifié par le cas d'utilisation abstrait qu'elle (ré)utilisera. Pour plus de clarté, nous appelons cette instance le cas d'utilisation « réel » que perçoivent les acteurs lors de leur interaction avec le système.


II

Expression des b e s o i n s s o u s j o n r m ^ CHAPITRE

7

Cas d'utilisation « réels » On peut conceptualiser un cas d'utilisation « réel », comme le montre la figure 7.22, lorsque Régler la facture est généralisé par Effectuer la transaction. I Igure 7.22 instance du cas d'utilisation « réel » formé par les cas utilisation Régler la facture et ffectuer la transaction, telle que ".a perçoivent les instances d'acteur Acheteur A et Vendeur B.

Régler la facture + Effectuer la transaction

Vendeur B

Figure 7.23 Relation d'extension entre les cas d'utilisation Régler la facture et Payer des agios.

Ce cas d'utilisation « réel » est le résultat de l'application de la généralisation aux deux cas d'utilisation, le concret et l'abstrait. Il représente le comportement de l'instance du cas d'utilisation que perçoit un acteur dialoguant avec le système. Si le modèle contenait un plus grand nombre de cas d'utilisation concrets généralisés par le cas d'utilisation Effectuer 1 a transacti on, il y aurait plus de cas d'utilisation réels, dont les spécifications présenteraient des chevauchements, ces chevauchements étant ce que le cas d'utilisation Effectuer 1 a transaction spécifie. Remarquez que cet exemple ne dit pas toute la vérité, puisqu'un autre cas d'utilisation (Pay e r des agi os) étend le cas d'utilisation Régler la facture et donne ainsi lieu à d'autres cas d'utilisation réels. Nous nous intéressons à 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 fonctionnalités L'autre relation entre cas d'utilisation est la relation d'extension [7]. Cette relation modélise les éléments ajoutés à la séquence d'actions d'un cas d'utilisation. Une extension « se comporte » comme un élément 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 intégrer (sous des conditions spécifiques précisées dans l'extension) le comportement défini par A. Un comportement spécifié par plusieurs extensions d'un même 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 référence du point d'extension, c'est-à-dire de l'emplacement auquel les ajouts peuvent être effectués, dans le cas d'utilisation cible. Dès qu'une instance d'un cas d'utilisation (cible) atteint le point d'extension auquel se réfère une relation d'extension, la condition de la relation est évaluée. Si la condition nécessaire est remplie, la séquence suivie par l'instance du cas d'utilisation est étendue pour accueillir la séquence 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, « Décrire le modèle des cas d'utilisation comme un tout », dans lequel le cas d'utilisation Régi er la

facture est étendu par le cas d'utilisation Pawr des aoios. La séouence dînions d*,*.

Acheteur

Régler la facture t> « attend »

Effectuer la transaction

Payer des agios

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 nTraiséoarFffPct ? ' ° (c'est-à-direRégi la fac g neral se par Effectuer 1 a transaction, on obtient un autre cas d'utilisation réel 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

Figure 7.24 Instance du cas d'utilisation « réel » formé par les cas d'utilisation Régler la facture et Effectuer la transaction étendus par le cas d'utilisation Payer des agios, telle que la perçoivent les instances d'acteur Acheteur A et Vendeur B.

Acheteur A

Régler la facture -t Effectuer la transaction + Payer des agios ~

VendeurB

On peut dire que les cas d'utilisation réels, qui sont des cas d'utilisation à part entière, sont le fruit de l'application des relations de généralisation et d'extension aux cas d'utilisation du modèle. Les cas d'utilisation réels sont ceux qui fournissent des résultats aux utilisateurs. Les critères déterminant un bon cas d'utilisation, édictés dans la section 7.4.1, « Acli\é identifier les acteurs et les cas d'utilisation » (un cas d'utilisation livre un résultat observable et satisfaisant pour un acteur particulier), ne valent donc que pour les cas d'utilisation réels Les cas d'utilisation concrets ne doivent pas décrire 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é, réutilisable- I c: cas d'utilisation d'extension spécifient un comportement supplémentaire pour les autres I M d'utilisation, sans se soucier du caractère facultatif ou obligatoire de ce comportement. Pour clarifier les relations de généralisation et d'extension, nous avons donc introduit la notion de cas d'utilisation réel. Une fois que les cas d'utilisation concrets, abstraits et d'extension ont été identifiés, i l suffit de les associer pour obtenir des cas d'utilisation réels. Cependant, lorsqu'on commence à modéliser un nouveau système, on procède généralement


Expression des besoins sous forme de cas d'utilisation KM

II

de façon inverse : on part des cas d'utilisation réels et l'on identifie les comportements partagés, qui séparent les cas d'utilisation concrets des cas d'utilisation abstraits, puis les comportements supplémentaires, que l'on traite comme des extensions des autres cas d'utilisation. Reportez-vous à [ 7 ] pour découvrir un traitement plus approfondi des généralisations (également appelées 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 inversée fournissant à un cas d'utilisation des extensions explicites et sans condition. Par ailleurs, lors de l'inclusion d'un cas d'utilisation, la séquence de comportement et les attributs du cas d'utilisation inclus sont encapsulés et ne peuvent être ni modifiés, ni atteints. Seul le résultat (ou la fonction) du cas d'utilisation inclus peut être exploité ; c'est là que réside la différence par rapport à l'utilisation de la relation de généralisation. Mais cet ouvrage ne s'attardera pas sur ces relations. Nous nous contenterons de ces quelques avertissements : • la structure des cas d'utilisation et de leurs relations doit refléter autant que possible les cas d'utilisation réels (comme nous l'avons vu précédemment). Plus cette structure diverge des cas d'utilisation réels, 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 développeurs eux-mêmes ;

7.6

ensemble de diagrammes et une description détaillée de chaque cas d'utilisation rendent compte du modèle des cas d'utilisation ; • d'un ensemble d'esquisses et de prototypes d'interface utilisateur pour chaque acteur représentant la conception des interfaces utilisateur ; • d'une spécification des exigences supplémentaires pour les exigences génériques et non spécifiques à un cas d'utilisation en particulier. Ce résultat constitue un excellent point de départ pour les enchaînements d'activité! suivants : analyse, conception, implémentation et tests. Les cas d'utilisation dirigeront le développement à travers ces enchaînements d'activités, d'itération en itération. Nous identi fierons, pour chaque cas d'utilisation du modèle des cas d'utilisation, une réalisation 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 différentl enchaînements d'activités. Dans le chapitre 8, nous passons à l'étape suivante de notre ensemble d'enchaînements d'activités - l'analyse-, au cours de laquelle nous exprimerons les cas d'utilisation sous forme d'objets en vue d'accéder à une meilleure compréhension des besoins et des exigences et de préparer les phases de conception et d'implémentation du système.

Références 1

AHLQVIST STEFAN et JONSSON PATRIK, « Techniques for systematics design of

graphical user interfaces based on use cases », Proceedings

• chaque cas d'utilisation individuel doit être traité comme un artefact indépendant. Quelqu'un (un spécificateur de cas d'utilisation) doit avoir la responsabilité de le décrire ; et i l faut, dans les enchaînements d'activités ultérieurs (analyse et conception), que le cas d'utilisation soit réalisé par des réalisations séparées (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 disproportionnée ;

2

OOPSLA 96.

GRADY BOOCH, JAMES RUMBAUGH et IVAR JACOBSON, Unified Modeling

Language

User Guide, Reading, MA, Addison-Wesley, 1998. 3

ALISTAIR COCKBURN, « Structuring use cases with goals », Report on Analysis and Design (ROAD),

4

• évitez de procéder à une décomposition fonctionnelle des cas d'utilisation dans le modèle des cas d'utilisation. I l sera bien plus efficace d'affiner chaque cas d'utilisation dans le modèle d'analyse, car, comme nous le verrons au chapitre 8, les fonctionnalités définies par les cas d'utilisation seront plutôt décomposées, selon un mode orienté objet, comme des collaborations d'objets d'analyse conceptuels. Cette décomposition permettra, si nécessaire, une compréhension approfondie des besoins et des exigences.

1997.

IVAR JACOBSON, MAGNUS CHRISTERSON, PATRIK JONSSON et GUNNAR ÔVERGAARD,

Object-Oriented Software Engineering: A Use-Case-Driven Addison-Wesley, 1992 (quatrième édition révisée, 1993). 5

Approach, Reading, MA,

IVAR JACOBSON, M A R I A ERICSSON et AGNETA JACOBSON, The Object

Business Process Reengineering Wesley, 1994.

7.5 R é s u m é de l'enchaînement d'activités des besoins Dans ce chapitre et le précédent, nous avons décrit le moyen de formuler les besoins et les exigences d'un système sous la forme :

Advantage:

with Object Technology, Reading, M A , Addison-

IVAR JACOBSON et MAGNUS CHRISTERSON, « A growing consensus on use cases »,

8

IVAR JACOBSON, « Basic use case modeling (continued) », Report on Analisys and Design ROAD 1(3), septembre-octobre 1994.

7

IVAR JACOBSON, « Basic use case modeling », Report on Analisys and Design ROAD 1(2), juillet-août 1994.

6

Journal of Object-Oriented

• d'un modèle du métier ou d'un modèle du domaine afin de définir le contexte du système ; • d'un modèle des cas d'utilisation exprimant les besoins fonctionnels et les exigences non fonctionnelles spécifiques à des cas d'utilisation précis. Une description générale, un

Programming,

mars-avril 1995.

I . JACOBSON, K. PALMQVIST et S. DYRHAGE, « Systems of interconnected Report on Analysis and Design (ROAD), mai-juin 1995.

9

Systems » ,

Les e n c h a î n e m e n t s d'activités principaux PARTIE

II

~~

JOHN CARRO^ Scenario-Based

16

CCITT, Speci Geneva, 1988

15

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.

14

IVAR JACOBSO MARTIN GRISS et PATRIK JONSSON, Software Reuse: Architecture, Process and O nization for Business Success, Reading, MA, Addison-Wesley, 1997.

13

OMG Unified Modeling Language Spécification, Object Management Group, Framingham, A, 1998. Internet : www.omg.org.

12

JAMES R U M B T AR JACOBSON et GRADY BOOCH, Unified Modeling Référence M Q „ ; Reading, MA, Addison-Wesley, 1998.

11

IVAR JACOBSrj « Modeling with use cases-Formalizing use-case modeling », Journal of Object-Ori i Programming, juin 1995.

10

Ni

mte(

A U G H I

mû

V

Language

;

M

N>

rga

flcation a

n

Q

Description Language (SDL), Recommendation Z. 100,

Analyse

Design, New York, John Wiley & Sons, 1995.

D A V I D HAREI_ MlCHAL POLITI, Modeling Reactive Systems with Statecharts: The STATEMATE\pproach, New York, McGraw-Hill, 1998.

17

e t

8.1 Introduction Comme son nom l'indique, l'enchaînement d'activités de l'analyse se consacre à l'analyse des besoins décrits dans l'expression des besoins, en les affinant et en les structurant. L'objectif est d'accéder à une compréhension plus aiguë des besoins et des exigences et d'en livrer une description facile à entretenir, favorisant la structuration de l'ensemble du système, y compris de son architecture. Avant d'examiner ce que cela suppose, revenons quelques instants sur les résultats de l'expression des besoins. Rappelez-vous que la règle numéro un en matière 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, même si nous parvenons à un accord avec le client sur ce que le système doit faire, i l est fort probable que des problèmes non résolus au sujet des besoins et des exigences du système subsistent. C'est le prix à payer pour l'utilisation du langage, certes intuitif, mais imprécis, du client au cours du recueil des besoins. Afin de mettre en lumière ces « problèmes non résolus » concernant les besoins et les exigences du système, souvenez-vous que, pour communiquer efficacement les fonctions du système au client, les cas d'utilisation doivent présenter les caractéristiques énoncées ci-dessous. 5.

Les cas d'utilisation doivent autant que possible rester indépendants les uns des autre! Il faut, pour cela, éviter de se perdre dans les détails quant aux interférences, à la concurrence et aux conflits entre cas d'utilisation lorsque, par exemple, ils sont en concurrence pour l'utilisation de ressources partagées internes au système (voir la section 7.2.3). Par exemple, les cas d'utilisation Dépôt et Retrait accèdent tous deux au même compte utilisateur. Ou alors, i l se produit un conflit si un acteur associe des CM d'utilisation aboutissant à un comportement indésirable, comme lorsqu'un abonne au téléphone utilise un cas d'utilisation Commander un r é v e i l par téléphone suivi d'un cas d'utilisation Transfert d'appels entrants pour commander un réveil téléphonique pour


II

un autre abonné. Les questions d'interférence, de concurrence et de conflits entre cas d'utilisation peuvent donc avoir été laissées en suspens lois de l'expression des besoins. 6. Les cas d'utilisation doivent être décrits dans le langage du client. Il s'agit essentiellement d'utiliser la langue naturelle dans les descriptions de cas d'utilisation et d'être particulièrement vigilant dans l'utilisation de notations plus formelles telles que les diagrammes d'états-transitions, d'activités et d'interaction (voir la section 7.4.3.2). Mais l'utilisation exclusive de la langue naturelle entraîne une perte de puissance d'expression ; un grand nombre de questions qui auraient pu être précisées à l'aide de notations plus formelles risquent de demeurer non résolues, ou au mieux vaguement décrites, dans la formulation des besoins. 7. Chaque cas d'utilisation doit être structuré de façon à constituer une spécification complète et intuitive des fonctionnalités. 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 reflètent de façon intuitive les cas d'utilisation « réels » fournis par le système. I l convient de ne pas les répartir en cas d'utilisation limités, 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 conséquent, i l est fort possible que les problèmes de redondances parmi les besoins ayant fait l'objet d'une description aient été laissés de côté. Le premier objectif de l'analyse est donc de résoudre ces problèmes restés en suspens en procédant à une analyse plus approfondie des besoins et des exigences, avec une nouveauté notable (par rapport au recueil des besoins) : on peut désormais utiliser le langage des développeurs pour en décrire les résultats. Cette possibilité permet ainsi de mieux cerner les aspects internes du système et de résoudre les questions concernant les interférences entre cas d'utilisation et les autres écueils mentionnés dans la première caractéristique de la liste ci-dessus. On peut également, au cours de l'analyse, utiliser un langage plus formel pour mettre le doigt sur les détails concernant les exigences du système (deuxième caractéristique 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 compréhension, leur préparation, leur modification, leur réutilisation et, d'une manière générale, leur maintenance en soient facilitées (troisième caractéristique de la liste cidessus). Cette structure (fondée sur les classes et les paquetages d'analyse) est orthogonale à la structure fournie par les besoins (fondée sur les cas d'utilisation). Une parfaite traçabilité relie néanmoins ces différentes structures, si bien que l'on peut remonter à différentes descriptions - à différents niveaux de détails - de la même exigence et préserver facilement la cohérence entre descriptions. En fait, cette traçabilité transparente est définie entre les cas d'utilisation du modèle des cas d'utilisation et les réalisations des cas d'utilisation du modèle d'analyse ; nous étudierons en détail cette question plus loin dans ce chapitre (voir aussi le tableau 8.1).

Analyse CHAPITRE

8

Tableau 8.1 : Brève comparaison des modèles des cas d'utilisation et d'analyse.

Structuré par les classes et les paquetages stéréotypés ; donne une structure à la vue interne.

Structuré par les cas d'utilisation ; donne une structure à la vue externe.

Vue interne du système.

Vue externe du système.

Formulé dans le langage du dévelop- peur.

Formulé dans le langage du client.


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

Esquisse la réalisation des caractéristiques dans le système, y compris les caractéristiques significatives sur le plan architectural ; sert de premier brouillon du système.

Exprime les caractéristiques du système, y compris les caractéristiques significatives sur le plan architectural.

Ne doit contenir aucune redondance, incohérence, etc., parmi les besoins et exigences.

Susceptible de contenir des redondances, des incohérences, etc., parmi les besoins et exigences.

Sert principalement aux développeurs pour comprendre la forme que doit revêtir le systèmo, c'est-à-dire sa conception et son implémentation.

Sert principalement de contrat entre le client et les développeurs sur ce que le système doit faire et ne doit pas faire.

Définit les cas d'utilisation, qui sont ensuite analysés plus précisément dans le modèle , d'analyse.

Définit les réalisations de cas d'utilisation, chacune représentant l'analyse d'un cas d'utilisation du modèle des cas d'utilisation.

Enfinde compte, la structure des besoins fournie par l'analyse constitue également une base fondamentale pour modeler le système comme un tout (avec son architecture) ; ceci parce que l'on souhaite envisager le système comme un tout maintenable, et non se contenter d'en décrire les besoins et les exigences. Nous allons présenter, dans ce chapitre, une explication plus détaillée 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 décrirons son rôle au coins des différentes phases du cycle de vie du logiciel (section 8.3). Ensuite, nous présenterons les artefacts (section 8.4) et les travailleurs (section 8.5) prenant part à l'analyse ( v o n la figure 8.1). Enfin, nous décrirons l'enchaînement d'activités de l'analyse (section 8.6).


Analyse

II

gure 8.1 travailleurs et QrttfÙCtS impliqués lions l'analyse.

O O

Architecte responsable de

/ Modèle d'analyse

\


â

Ingénieur de cas d'utilisation responsable de

I Réalisation-analyse des cas d'utilisation

O D

Ingénieur de composants

/

\

responsable de

/

Û

\

Paquetage d'analyse

Classe d'analyse

~.2 L'analyse en bref Le langage employé dans l'analyse repose sur un modèle objet conceptuel, appelé modèle d'analyse. Ce modèle d'analyse aide à préciser les besoins et les exigences selon les lignes de force mentionnées plus haut (section 8.1) et permet d'envisager les aspects internes du système, sans omettre les ressources internes partagées. En fait, dans le modèle d'analyse, une ressource interne peut être représentée sous forme d'objet, tel le compte client auquel accèdent les cas d'utilisation Dépôt et Retrait. Le modèle 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 décrire les aspects dynamiques du système. Comme nous l'avons mentionné plus haut (section 8.1), le modèle d'analyse aide aussi à hiérarchiser les exigences et fournit une structure particulièrement axée sur la maintenance, comme la capacité de réaction aux changements des exigences et la réutilisabilité. (Nous discuterons, plus loin dans ce chapitre, des principes susceptibles d'accroître la réactivité du modèle d'analyse aux changements et qui lui permettront de contenir des éléments réutilisables.) Cette structure n'est pas seulement utile pour la maintenance des exigences en tant que telle, mais elle sert également d'entrée aux activités de conception et d'implémentation (telles que nous les décrivons dans les chapitres 9 et 10). On s'efforce de préserver cette structure à mesure que l'on façonne le système et que l'on décide de sa conception et de son implémentation. A partir de là, le modèle d'analyse peut être vu comme un premier jet du modèle de conception, bien qu'il soit un modèle à part entière. En préservant la structure du modèle d'analyse lors de la conception, on obtiendra un système dont la maintenance globale sera aisée : i l saura réagir aux modifications des exigences et contiendra des éléments susceptibles d'être réutilisés dans la construction de systèmes proches. Ici, il convient toutefois de noter que le modèle d'analyse reste quelque peu évasif et omet de résoudre certains problèmes et de gérer certaines exigences qu'il vaut mieux, selon nous, différer à la conception et à l'implémentation (annexe C ; voir également la section 8.2.1). I l est possible, pour cette raison, que la structure fournie par le modèle d'analyse ne soit pas toujours conservée et nécessite quelques négociations et compromis lors de la conception et de l'implémentation, 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 réside dans le fait que la conception exige de prendre en considération la plate-forme d'implémentation : langage de programmation, systèmes d'exploitation, infrastructures (fra-

meworks) préfabriquées, systèmes existants, etc. Par souci de rentabilité, on parviendra à une meilleure architecture en modifiant la structure du modèle d'analyse au moment de passer au modèle de conception et de façonner le système.

8.2.1 Pourquoi l'analyse n'est ni la conception, ni l'implémentation... À 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'implémentation du système. Noire réponse à cette question est la suivante : la conception et l'implémentation représentent tel lement plus que l'analyse (raffinement et structuration des besoins), qu'une séparation des préoccupations nous semble indispensable. Pendant la conception, il nous faut modeler le système et en définir la forme, y compris son architecture. Une forme qui devra prendre en compte toutes les exigences imposées au système. Une forme qui comprendra les compo sants fichiers compilés et intégrés sous forme de versions exécutables du système. Une forme qui, avec un peu de chance, pourra être maintenue pendant longtemps. Une forme capable de résister à la pression du temps, du changement et des évolutions. Une forme, enfin, qui gardera toute son intégrité. La conception commande donc de prendre des décisions sur la manière dont le système devra gérer, par exemple, les exigences de performances et de distribution et de répondre à des questions telles que « comment optimiser cette procédure afin que son exécution ne dépasse pas 5 millisecondes ? » ou « comment déployer ce code sur ce noeud de réseau sans surcharger le trafic réseau ? » Et il y aura bien d'autres problèmes du même ordre à traiter en conception : trouver le moyen d'exploiter efficacement les composants acquis, tels que les bases de données et les ORB, et de les intégrer dans l'architecture du système ; 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'implémentation, mais nous y reviendrons dans les chapitres 9 et 10. Nous espérons avoir été parfaitement clairs, c'est-à-dire vous avoir convaincu que la conception et l'implémentation ne se bornent pas - loin de là - à une analyse approfondie et structurée des besoins ; la conception et l'implémentation s'attachent à façonner le système de sorte qu'il satisfasse à toutes les exigences, y compris aux exigences non fonctionnelles, qui lui sont imposées. Pour vous donner une idée des omissions du modèle d'analyse par rapport au modèle de conception, sachez que l'on constate fréquemment un ratio de 1 à 5 entre les éléments qui les constituent. À partir de ce constat, nous estimons qu'il est indispensable, avant de débuter la conception et l'implémentation, d'avoir une vision précise et détaillée des besoins et des exigences. d< mi le client ne se préoccupe pas un seul instant (dans la plupart des cas). Par ailleurs, si l'on dispose d'une structure des besoins pouvant servir d'entrée au façonnage du système, c'est encore mieux. Et cela, c'est l'analyse qui le permet. En clair, la conduite de l'analyse établit une séparation des préoccupations qui prépare et simplifie les activités ultérieures de conception et d'implémentation en délimitant les pro blêmes à résoudre et les décisions à prendre pendant ces activités. Cette séparation des problèmes permet en outre aux développeurs d'« attaquer la falaise» dès le début du développement et d'éviter la paralysie qui risque de survenir si l'on essaie de résoudre trop


II

de problèmes à la fois. Sans compter les problèmes qui n'ont peut-être pas été résolus du tout en raison d'une formulation trop vague et d'une mauvaise compréhension de certains besoins et exigences !

Jf.2.2 Objectif de l'analyse :

résumé

Comme nous l'avons expliqué plus haut, l'analyse des besoins et des exigences sous la forme d'un modèle d'analyse est importante pour plusieurs raisons : • un modèle d'analyse livre une spécification plus précise des besoins que celle issue des résultats de l'expression dts besoins, y compris du modèle des cas d'utilisation ; • un modèle d'analyse s'écrit dans le langage des développeurs et peut, par conséquent, introduire un plus grand formalisme et servir de base à une réflexion sur les mécanismes internes du système ; • un modèle d'analyse structure les besoins et les exigences sous une forme qui en facilite la compréhension, la préparation, la modification et, d'une manière générale, la maintenance ; • un modèle d'analyse peut être envisagé comme une première ébauche du modèle de conception (bien qu'il soit un modèle à part entière), et constitue ainsi une entrée essentielle pour l'élaboration du système, pendant les activités de conception et d'implémentation. Ceci s'explique par le fait que le système doit pouvoir être actualisé en tant que tout et ne pas se réduire à une simple description des besoins.

Quand employer l'analyse : exemples concrets En complément 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 manière d'exploiter ses résultats (c'est-à-dire le modèle d'analyse). • Effectuer l'analyse séparément, au lieu de la considérer comme faisant partie de la conception et de l'implémentation, permet d'analyser à moindre frais une grande partie du système. On peut ensuite utiliser son résultat pour planifier le travail ultérieur de conception et d'implémentation ; parexemple, sous forme d'incréments successifs dont chacun prendra seulement en charge la conception et l'implémentation d'une petite partie du système ; ou encore sous forme d'incréments concurrents, éventuellement conçus et implémentés par des équipes de développement géographiquement dispersées. L'identification et la planification risquent d'être plus compliquées sans les résultats de l'analyse. • L'analyse offre une vision d'ensemble du système qu'il serait peut-être plus difficile d'obtenir en étudiant les résultats de la conception ou de l'implémentation, vu qu'un grand nombre de détails ont alors été introduits (rappelez-vous le ratio de 1 à 5 évoqué dans la section 8.2.1). Ce type de présentation générale peut se révéler très précieuse pour ceux qui découvrent le système ou pour les développeurs qui en assurent la maintenance d'une manière générale. Par exemple, une société a mis au point, selon des principes semblables à ceux décrits dans les chapitres 3 et 4, un vaste système (comportant des

Analyse ||B CHAPITRE

8

m

milliers de sous-systèmes de service). A partir de là, nous avons introduit un modèle d'analyse afin de parvenir à une meilleure compréhension du système déjà développé. L e directeur informatique résume ainsi l'expérience que vit aujourd'hui sa société : « grâce au modèle d'analyse, nous pouvons désormais former des architectes système en deux uns au heu de cinq ». Pour un système de moindre envergure, cette période de formation se mesurerait en mois plutôt qu'en années, mais les proportions resteraient identiques. • Certaines parties du système présentent des conceptions et/ou des implémentations de rechange. Par exemple, les systèmes stratégiques tels que les systèmes de contrôle aéi ieu ou ferroviaire peuvent se composer de plusieurs programmes différents calculant de façon concurrente les mêmes opérations, et seule la convergence des résultats de ces divei ses sources de calcul pourra permettre l'exécution d'une manœuvre d'importance. Aulie exemple : admettons qu'un client veuille que plusieurs éditeurs (ou sous-traitants) fournissent des logiciels sur différents sites : i l voudra que ces SSII concurrentes lui soumettent des propositions à partir de la même spécification. C'est le cas, en général, lorsqu'une partie du système est implémenté plus d'une fois par l'usage de différentes technologies telles que des langages de programmation ou des composants s'exécutant sur différentes plates-formes. Le modèle d'analyse peut alors offrir une vue conceptuelle, précise et unifiée de ces différentes implémentations. Dans ce cas, i l est évident que le modèle d'analyse doit être maintenu tout au long du cycle de vie du système. • Le système est bâti à partir d'un système existant complexe. L'ingénierie de ce système existant, ou tout au moins d'une partie de ce système, peut être décrite sous la forme d'un modèle d'analyse, afin de permettre aux développeurs de le comprendre sans avoir à se plonger dans les détails de sa conception et de son implémentation, et de construire le nouveau système en se servant de l'ancien comme d'une brique de base réutilisable. Une réingénierie complète de la conception et de l'implémentation d'un tel système existant serait non seulement très complexe et coûteuse, mais finalement de peu de secours, surtout si le système en question n'a pas besoin d'être modifié ou repose sur des technologies obsolètes.

8.3 Rôle de l'analyse dans le cycle de vie du logiciel L'analyse constitue le point de convergence des premières itérations 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 compréhension 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 déplace vers la conception et l'implémentation.


Igure 8.2 '.•m/ de onvergence If I analyse.

Enchaînements d ' a c t i v i t é s principaux Besoins

Création , Élaboration , i i

Phases Construction

Transition

Analyse CHAPITRE

rfHïyB

8 ~ r

m

m

m

^

relativement directe un système répondant à ces exigences. Là encore, nous sommes quelque peu sceptique Pour choisir entre les deux premières variantes, i l convient d'évaluer les avantages que pr*" sente la conservation du modèle d'analyse par rapport au coût de sa mise à jour sur plusicii" itérations et générations. I l nous faut, par conséquent, effectuer le meilleur compromis ent " coût et avantages et décider s'il est préférable d'interrompre la mise à jour du mode d'analyse (peut-être dès la fin de la phase d'élaboration) ou s'il vaut mieux en poursuiv" l'actualisation pendant le reste de la durée de vie du système. s

r

1

| Analyse Conception

Implémentation

Nous admettons que la troisième variante permet d'éviter non seulement le coût de lu min jour du modèle d'analyse, mais aussi celui de l'introduction même de ce modèle (Ici que temps et les ressources nécessaires pour former les développeurs - e t leur | K - I I I M I I " d'acquérir de l'expérience - à l'utilisation de ce modèle). I l nous semble néanmoins, comn™ nous l'avons fait remarquer plus haut, que les avantages que confère l'emploi d'un mode d'analyse, au moins au début, l'emportent largement sur le coût de son introduction. Cet ' variante doit donc être réservée aux très rares cas où le système à développer est extrf ' mement simple. 1 6

Itérations lier. préliminaires #1

Iter. #2

Iter. Iter. Iter. #n #n+1 #n+2

iter. #m

iter. #m+1

Itérations

Si chaque projet doit se conformer au propos et à l'objectif de l'analyse, la façon 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 modèle d'analyse (comme nous le verrons en détail plus loin dans ce chapitre) pour décrire les résultats de l'analyse et veille à sa cohérence tout au long du cycle de vie du logiciel. Cette mise à jour peut être effectuée continûment, à travers chaque itération du projet, afin de procurer certains des avantages suggérés dans la section 8.2.3. 2. Le projet utilise le modèle d'analyse pour décrire les résultats de l'analyse, mais i l envisage ce modèle comme un outil transitoire et intermédiaire, essentiellement axé sur la phase d'élaboration. Par la suite, lorsque la conception et l'implémentation trouvent leur vitesse de croisière, au cours de la phase de construction, on abandonne la mise à jour du modèle d'analyse. Toutes les « questions d'analyse » encore en suspens sont alors résolues dans le cadre du travail de conception, directement dans le modèle de conception qui en résulte (sur lequel nous nous attarderons au chapitre 9). 3. Le projet n'utilise pas du tout le modèle d'analyse pour décrire les résultats de l'analyse, mais place l'analyse des besoins et des exigences soit dans l'expression des besoins, soit dans la conception. La première solution réclamera un plus grand formalisme dans le modèle des cas d'utilisation. Le choix d'une telle option peut se justifier si le client est capable de comprendre les résultats, 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 défendre, par exemple si les besoins sont très simples et/ou parfaitement connus, si la forme du système (y compris son architecture) est facile à identifier, ou si les développeurs ont une compréhension intuitive mais fidèle des besoins et qu'ils sont capables de construire de manière

Figure 8.3 Le modèle d'analyse est une hiérarchie de paquetages d'analyse Modèle d'analyse contenant des classes d'analyse et des réalisations de cas d'utilisation.

Système d'analyse

Classe d'analyse

Réalisatlon-analys' de cas d'utlllsatior" 86

8.4 Artefacts 8.4.1 Artefact : modèle d'analyse Nous avons présenté le modèle d'analyse au début de la section 8.2. Comme l ' i l l u s i u - I ' figure 8.3, la structure qu'impose ce modèle est définie par une hiérarchie. Le modèle d'analyse est représenté par un système d'analyse indiquant le paquetage d i niveau supérieur du modèle. L'utilisation d'autres paquetages d'analyse permet e i i s u i h " d'aménager le modèle en parties plus gérables, représentant des abstractions de s o u . ivi"' tèmes, voire des couches complètes de la conception du système. Les classes d'analy«| constituent des abstractions de classes et éventuellement de sous-systèmes de la concepttOT (

0

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 système. Dans le modèle d'analyse, les cas d'utilisation sont réalises par des classes d'analyse et les objets qu'elles comportent. Ces réalisations sont représentées par des collaborations dans le modèle d'analyse et signalées par l'expression réalisation-analyse de cas d'utilisation. Les artefacts du modèle d'analyse sont abordés en détail dans les sections 8.4.2 à 8.4.5.

Figure 8.4 Attributs et soustypes (c'est-à-dire stéréotypes) essentiels d'une classe d'analyse.

8.4.2 Artefact : classe d'analyse

Analyse CHAPITRE

8

Q Classe d'analyse responsabilités attributs relations exigences particulières

Une classe d'analyse représente une abstraction d'une ou de plusieurs classes et/ou sous-systèmes dans la conception du système. Cette abstraction possède les caractéristiques suivantes : • une classe d'analyse se concentre sur les besoins fonctionnels et renvoie la prise en compte des exigences non fonctionnelles aux activités postérieures de conception et d'implémentation en les désignant comme exigences particulières de la classe. Cette séparation rend les classes d'analyse plus évidentes dans le contexte du domaine du problème, plus « conceptuelles » et souvent d'une granularité plus large que leurs équivalents en conception et en implémentation ; • une classe d'analyse définit ou fournit rarement une interface en termes d'opérations et de signatures. Son comportement est, en revanche, défini par des responsabilités à un niveau plus élevé, moins formel. Une responsabilité est une description textuelle d'un sousensemble cohérent du comportement défini par une classe ; • une classe d'analyse définit 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 problème, tandis que ceux des classes de conception et d'implémentation présentent souvent des types issus de langages de programmation. I l est assez courant, en outre, que les attributs identifiés au cours de l'analyse se transforment en classes au cours de la conception et de l'implémentation ; • une classe d'analyse est impliquée dans des relations, même si celles-ci sont plus conceptuelles que leurs homologues de conception et d'implémentation. Par exemple, la navigabilité entre associations compte assez peu pour l'analyse, alors qu'elle est essentielle dans la conception. De même, les généralisations peuvent être utilisées dans l'analyse, mais i l peut très bien être impossible de s'en servir dans la conception si elles ne sont pas prises en charge par le langage de programmation ; • les classes d'analyse appartiennent toujours à l'un de ces trois stéréotypes de base : « f r o n t i è r e », « contrôle » ou « e n t i t é » (voir la figure 8.4). Le fait que chaque stéréotype implique une sémantique particulière (décrite brièvement) donne une méthode puissante et cohérente d'identification et de description des classes d'analyse et contribue à la création d'un modèle objet et d'une architecture robustes. I l est cependant beaucoup plus difficile de définir des stéréotypes de classes de conception et d'implémentation d'une façon aussi claire et intuitive. Parce qu'elles gèrent les exigences non fonctionnelles, ces classes « existent dans un contexte propre au domaine de la solution » et sont souvent décrites par une syntaxe de langage de programmation et des technologies comparables de bas niveau.

Ô

Classe de contrôle Ces trois stéréotypes sont standardisés dans UML et aident les développeurs à répartir les préoccupations entre les différentes classes [3]. Chaque stéréotype dispose de son propre symbole, comme l'illustre la figure 8.5. Figure 8.5 UML fournit trois stéréotypes de classes standard, que nous utilisons dans l'analyse.

Q

Compte

O

Interface guichet

Ô

Alt. 2: «entité»

û

8.4.2.1

«frontière»

Interface guichet

Ô

C l a s s e s frontières

On utilise une classe frontière pour modéliser l'interaction entre le système et ses aelems (c'est-à-dire entre les utilisateurs et les systèmes externes). L'interaction implique souvent la réception (et la présentation) d'informations et de requêtes de la part (et en direction) des utilisateurs et des systèmes externes. Les classes frontières modélisent les parties du système qui dépendent de ses acteurs, ce qui implique qu'elles clarifient et recueillent les exigences pesant sur les frontières du système Ainsi, la modification d'une interface utilisateur ou d'une interface de communication H cantonne généralement à une ou plusieurs classes frontières. Les classes frontières représentent souvent des abstractions de fenêtres, de formulaires, df volets, d'interfaces de communication, d'interfaces d'imprimantes, de capteurs, de terminaux et d'API (éventuellement non orientées objet). Cependant, ces classes frontières


II

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 frontières décrivent le produit de l'interaction (c'est-à-dire les informations et requêtes échangées entre le système et ses acteurs). Elles n'ont pas besoin de décrire la réalisation physique de l'interaction, puisque cet aspect est pris en compte par les activités ultérieures de conception et d'implémentation. Chaque classe frontière doit être liée à au moins un acteur, et vice versa. Classe frontière de l'interface utilisateur Demande de règlement La classe frontière iu Demande de règlement permet de prendre en charge l'interaction entre l'acteur Acheteur et le cas d'utilisation Régler la facture (figure 8.6). Figure 8.6 Classe frontière Demande de règlement.

IU

S Acheteur

Analyse CHAPITRE

8

La classe entité Facture La classe entité suivante, appelée Facture, permet de représenter les factures. Cette classe est associée à la classe frontière lu Demande de règlement, grâce à laquelle l'utilisateur parcourt et manipule les factures (voir la figure 8.7). Figure 8.7 Classe entité Facture et sa relation avec la classe frontière IU Demande de règlement.

IU Demande de règlement

parcourt

Q

*0

Facture


8.4.2.3 Classes de contrôle

La dynamique du système est modélisée par les classes de contrôle, puisque celles-ci gèrent et coordonnent les actions et les flots de contrôle principaux, et délèguent le travail à d'autres objets (les objets frontières et entités).

Nous donnerons, ensuite, des exemples de la manière dont cette classe frontière est liée à l'« intérieur » du système, c'est-à-dire aux classes de contrôle et aux classes entités.

Les classes de contrôle représentent la coordination, le séquencement, les transactions et le contrôle d'autres objets. Elles servent souvent à encapsuler le contrôle associé à un cas d'utilisation spécifique. Elles permettent aussi de représenter des dérivations et des calculs complexes, tels que la logique métier, ne pouvant être liés à aucune information spécifique et durable stockée par le système (une classe entité spécifique).

iu Demande de règlement permet à un utilisateur de parcourir les factures à payer, de contrôler chaque facture en détail, puis de demander au système de régler une facture (en en programmant le règlement), iu Demande de règlement permet également à l'utilisateur de rejeter une facture que l'acheteur ne souhaite pas payer.

8.4.2.2 Classes entités

Notez que les classes de contrôle n'encapsulent pas les questions liées aux interactions avec les acteurs, pas plus qu'elles n'encapsulent celles liées aux informations durables, persistantes gérées par le système, encapsulées respectivement par les classes frontières et les classes entités. Les classes de contrôle, de leur côté, encapsulent, et par conséquent isolent, les modifications du contrôle, de la coordination, du séquencement, des transactions et, parfois, de la logique métier complexe impliquant plusieurs autres objets.

Une classe entité sert à modéliser les informations de longue durée et souvent de nature persistante. Ce type de classe modélise les informations et le comportement associé d'un phénomène ou d'un concept tel qu'un individu, un objet ou un événement du monde réel. Dans la plupart des cas, les classes entités sont directement dérivées de la classe entité métier (ou de la classe du domaine) correspondante du modèle objet métier (ou du modèle du domaine). Une différence essentielle oppose toutefois les classes entités et les classes entités métier : les premières représentent des objets gérés par le système envisagé, tandis que les secondes renvoient à des objets du métier (et du domaine du problème) en général. Les classes entités fournissent donc une représentation des informations utile aux développeurs lors de la conception et de l'implémentation du système, y compris en ce qui concerne la prise en charge de la persistance. Ce n'est pas exactement le cas des classes entités métier (ou classes du domaine), qui décrivent plutôt le contexte du système et expriment par conséquent des informations qui ne sont absolument pas gérées par le système. Un objet entité n'est pas nécessairement passif et peut avoir un comportement complexe selon les informations qu'il représente. Ces objets isolent les modifications des informations qu'ils incarnent.

EMU

Classe de contrôle Échéancier Pour affiner l'exemple précédent, nous introduisons une classe de contrôle appelée lehMu cier, chargée de la coordination entre iu Demande de règlement et Facture; voir la figure 8.8.

Figure 8.8 Introduction de la classe Échéancier et de ses relations avec les classes frontières et entités.

Acheteur

Les classes entités font souvent apparaître une structure de données logique et contribuent à une meilleure compréhension des informations dont le système dépend.

programmer la facture '


Échéancier

m


II

Échéancier accepte une demande de règlement, telle qu'une requête de paiement d'une facture, et une date à laquelle la facture doit être réglée. Ensuite, lorsque la facture arrive à échéance, Échéanci er effectue le paiement en demandant un transfert de la somme entre les comptes voulus.

8.4.3 Artefact : réalisation-analyse

de cas d'utilisation

Une réalisation-analyse de cas d'utilisation est une collaboration au sein du modèle d'analyse décrivant la façon dont un cas d'utilisation donné est réalisé et exécuté en termes de classes d'analyse et d'interactions entre les objets qu'elles contiennent. Une réalisation de cas d'utilisation offre donc une traçabilité directe vers un cas d'utilisation spécifique dans le modèle des cas d'utilisation (figure 8.9). Figure 8.9 // existe une traçabilité entre une réalisationanalyse de cas d'utilisation du modèle d'analyse et un cas d'utilisation du modèle des cas d'utilisation.


d'une

Analyse CHAPITRE

8

8.4.3.1 Diagrammes de classes

Régler

la facture.

Réalisation-analyse de cas d'utilisation

et

associations

cas

du cas

d'utilisation


Echéancier

8.4.3.2 Diagrammes d'interaction

Figure 8.10 l'ttncipaux attributs

de

Utilisation.

Une classe d'analyse et les objets qu'elle comporte participent en général à plusieurs r é a l i s a tions de cas d'utilisation, alors qu'un certain nombre de responsabilités, d'attributs et d'aSSO dations ne sont souvent pertinents que dans une seule de ces réalisations. Il est donc important, pendant l'analyse, de coordonner toutes les exigences que sont susceptibles d'avoir différentes réalisations de cas d'utilisation sur une classe et ses objets, ("esl pourquoi on associe les diagrammes de classes aux réalisations 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 réalisation

C a s d'utilisation

o -

M o d è l e des cas d'utilisation

Acheteur

Une réalisation de cas d'utilisation présente une description textuelle des flots d'événements, des diagrammes de classes qui décrivent ses classes d'analyse, et des diagrammes d'interaction illustrant la réalisation d'un flot ou d'un scénario particulier du cas d'utilisation en termes d'interactions entre objets d'analyse (voir la figure 8.10). De même, étant donné qu'une réalisation de cas d'utilisation est décrite ici à l'aide des classes d'analyse et des objets que renferment celles-ci, elle s'intéresse naturellement aux exigences fonctionnelles. Elle peut donc, tout comme les classes d'analyse elles-mêmes, reporter la prise en charge des exigences non fonctionnelles aux activités de conception et d'implémentation en les désignant comme exigences particulières de la réalisation en question.

La séquence d'actions d'un cas d'utilisation débute lorsqu'un acteur invoque ce cas d'utilisation en envoyant une forme quelconque de message au système. Si, dans ces pages, nous considérons l'« intérieur » du système, c'est un objet frontière qui recevra ce message adressé par l'acteur. L'objet frontière envoie à son tour un message à un autre objet, de sorte que les objets concernés dialoguent pour réaliser le cas d'utilisation. Nous préférons, dans l'analyse, traduire ce phénomène par des diagrammes de collaboration puisque notre propos est avant tout d'identifier les exigences et les responsabilités des objets et non de déterminer des séquences détaillées et chronologiques d'interactions (auquel cas nous utiliserions plutôt des diagrammes de séquence).

flot d ' é v é n e m e n t s - a n a i y s e diagrammes de classes diagrammes d'interaction exigences particulières

utilisation— mi,tlv.se ,1

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

participante

Diagramme de collaboration montrant la réalisation d'un cas d'utilisation La figure 8.12 montre un diagramme de collaboration réalisant la première partie du cas et'utilisation Régler la facture.

Q

Classe d'analyse

a l


iure8.12 Diagramme de . ollaborationpour ic réalisation du v tl'utilisation fier la facture. 3: Contrôler la facture 1: Parcourir les factures 6: Programmer la facture pour règlement

En ce qui concerne la création et l'achèvement des objets d'analyse au sein d'une réalisation de cas d'utilisation, différents objets ont différents cycles de vie (annexe C) : • un objet frontière n'a pas besoin d'être spécifique à une réalisation de cas d'utilisation s'il doit par exemple apparaître dans une fenêtre 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 même réalisation de cas d'utilisation ; • la plupart du temps, un objet entité n'est pas spécifique à une réalisation de cas d'utilisation. I l sera plutôt durable et participera à plusieurs réalisations de cas d'utilisation avant de prendrefin;

Analyse CHAPITRE

8

L'acheteur parcourt les factures gérées par le système afin de trouver celles reçues (1,2) par l'iu Demande de règlement. L'IU Demande de règlement Utilise le Gestionnaire de commandes pour vérifier les factures par rapport aux confirmations de commande concernées (3,4,5), avant de présenter la liste des factures à l'acheteur. Les implications de cette vérification dépendent des règles métier que met en œuvre la société 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 règles métier pour déterminer les questions (illustrées pai lus messages Obtenir 4, 5) à poser aux Objets Confirmation de commande et Facture pour analyser les réponses. Toute facture suspecte est, d'une façon ou d'une autre, si gnalée à l'attention de l'acheteur par l'intermédiaire de l'iu Demande de règl em«n t, éventuellement par l'usage d'une couleur différente destinée à la mettre en relief. L'acheteur sélectionne une facture à l'aide de l'iu Demande de règlement utniipiu gramme le règlement (6). L'iu Demande de règlement demande à Ti-u-iu:nu-i,-i de programmer le règlement de la facture (7). L'Échéancier crée ensuite une demanda du règlement (8). L'iu Demande de règlement fait alors passer la facture en état « programmé » (9). L'Échéancier gramme).

déclenche le règlement à la date d'échéance (ceci n'apparaît pas sur le dia-

Il est intéressant de comparer cette description avec le flot d'événements du cas d'utilisation tel qu'il a été décrit dans le chapitre 7, section 7.2.3.1. La description du chapitre 7 expose le comportement du cas d'utilisation vu de l'extérieur, tandis que la description ci-dessus s'attache à montrer la réalisation du cas d'utilisation par le système en termes de collaborations entre objets (logiques). 8.4.3.4 E x i g e n c e s

particulières

Voici un exemple d'exigences particulières pour une réalisation du cas d'utilisation mi ici i
Les diagrammes, en particulier ceux de collaboration, d'une réalisation de cas d'utilisation sont parfois difficiles à lire ; i l peut donc être utile d'ajouter un texte explicatif. Ce texte doit être rédigé en termes d'objet, notamment d'objets de contrôle, qui dialoguent pour exécuter le cas d'utilisation. I l ne doit toutefois mentionner aucun des attributs, des responsabilités et des associations des objets, qu'il serait difficile d'actualiser en raison de leurs fréquentes modifications.

Exigences particulières pour la réalisation d'un cas d'utilisation

BMflj

8.4.3.3 Flot d ' é v é n e m e n t s - a n a l y s e

Les exigences particulières sont des descriptions textuelles regroupant toutes les exigences non fonctionnelles qui affectent une réalisation de cas d'utilisation. Certaines de ces exigences avaient déjà été formulées d'une manière ou d'une autre pendant l'enchaînement d'activités des besoins (tel qu'il est décrit dans les chapitres 6 et 7), et sont simplement transformées en réalisations-analyse de cas d'utilisation. I l se peut toutefois que des exigences nouvelles ou dérivées apparaissent au cours du travail d'analyse.

• les classes de contrôle encapsulent souvent le contrôle lié à un cas d'utilisation spécifique, ce qui implique qu'un objet de contrôle est créé au démarrage du cas d'utilisation et prend fin à l'issue du cas d'utilisation. I l y'a néanmoins des exceptions : lorsqu'un objet de contrôle participe à plusieurs réalisations de cas d'utilisation, lorsque plusieurs objets de contrôle (issus de différentes classes de contrôle) participent à une seule réalisation de cas d'utilisation, et enfin lorsqu'une réalisation de cas d'utilisation ne nécessite aucun objet de contrôle.

BfflH

facture : • lorsque l'acheteur demande à voir les factures reçues, leur apparition à l'écran ne doit pas pinn dre plus d'une demi-seconde ; • le règlement des factures doit utiliser le standard SET.

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 compléter le diagramme de collaboration montré dans l'exemple précédent (voir la figure 8.12) :

tiNlnninonts d ' a c t i v i t é s principaux

Mm

8

pjj

Analyse CHAPITRE

irf.ici

: p a q u e t a g e

d ' a n a l y s e

ii|in-iages d'analyse offrent un moyen d'organiser les artefacts du modèle d'anilyie en labiés. Un paquetage d'analyse peut se composer de classes d'analyse, de icalisa M d'utilisation et d'autres paquetages d'analyse (de façon récurslve), Voir la Ut» H 1.1.

A

Paquetage d'analyse

8.4.4.1 P a q u e t a g e s d e s e r v i c e

Outre les cas d'utilisation qu'il fournit à ses acteurs, chaque système procure à ses clients un ensemble de services. Un client acquiert ainsi une combinaison adaptée de services afin d'offrir à ses utilisateurs les cas d'utilisation nécessaires à l'exécution de leur mission. • Un cas d'utilisation spécifie une séquence d'actions : le processus est déclenché par un acteur, se poursuit par les interactions entre l'acteur et le système, et enfin s'achève et s'interrompt après avoir renvoyé une valeur à l'acteur. En général, les cas d'utilisation n'existent pas isolément. Par exemple, le cas d'utilisation Facturer l'acheteur part de l'hypothèse qu'un autre cas d'utilisation a créé une facture et que l'adresse tic l'ai lirinn et les autres données concernant le client sont accessibles. • Un service représente un ensemble cohérent d'actions fonctionnellement liées un paquetage de fonctionnalités - employé par plusieurs cas d'utilisation. Le client d'un système achète généralement 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 système doit le fournir intégralement ou pas du tout. • Les cas d'utilisation sont destinés 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.

Classe d'analyse


ii |t ici âges d'analyse doivent être cohérents (c'est-à-dire que leur contenu doit être forI hé) et faiblement couplés (leurs dépendances mutuelles doivent être réduites le plus Hulble). i • H itii'luges peuvent, en outre, présenter les caractéristiques suivantes : i iquetages d'analyse peuvent marquer une séparation des questions d'analyse. Par r> in pie, il est possible, dans un vaste système, que certains paquetages d'analyse soient llltilysés séparément ou parallèlement par des développeurs ayant des connaissances dans ili domaines différents ; i mquetages d'analyse doivent provenir des besoins fonctionnels et du domaine du problème (c'est-à-dire l'application ou le métier), 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 répartis entre, des systèmes des deux couches supérieures d'applications du modèle de conception. i ertains cas, un paquetage d'analyse pourra même refléter toute une couche de m supérieur du modèle de conception.

Dans le Processus unifié, le concept de service est pris en charge par les paquetages de service. Ceux-ci sont utilisés à un niveau inférieur de la hiérarchie (de contenance) des paquetages d'analyse pour structurer le système 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 liées ; • 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 réalisation d'un cas d'utilisation, et i l n'est pas rare qu'un paquetage spécifique participe à plusieurs réalisations de cas d'utilisation ; • un paquetage de service présente généralement des dépendances très limitées vis-à-vis des autres paquetages de service ; • un paquetage de service ne présente généralement de pertinence que pour une poignée d'acteurs ; • une fois conçues et implémentées, les fonctionnalités définies par un paquetage de service peuvent être gérées comme des unités livrées séparément. Un paquetage de service pi-ut ainsi représenter des fonctionnalités « additionnelles » du système. Lorsqu'un paquetage de service est exclu, i l en va de même pour chaque cas d'utilisation dont la réalisation implique son intervention ; • les paquetages de service peuvent être mutuellement exclusifs ou représenter divers aspects ou variantes du même service. Par exemple, « vérification d'orthographe pour le français de France » et « vérification d'orthographe pour le français de Belgique » peuvent être deux paquetages de service fournis par un même système ;

i

' •

1

nti d ' a c t i v i t é s principaux

Analyse CHAPITRE

!»• i-i|',rs de service constituent une entrée essentielle pour les activités ultl I II un MU. . | ii H m cl d'implémentation, en ce qu'ils contribuent à la structuration dei modèles l'iion cl d'implémentation sous forme de sous-systèmes de service. Ils cxai cnl, m. H lui. une influence majeure sur la décomposition du système en composants • M'cutables. m M H m du système en fonction des services qu'il fournit prépare 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 système i|. il.lt- île s'adapter au changement. H

dans la section 8.6.1.1 une méthode d'identification des paquetages de in. .les exemples de ces paquetages.

d u

(vue

Artefact

8.4.5

: description

m o d è l e

d e

8

l'architecture

d'analyse)

La description de l'architecture contient une vue architecturale du modèle d'analyse (annexe C) et en décrit les artefacts significatifs sur le plan architectural (figure 8.14). Figure 8.14 La description de


l'architecture contient une vue architecturale du modèle

pu l H le d'agencement courant des artefacts du modèle d'analyse reste dicté par H .1. paquetages d'analyse ordinaires, comme l'explique la section précédente. I l uilili iiiiiirlbis indispensable d'introduire ici un stéréotype « paquetage de service» i iiiniqiii'i explicitement les paquetages représentant des services. I l est particulièi..H.mi. dans les systèmes d'envergure (contenant de nombreux paquetages), de un I.H ilement la distinction entre les différents types de paquetages. De plus, cette Mu in- l'utilisation et l'exploitation des stéréotypes au sein d'UML.

•

vue architecturale

d'analyse.

Modèle d'analyse

On considère généralement comme significatifs sur le plan architectural les artefacts du modèle d'analyse suivants :

. le service sont réutilisables - Comme nous l'avons vu dans la section précéI.I. h |im|iii'lages de service présentent un certain nombre de caractéristiques fort séduih II. que leur cohérence (annexe C), leur indivisibilité, leur faible couplage, leur FMIMIII M'I'IUÏT, cl ainsi de suite. Ces qualités font de la plupart des paquetages de service i .r i la réutilisation, à la fois à l'intérieur d'un même système et entre systèmes • I un moins) liés. De façon plus spécifique, i l y a des chances pour que les paquetages • | - n nés sont centrés autour d'une ou plusieurs classes entités (voir la ^ ^ H | , 2 . 2 ) soient réutilisables dans différents systèmes prenant en charge le même m le infime domaine. Le fait que les classes entités dérivent de classes entités métier i. .lu domaine fait de ces classes entités et des services qui leurs sont liés des can-

• la décomposition du modèle d'analyse en paquetages d'analyse avec leurs dépendances. Cette décomposition influe souvent sur les sous-systèmes des couches supérieures au cours de la conception et de l'implémentation et présente donc un intérêt pour l'architecture en général ; • les classes d'analyse clés telles que les classes entités qui encapsulent un phénomène majeur du domaine du problème ; les classes frontières qui encapsulent des interfaces de communication et les mécanismes d'interfaces utilisateur essentiels ; les classes de contrôle qui encapsulent d'importantes séquences à large couverture (c'est-à-dire celles qui coordonnent les réalisations de cas d'utilisation significatives) ; enfin, les classes d'analyse générales et centrales qui entretiennent de nombreuses relations avec d'autres classes d'analyse. I l est d'ordinaire suffisant de considérer une classe abstraite, et non ses sous-classes, comme étant significative sur le plan architectural ;

I

i i lu n utilisation dans l'ensemble du métier ou du domaine et dans la plupart des syspicnant en charge, et non pas uniquement dans un système spécifique. Les ijiii i.i).. ilr service et les services eux-mêmes sont orthogonaux aux cas d'utilisation dans m paquetage de service peut être employé dans plusieurs réalisations de cas d'utiiitti 'rentes. Ceci est particulièrement vrai lorsque le paquetage de service réside | | mit' couche générale comportant des fonctionnalités communes et partagées (voir la d I I ) . Un paquetage de ce type est ensuite susceptible d'être réutilisé dans plu| | ipplii .liions (configurations) différentes du système, chacune d'entre elles fournissant . i lisaiion dont la réalisation nécessite le paquetage de service. On peut remonter i.ijvs de service aux sous-systèmes de services de la conception (voir la I I ) et aux composants d'implémentation (voir la section 10.3.2). Ces compo• ...i u'iililisables pour les mêmes raisons que les paquetages de service le sont.

• les réalisations de cas d'utilisation qui réalisent certaines fonctionnalités importantes et stratégiques ; celles qui impliquent un grand nombre de classes d'analyse et, par là même, ont une large couverture et peuvent traverser plusieurs paquetages d'analyse ; ou celles qui s'attachent à un cas d'utilisation important devant être développé tôt dans le cycle de vie du logiciel, et par conséquent susceptible de figurer dans la vue architecturale du modèle des cas d'utilisation (annexe C).

ii

i.igcs de service se révèlent par conséquent notre principal outil de réutilisation i analyse et influent à la fois sur la conception et l'implémentation du système, pour i ' ii donner lieu à des composants réutilisables.

J B.5

8.5.1

:

Les e n c h a î n e m e n t s d'activités

principaux

PARTIE II

:

Analyse CHAPITRE

T r a v a i l l e u r s

Travailleur

architecte

Pendant l'enchaînement d'activités de l'analyse, l'arehilei i. . i i. jiunsnlile III I 'p.iiicdu modèle d'analyse dans son ensemble et doit s'assurei de son cxw lititdi .1. su . ohéieni c cl de sa lisibilité (voir la figure 8.15). Pour de vastes systèmes i omplcxes i es responsabilités peuvent exiger, après quelques itérations, une maintenance supplémentaire . d est possibltque le travail impliqué devienne assez routinier. L'architecte peut alors déléguer celle lâche à un autre travailleur, tel qu'un ingénieur 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é déléguée une partie du travail sera chargé du paquetage de niveau supérieur du modèle d'analyse, qui doit être conforme à la description de l'architecture.

Figure 8.16

c

l'analyse.

a

Travailleur

f~j


d e c a s

H

Ingénieur de «'utilisation s

responsable de


8.5.3

Q de

y \^ responsable de

: i n g é n i e u r

8 Jmm

Notez que l'ingénieur de cas d'utilisation n'est pas responsable des classes d'analyse et des relations employées dans la réalisation du cas d'utilisation. Ces responsabilités-là sont du ressort de l'ingénieur de composants (voir la section 8.5.3). Comme nous le verrons dans le chapitre suivant, l'ingénieur de cas d'utilisation est également chargé de la conception des réalisations de cas d'utilisation. Le fait que l'analyse et la conception du cas d'utilisation soient confiées à la même personne garantit une transit parfaitement fluide. O

Responsabilités d'un ingénieur de cas d'utilisation pendant

I

Le modèle d'analyse est jugé correct lorsqu'il réalise les fonctionnalités décrites dans le modèle des cas d'utilisation, et celles-là seulement. L'architecte est également responsable de l'architecture du modèle d'analyse, c'est-à-dire de l'existence de ses parties significatives sur le plan architectural telles que la vue architecturale de ce modèle les dépeint. Rappelez-vous que cette vue fait partie de la description de l'architecture du système.


d e

c o m p o s a n t s

L'ingénieur de composants définit les responsabilités, attributs, relations et exigences particulières 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 réalisations de cas d'utilisation auxquelles elle participe (voir la figure 8.17).

Remarquez que l'architecte n'est pas responsable du développement et de la maintenance permanents des divers artefacts du modèle d'analyse, qui sont à la charge des ingénieurs de cas d'utilisation et de composants concernés (voir les sections 8.5.2 et 8.5.3). qure8.15 Responsabilités

L'ingénieur de composants veille également au respect de l'intégrité 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 dépendances par rapport aux autres paquetages d'analyse sont correctes et minimales.

Architecte

I architecte mdant Vanalyse.

Il peut être intéressant qu'un ingénieur 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-systèmes de conception correspondants (voir la section 8.4.4), l'ingénieur de composants doit aussi être responsable de ces sous-systèmes et exploiter les connaissances acquises au cours de l'analyse effectuée lors de la conception et de l'implémentation du paquetage d'analyse. En l'absence d'une telle correspondance, d'autres ingénieurs de composants peuvent prendre part a la emi ception et à l'implémentation du paquetage d'analyse.

vue architecturale Modèle d'analyse

. 5 . 2 Travailleur

d'utilisation

Un ingénieur de cas d'utilisation est responsable de l'intégrité d'une ou de plusieurs réalisations de cas d'utilisation et doit s'assurer que celles-ci satisfont aux exigences qui leur sont imposées (voir la figure 8.16). Une réalisation de cas d'utilisation doit réaliser de façon adéquate le comportement du cas d'utilisation correspondant dans le modèle 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 décrivant cette réalisation sont lisibles et remplissent leur mission.

^ mmtÊ


Figure 8.17 Responsabilités l'ingénieur

de

de

â

8.6.1

l'analyse.

/

\

responsable de

E n c h a î n e m e n t

\ •

/

Paquetage d'analyse

A c t i v i t é

Analyse CHAPITRE

8

architecturale

Figure 8.19 Entrées

et

O

résultat

de l'analyse architecturale.

Modèle des ** cas d'utilisation


d ' a c t i v i t é s

Analyse architecturale

s

o

Jfcjfc

D

activités.

D Paquetage d'analyse [esquisse]

-•À

f

i

Description de l'architecture [vue du modèle d'analyse]

Description de l'architecture [vue du modèle des Architecte]

- > Û Analyse architecturale Classe d'analyse [esquisse]

Modèle du métier [ou modèle du domaine]

Analyse ârchitecturale

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

Les paquetages d'analyse permettent d'agencer le modèle d'analyse en parties plus modestes et plus facilement gérables. Ils sont identifiés soit dès le début comme un moyen de répartir le travail d'analyse, soit au cours de l'évolution du modèle d'analyse, lorsque celui-ci devient une structure imposante qu'il faut décomposer.

O a Architecte

dans

l'analyse, avec les availleurs y renant part et veurs

: a n a l y s e

Le propos de l'analyse architecturale est de tracer les contours du modèle d'analyse et de l'architecture en identifiant les paquetages d'analyse, les classes d'analyse manifestes et les exigences particulières communes (voir la figure 8.19).


composants rendant

û

Classe d'analyse

3.6

Après avoir décrit le travail d'analyse en termes statiques, nous allons maintenant utiliser un diagramme d'activités pour réfléchir à son comportement dynamique (voir la figure 8.18). Ce sont les architectes qui amorcent la création du modèle d'analyse (tel qu'il est défini plus haut dans ce chapitre) en commençant par identifier les principaux paquetages d'analyse, les classes entités manifestes et les exigences communes. Puis les ingénieurs de cas d'utilisation réalisent 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, spécifiées par des ingénieurs de composants et intégrées à chaque classe par la création de responsabilités, d'attributs et de relations cohérents pour chaque classe. Pendant l'analyse, l'architecte identifie en permanence de nouveaux paquetages, classes d'analyse et exigences communes, à mesure qu'évolue le modèle d'analyse, tandis que les ingénieurs de composants responsables de chacun des paquetages d'analyse précisent et actualisent ces paquetages. igure 8.18 nchaînement d'activités

Une première identification des paquetages d'analyse s'effectue naturellement à partir des besoins fonctionnels et du domaine du problème, c'est-à-dire de l'application ou du métier considérés. Puisque les besoins fonctionnels sont exprimés 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 à réaliser la fonctionnalité correspondante au sein de ce paquetage. On peut considéra comme appropriée l'« affectation » à un paquetage spécifique des cas d'utilisation suivants

Analyser un cas

Ingénieur de cas d'utilisation

O

• les cas d'utilisation nécessaires à la prise en charge d'un processus métier précis

O Ingénieur de composants

Analyser une classe

Analyser un paquetage

• les cas d'utilisation nécessaires à la prise en charge d'un acteur particulier du .\u • les cas d'utilisation liés par des généralisations et des relations d'extension. Ces ensembles de cas d'utilisation sont cohérents dans le sens où les cas d'utilisation se spécialisent ou « s'étendent » les uns les autres. Des paquetages de ce type localiseront respectivement les modifications d'un pTOCMSUN métier, les évolutions du comportement d'un acteur et les changements intervenus dans un ensemble de cas d'utilisation étroitement liés. 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

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 Ot i.m l n w i u n q u e l'analyse progresse et que les cas d'utilisation soin réalisés ions li île i nllnhoriilions entre classes, éventuellement situées dans différents pai|uei:i|'i'. une stiiu line de paquetages plus sophistiquée se met en place. BfflH

Identification des paquetages d'analyse Cet exemple illustre la façon dont Interbank Software pourtail idcnliltiii cet tains de ses paquetages d'analyse à partir du modèle des cas d'utilisation. Les cas d'utilisation Reg 1er i a fac-

ture, Envoyer une relance et Facturer l'acheteur sont tous impliqués dans le même processus métier, Ventes : de la commande à la 1 i vrai son. Ils peuvent donc être fournis

Analyse CHAPITRE

8

consiste à extraire la classe partagée, à la placer dans un paquetage lui appartenant en propre ou juste en dehors des autres paquetages, puis à faire dépendre les autres paquetages de ce paquetage ou de cette classe plus généraux. Il y a de fortes chances pour que ces classes partagées représentant des chevauchements soient des classes entités dont on peut attribuer l'origine à des classes du domaine ou ii des classes entités métier. Il est donc utile d'étudier les classes du domaine ou les classes eniii. métier si elles sont partagées et de dégager des paquetages d'analyse généraux dès le début de l'analyse. fjMH

Identification des paquetages d'analyse g é n é r a u x Cet exemple illustre la façon dont Interbank Software pourrait identifier les paquetaqt::; d'aiu

par le même paquetage d'analyse.

lyse généraux à partir du modèle du domaine. Chacune des classes du domaine 11

i << i

des clients de la banque, pour chaque classe (voir la figure 8.21).

vendeur a besoin de celle des cas d'utilisation qui ne sont utiles qu'à l'acheteur. Nous voyons,

spécifiques. Interbank crée donc des paquetages séparés, Gestion des comptes et Gest Ion

terbank Software choisit par conséquent de séparer la réalisation des cas d'utilisation dont le

tion plus sophistiquée et qu'elles sont partagées par d'autres paquetages d'analyse plus

d'autres uniquement en tant que vendeurs, d'autres enfin cumuleront ces deux aspects. In-

bank se rend compte que ces classes exigent une prise en charge par le système d'informa-

besoins. Certains de ces clients se serviront du système seulement en tant qu'acheteurs,

la banque et Compte représente des entités importantes et complexes du monde réel. Inter-

Mais Interbank Software doit livrer ce système à différents clients ayant différents types de

ici, que l'hypothèse initiale d'un paquetage d'analyse unique pour le processus métier Ventes

: de l a commande à l a l i v r a i son a été adaptée afin de répondre aux

exigences des clients. Il en résulte deux paquetages d'analyse pouvant être livrés séparément 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

le

l'ache-

vendeur (voir la figure 8.20).

o 8.20

Figure 8.21 Identification de paquetages d'analyse généraux à partir des classes du domaine.

Û

Compte

A

Û

Client de la banque

A partir du m o d è l e du domaine

A

•liraiion des /uelages

Régler la facture

thilvsc à partir

Facturer l'acheteur

A

Envoyer une relance

•71

%s

Gestion des comptes

isation.

Gestion des clients de la banque

Paquetages d'analyse

Paquetages d'analyse

Remarquez que les paquetages Gestion des comptes et Gestion des clients de la banque Gestion des factures par l'acheteur

contiendront probablement de nombreuses classes d'analyse, notamment des classes de

Gestion des factures par le vendeur

contrôle et des classes frontières liées 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 entités permettant de remonter aux classes du domaine correspondant!!!!.

Notez que d'autres cas d'utilisation prennent également en charge le processus métier Ventes

: de l a

commande à l a

Identification des paquetages

1 i v r a i son, mais nous avons choisi de les

ignorer pour plus de simplicité.

Gestion des chevauchements entre paquetages d'analyse - Il n'est pas rare de rencontrer des chevauchements entre les paquetages tels qu'ils ont été identifiés dans la section précédente. On trouvera un exemple de ce type de chevauchement lorsque plusieurs paquetages ont besoin de partager la même classe d'analyse. Une réponse efficace à ce problème

de service

L'identification des paquetages de service appropriés 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 même paquetage de service COnbi buent toutes au même service. Lors de l'identification des paquetages de service, i l convient d'effectuer les démarches décrites ci-dessous.

J

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

• 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 système Interbank réclament un service d'envoi de relances. r e l a nce. Certains sou-

Analyse CHAPITRE

8

Identification des paquetages de service encapsulant des classes fonctionnellement liées Le paquetage Gestion des comptes comprend un paquetage de service général appelé Comp tes, qui permet d'accéder aux comptes pour des activités telles que le transfert d'argent et l'extraction d'historiques des transactions. Ce paquetage contient également un paquetage de

cas d'utilisation. Voir la figure 8.23.

est dépassée, tandis que d'autres préfèrent être d'abord informés et choisir ensuite d'envoyer ou non

Ces différents paquetages de service sont communs et utilisés par plusieurs réalisations du

haitent que des relances soient envoyées automatiquement dès que la date d'échéance d'une facture

service appelé Ri sques, consacré à l'estimation des risques associés à un compte particulier

Ce service est décrit dans le cas d'utilisation (facultatif) Envoyer une

une relance. Cette variabilité est représentée 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 décide 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 désire aucune prise en charge des

relances, ni l'un ni l'autre de ces paquetages ne lui seront livrés avec le système. ** are 8.22 filetages de • t'ire Relances im.'iinitit/ues et 'i. I,IIII

Figure 8.23 Paquetages de service Comptes et Risques, encapsulant chacun des classes fonctionnellement liées.

Gestion des comptes «paquetage de service» Comptes

û Compte

Transferts du compte

Û — Risques

Historique du compte

Envoyer une relance

es

UMlles, situés I le paquetage h\lion des tu tinvs par le 'leur.

ô Estimation des risques

A Définition des d é p e n d a n c e s entre paquetages d'analyse - I l faut définir les dépendances entre paquetages de service si leurs contenus respectifs entretiennent des relations. La direction de la dépendance doit être la même que la direction (de navigabilité) de la relation.


Relances manuelles

Relances automatiques

«paquetage de service»

'paquetage de service» |

• Identifiez un paquetage de service pour chaque service qui pourrait être rendu facultatif, même si tous les clients le demandent. Étant donné que les paquetages de service contiennent des classes fonctionnellement liées, vous obtiendrez ainsi une structure de paquetages localisant la plupart des changements dans des paquetages de service individuels. On peut également formuler ce critère de la façon suivante : identifiez un paquetage de service pour chaque service fourni par des classes fonctionnellement liées. Une classe A peut être considérée comme fonctionnellement liée à une classe B lorsque :

L'objectif est de mettre au point des paquetages relativement indépendants et faiblement couplés, mais ayant une forte cohésion interne. Les caractéristiques de faible couplage et de forte cohésion facilitent la maintenance des paquetages, puisque le fait de modifier certaines classes d'un paquetage affectera essentiellement les classes du paquetage lui-même. I l est donc recommandé de tenter de réduire le nombre de relations entre classes de différents paquetages afin de limiter les dépendances entre paquetages. Pour clarifier les dépendances, i l peut être utile de découper le modèle d'analyse en couches, en plaçant les paquetages spécifiques à l'application dans une couche de haut niveau et les paquetages plus généraux dans une couche inférieure. La distinction entre fonctionnalités spécifiques et fonctionnalités générales 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

paquetages Gestion des factures par l'acheteur et Gestion des facture:, par le veu

• la suppression de A rend B superflu ;

des classes issues d'autres paquetages. La classe Compte est, par exemple, utilisée dans lus

• un changement intervenant dans A a de fortes chances de nécessiter un changement dans B ;

deur. Ces paquetages dépendent, par conséquent, du paquetage Gestion des comptes (voir

• les objets de A ont d'importantes interactions avec des objets de B, éventuellement par l'intermédiaire de différents messages.

la figure 8.24).

in

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 m 8.24 •iitUinces et

|n

(te

•••••Murs


Gestion des factures par l'acheteur

(Couche spécifique A l'application)

ulvse.

Analyse CHAPITRES

Wm

• persistance ; • distribution et concurrence ; • caractéristiques de sécurité ; • tolérance aux pannes ; • gestion des transactions. Gestion des comptes

(Couche générale aux applications)

Ces couches seront ensuite affinées et détaillées au cours de la conception et de l'implémentation, lorsque l'environnement d'implémentation et les exigences non fonctionnelles en général seront pris en considération. 8 . 6 . 1 . 2 Identification d e s c l a s s e s e n t i t é s

manifestes

La plupart du temps, i l est bien venu de dresser une proposition préliminaire des classes entités les plus importantes (de 10 à 20), à partir des classes du domaine ou des entités métier identifiées au cours de la formulation des besoins. Cependant, la plupart des classes seront identifiées au moment de la création des réalisations 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 forêt de détails superflus. Une première é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 entités véritablement indispensables, c'est-à-dire celles prenant part à des réalisations de cas d'utilisation. Une classe entité ne participant à aucune réalisation de cas d'utilisation est inutile. Les agrégations et associations entre classes du domaine dans le modèle du domaine (ou entre entités métier dans le modèle du métier) peuvent servir de base à l'identification d'un ensemble préliminaire d'associations entre les classes entités correspondantes. TOIfll

L'architecte a la charge d'identifier les exigences particulières communes de sorte que les développeurs puissent s'y référer comme à des exigences particulières sur des réalisations de cas d'utilisation et des classes d'analyse déterminées. Dans certains cas, il esl impossible de détecter à l'avance ces exigences particulières, et i l faut attendre d'avoir exploré les réalisa 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 réalisation de cas d'utilisation spécilie pliisirui s exigences particulières. Pour faciliter la conception et l'implémentation, les caractéristiques essentielles île chaque exigence particulière commune doivent être identifiées. IWjjHH

Identification des caractéristiques essentielles d'une exigence particulière Une exigence de persistance présente les caractéristiques suivantes : • intervalle de taille : intervalle de taille des objets dont la persistance doit être préservée ; • volume : nombre d'objets dont la persistance doit être préservée ; • période de persistance : période de temps pendant laquelle la persistance d'un objet doit en principe être préservée ; • fréquence de mise à jour : fréquence de mise à jour des objets ; • fiabilité : questions de fiabilité ; par exemple, déterminer si des objets doivent survivre à un échec du logiciel ou du matériel.

Les caractéristiques de chaque exigence particulière sera ensuite qualifiée pour chaque classe ou réalisation de cas d'utilisation faisant référence à cette exigence particulière.

Une classe entité identifiée à partir d'une classe du domaine

• identifier les classes d'analyse dont les objets sont nécessaires à l'exécution du Ilot d'événements de ce cas d'utilisation ;

de règlement. Des associations seront également définies entre les classes entités à partir du

On procède à l'analyse d'un cas d'utilisation (voir la figure 8.25) pour :

gérer l'une des premières classes entités. Nous pouvons proposer, à titre de point de départ,

A c t i v i t é

Facture est une classe du domaine mentionnée au chapitre 6, que nous utiliserons pour sug-

8.6.2

les mêmes attributs que pour la Classe Facture : montant, date d'émission et date limite modèle du domaine, telles que l'association payable entre une Commande et une Facture. 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

: a n a l y s e r

un

c a s

d'utilisation

• répartir le comportement du cas d'utilisation entre des objets d'analyse en interaction les uns avec les autres ;

communes

• formuler des exigences particulières sur la réalisation du cas d'utilisation.

Une exigence particulière est une exigence surgissant au cours de l'analyse et qu'il est important de saisir afin de pouvoir la gérer comme i l convient dans les activités ultérieures de conception et d'implémentation. I l s'agit par exemple de restrictions ou de contraintes dans les domaines suivants :

L'analyse des cas d'utilisation est également appelée raffinement des cas d'utilisation Chaque cas d'utilisation est affiné sous forme de collaboration entre classes d'analyse.


l'ARTIE II Igure 8.25 titrées et tir l'analyse

résultat d'un

• <•. .l'utilisation.

Modèle des \ cas d'utilisation


Modèle du métier [ou modèle du domaine]

O

O

Ingénieur de cas d'utilisation

,.-•7 IIOIIIIMIIIOII

"A >

S

ly.i-

de cas d'utilisation tAl V S

.

Analyser .-•7 un cas d'utilisation

Û Classe d'analyse [esquisse]


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 contrôle, les classes entités et les classes frontières nécessaires à la réalisation du cas d'utilisation, et l'on en fait apparaître le nom, les responsabilités, les attributs et les relations. Les cas d'utilisation décrits dans les besoins et les exigences ne sont pas toujours assez détaillés pour permettre l'identification des classes d'analyse. Les informations sur l'intérieur du système présentant généralement peu d'intérêt au moment de la formulation des besoins et des exigences, i l est possible qu'elles aient été négligées. Pour identifier les classes d'analyse, i l faut, par conséquent, préciser les descriptions des cas d'utilisation en ce qui concerne l'intérieur du système. Ce surcroît de précision doit figurer dans le flot d'événements textuel, c'est-à-dire la description de l'analyse de la réalisation d'un cas d'utilisation. Les conseils et les principes énoncés ci-dessous s'appliquent d'une façon générale à l'identification des classes d'analyse. • Identifiez les classes entités en étudiant en détail la description du cas d'utilisation et tout modèle du domaine existant, puis envisagez les informations nécessaires à la réalisation du cas d'utilisation. Distinguez toutefois les informations qu'il est préférable 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 frontières ou à des classes de contrôle, et enfin de celles qui ne sont tout simplement pas nécessaires à la réalisation du cas d'utilisation. Les informations répondant à ces critères ne doivent pas être modélisées en tant que classes entités. • Identifiez une classe frontière centrale pour chaque acteur humain et faites en sorte que cette classe représente la fenêtre principale de l'interface utilisateur avec laquelle dialoguera l'acteur. Si l'acteur dialogue déjà avec une classe frontière, envisagez de réutiliser cette classe afin d'assurer un bon niveau d'utilisation de l'interface utilisateur

mm

8

Mj

Analyse CHAPITRE

(annexe C) et de réduire le plus possible le nombre de fenêtres principales avec lesquelles chaque acteur aura besoin de dialoguer. Ces classes frontières centrales sont souvent considérées comme des agrégats de classes frontières plus primitives. • Identifiez une classe frontière primitive pour chaque classe entité détectée précédemment Ces classes représentent les objets logiques avec lesquels l'acteur (humain) dialoguera a travers l'interface utilisateur, pendant l'exécution du cas d'utilisation. Ces classes frontières primitives peuvent ensuite être affinées selon divers critères d'utilisabiliie et contribuer à la naissance d'une bonne interface utilisateur. • Pour chaque acteur système externe, identifiez une classe frontière centrale, dont voui ferez la représentante de l'interface de communication. Rappelez-vous qu'un aelein système peut représenter n'importe quel élément logiciel ou dispositif matériel imprimantes, terminaux, dispositifs d'alarme, capteurs, etc., en interaction avec le système en question. Si la communication système est répartie entre pln.su ni oJvMUX de protocoles, i l faudra peut-être que le modèle d'analyse ait la possibilité d'établi] une distinction entre certains de ces niveaux. Si c'est le cas, identifiez des classes l'ronliéres séparées pour chaque niveau d'intérêt. • Identifiez une classe de contrôle responsable de la gestion du contrôle et de la coordination de la réalisation 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 contrôle dans une classe frontière, en particulier si l'acteur assume une part importante de ce contrôle ; i l ne sera alors pas nécessaire de faire appel à une classe de contrôle. Dans d'autres cas, en revanche, le contrôle sera si complexe qu'il vaudra mieux l'encapsuler dans deux ou plusieurs classes de contrôle ; la classe de contrôle devra être scindée. Au cours de cette étape, les classes d'analyse du modèle d'analyse doivent, bien sûr, être prises en considération. Certaines sont susceptibles d'être réutilisées dans la réalisation de cas d'utilisation en cours, et plusieurs cas d'utilisation seront réalisés presque simultanément, ce qui facilitera la détection des classes d'analyse participant à plusieurs réalisations de cas d'utilisation. Réunissez les classes d'analyse participant à la réalisation d'un cas d'utilisation dans un diagramme de classes, qui vous permettra de montrer les relations existant au sein de cette réalisation. 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

Une fois que l'on dispose d'une ébauche des classes d'analyse nécessaires à la réalisai ion du cas d'utilisation, i l faut décrire 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 préférable de créer un diagramme de ciillahniaiiiui pour chacun de ces flots. La réalisation du cas d'utilisation n'en sera que plus claire et l elli option permettra d'extraire des diagrammes de collaboration représentant les inleiai i • générales et réutilisables.

• o n c h a î n e m e n t s d ' a c t i v i t é s principaux

nu II On crée un diagramme de collaboration en partant du début du flotdlll I I d'Utilisation pull en parcourant tout le flot étape par étape et en déterininani les intrrnt lions entre objets
EflfflH

8.6.3

Analyse WÊÊ CHAPITRE

8

Mm

Exigences particulières sur une réalisation de cas d'utilisation Parmi les exigences particulières imposées par la réalisation du cas d'utilisation Régier la facture, citons les suivantes : • la classe F a c t u r e doit être persistante ;

On notera les remarques ci-dessous au sujet du diagramme de collaboration,

• la classe G e s t i o n n a i r e de

• Le cas d'utilisation est invoqué par un message adressé par une instance d'acteur à un objet frontière. • Chaque classe d'analyse identifiée dans l'étape précédente doit posséder 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 réalisation du cas d'utilisation. • Les messages ne sont pas affectés à des opérations puisqu'on ne spécifie pas d'opération 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 récepteur et peut même devenir le nom de la responsabilité en question. • Il est souvent nécessaire que les liens figurant dans le diagramme soient des instances d'associations entre classes d'analyse. Soit ces associations existent déjà, soit les liens définissent la nécessité de telles associations. Toutes les associations manifestes doivent être esquissées à ce moment-là et représentées dans le diagramme de classes concernant la réalisation du cas d'utilisation.

commandes doit être capable de gérer

10 000 transactions à l'heure.

Lors de la formulation de ces exigences, référez-vous, si possible, aux exigences parti) u lières communes ayant pu être identifiées par l'architecte. Activité

: analyser

une

classe

L'objectif de l'analyse d'une classe (voir la figure 8.26) consiste : • à identifier et à actualiser les responsabilités d'une classe d'analyse, à partir du rôle qu'elle joue dans les réalisations de cas d'utilisation ; • à identifier et à actualiser les attributs et relations de la classe d'analyse ; • à formuler les exigences particulières pesant sur la réalisation de la classe d'analyse. Figure 8.26 Entrées et résultat de l'analyse d'une classe.

• La séquence indiquée dans le diagramme ne doit pas être le principal objet d'attention ; elle peut même être exclue si elle se révèle trop compliquée à maintenir ou si elle provoque un éclatement du diagramme. I l convient en revanche de s'intéresser particulièrement aux relations (liens) entre objets et aux besoins et exigences (tels qu'ils sont exprimés dans les messages) sur chaque objet individuel.

O D Ingénieur de composants Réalisation -analyse de cas d'utilisation ,-"7

• Le diagramme de collaboration doit prendre en compte toutes les relations du cas d'utilisation en cours de réalisation. Par exemple, si un cas d'utilisation A spécialise un cas d'utilisation B par le biais d'une relation de généralisation, le diagramme de collaboration réalisant le cas d'utilisation A devra probablement faire référence à la réalisation (par exemple, au diagramme de collaboration) du cas d'utilisation B.

Analyser une classe

Classe d'analyse [complète]

Û Classe d'analyse [ébauche] 8.6.3.1 Identification d e s

Il convient, dans certains cas, de compléter les diagrammes de collaboration par des descriptions textuelles, notamment si un grand nombre de diagrammes réalisent le même cas d'utilisation ou si certains diagrammes représentent des flots complexes. Ces descriptions textuelles doivent être intégrées au flot d'événements-analyse de la réalisation du cas d'utilisation. 8.6.2.3 Expression des exigences

responsabilités

Les responsabilités d'une classe peuvent être identifiées par l'association de tous les rôles qu'elle joue dans les différentes réalisations de cas d'utilisation, que l'on recensera en étU diant les diagrammes de classes et d'interaction de ces diverses réalisations. N'oubliai p l i non plus, que les exigences de chaque réalisation de cas d'utilisation par rapport a < . classes font parfois l'objet d'une description textuelle, contenue dans le flot d'événement analyse de la réalisation du cas d'utilisation.

particulières

Nous allons, dans cette étape, formuler toutes les exigences, telles que les exigences non fonctionnelles, pesant sur une réalisation de cas d'utilisation identifiée au cours de l'analyse et qui devront être prises en compte pendant la conception et l'implémentation.

fiflfflfl

R ô l e s des classes Les objets Facture sont créés pendant le cas d'utilisation Facturer l'acheteur. Le vendeur exécute ce cas d'utilisation pour demander à un acheteur de régler une commande (créée pendant le cas d'utilisation Commander des marchandises ou des services). Pendant l'exécution


II

du cas d'utilisation, la facture est transmise à l'acheteur, qui peut ensuit» dôckloi do la rôylm ou non. Le paiement est effectué au cours du cas d'utilisation Rpg 1er i ,i facture, dans lequel l'objet Échéancier programme le règlement d'un objet Facture. La facture est ensuite réglée et l'ob-

jet Facture est soldé. Notez cependant que la même instance de Facture participe à la fois aux cas d'utilisation Fac-

turer l'acheteur et Régler la facture. Il existe plusieurs moyens de synthétiser les responsabilités d'une classe. L'approche la plus simple consiste à extraire les responsabilités de chaque rôle, un par un, et à ajouter les responsabilités ainsi détectées ou à modifier les responsabilités existantes à partir d'une réalisation de cas d'utilisation à la fois. BlflfflH

Responsabilités des classes La classe Échéancier possède les responsabilités suivantes : • création d'une demande de règlement; • suivi des règlements programmés et envoi d'une notification lors de l'exécution ou de la suspension d'un règlement ; • déclenchement du transfert d'argent à la date d'échéance ; • notification d'une facture lors de son inscription à l'échéancier et une fois qu'elle a été réglée (c'est-à-dire acquittée).

8.6.3.2

Identification d e s

attributs

Les attributs spécifient les propriétés d'une classe d'analyse et sont souvent nécessités par les responsabilités d'une classe (telles qu'elles ont été évoquées 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 ] ; • souvenez-vous que les types d'attributs doivent être conceptuels en analyse et, si possible, ne pas être limités par l'environnement d'implémentation. Par exemple, « montant » conviendra pour l'analyse, tandis que son équivalent en conception pourra être « entier » ;

Analyse

tÊPf

cTiATrmËcTmm • les attributs des classes frontières dialoguant avec des acteurs humains représentent souvent des informations manipulées par les acteurs, comme des champs de texte étiquetés ; • les attributs des classes frontières dialoguant avec des acteurs système représentent souvent les propriétés d'une interface de communication ; • les classes de contrôle sont rarement dotées d'attributs en raison de leur courte durée de vie. Il leur arrive toutefois d'en avoir ; ils représentent des valeurs accumulées on dérivées au cours de la réalisation d'un cas d'utilisation ; • les attributs formels ne sont pas forcément indispensables. Une simple explication d'une propriété gérée par une classe d'analyse pourra suffire et figurer dans la description des responsabilités de la classe ; • si une classe présente des attributs trop nombreux ou trop complexes, elle peut être illustrée sous la forme d'un diagramme de classes séparé 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

agrégations

Les objets d'analyse dialoguent les uns avec les autres par l'intermédiaire des liens figurant dans les diagrammes de collaboration. Ces liens sont souvent des instances des associations reliant les classes correspondantes. L'ingénieur de composants doit, par conséquent, étudier les liens des diagrammes de collaboration afin de déterminer les associations nécessaires. Ces liens peuvent susciter le besoin de références et d'agrégations entre objets. Le nombre de relations entre classes doit être réduit le plus possible. I l ne s'agit pas, avant tout, de relations du monde réel devant être modélisées sous forme d'agrégations ou d'associations, mais de relations dont l'existence répond aux exigences des diverses réalisations d'un cas d'utilisation. L'analyse ne doit pas s'attarder sur la modélisation des meilleurs chemins de recherche à travers les agrégations ou les associations, qui sera mieux prise en charge par la conception et l'implémentation. L'ingénieur de composants définit également la multiplicité des associations, les noms de rôles, les associations récursives, les rôles ordonnancés, les rôles qualifiés 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 représentée par une association de multiplicité I " (il

• lorsque vous choisissez un type d'attribut, essayez d'en réutiliser un qui existe déjà ;

y a toujours au moins une commande associée à une facture) et par le nom de rôle <

• une même instance d'attribut ne peut être partagée par plusieurs objets d'analyse. Si le besoin s'en fait sentir, l'attribut doit être défini dans sa propre classe ;

MIIUV

à régler.

• 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 entités coulent de source. Si une classe entité remonte à une classe du domaine ou à une classe entité métier, les attributs de ces classes constituent des entrées intéressantes ;

r

'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 0 8.27

i-ji/rrure est la

Q

lunule de '"lient d'une ou isieurs mandes.

commando h riï(|lcn

û Facture

8.6.3.5

Expression des exigences

Mm

8

M/{

Analyse CHAPITRE

particulières

Nous allons, maintenant, procéder à l'expression de toutes les exigences d'une classe d'analyse identifiées au cours de l'analyse mais appelées à être gérées pendant la conception et l'implémentation (par exemple, les exigences non fonctionnelles). Veillez, pendant cette étape, à étudier les exigences particulières de la réalisation de cas d'utilisation, qui peuvent comprendre des exigences (non fonctionnelles) supplémentaires pour la classe d'analyse. BMH

Expression des exigences particulières concernant une classe d'analyse On pourrait qualifier de la façon suivante les caractéristiques des exigences de persistance concernant la classe Facture :

Il convient d'utiliser des agrégations lorsque les objets représentent : • intervalle de taille : de 2 à 24 kilo-octets par objet ;

• des concepts physiquement inclus les uns dans les autres, comme une voiture contient le conducteur et les passagers ;

• volume: jusqu'à 100

Identification des

généralisations

8.6.4

000;

• fréquence de mise à jour :

• des concepts constitués 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 père, d'une mère et des enfants. 8 . 6 . 3 . 4 Identification d e s

On utilise les généralisations au cours de l'analyse pour dégager les comportements communs et partagés entre différentes classes d'analyse. Ces généralisations doivent demeurer à un niveau élevé et conceptuel, et leur principal objectif doit être de faciliter la compréhension du modèle d'analyse. EfflH

création/suppression : 1 000 par jour ;

lecture : 1 accès à l'heure.

-

mise à jour : 30 mises à jour à l'heure ;

-

Lors de la formulation de ces exigences, référez-vous, si possible, aux exigences particulières communes ayant pu être identifiées par l'architecte. Activité

: analyser

un

paquetage

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 indépendant que possible des autres paquetages ;

généralisations

Les Factures et les Commandes ont des responsabilités semblables. Les unes et les autres sont

• s'assurer que ce paquetage d'analyse remplit sa mission, qui est de réaliser certaines classes du domaine ou certains cas d'utilisation ;

des spécialisations d'un objet Transacti on commerci al e plus général ; voir la figure 8.28. Iiro 8.28 rfiji!/ transaction f trciale ^j/i.vp

• décrire les dépendances afin que les effets de futurs changements puissent être estimés. Transaction commerciale

Voici quelques directives générales s'appliquant à cette activité :

les

• définissez et actualisez les dépendances du paquetage envers les autres paquetages dont les classes lui sont associées ;

, i\ oinmande

• assurez-vous que le paquetage contient les classes qui conviennent. Efforcez-vous de garantir la cohésion du paquetage en n'y incluant que les objets fonctionnellement liél • limitez les dépendances envers d'autres paquetages. Envisagez de reloger dans ces paquetages les classes trop dépendantes des autres paquetages.

Commande

Au cours de la conception, les généralisations seront ajustées afin qu'elles s'adaptent mieux à l'environnement d'implémentation, par exemple au langage de programmation. I l est possible que certaines généralisations disparaissent ; elles seront alors réalisées par d'autres relations telles que des associations.

I

J


II

lire 8.29 Titrées et

résultat

II / analyse d'un ~iut'tage.


Ô Ingénieur de composants

Analyser un paquetage

Paquetage d'analyse [complet]

Paquetage d'analyse [esquisse]

D é p e n d a n c e s de paquetages

Le paquetage Gestion des factures par le vendeur contient une Classe Traitement des factures associée à la classe Compte du paquetage Gestion des comptes, ce qui nécessite une dépendance correspondante entre les paquetages (voir la figure 8.30). Igurn 8.30

Gestion des factures par le vendeur I

ttnrndances

Gestion des factures par le vendeur |

ssnires entre triages.

Ô

Ô

Traitement des factures

Gestion des comptes

\

Traitement des factures |

Gestion des comptes J

\

\

Cû ompte

7

R é s u m é

de

l ' a n a l y s e

L'enchaînement d'activités de l'analyse (annexe C) aboutit à la création d'un modèle d'analyse. I l s'agit d'un modèle objet conceptuel qui analyse les besoins et les exigences en les affinant et en les structurant. Le modèle d'analyse comprend les éléments recensés cidessous. • Des paquetages d'analyse et de services, ainsi que leurs dépendances et leur contenu. Les paquetages d'analyse localisent les changements apportés à un processus métier, au comportement d'un acteur ou à un ensemble de cas d'utilisation étroitement liés. De leur côté, les paquetages de service localisent les changements apportés aux services

p

WL

8

Wfj

Analyse CHAPITRE

individuels fournis par le système et constituent un outil fondamental de préparation de la réutilisation pendant l'analyse. • Des classes d'analyse, leurs responsabilités, attributs, relations et exigences particulières Chacune des classes de contrôle, des classes entités et des classes frontières localisera les changements apportés au comportement (stéréotypé) et aux informations qu'elles représentent. Une modification de l'interface utilisateur ou de l'interface de communication sera généralement localisée dans une ou plusieurs classes frontières ; uneévolution des informations durables et souvent persistantes gérées par le système scia, an principe, localisée dans une ou plusieurs classes entités ; enfin, un changement allée taul li contrôle, la coordination, le séquencement, les transactions et, parfois, la logique inein i complexe impliquant plusieurs objets (frontières et/ou entités) sera habitiiellenienl localisé dans une ou plusieurs classes de contrôle. • Les réalisations-analyse de cas d'utilisation, qui décrivent la manière dont les cas d'utilisation sont précisés en termes de collaborations dans le modèle d'analyse et leurs exigences particulières. Les réalisations 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 réalisation devra également changer. • La vue architecturale du modèle d'analyse, avec ses éléments significatifs sur le plan architectural. La vue architecturale (annexe C) localisera les changements dans l'architecture. Comme nous allons le voir dans le chapitre suivant, le modèle d'analyse est considéré comme le principal document de travail des activités ultérieures de conception et d'implémentation. En utilisant le modèle d'analyse dans ce but, on préserve autant que possible la structure qu'il définit tout en procédant à la conception du système par la prise en compte de la majeure partie des exigences non fonctionnelles et des autres contraintes liées à l'environnement d'implémentation. Plus spécifiquement, le modèle d'analyse aura sur le modèle de conception le retentissement décrit ci-dessous. • Les paquetages d'analyse et de services auront, respectivement, une influence majeure sur les sous-systèmes de conception et de services, dans les couches spécifiques à l'application et générales à toutes les applications. Dans bien des cas, une relation de traçabilité un-à-un (isomorphe) liera les paquetages aux sous-systèmes correspondants. • Les classes d'analyse serviront de spécifications pour la conception des classes I a conception de classes d'analyse issues de différents stéréotypes réclamera des compétences et des technologies différenciées. Par exemple, la conception des classes entités nécessite souvent l'utilisation de bases de données, tandis que la conception de classes frontières exige plutôt l'exploitation de technologies d'interfaces utilisaleui Toutefois, les classes d'analyse et leurs responsabilités, leurs attributs et leurs relations servent d'entrée (logique) à la création des opérations, des attributs et des relations correspondants dans les classes de conception. De même, la plupart des exigences particulières 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 données ou d'interfaces utilisateur.

di hases

• Les réalisations-analyse de cas d'utilisation poursuivent deux uh|ei nr. | paiw l . un de ces objectifs est d'aider à la création de spécifications plus précises pont les i as d'utihsation. Au lieu de détailler chaque cas d'utilisation dans le modèle des, a-, d'utilisation par des diagrammes d'états-transitions ou des diagrammes d'activités, la description de chaque cas d'utilisation sous forme de collaboration entre classes d'analyse produira une spécification formelle complète des exigences du système I .es réalisations analyse de cas d'utilisation servent également d'entrées lors de la conception des cas d'utilisation. Elles facilitent l'identification des classes de conception devant participer aux réalisations-conception de cas d'utilisation correspondantes. Elles permettront également une première esquisse des interactions entre objets de conception. De même, la plupart des exigences particulières exprimées sur une réalisation-analyse de cas d'utilisation seront gérées par la réalisation-conception de cas d'utihsation correspondante lorsqu'il sera par exemple question de technologies de bases de données ou d'interfaces utilisateur. • La vue architecturale du modèle d'analyse constitue une entrée pour la création de la vue architecturale du modèle de conception. I l y a de fortes chances qu'une relation de traçabihté unisse les éléments des différentes vues (des différents modèles), car la notion de pertinence architecturale a tendance à se répandre à travers les modèles par le biais de dépendances de traçabihté.

9.1

C

o

n

c

e

p

t

i

9

o

n

Introduction

L'activité de conception consiste à façonner le système et à lui donner une forme (et une architecture) répondant à tous les besoins et exigences (y compris les exigences non fonctionnelles et autres contraintes) formulées à son endroit. Base fondamentale de la conception, le modèle d'analyse (voir le tableau 9.1) issu de l'analyse apporte une compréhension détaillée des besoins et des exigences. Mais surtout, i l impose au système une structure qu'il faudra s'efforcer autant que possible de conserver lors de l'élaboration du système (voir le chapitre 8, section 8.2). Pour être plus précis, énumérons les objectifs de la conception :

R é f é r e n c e s 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 ,

1

Object-Oriented Software Engineering:

A Use-Case Driven Approach, Reading, MA,

Addison-Wesley, 1992 (quatrième édition révisée, 1993).

• acquérir une compréhension approfondie des questions concernant les exigences non fonctionnelles et les contraintes liées aux langages de programmation, à la réutilisation des composants, aux systèmes d'exploitation, aux technologies de distribution, de concurrence, de bases de données, d'interfaces utilisateur, de gestion des transactions, etc. ;

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-

2

Oriented Modeling and Design, Englewood Cliffs, NJ, Prentice Hall, 1991. 3

OMG Unified Modeling Language Spécification, Object Management Group, Framingham, MA, 1998. Internet : www.omg.org.

• constituer une base et un point de départ aux activités subséquentes d'implémentation en formulant les exigences pesant sur chaque sous-système individuel, sur les interfaces et sur les classes ; • décomposer le travail d'implémentation en portions plus gérables, prises en charge pin plusieurs équipes de développement, éventuellement en parallèle. Celle possibilité se révèle utile dans les cas où la décomposition ne peut se fonder sur les résultats de l'expression des besoins (et du modèle des cas d'utilisation) ou de l'analyse (et du moileli d'analyse). I l s'agit, par exemple, des cas où l'implémentation de ces résultats ne peut êin directe ; • déterminer, très tôt dans le cycle de vie du logiciel, les principales interfaces entre soussystèmes. Tout l'intérêt de cette démarche apparaît lorsqu'il s'agit de réfléchir à

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

l'architecture et d'utiliser les interfaces comme instruments de synchronisi différentes équipes de développement ;

i

les

• visualiser et penser la conception à l'aide d'une notation commune ;

Figure 9.2 Point de convergence de la conception.

• créer une abstraction transparente de l'implémentation du système, au sens < m l'implémentation 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 génération de code ou le round-trip engineering entre la conception et l'implémentation.

Conception CHAPITRE

9

Phases Enchaînements d ' a c t i v i t é s principaux Besoins

Nous présenterons, dans ce chapitre et dans les suivants, les moyens d'atteindre ces objectifs. Notre approche de l'enchaînement d'activités de la conception est identique à celle adoptée pour l'enchaînement d'activités de l'analyse (voir la figure 9.1). y.1 Heurs et M impliqués , onception.

D

D Ingénieur de cas d'utilisation

Itérations préliminaires

responsable de

jter. #1

iter. #2

iter. #n

iter. #n+1

Iter. #n+2

Iter. Il m

Iter. #m+1

Itérations


Description Réalisation-conception Classe Sous-système de l'architecture de cas d'utilisation de conception de conception

Interface

9.3

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

A r t e f a c t s

Artefact

: modèle

de

conception

Le modèle de conception est un modèle objet décrivant la réalisation physique des cas d'utilisation en s'attachant aux effets conjugués des exigences fonctionnelles et non fonctionnelles et des autres types de contraintes sur le système en question. En outre, i l tient heu de vision abstraite de l'implémentation du système et constitue par conséquent une entrée majeure pour les activités d'implémentation.

logiciel

Durant les itérations de la fin de l'élaboration et celles du début 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 crée un plan d'élaboration et de construction pour le modèle d'implémentation. 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'implémentation.

Le modèle de conception définit une hiérarchie, comme l'illustre la figure 9.3. Enfin, le modèle de conception est représenté par un système de conception illustrant le sous-système de plus haut niveau du modèle. L'utilisation d'autres sous-systèmes offre ensuite un moyen de découper le modèle de conception en parties plus gérables.

Le modèle de conception étant très proche de l'implémentation, il est naturel de le conserver et de l'actualiser tout au long du cycle de vie du logiciel. Ceci se vérifie particulièrement dans le cadre du round-trip engineering, où le modèle de conception peut servir de visualisation à l'implémentation et de support aux techniques de programmation graphique.

Les sous-systèmes et les classes de conception constituent des abstractions (annexe C) des sous-systèmes et des composants de l'implémentation du système. Ces abstractions sont directes et représentent une correspondance simple entre la conception et rimplémcnlation Dans le modèle de conception, les cas d'utilisation sont réalisés par les classes de concept u m et leurs objets. Ces réalisations sont figurées par des collaborations dans le modelé de cou ception et signalées par l'expression réalisations-conception de cas d'utilisation. Note/ la distinction entre la réalisation-conception de cas d'utilisation et la réalisation-analyse de cas d'utilisation : la première décrit la réalisation du cas d'utilisation par des interactions entre objets de conception, tandis que la seconde la décrit par des interactions entre objets d'analyse. Les artefacts du modèle de conception sont présentés en détail dans les sections qui suivent.

| • » e n c h a î n e m e n t s d ' a c t i v i t é s principaux

Conception CHAPITRE

tu :i t'iii'ii est une H Itie de sous-

NH de llillrIM


Système de conception

Sous-système de conception

M* Hun, des

9

mm

la classe en question. On peut ainsi différer les décisions qui n'ont pas lieu d'être tranchées dans le modèle de conception, par exemple celles concernant le codage de la classe. • Une classe de conception se voit souvent attribuer un stéréotype 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 stéréotypée en tant que «module de classe », « formulai re », « contrôle u t i l i s a t e u r » , etc. • Une classe de conception peut réaliser, et par conséquent fournir, des interfaces, si cell M justifie dans le langage de programmation. Par exemple, une classe de conception représentant une classe Java pourra fournir une interface.

iinti de cas iiiiim et des PS.

Classe de conception

Artefact

: c l a s s e

d e

Réalisation-conception de cas d'utilisation

Interface

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'implémentation du système (voir la figure 9.4). Le sens de la « transparence » de cette abstraction est expliqué ci-dessous. • La spécification d'une classe de conception utilise le même langage que le langage de programmation, si bien que les opérations, paramètres, attributs, types, etc., sont spécifiés à l'aide de la syntaxe du langage de programmation choisi. • La visibilité des attributs et des opérations d'une classe de conception est souvent précisée. Par exemple, l'usage des mots-clés public, protected ou private est fréquent en C++. • Les relations liant une classe de conception à d'autres classes trouvent souvent une signification directe lors de l'implémentation de la classe. Par exemple, la généralisation, ou tout stéréotype de généralisation, emprunte une sémantique correspondant à la signification de la généralisation (ou de l'héritage) dans le langage de programmation. Ce qui signifie qu'il existe souvent, entre les associations - ou les agrégations - et les variables (attributs) des classes de l'implémentation, une correspondance fournissant des références entre objets.

Figure 9.4

• Une classe de conception peut être active, ce qui implique que les objets de celle classe maintiennent leur propre thread de contrôle et s'exécutent en même temps que il ; objets actifs. Mais, en principe, les classes de conception ne sont pas actives : leurs objet! « s'exécutent » dans l'espace d'adressage et sous le contrôle d'un autre objet actif. Là encore, la sémantique détaillée exprimant ce fait dépend du langage de programmation cl des technologies de gestion de la concurrence et de la distribution utilisées. Notez qu'une différence significative existe entre la sémantique des classes actives de celle des autres classes. En vertu de cette différence, les classes actives pourraient tout aussi bien résider dans leur propre modèle de processus au lieu de figurer dans le modèle de conception. Une telle répartition convient dans les cas où les classes actives sont nombreuses et où leurs objets entretiennent des interactions complexes, par exemple dans certains systèmes temps réel. >

Attributs clés et associations d'une classe de

|zzj

—


conception.

Interface r é a l i s e r

relations méthodes exigences d'implémentation est active : {true, false}

Tableau 9.1 : Brève comparaison des modèles d'analyse et de conception.

• Les méthodes (c'est-à-dire les réalisations des opérations) d'une classe de conception présentent des liens directs avec les méthodes correspondantes dans l'implémentation de la classe (c'est-à-dire le code). Si les méthodes sont spécifiées en conception, elles le sont généralement en langue naturelle ou en pseudo-code, et peuvent ainsi servir d'annotations à l'implémentation des méthodes. C'est l'une des principales abstractions entre conception et implémentation, assez peu usitée, cependant, puisque nous recommandons de confier au même développeur la conception et l'implémentation d'une classe (voir la section 9.4.3).

[

• Une classe de conception peut retarder la prise en compte de certaines exigences aux activités ultérieures d'implémentation en les qualifiant d'exigences d'implémentation sur

Non générique, mais spécifique à une implémentation.

Générique à ia conception (applicable à plusieurs conceptions).

Modèle physique, puisque c'est un plan d'élaboration et de construction de l'implémentation.

Modèle conceptuel, car c'est une abstraction du système qui évite les questions d'implémentation.



I *< mu ii.niioments d ' a c t i v i t é s principaux

Conception CHAPITRE

Façonne le système tout en s'efforçant de préserver autant que possible la structure définie par le modèle d'analyse.

Définit une structure constituant une base essentielle pour la création du système (y compris pour la création du modèle de conception).

Doit être conservé tout au long du cycle de vie du logiciel.

Risque de ne pas être conservé tout au long du cycle de vie du logiciel.

Émerge principalement de la « programmation visuelle » dans les environnements de round-trip engineering ; on effectue des allers-retours entre le modèle de conception et le modèle d'implémentation (décrit dans le chapitre 10).

( merge principalement d'un véritable « marathon » entre les ateliers et les divers lieux de réflexion.

Exprime la conception du système, y compris de son architecture (une de ses vues).

Irace les grandes lignes de la conception du système, y compris de son architecture.

Dynamique (mais s'intéresse beaucoup à la séquence).

Dynamique (mais s'attache peu à la séquence).

Nombreuses couches.

l'un de couches.

Plus coûteux à développer (ratio de 5 à 1 par rapporta l'analyse).

Moins coûteux à développer.

Plus formel.

Moins formel.

Autant de stéréotypes (physiques) de classe que le permet le langage d'implémentation.

Imis stéréotypes (conceptuels) de classe : « de i ml rôle », « entité » et « frontière ».



9.3.3

Artefact

Classe de conception Facture

montant: Argent date de règlement: Date date d'émission: Date

: réalisation-conception

Modèle d'analyse

^ solde: Argent

9

mm

d'utilisation


_ _. JWc Réalisation-analyse de cas d'utilisation

Figure 9.7 Compte compte à créditer 1

titulaire: TypeTitulaire

+créer (montant: Argent, dateDeRèglement: Date) remettre (acheteur: TypeAcheteur) •^-planifier (échéance: Date) +solder()

d e c a s

Une réalisation-conception de cas d'utilisation est une collaboration du modèle de conception qui décrit la réalisation et l'exécution d'un cas d'utilisation spécifique par des classes de conception et les objets qui les composent. Une réalisation-conception de cas d'utilisation offre une traçabilité directe avec une réalisation-analyse de cas d'utilisation issue du modèle d'analyse (voir la figure 9.6). On peut donc faire remonter une réalisation conception de cas d'utilisation à un cas d'utilisation dans le modèle des cas d'utilisation pai le biais de la réalisation-analyse du cas d'utilisation. Figure 9.6 // existe des relations de traçabilité entre les réalisations de cas d'utilisation des différents modèles.


Dans les cas où le modèle d'analyse ne sera pas conservé tout au long du cycle de vie du logiciel mais ne servira qu'à créer une conception satisfaisante, i l n'y aura pas de réalisations-analyse de cas d'utilisation ; la dépendance de traçabilité d'une réalisation-conception de cas d'utilisation mènera directement au cas d'utilisation dans le modèle des cas d'utilisation. Une réalisation-conception de cas d'utilisation comporte une description textuelle de flot d'événements, des diagrammes de classes décrivant les classes de conception y participant et des diagrammes d'interaction décrivant la réalisation d'un flot ou d'un scénario précis du cas d'utilisation en termes d'interactions entre objets de conception (voir la figure 9.7). Si nécessaire, les diagrammes peuvent également décrire les sous-systèmes et les interfaces impliqués dans la réalisation du cas d'utilisation (c'est-à-dire les sous-systèmes contenant les classes de conception y prenant part).

La figure 9.5 illustre la classe de conception Facture telle qu'elle a été élaborée en conception. L'attribut compte, suggéré lors de l'analyse, a été transformé en association avec une

classe Compte. Facture

in 'u Facture t attributs et Unis et une iiu'ii reliant i n Facture Iris ( 'ompte.

,'""""->

Attributs clés et . associations dune réalisationconception de cas

' Réalisation-conception de cas d'utilisation d'événements-conception diagrammes de classes diagrammes d'interaction exigences d'implémentation

, l o t

d utilisation.

larticipant


\t


I ns e n c h a î n e m e n t s d ' a c t i v i t é s principaux

PARTIE II Une réalisation-conception de cas d'utilisation fournit une réuliNiillon physique de In rénli sation-analyse de cas d'utilisation à laquelle elle csl liée pui une relation d, liaeiibllité, ci prend en compte la plupart des exigences non fonctionnelles (c'est a due des exigences pai ticulières) définies sur cette dernière. 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, différer la prise en compte de certaines exigences aux activités d'implémentation en les qualifiant d'exigences d'impie mentation dans la réalisation. 9.3.3.1

Diagrammes de c l a s s e s

Une classe de conception et les objets qu'elle comporte - et, par conséquent, le soussystème contenant la classe en question - participent souvent à plusieurs réalisations de cas d'utilisation. I l se peut également que certaines opérations, certains attributs et certaines associations d'une classe en particulier ne soient pertinents que pour une seule réalisation de cas d'utilisation. I l est donc important de coordonner toutes les exigences qu'imposent les différentes réalisations de cas d'utilisation sur une classe et ses objets, mais aussi sur le soussystème la contenant. On emploie à cet effet des diagrammes de classes associés à une réalisation de cas d'utilisation, montrant les classes les sous-systèmes qui y participent et leurs relations. Ceci permet de garder la trace des éléments prenant part à une réalisation 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 séquence d'actions d'un cas d'utilisation débute lorsqu'un acteur invoque celui-ci en adressant au système un message sous une forme quelconque. Considérons l'« intérieur » du système : un objet de conception recevra ce message de la part de l'acteur. Puis cet objet appellera un autre objet, afin que les objets impliqués dialoguent entre eux et exécutent le cas d'utilisation. On préférera, en conception, retracer cette interaction par le biais d'un diagramme de séquence, puisque l'on s'attache avant tout à détecter les séquences d'interactions détaillées et chronologiques. Dans certains cas, ces diagrammes de séquence indiqueront en outre les sous-systèmes qui prennent part à la réalisation d'un cas d'utilisation et, éventuellement, les interfaces fournies (c'est-à-dire réalisées) par ces sous-systèmes. Cette option permet de concevoir les cas d'utilisation à un niveau élevé, avant de développer la conception interne des sous-systèmes participants ; elle est utile lorsqu'il s'agit, par exemple, d'identifier les interfaces des sous-systèmes tôt dans le cycle de vie du logiciel, avant que leur conception interne ne soit mise au point. Les diagrammes de séquence représentent les interactions entre objets par des échanges de messages entre les lignes de vie d'objets ou de sous-systèmes. On parle de la « réception » d'un message par une ligne de vie de sous-système pour signifier que c'est en fait un objet d'une classe contenue dans ce sous-système qui reçoit le message. De même, lorsqu'un message est « envoyé » depuis la ligne de vie d'un sous-système, c'est en réalité un objet d'une classe contenue dans ce sous-système qui l'envoie. Le nom d'un message doit indiquer une opération de l'objet invoqué ou d'une interface fournie (réalisée) par l'objet.

9.3.3.3

Conception mm CHAPITRE

9

Mm

Flot d ' é v é n e m e n t s - c o n c e p t i o n

Les diagrammes décrivant une réalisation de cas d'utilisation sont souvent difficiles à déchiffrer, en particulier les diagrammes d'interaction. C'est pourquoi les flots d'événements-conception, qui proposent une description textuelle éclairant et complétant les dia grammes et leurs étiquettes, peuvent apporter un secours précieux. Le texte doit évoquer les objets qui dialoguent entre eux pour exécuter le cas d'utilisation ou les sous-systèmes IJUI \ prennent part. Cette description ne doit pas, cependant, faire mention des attributs, Opéra tions ou associations des objets : elle en deviendrait difficile à actualiser étant donne l< caractère changeant des attributs, opérations 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 réduire au strict minimum la mv< u, d'actualiser la description du flot d'événements-conception si les dlagîl 61 de. m notamment les opérations apparaissant sur les messages des diagrammes d'inlcu viennent à être modifiés. Les flots d'événements-conception montrent tout leur intérêt lorsqu'une même réalisation de cas d'utilisation est décrite par un grand nombre de diagrammes de séquence ou lorsque certains diagrammes représentent des flots complexes. I l convient de noter les remarques suivantes : • le flot d'événements-conception d'une réalisation de cas d'utilisation n'étant pas local à un diagramme de séquence en particulier, on peut l'utiliser pour décrire 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 séquence ne sont pas locales à ce diagramme. Toutefois, un trop grand nombre d'étiquettes risque de créer une certaine confusion. I l peut être préférable, dans ce cas, d'inclure le texte de certaines étiquettes dans le flot d'événements-conception. Si l'on utilise à la fois un flot d'événements-conception et des étiquettes, i l faut qu'ils se complètent. Vous trouverez des exemples de description de flots d'événements-conception dans la section 9.5.2.2. 9.3.3.4

Exigences

d'implémentation

Les exigences d'implémentation sont présentées 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 exprimées en conception, mai' qui seront mieux prises en charge lors de l'implémentation. Certaines de ces exigences ont déjà pu être formulées dans les enchaînements d'activités précédents ; il ne reste a loi s qu i les transformer en réalisation de cas d'utilisation. Mais i l arrive aussi que le ii.iv.nl de < mi ception en fasse apparaître de nouvelles. Vous trouverez des exemples d'exigences d'implémentation sur des réalisations CODI eption de cas d'utilisation dans la section 9.5.2.5.

Vous trouverez des exemples de ce type de diagramme d'interaction dans la section 9.5.2.2.

9.3.4


PARTIE II

Artefact

: s o u s - s y s t è m e

d e

conception

Les sous-systèmes de conception offrent un moyen d'agcnei i li ni im i .lu modèle de conception en portions plus gérables (voir la ligure ').«). I In IOUI IVItèfflC peut se composer de classes de conception, de réalisations de cas d'utilisalion, d'intérim es cl d'aunes sous systèmes (de façon récursive), mais il peut aussi fournir des Interfaces représentant If. loue tions qu'exportent celles-ci en termes d'opérations.

I

Conception J K V V B CHAPITRE 9 K À U Figure 9.8

Contenu d'un soussystème et associations clés.

Chaque sous-système doit montrer de la cohésion : les éléments qui le composent doivent être fortement liés. I l faut aussi que les sous-systèmes soient faiblement couplés : les dépendances qui les unissent à leurs homologues ou à leurs interfaces respectives doivent être réduites au strict minimum. Ces sous-systèmes de conception doivent, en outre, présenter les caractéristiques décrites cidessous. • Les sous-systèmes peuvent représenter une segmentation des questions de conception. Par exemple, dans un vaste système, certains sous-systèmes pourront être conçus séparément, et éventuellement en parallèle, par plusieurs équipes de développement ayant différentes compétences de conception.


9.3.4.1

• Les deux couches supérieures de l'application et leurs sous-systèmes dans le modèle de conception ont souvent une traçabilité directe avec des paquetages d'analyse et/ou des classes d'analyse.


Interfaco

S o u s - s y s t è m e s de service

On utilise les sous-systèmes de service à un niveau inférieur de la hiérarchie des sous sys tèmes de conception pour la même raison que l'on utilise les paquetages de service dans le modèle d'analyse : afin de préparer les changements intervenant dans chaque service en localisant ces modifications au sous-système de service correspondant. Pour revenir plus en détail sur la notion de service, consultez la section 8.4.4.1 du chapitre 8.

• Les sous-systèmes peuvent représenter des composants à plus large granularité dans l'implémentation du système ; c'est-à-dire que les composants fournissant plusieurs interfaces sont créés à partir de plusieurs autres composants à granularité plus fine, comme ceux qui spécifient les classes d'implémentation individuelles, et se manifestent sous forme d'exécutables, de binaires ou d'entités semblables pouvant être déployés sur différents nœuds.

L'identification des sous-systèmes de service repose sur les paquetages de service du modèle d'analyse, auxquels ils sont généralement liés par une traçabilité un-à-un (isomorphe). Les sous-systèmes de service sont donc plus répandus dans les deux couches supérieures (la couche spécifique à l'application et la couche générale aux applications), mais ils ont plus de problèmes à gérer que leurs homologues paquetages de service, parce que :

• Les sous-systèmes peuvent représenter des produits logiciels réutilisés en les emballant (wrap) et accompagner la réflexion sur l'intégration de ce type de produits dans le modèle de conception. Ces sous-systèmes résident dans les couches de middleware et de logiciel système.

• i l est possible que les sous-systèmes de service aient besoin de fournir leurs services en termes d'interfaces et d'opérations ; • les sous-systèmes de service contiennent des classes de conception et non des classes d'analyse : ils traitent par conséquent de nombreuses exigences non fonctionnelles et d'autres contraintes liées à l'environnement d'implémentation. Ils ont donc tendance a contenir un plus grand nombre de classes que leurs homologues paquetages de service el il peut être nécessaire de les décomposer à leur tour en sous-systèmes (plus modestes ) pour en gérer la taille ;

• Les sous-systèmes peuvent représenter des systèmes hérités en les emballant (totalement ou partiellement) et permettre l'intégration de systèmes existants dans le modèle de conception. La section 9.5.1.2 fournit de plus amples informations sur les sous-systèmes et leur utilisation, et propose une méthode permettant de les identifier ainsi que leurs interfaces.

• un sous-système de service conduit souvent à un composant binaire ou exécutable •lin l'implémentation. Dans certains cas, i l faudra toutefois diviser ce sous système, et le déploiement de chacune de ses parties sur différents nœuds pourra implique! la ne.. Il d'un composant binaire ou exécutable pour chaque nœud. Il faudra peut être a loi' décomposer à nouveau le sous-système de service en sous-systèmes (plus petits) alui qn< chacun encapsule la fonction déployée sur un nœud spécifique. Vous trouverez des exemples de sous-systèmes de service dans la section 9.5.1.2.

I


PARTIE II Notez que l'on utilise encore, d'une manière générale, les • •. sysiêim ,1, eiviee ordi naires pour agencer les artefacts du modèle de conceptii m. couiinr l'évoqui In si cl précé dente. Toutefois, nous introduisons ici un stéréotype >• '.nie, syslèinr î l e M-I v h .• » pont indiquer explicitement que ces sous-systèmes représentent d e s services Celte possibilité dévoile tout son intérêt dans les systèmes d'envergure (comprenant d e nombreux sous sys tèmes) et permet de différencier facilement les divers types de sous systèmes kappelczvous que le même raisonnement vaut pour le stéréotype « paquetage de service », Introduit au chapitre 8. - 3.5

Artefact

:

interface

Les interfaces permettent de spécifier les opérations fournies par les classes et les sous-systèmes de conception (voir la figure 9.9).

9.3.6

Artefact d e

: description

d e

l'architecture

(vue

d u

Conception CHAPITRE

9

ma

m o d è l e

c o n c e p t i o n )

La description de l'architecture contient une vue architecturale du modèle de conception (annexe C), dont elle décrit les artefacts significatifs sur le plan architectural (figure 9.10). Figure 9.10

B,

La description de , . l architecture contient une vue architecturale modèle

d

e

_ =l Description |. ecture archit

vue architecturale

du

de

conception.

luure 9.9


fgocUttions clés f interface.

Les artefacts suivants sont normalement considérés comme significatifs architectural :

sur le plan

• la décomposition du modèle de conception en sous-systèmes, avec leurs interfaces et les dépendances les reliant. Cette décomposition est particulièrement significative pour l'architecture en général, puisque ce sont les sous-systèmes et leurs interfaces qui échafaudent la structure fondamentale du système ;


• les classes de conception clés, 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 générales et centrales, celles qui représentent des mécanismes génériques de conception et qui entretiennent de nombreuses relations avec les autres classes de conception. En principe, i l est suffisant de considérer comme importante sur le plan architectural une classe abstraite, en laissant de côté ses sous-classes, à moins que cellesci ne manifestent un comportement intéressant pour l'architecture, indépendamment de leur classe abstraite ;

Une classe de conception fournissant une interface doit également procurer les méthodes qui en réaliseront les opérations. Un sous-système fournissant une interface doit aussi contenir les classes de conception et les autres sous-systèmes (de façon récursive) qui fournissent cette interface.

1

Les interfaces offrent un moyen de séparer la spécification des fonctions par des opérations de leur implémentation par des méthodes. Cette séparation libère chaque client dépendant, ou utilisateur, d'une interface donnée de l'implémentation de cette interface. On peut, dès lors, remplacer l'implémentation spécifique d'une interface (une classe ou un sous-système de conception) par une autre implémentation sans avoir à modifier le client.

• les réalisations-conception de cas d'utilisation qui réalisent certaines fonctions importantes et stratégiques devant être développées tôt 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-systèmes, ou enfin celles qui impliquent des classes de conception clés répondant aux critères énonces précédemment On trouvera, normalement, les cas d'utilisation correspondants dans lu vue a n i m e , lui il. du modèle des cas d'utilisation et les réalisations-analyse de cas d'utilisation 01 dans la vue architecturale du modèle d'analyse.

La plupart des interfaces entre sous-systèmes sont considérées comme significatives sur le plan architectural parce qu'elles définissent les conditions d'interaction entre les sous-systèmes. Dans certains cas, il est également utile d'esquisser des interfaces stables très tôt dans le cycle de vie du logiciel, avant que les fonctions représentées ne soient implémentées par les sous-systèmes. Ces interfaces peuvent alors être considérées comme des exigences par les équipes de développement chargées de concevoir les sous-systèmes et servir d'instruments de synchronisation entre les différentes équipes susceptibles de travailler en parallèle sur plusieurs sous-systèmes [2]. La section 9.5.1.2 fournit de plus amples informations sur les interfaces et leur utilisation, et propose une méthode permettant de les identifier.

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 modèle de conception. 1. Si les classes actives devaient résider dans leur propre modèle de processus (comme nous l'avons liui rinwqui i plus haut), ellesfigureraientalors dans la vue architecturale du modèle 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

''Artefact

: m o d è l e

d e

d é p l o i e m e n t

9.3.8

Le modèle de déploiement est un modèle objet qui décrit la distribution physique du système en montrant la répartition des fonctions sur les différents nœuds de calcul du réseau (voir la figure 9.11). I l constitue une entrée essentielle aux activités de conception et d'implémentation, puisque la distribution du système a une influence majeure sur sa conception.

Artefact d e

: d e s c r i p t i o n

d e

de


ment nœuds.

l'architecture

(vue

d u

Conception CHAPITRE

9

HU

m o d è l e

d é p l o i e m e n t )

La description de l'architecture contient une vue architecturale du modèle de déploiement (annexe C), dont elle décrit les artefacts significatifs sur le plan architectural (figure 9.12). Figure 9.12

..'tu '"èle \ des

0

pu

La description de ,, ... , l architecture contient une vue architecturale modèle

Description de l'architecture vue architecturale

du

de

déploiement. *

O

Nœud


On peut formuler les remarques suivantes à propos du modèle de déploiement : En raison de son importance, tous les aspects du modèle de déploiement doivent apparaître dans la vue architecturale, y compris la répartition des composants sur les nœuds telle qu'on la trouve dans l'implémentation.

• chaque nœud représente une ressource de calcul, souvent un processeur ou une unité matérielle de ce type ; • des relations entre les nœuds représentent les moyens de communication qui les relient, tels qu'Internet, intranet, bus, etc. ;

La section 9.5.1.1 propose des exemples de ce qui peut figurer dans la vue architecturale du modèle de déploiement.

• le modèle de déploiement peut décrire plusieurs configurations réseau différentes, y compris les configurations de test et de simulation ; • Les fonctions (ou processus) d'un nœud sont définies par les composants déployés sur ce nœud ; • le modèle de déploiement lui-même manifeste une correspondance entre l'architecture logicielle et l'architecture système (le matériel).

9.4

9.4.1

Travailleurs

Travailleur

:

a r c h i t e c t e

Pendant la conception, l'architecte est responsable de l'intégrité des modèles de conception et de déploiement, et doit s'assurer que chacun de ces modèles est correct, cohérent et lisible (voir la figure 9.13). Comme pour le modèle d'analyse, i l est possible, dans le cas de systèmes vastes et complexes, qu'un autre travailleur reprenne à son compte la responsabilité du sous-système de niveau supérieur du modèle de conception (c'est-à-dire le système de mu ception).

Vous trouverez des exemples de modèle de déploiement dans la section 9.5.1.1.

Les modèles sont jugés corrects lorsqu'ils réalisent les fonctions décrites dans le modèle des cas d'utilisation - e t uniquement celles-là - , les exigences supplémentaires et I. iim.l.l. d'analyse. L'architecte a également la charge de l'architecture des modèles de conception I I .1. déploiement, c'est-à-dire de l'existence de leurs parties significatives sur le plan au luie. tural telles qu'elles sont décrites parles vues architecturales des modèles. N'oublie/ pas qui ces vues font partie de la description de l'architecture du système.


ire 9.13 nmsabilités

de

architecte au Mrs de la

Figure 9.14 Responsabilités l'ingénieur

de

de cas

d'utilisation au cours de la

eption.

Conception CHAPITRE

9

O D Ingénieur de cas d'utilisation I

conception. responsable de

V Réalisation-conception de cas d'utilisation

9.4.3

Travailleur

vue architecturale


d e

c o m p o s a n t s

L'ingénieur de composants définit et actualise les opérations, méthodes, attributs, relut s cl exigences d'implémentation d'une ou plusieurs classes de conception, cl s'assuic que chacune satisfait aux exigences formulées à son endroit à partir des réalisations de cas d'un lisation auxquelles elle prend part (voir la figure 9.15).

Description de l'architecture Figure 9.15

Notez que l'architecte n'est pas chargé du développement continu et de l'actualisation des divers artefacts du modèle de conception, qui sont du ressort des ingénieurs de cas d'utilisation et de composant concernés (voir les sections 9.4.2 et 9.4.3).

O

Responsabilités l'ingénieur

O

de

de

composants


au

cours de la conception.

".2

Travailleur


d e c a s d'utilisation

L'ingénieur de cas d'utilisation veille à l'intégrité d'une ou de plusieurs réalisations-conception de cas d'utilisation et s'assure que celles-ci satisfont aux exigences les concernant (voir la figure 9.14). Une réalisation-conception de cas d'utilisation doit réaliser correctement le comportement de la réalisation-analyse de cas d'utilisation qui lui correspond dans le modèle d'analyse - et uniquement ce comportement-ci - , ainsi que le comportement du cas d'utilisation correspondant dans le modèle des cas d'utilisation.

_ m



O Interface

L'ingénieur de composants peut également veiller à l'intégrité d'un ou de plusieurs soussystèmes, c'est-à-dire s'assurer que leur contenu (par exemple, des classes et leurs relations) est juste, que leurs dépendances vis-à-vis d'autres sous-systèmes et/ou interfaces sont correctes et réduites au strict minimum, et enfin qu'ils réalisent correctement les interfaces qu'ils fournissent.

Ceci suppose de rendre parfaitement lisibles et conformes à leur objectif la totalité des descriptions textuelles et des diagrammes décrivant la réalisation de cas d'utilisation. Notez que l'ingénieur de cas d'utilisation n'est pas chargé des classes de conception, des sous-systèmes, interfaces et relations employés dans la réalisation d'un cas d'utilisation, qui sont de la responsabilité de l'ingénieur de composants concerné.

il

Il sera bien venu, en général, de confier à l'ingénieur de composants chargé d'un sous système la responsabilité des éléments de modèle que contient celui-ci. D'autre part, poui instaurer un développement fluide et transparent, i l semble naturel que les artefacts du modèle de conception (par exemple, les classes et les sous-systèmes de conception) soient menés jusqu'à l'enchaînement d'activités de l'implémentation et implémentés pai le iiit'inc ingénieur de composants.

J t.5


II

E n c h a î n e m e n t d ' a c t i v i t é s

Nous avons décrit, précédemment dans ce chapitre, le travail de eonceplion en lermel M.I tiques. Nous allons maintenant employer un diagramme d'activités pour eu ex; ci le comportement dynamique (voir la figure 9.16).

•

Figure 9.16 Enchaînement activités de la meeption, avec 1rs travailleurs y prenant part et tirs activités.

O

O

Architecte

Conception CHAPITRE

249

• les classes de conception significatives sur le plan architectural, telles que les classes actives ; • les mécanismes de conception génériques prenant en charge les exigences communes (par exemple, les exigences particulières de persistance, de distribution, de performances, etc.) telles qu'elles ont été formulées au cours de l'analyse à travers les classes d'analyse et les réalisations-analyse de cas d'utilisation. Figure 9.17 Entrées de la

O

et

résultat

conception

architecturale.

Modèle \ des cas d'utilisation "«

O

O

Architecte

O

Ingénieur de cas d'utilisation Conception „ , ârchitecturale '

Concevoir un sous-système

'Sous-système [esquisse] Interface [esquisse]


o D Ingénieur de composants

Classe de conception [esquisse]

Modèle d'analyse \e de déploiement [esquisse]

La création des modèles de conception et de déploiement (tels qu'ils ont été définis plus haut dans ce chapitre) est mise en route par les architectes, qui esquissent les nœuds du modèle de déploiement et suggèrent les principaux sous-systèmes et leurs interfaces, les classes de conception importantes (y compris les classes actives) et les mécanismes de conception génériques du modèle de conception. Les ingénieurs de cas d'utilisation réalisent ensuite chaque cas d'utilisation sous forme de classes et/ou de sous-systèmes de conception avec leurs interfaces. Les réalisations issues de cette phase expriment des exigences de comportement pour chaque classe ou chaque sous-système prenant part aux réalisations de cas d'utilisation. Ces exigences sont ensuite spécifiées par les ingénieurs de composants et intégrées dans chaque classe, soit par la création d'opérations, d'attributs et de relations cohérents sur chaque classe, soit par la création d'opérations cohérentes sur chaque interface fournie par le soussystème. Tout au long de l'enchaînement d'activités de la conception, les développeurs identifieront des candidats à la formation de nouveaux sous-systèmes, interfaces, classes et mécanismes de conception génériques à mesure que le modèle de conception évoluera, tandis que les ingénieurs de composants responsables de chaque sous-système affineront et actualiseront ces sous-systèmes. 3.5.1

A c t i v i t é

: c o n c e p t i o n

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 déploiement]

Tout au long de cette activité, les architectes envisagent les diverses possibilités de réutilisation, comme la réutilisation partielle de systèmes comparables ou de produits logiciels généralistes. Les sous-systèmes, interfaces et autres éléments de conception qui en résultent sont ensuite intégrés au modèle de conception. L'architecte est également chargé de maintenir, d'affiner et d'actualiser la description de l'architecture et les vues architecturales des modèles de conception et de déploiement. 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

Les configurations réseau physiques ont souvent un impact majeur sur l'architecture du logiciel et affectent les classes de conception nécessaires et la répartition des fonctiona entre les nœuds du réseau. I l est fréquent que ces configurations suivent un modèle il trois niveau-, distinguant les clients (les interactions avec les utilisateurs), les fonctions de bue de donnéi et la logique métier/applicative sur trois couches indépendantes. Le schéma Client IC simple n'est qu'un cas particulier de ce schéma dans lequel la logique métici/appln ai m placée sur l'un des deux autres niveaux (celui des clients ou celui des base-, de données l

architecturale

La conception architecturale a pour objectif de tracer les grandes lignes des modèles de conception et de déploiement et de leur architecture, en identifiant les éléments suivants (voir la figure 9.17) :

Les configurations réseau traitent notamment des aspects énumérés ci dessous • Quels sont les nœuds impliqués et quelles sont leurs capacités en puissance de liiiilcnu ni et en taille de mémoire ?

• les nœuds et leur configuration réseau ; • les sous-systèmes et leurs interfaces ;

•••

ii<-inents d ' a c t i v i t é s principaux

Conception CHAPITRE

a II

• Quel type de connexions existe entre les nœuds et

par quels protOCOlcjl COrflJnuniquaronl

lin? • Ouelles sont les caractéristiques des connexions et des protocoles de coin telles que largeur de bande, disponibilité et qualité ?

cation,

• \1 l-il un besoin de capacité de traitement redondante, de modes dégradés, de migration des processus, de création de copie de secours des données, etc. ? I .11 minaissance des limites et des possibilités des nœuds et de leurs connexions permettra à i il. lulecte d'intégrer des technologies telles que les ORB (Object Request Brokers) ou les • i \s de duplication des données, qui faciliteront la distribution du système. IHfflPJ

Configuration réseau pour le s y s t è m e interbancaire Le système interbancaire s'exécutera sur trois nœuds serveurs et sur un certain nombre de nœuds clients. Avant tout, il y a un nœud 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 métier. Les utilisateurs finals accèdent au système par le biais de nœuds clients, tels que le client Acheteur. Les nœuds communiquent par le protocole TCP/IP sur l'Internet ou un intranet ; voir la figure 9.18. Il y a également un troisième nœud serveur, pour la banque elle-même. C'est sur ce nœud que le paiement des factures est réellement effectué (que l'argent est viré de compte à compte).

„ de m four Serveur vendeur

9

alors se dégager de l'évolution progressive du modèle de conception, lorsque le besoin d'éclatement se fait sentir. Notez aussi que tous les sous-systèmes ne sont pas développés en interne par l'équipe du projet en cours ; certains d'entre eux pourront être des produits réutilisés ou des systèmes appartenant au patrimoine de l'entreprise. L'intégration, dans le modèle de conception, de sous-systèmes de ce type permet d'envisager et d'estimer les possibilités de réutilisation. 9.5.1.2.1.

Identification

des sous-systèmes

d'applications

Au cours de cette étape, nous allons identifier les sous-systèmes de la couche spécifique a l'application et ceux de la couche générale aux applications (les deux couches supéi leuiH I Voir la figure 9.19. Si l'analyse autorise une décomposition satisfaisante en paquetages d'analyse, on unir., r i ces derniers autant que possible et on identifiera les sous-systèmes correspondants dtni II modèle de conception. Ceci est particulièrement important lorsqu'on en arrive mis piiqui tages de service et permet l'identification de sous-systèmes de service correspondants ne compromettant pas la structuration du système en fonction des services qu'il In i Cependant, cette première identification des sous-systèmes sera légèrement améliorée IU cours de la conception afin de prendre en compte les questions relatives à la conception, il l'implémentation et au déploiement du système ; nous évoquerons ce point d'ici peu. Figure 9.19 Sous-systèmes de la couche spécifique à l'application et de la couche générale aux applications.



Couche de middleware

Internet \ Client vendeur

Serveur banque

1Y £

Couche de logiciel système

/

( iiaque configuration réseau, y compris les configurations spéciales destinées aux tests et aux simulations, doit être présentée dans un diagramme de déploiement indépendant. On peut ensuite commencer à réfléchir au moyen de répartir les fonctions entre ces diverses configurations (voir la section 9.5.1.3).

Identification des s o u s - s y s t è m e s de conception à partir des paquetages d'analyse

Les paquetages Gestion des factures par l'acheteur et Gestion des ciiiii|il.i". putiiiiil tent d'identifier les sous-systèmes correspondants dans le modèle de conception (von la

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

figure 9.20).

Les sous-systèmes permettent d'agencer le modèle de conception en portions gérables. Ils peuvent être identifiés dès le début comme un moyen de répartir le travail de conception, ou

I

• M. ii.unements d ' a c t i v i t é s principaux

Conception CHAPITRE

n i/l'.V

M o d è l e d'analyse «paquetage d'analyseGestion des factures par l'acheteur

m IMI.'.II, i ,i

.pnquotnuo il'niiiilyiio. Gestion des comptes

M o d è l e de conception «sous-système de conception» Gestion des factures par l'acheteur

«sous-système de conception» Gestion des comptes

9

mm

Lorsque les paquetages d'analyse (précédents) ne reflètent pas l'intégration d'un système existant. I l est alors possible que la totalité, ou une partie, d'un système existant soit emballée sous forme de sous-système de conception à part entière. Si les paquetages d'analyse (précédents) n'ont pas été conçus pour un déploiement direct sur les nœuds. I l faudra sans doute alors que la décomposition en sous-systèmes résolve certaines questions de déploiement en autorisant une nouvelle décomposition en sous systèmes (plus petits) qui seront affectés chacun à un nœud individuel. Ces sous lyitèml (plus petits) doivent ensuite être perfectionnés afin de réduire le plus possible le tralie réseau, etc.

Ifflfl

Raffinement des s o u s - s y s t è m e s afin de prendre en compte les fonctions partagées

auquel ils semblaient appartenir à l'issue de l'analyse des cas d'utilisation liés à la factuiatiun.

correspondants dans le modèle de conception (voir la figure 9.21 ).

glement des factures dans le sous-système Gestion des factures par l'acheteur,

tion des comptes du modèle d'analyse permettent d'identifier les sous-systèmes de service

Interbank Software avait envisagé d'implémenter tous les paquetages de service pour lu ré

D'autre part, les paquetages de service Comptes et Risques figurant dans le paquetage Ges-

Les développeurs se sont ensuite rendu compte que plusieurs cas d'utilisation futurs tire1,11

mil m îles Ifmrs de i t'iiiltt des thikr\ •0 ni Munis.

•paquetage d'analyse» Gestion des comptes

raient un bénéficie de la présence d'un sous-système de service général de paiement. Ils ont donc décidé d'attribuer à cette fonction de règlement un sous-système de service complet,

M o d è l e d'analyse «paquetage de service» Comptes

appelé Gestion de l ' é c h é a n c i e r . Ce qui signifie que le sous-système Gestion des fac-

«paquetage de service» Risques

tures par l'acheteur utilise la fonction de planification des règlements depuis le sous-système de service Gestion de l ' é c h é a n c i e r . Une fois que la facture arrive à échéance, le sous-système Gestion de l ' é c h é a n c i e r utilise le sous-système Gestion des comptes pour le virement effectif d'un compte à l'autre. Voir la figure 9.22.

«sous-système de conception» Gestion des comptes M o d è l e de conception «sous-système de service» Risques

«sous-système de service» Comptes

Les cas décrits ci-dessous exigent une amélioration de cette décomposition initiale en soussystèmes par rapport aux paquetages d'analyse (précédents) du modèle d'analyse.

Figure 9.22 La conception permet d'identifier le sous-système de service Gestion de l'échéancier, qui fournira un service général susceptible d'être employé par plusieurs réalisations de cas d'utilisation.

• Lorsqu'une partie du paquetage d'analyse (précédent) correspond à un sous-système à part entière (par exemple, s'il s'avère que cette partie peut être partagée et utilisée par plusieurs autres sous-systèmes).

«sous-système de conception» Gestion des factures par l'acheteur


Couche générale aux applications «sous-système de service» Gestion de l'échéancier

«sous-système de conception» Gestion des comptes

Distribution d'un s o u s - s y s t è m e sur différents

nœuds

Le déploiement du sous-système Gestion des factures par l'acheteur nécessite sa distri-

• Lorsque certaines parties du paquetage d'analyse (précédent) sont réalisées par des produits logiciels réutilisés. I l est possible, dans ce cas, que certaines fonctions soient affectées à des sous-systèmes de middleware ou de logiciel système (voir la section 9.5.1.2).

bution sur plusieurs nœuds. Pour ce faire, le sous-système est, à son tour, décomposé en trois sous-systèmes : IU de l'acheteur, Gestion des demandes de règlement et Gest i o n des factures (voir la figure 9.23). Les composants créés à partir de chacun de ces trois sous-systèmes (plus petits) peuvent ensuite être déployés respectivement sur les nœuds Client acheteur, Serveur acheteur et Serveur vendeur.

• Lorsque les paquetages d'analyse (précédents) ne reflètent pas une répartition appropriée 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

Ngiire 9.23 \>>ii\ ./• i omposé de

«sous-système de conception» Gestion des factures par l'acheteur

•" récursive en «sous-système de conception» tivis nouveaux IU de l'acheteur WMJ systèmes, afin -A prendre en de demande i ompte le de règlement J. ploiement.

«sous-système de conception» Gestion des demandes do reglomtinl Traitement des demande de règlement

xsoun-systèmo do conception'

Gestionnaire de commandos

Il ni

I.ii line .

liiiltemi-nl dos IncluroH

Serveur acheteur

Conception B j j CHAPITRE

9 Mm

dépendant possible de produits du commerce et de limiter, par là-même, les risques liés à leur utilisation en cas de changement, ou de garder la possibilité de choisir un autre éditeur si nécessaire. Il existe un moyen de contrôler les dépendances : i l suffit de traiter chaque produit logiciel acquis comme un sous-système à part ayant des interfaces explicites avec le reste du système. Par exemple, si vous avez besoin d'un mécanisme de distribution transparente des objets, vous pouvez définir une interface stricte vis-à-vis d'un sous-système qui réalisera i i mécanisme. Cette solution vous laissera la liberté de choisir entre divers produits, puisque le coût d'actualisation du système sera, de ce fait, parfaitement délimité. Bfflgfl

Client acheteur

Utilisation de Java lors de la construction de la couche de middleware Il est possible que plusieurs des implémentations de sous-systèmes d'applications inlstis m

Serveur vendeur

point par Interbank Software s'exécutent sur différents types de machines, pat exemple dm; PC et des stations de travail Unix, et soient par conséquent amenées à coopérai sut divin sur. plates-formes. Interbank Software a choisi d'implémenter cette interopérabilité a iaidi: du Toolkit), RMI (Remote Method Invocation) et Applets. Ces paquetages Java sont représentés

Le middleware et le logiciel système constituent le fondement d'un système, car toutes les fonctions s'appuient sur des logiciels tels que les systèmes d'exploitation, les systèmes de gestion de base de données, 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'intégration de produits logiciels acquis ou construits spécialement pour le projet se situent par conséquent au cœur des préoccupations des phases de création et d'élaboration. L'architecte valide que les logiciels choisis conviennent à l'architecture et qu'ils assurent une implémentation rentable du système.

produits de middleware, en l'occurrence des paquetages Java AWT (Abstract Wiiidowiny

9.5.1.2.2.

Identification

I Iqure 9.24 Ifi sous-systèmes des
des sous-systèmes

de middleware

et de logiciel

système

sous forme de sous-systèmes dans la figure 9.25. Ils sont bâtis sur la machine virtuelle Java, c'est-à-dire l'interpréteur Java qui doit être installé pour qu'une machine puisse exécuter 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 système tel que le protocole TCP/IP pour les communications par l'Internet (voir la figure 9.25). Le sous-système Appf et Java est un middleware qui permet à Interbank de créer des applets Java.


Chaque fenêtre d'interface utilisateur est conçue à l'aide de la classe Appl et Java et d'autres

_•

f—IV

•

classes d'interface utilisateur telles que Li sts, fournies par le sous-système AWT. Le paquetage Java AWT (java.awt) est conçu pour permettre la création d'interfaces utilisateur indé-


pendantes de toute plate-forme et comprend des classes telles que Fields, Scroilbars et Check Boxes. Couche de middleware

Java RMI est un mécanisme de distribution des objets intégré dans les bibliothèques 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 tiveX/DCOM aurait tout aussi bien fait l'affaire.


Avertissement : l'acquisition des logiciels de middleware et du logiciel système limite, voire invalide, la maîtrise de leur évolution. I l est donc important de conserver une marge de manœuvre raisonnable et d'éviter de se retrouver « piégé » et totalement dépendant 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

I mttlillrware Hf /munissent • minimes |i.il, m

Java.applet

n

Java.awt

KjfMJ Itpr minute s de

Navigateur

ffp plan-forme

Coin IH. .1.- nil.ML.wm,>

Figure 9.26

Dépendances et couches de certains des sous-systèmes du système interbancaire.

9

Couche spécifique à l'application Gestion des factures par l'acheteur

Machine virtuelle Java

mmtlet jnrnt lu mise en " i , de lu \IHhiitnm des

Gestion de l'échéancier

Gestion des comptes


Couche générale aux application.»

Couche do mtddluwmn Java.applet

ii (invti.rmi).

La figure 9.25 illustre la façon dont les services Java peuvent être répartis en sous-systèmes

Machine virtuelle Java

dans la couche de middleware. Elle ne montre aucune dépendance entre sous-systèmes (cel-

Navigateur

les-ci sont présentées dans la figure 9.26). Chaque sous-système contient des classes conçues pour être utilisées en association les unes avec les autres afin d'offrir certains services.

Couche de logiciel systèmo

De même, les composants ActiveX (comme ceux prenant en charge les tableurs, le multimédia, le traitement d'images, la gestion de la sécurité, la persistance, la distribution, les moteurs d'inférences, les traitements et la concurrence) peuvent également être représentés sous for-

de cas d'utilisation, comme les ingénieurs de composants, peuvent ensuite se reporter à ces dia-

de base de Java, telles que Boolean, Integer et Float.

et de les décrire dans des diagrammes de classes tels que celui de la figure 9.26. Les ingénieurs

vent importer et employer : par exemple, java.lang, qui fournit une grande partie des classes

les « traversent » les couches, il est utile de les rendre explicites dans le modèle de conception

de données ou les classes fondamentales standard que tous les autres sous-systèmes peu-

Mais lorsque les dépendances ont un impact sur l'architecture du système, notamment lorsqu'el-

me de sous-systèmes. Souvent, il est pratique de créer un sous-système à part pour les types

grammes lors de la conception des cas d'utilisation, des classes et des sous-systèmes. 9.5.1.2.3

Définition

des dépendances

entre

sous-systèmes 9.5.1.2.4.

Les dépendances entre sous-systèmes doivent être définies si les éléments que contiennent ces sous-systèmes entretiennent des relations. La direction de la dépendance doit être la même que la direction (de navigabilité) de la relation. Si les dépendances doivent être tracées avant que le contenu des sous-systèmes ne soit connu, on considère que les dépendances entre paquetages d'analyse correspondent aux sous-systèmes de conception. Il y a de fortes chances pour que ces dépendances soient identiques dans le modèle de conception. Enfin, si l'on utilise des interfaces entre sous-systèmes, les dépendances doivent relier ces interfaces et non les sous-systèmes eux-mêmes (voir le paragraphe « Identification des interfaces de sous-système »). BlflfflH

Identification

des interfaces

de

sous-système

Les interfaces que procure un sous-système définissent les opérations accessibles depuis l'« extérieur » de ce sous-système. Ces interfaces sont fournies soit par des classes, soit par d'autres sous-systèmes (de façon récursive) contenus dans le sous-système en question. Pour jeter les bases des interfaces, et avant que le contenu des sous-systèmes ne soit connu, on commence par prendre en considération les dépendances entre sous-systèmes telles qu'elles ont été identifiées dans l'étape précédente (paragraphe «Définition des dépen dances entre sous-systèmes »). L'existence d'une dépendance dirigée vers un soiis-sysièine nécessite en général que ce sous-système fournisse une interface. D'aulrc pari, si l'on peui remonter à un paquetage d'analyse à partir de ce sous-système, il esl possible que chaque classe d'analyse référencée depuis l'extérieur du paquetage suppose une interface CWldidâti fournie par le sous-système (comme le montre l'exemple suivant).

D é p e n d a n c e s et couches La figure 9.26 illustre les sous-systèmes du système interbancaire et certaines de leurs dépendances (initiales)

Effijfl Notez que certaines de ces dépendances, en particulier celles des couches de middleware et

Identification d'interfaces candidates à partir du m o d è l e d'analyse Le paquetage de service Comptes contient une classe d'analyse nommée V i rcmcn t •. m t re

de logiciel système, peuvent être plus ou moins implicites dans l'environnement d'implémen-

comptes, référencée depuis l'extérieur du paquetage. On peut donc identifier une interface lui

tation (dans ce cas, Java).

tiale, appelée Vi rement s, fournie par le sous-système de service Compte correspondant dan:; le modèle de conception (voir la figure 9.27).

U

luiinements d ' a c t i v i t é s principaux

Conception CHAPITRE

IB»/


Classe référençant Virements entre comptes depuis l'extérieur

«paquetage d# Mrvlce» ] Comptes | • Ô Û Virements Comnto entre comptes

Û Historique des comptes

implique une candidate M o d è l e de conception

«sous-système de service» Comptes

o Virements

9

mm

L'identification des interfaces des deux couches inférieures (c'est-à-dire les couches de middleware et de logiciel système) est plus simple, car les sous-systèmes de ces couches encapsulent des produits logiciels susceptibles de comporter des interfaces prédéfinies sous une forme ou une autre. Mais il ne suffit pas d'identifier les interfaces ; i l faut aussi déterminer les opérations quechaque interface doit définir. Pour ce faire, les cas d'utilisation sont conçus sous forme de sous-systèmes et d'interfaces de sous-systèmes, comme le décrivent les sections 9.5.2 i ,
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 supérieures du modèle de conception

«sous-système H O de conception» DestinataireFacture Gestion des factures par l'acheteur


Demande De Règlement «sous-système de service» Gestion de ('échéancier

Couche générale aux applications «sous-système • - 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 tôt dans le cycle de vie du logiciel, afin d'amorcer le travail de conception, Mae. la plupart des classes de conception seront déterminées lorsque les classes seront conçues dans l'activité de conception des classes, puis affinées en fonction du résultat de l'activité de conception des cas d'utilisation (voir les sections 9.5.2 et 9.5.3). C'est pourquoi les développeurs doivent veiller à ne pas identifier un trop grand nombre de classes à ce stade et à ne pas se noyer dans les détails : en principe, une première é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 réalisations de cas d'utilisation). Une classe de conception ne participant à aucune réalisation de cas d'utilisation est inutile. 9.5.1.3.1.

Le sous-système Gestion des comptes fournit l'interface Virements pour le transfert d'argent entre comptes. Il s'agit de la même interface que celle fournie par le sous-système de service Comptes au sein du sous-système Gesti on des comptes (voir l'exemple précédent).

Identification

des classes

de conception

à partir des classes

d'analyse

Certaines classes de conception peuvent, dans un premier temps, émerger des classes d'analyse significatives sur le plan architectural détectées au cours de l'analyse. De même, les relations entre ces classes d'analyse peuvent servir à l'identification d'un ensemble provisoire de relations entre les classes de conception correspondantes.

d'analyse (voir la figure 9.29).

l'acheteur fournit l'interface DestinataireFacture afin de recevoir de nouvelles factures

La classe de conception Facture est esquissée à partir de la classe entité Facture du modèle

permet de planifier les règlements. Enfin, le sous-système Gestion des factures par

Esquisse d'une classe de conception à partir d'une classe d'analyse

Le sous-système Gestion de l ' é c h é a n c i e r fournit l'interface DemandeDeRèglement, qui

B M H

émises par un vendeur. Cette interface est utilisée dans le cas d'utilisation Facturer l'acheteur, qui prévoit l'expédition d'une nouvelle facture à l'acheteur.

Notez que les interfaces identifiées ici permettent d'affiner les dépendances entres sous-syslenics, selon les termes évoqués plus haut, dans le paragraphe « Définition des dépendances intre sous-systèmes », puisque les dépendances peuvent porter sur les interfaces et non sur les sous-systèmes.

Figure 9.29 La classe de conception Facture est d'abord issue de la classe entité Facture.



Q

Iiniiioments d ' a c t i v i t é s principaux

Conception CHAPITRE

/ I l. Identification

des

classes

actives

liilecte identifie également les classes actives nécessaires au sysicmc en prenant en con ni les exigences de concurrence pesant sur le système, telles que celles Indiquée! l I dénions i exigences de performances, de débit et de disponibilité qu'expriment les différents MIS dans leur interaction avec le système. Si, par exemple, un acteur particulier a de tintes exigences sur les temps de réponse, i l faudra peut-être y consacrer un objet actif, ii ii re de prendre en compte les entrées 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 chargés (à condition que la capacité du processeur et les ressources en mémoire le permettent). • l . i distribution du système sur des nœuds. Les objets actifs ont besoin de prendre en charge la distribution sur plusieurs nœuds différents qui pourra nécessiter au moins un ' ilijei actif par nœud et des objets actifs séparés pour assurer les communications entre i u ends. • I iilui. d'autres exigences, comme celles pesant sur le démarrage et l'interruption du terne, sur sa vivacité (liveliness), l'évitement des blocages et de la privation de ressources, la reconfiguration des nœuds et la capacité des connexions. i ti.n une des classes actives est ébauchée en prenant en considération le cycle de vie de ses Objet! actifs et la façon dont ceux-ci doivent communiquer, synchroniser et partager les Informations. Ces objets actifs sont ensuite affectés aux nœuds du modèle de déploiement. I on de cette affectation, il convient de prendre en compte la capacité des nœuds, notamment li un processeurs et la taille de leur mémoire, ainsi que les caractéristiques des connexions, i u particulier leur largeur de bande et leur disponibilité. Une règle élémentaire veut que le u .ilu réseau ait une influence substantielle sur les ressources de calcul (aussi bien matémiles que logicielles) requises par le système et doive, par conséquent, être parfaitement I I mi rôle. Ce qui peut avoir un retentissement majeur sur le modèle de conception. Il est possible, pour commencer à identifier les classes actives, d'utiliser comme entrées les résultats de l'analyse et le modèle de déploiement, puis de relier les conceptions correspon• I.mies des classes d'analyse (ou une partie de ces classes) à des nœuds par l'intermédiaire de classes actives. Bfflfll

Utilisation des classes d'analyse pour esquisser les classes actives Comme nous l'avons indiqué plus haut, le système interbancaire doit être réparti sur des nœuds 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

de com-

mandes, Confirmation de commande, Facture, etc. (voir la figure 9.30). Il apparaît maintenant qu'un acheteur est intéressé par la fonction offerte par les classes d'analyse Confirmation de commande et Gestionnaire de commandes, mais que cette fonction a be-

Figure 9.30 Une classe active, Traitement des demandes de règlement, se dégage de l'étude des classes d'analyse Gestionnaire de commandes et Confirmation de commande et du nœud Serveur acheteur. On décide que, lorsque seront conçues les classes d'analyse, les parties principales des classes de conception correspondantes seront affectées au nœud Serveur acheteur. La classe Traitement des demandes de règlement est alors identifiée pour encapsuler le thread de contrôle de ces classes de conception sur le nœud.

C l a s s e s d'analyse

Ô Gestionnaire stionna de commandes :omman

>

• de caractéristiques de sécurité,

soin de plus de puissance de calcul qu'un nœud Cl ient acheteur ne peut lui en fournir. Les des demandes de

règle-

9

N œ u d s et leurs objets actifs

: Serveur acheteur esquisse : Traitement des demandes dt rèolwiwnl

û Confirmation de commande

Une autre possibilité d'esquisser les classes actives consiste à utiliser les sous système! identifiés plus tôt et à affecter tout un sous-système à un nœud spécifique en identifiant une classe active à l'intérieur de ce sous-système (voir, plus haut, le paragraphe « Identification des sous-systèmes d'applications »). N'oubliez pas qu'il faudra peut-être améliorer la décomposition en sous-systèmes pour que ce soit possible. Toute classe active représentant un processus est potentiellement candidate à l'identification d'un composant exécutable lors de l'implémentation. L'affectation des classes actives à des nœuds au cours de cette étape constitue donc une entrée essentielle pour l'affectation des composants (exécutables) à des nœuds au moment de l'implémentation. Par ailleurs, lorsque tout un sous-système est affecté à un nœud, il arrive fréquemment que les éléments qui le constituent contribuent ensemble à la fabrication d'un composant (exécutable) affecté à ce nœud. 9 . 5 . 1 . 4 Identification d e s m é c a n i s m e s

génériques

de c o n c e p t i o n

Nous allons maintenant étudier les exigences communes, telles que les exigences particulières identifiées au cours de l'analyse sur les réalisations-analyse de cas d'utilisation et les classes d'analyse, et décider de la manière dont elles seront prises en charge en fonction des technologies de conception et d'implémentation disponibles. Il résultera de cette opération un ensemble de mécanismes génériques de conception qui pourront se présenter sous loi nie de classes de conception, de collaborations ou même de sous-systèmes identiques à ce que décrit [1]. Les exigences à prendre en charge concernent en général les questions : • de persistance, • de distribution transparente des objets,

• de détection des erreurs et de récupération,

principales parties de ces deux classes d'analyse doivent être affectées au nœud Serveur acheteur et gérées par une classe active séparée ( î r a i t e m e n t ment) sur ce même nœud.

• de gestion des transactions.

I

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

rAimi II

Dans certains cas, il arrive que ces mécanismes ne soicnl p u I m m é d i a t e m e n t apparents mais qu'ils se dégagent de l'exploration des réalisations 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 nœuds et conçus pour un système distribué. Interbank Software décide d'implémenter la distribution des objets en faisant de chaque classe distribuée 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 utilisée par Java pour parvenir aune distribution transparente des objets (c'est-à-dire que les objets sont distribués de telle sorte qu'un objet client n'ait pas à savoir où réside l'objet appelé).

rlUinn il :il li i /m vr destinée à ti ilmér doit être M mm Iv/ic de H/NII iiMh'emuleObject.

UnicastRemoteObject

7T

Conception CHAPITRE

9

263

Utilisation d'une collaboration g é n é r i q u e dans plusieurs réalisations de cas d'utilisation Au cours de leur travail sur les cas d'utilisation et leurs réalisations, les architectes Identifiant un pattern dans lequel un objet Transaction commerciale, tel qu'une Commande ou uni Fa ture, est créé par un acteur et envoyé à un autre acteur : • lorsqu'un acheteur décide de commander certaines marchandises ou certains swv ,nn vendeur, il invoque le cas d'utilisation Commander des marchandises ou des scrvln".. qui lui permet de rédiger et d'envoyer par courrier électronique une commanda an vninlmii concerné ; • lorsqu'un vendeur décide 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 représenté pat uni: ooHabninlion générique, comme le montre le diagramme de collaboration de la figure 9.32 1: envoyer transaction commerciale

:IU de création transactions commerciales

« une classe distribuée »

BH3H

2: créer Transaction Commerciale,;)

: Expéditeur

: Traitement par l'expéditeur

M é c a n i s m e s de conception pour la persistance Certains objets, tels que les objets Facture et Commande, doivent être persistants. Interbank Software peut utiliser, pour cela, un système de gestion de bases de données objet, un sys-

commerciale

4: recevoir Transaction Commerciale (stubTransaction Commerciale)

tème de gestion de bases de données relationnelles ou tout simplement des fichiers binaires. 6: présenterTransaction •M 7: présenter Commerciale : Traitement de présentation transaction commerciale par le destinataire (stubTransaction Commerciale) des transactions commerciales

Le choix dépend de la façon dont on aura besoin d'accéder aux objets et de les actualiser, et des possibilités d'implémentation et d'évolution ultérieures. Une base de données relationnelle offrira généralement de meilleures performances dans le cas de données tabulaires, tandis

>

qu'une base de données objet sera mieux adaptée aux structures complexes d'objets. Si les

de présenter

tème à l'aide d'un système de gestion de bases de données relationnelles, puis de le mettre à

Diagramme de collaboration montrant une collaboration générique

systèmes de bases de données objet, il peut toutefois revenir plus cher de construire un sys-

Figure 9.32

systèmes de gestion de bases de données relationnelles montrent plus de maturité que les

des transactions

permettant de créer, d'envoyer, de recen ,ii , i

commerciales.

niveau plus tard avec une base de données objet (une fois que celle-ci aura atteint un niveau

1 e(1) (les chiffres entre parenthèses renvoient à ceux de la figure 9.32). L'in de 11

sistance.

di teur des informations servant d'entrées à la création d'un objet Transaction COU in I

tecte en tant que mécanisme générique de conception pour la gestion des questions de per-

Tout d'abord, l'IU de création des transactions commerciales reçoit de l'acteur I xpi

de maturité satisfaisant). Quelle que soit la solution retenue, elle sera documentée par l'archi-

de transactions commerciales demande ensuite à Traitement par l'expéditeur do

par le destinataire (4). Traitement par le destinataire peut alors interrogei la

d'en fournir plusieurs et d'employer le plus approprié à chaque situation.

des factures soumet ensuite la référence de la Transaction commen iaieà

nisme ne suffit à lui seul à prendre en compte toutes les situations, i l peut être nécessaire

la classe Transaction commerciale correspondante de créer une instance (3) I M 11

manières et que chacune des approches a ses avantages et ses inconvénients. Si aucun méca-

créer un objet Transaction commerciale (2). Traitement par l'expéditeur demanda a

Ce dernier exemple illustre le fait que chaque mécanisme peut être géré de plusieurs

ni

i ,i 11 minii

Transacti on commerci a 1 e pour obtenir de plus amples informations (5). Tra i tement pa r

L'architecte doit également identifier les collaborations génériques pouvant servir de pat-

le destinataire envoie ensuite l'objetTransacti on commerci al e à l'IU de présentation

terns et être utilisées par plusieurs réalisations de cas d'utilisation du modèle de conception.

des transactions commerciales (6), qui le présentera à l'acteur Destinataire (7).

i j

< ne i i n î n e m e n t s d ' a c t i v i t é s principaux

tMIIUlTl

Ensuite, lorsque, par exemple, le cas d'utilisation Facturer i \ heieut ost ifoillsn, chacun des classificateurs abstraits prenant part à la collaboration gônéi iquii poulfttrusous typé par

CHAPITRE

9

Wm

• formuler les exigences d'implémentation pour le cas d'utilisation en question.

des classificateurs concrets, comme l'illustre la figure 9.33.

A

•

Conception

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

La réalisation du cas d'utilisation Facturer l'acheteur n'a donc qu'à faire référence à la collaboration générique, mais elle n'a pas besoin de la dupliquer ou de la spécialiser tant que les

Expéditeur

- •

lu

/\

i\

Traitement par l'expéditeur

IU de création des transactions commerciales

IU de facturation

i

Activité

• définir les exigences pesant sur les opérations des classes de conception et/ou des soussystèmes et leurs interfaces ;

Dans cette étape, nous allons identifier les classes de conception nécessaires à la réalisation du cas d'utilisation (voir la figure 9.34). I l convient de procéder de la façon suivante.

opérations (virtuelles) sur les classificateurs abstraits sont réalisées par des méthodes sur les classificateurs concrets qui les sous-typent.

•mi

i »ii„

Transaction commerciale


Traitement par le destinataire

l

^HMI |MIHt*Ml1 I lu i « n l l * « l l o n

II

Facture

i II lit meurs abstraits prenant part à une collaboration générique participant à une réalisation spécifique de cas d'utilisation.

Traitement des demandes de règlement

IU de présentation des transactions commerciales

t

Destinataire

A

IU de présentation des factures

par des

classificateurs

services.

: concevoir

un

c a s

• Étudiez les classes d'analyse prenant part à la réalisation-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é créées par l'ingénieur de composant! Ion dl la conception des classes ou par l'architecte lors de la conception architecturale • Étudiez les exigences particulières de la réalisation-analyse du cas d'utilisation correspondante et identifiez les classes de conception réalisant ces exigences pailu ulli n Ces classes sont détectées soit par l'architecte au cours de la conception archilei luiale (c'est-à-dire sous forme de mécanismes génériques), soit par l'ingénieur de composant! au cours de la conception des classes. • I l en résulte que la classe nécessaire doit être identifiée et qu'un ingénieur de composants . doit s'en voir attribuer la responsabilité.

sont sous-typés

I .a même approche vaut pour la réalisation du cas d'utilisation Commander des marchandises nu des

Noie/, que l'utihsation de généralisations n'est pas le seul moyen d'employer une collaboration générique. Les patterns, qui sont des collaborations paramétrées (des classes paraméii ces, par exemple), sont également génériques et peuvent être employés par l'association de classes concrètes aux paramètres. 1,11 plupart des mécanismes génériques doivent être identifiés et conçus au cours de la phase d'élaboration. En procédant avec attention, l'architecte pourra souvent élaborer un ensemble de mécanismes capables de résoudre les problèmes de conception les plus complexes et de rendre assez simple et directe la réalisation d'une majorité de cas d'utilisation au cours de la phase de construction. Les mécanismes liés à des produits logiciels sont des candidats naturels à la couche de middleware. D'autres mécanismes trouveront plutôt leur place dans la couche générale aux applications. 82

d'utilisation

La conception d'un cas d'utilisation poursuit les objectifs suivants :

• S'il manque toujours une classe de conception nécessaire à la conception d'un cas d'utilisation spécifique, l'ingénieur de cas d'utilisation doit en faire part aux architectes ou aux ingénieurs de composants. La classe requise doit être identifiée et un ingénieur de composants doit s'en voir attribuer la responsabilité. Réunissez les classes de conception prenant part à une réalisation de cas d'utilisation dans un diagramme de classes associé à cette réalisation, qui exposera les relations employées dans la réalisation. Figure 9.34 Entrées et résultat de la conception des cas d'utilisation. La réalisationanalyse de cas d'utilisation correspondante du modèle d'analyse est un point de départ essentiel pour cette activité.

• identifier les classes de conception et/ou les sous-systèmes dont les instances sont nécessaires au flot d'événements du cas d'utilisation ;

F3

,

Modèle des X cas d'utilisation

O

£7 Ingénieur de cas d'utilisation

Exigences supplémentaires D Modèle d'analyse


' Classe de conception [esquisse] ^Concevoir -y un cas d'utilisation

Modèle de conception ,

Sous-système [esquisse]

Interface [esquisse]

D " " Modèle de déploiement

• distribuer le comportement du cas d'utilisation aux objets de conception en interaction et/ ou aux sous-systèmes participants ;

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

Classes participant à la réalisation du cas d'utilisation Moulin la lacliuu La figure 9.35 montre un diagramme de classes décrivant lis; i t e m , inniiaiil p.ul ,i la i fiait sation du cas d'utilisation Régler la facture et les associations qui lus iHimil lis, mu::; aux autres.

:ir.

Gestionnaire de commandes

twi prenant

Confirmation de commando

iKiilmn i/w cas Traitement des demandes de règlement

IU de demande de règlement

Conception CHAPITRE

9

naturellement leur place dans la séquence d'interactions de la réalisation du cas d'utilisation. Quelques remarques s'imposent au sujet de ces diagrammes de séquence : • le cas d'utilisation est invoqué par un message adressé par une instance d'acteur à un objet de conception ; • chaque classe de conception identifiée lors de l'étape précédente doit avoir au moins un objet de conception participant à un diagramme de séquence ; • les messages circulent entre les lignes de vie d'objets (annexe A) pour réaliser le cas d'utilisation. Un message peut avoir un nom temporaire, qui deviendra le nom d'une opération dès que celle-ci aura été identifiée par l'ingénieur de composants i espi nisalih 11 la classe de l'objet récepteur ;

ÉHiuion Régler lit liiir nvcc

» msoeiations. flamme, les • > tCllvtS ont ftnturt plus


• la séquence du diagramme doit mobiliser l'attention car la réalisation-concept ion di i | d'utilisation constitue la principale entrée de l'implémentation 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'événements-conception pour compléta lei diagrammes de séquence ;

Echéancier Facture

Demande de règlement

Certaines classes actives, telles que Traitement des demandes de règlement ou Traitement des factures, garantissent l'exécution du système interbancaire en faisant passer les transactions commerciales entre les différents nœuds d'un émetteur à un récepteur, 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 séquence doit prendre en compte toutes les relations du cas d'utilisation en cours de réalisation. Par exemple, si un cas d'utilisation A spécialise le cas d'utilisation B par une relation de généralisation, le diagramme de séquence réalisant le cas d'utilisation A aura peut-être besoin de se référer à la réalisation (c'est-à-dire au diagramme de séquence) du cas d'utilisation B. Notez qu'il est fort probable que des références de ce type existent dans les réalisations-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 Régler la facture

Une fois que l'on dispose d'une esquisse des classes de conception nécessaires à la réalisation du cas d'utilisation, i l faut décrire les interactions entre les objets qu'elles renferment. ( )n utilise à cettefindes diagrammes de séquence contenant les instances des acteurs participants, les objets de conception et leurs échanges de messages. Si les cas d'utilisation présentent des flots ou des sous-flots distincts, i l peut être intéressant de créer un diagramme de séquence pour chacun d'eux. La réalisation de cas d'utilisation gagnera en clarté et i l sera possible d'en extraire des diagrammes de séquence représentant des interactions générales et réutilisables.

La figure 9.36 montre le diagramme de séquence de la première partie du cas d'utilisation Régler la facture. La description du flot d'événements-conception complétant ce diagramme de séquence pourra être rédigée de la façon suivante :

L'acheteur utilise le système, via TappletW de demande de règlement ef l'application irai tement des demandes de règlement, pour parcourir les factures reçues. Irai l.eitient. de.

Pour débuter cette étape, étudiez la réalisation-analyse de cas d'utilisation correspondante. ( )n peut en dégager une esquisse de la séquence de messages nécessaire entre les objets de conception, même s'il est probable qu'un grand nombre d'objets de conception supplémentaires auront été ajoutés. Dans certains cas, on pourra même transformer un diagramme de collaboration de la réalisation-analyse de cas d'utilisation en une première esquisse du diagramme de séquence correspondant.

demandes de règlement 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 règl ement ne présente la liste des factures à l'acheteur. L'acheteur sélectionne une facture par le biais de /'IU de demande de règlcnirni et en M nifie le règlement,

puis l'IU de demande de règlement transmet cette requête im

Traitement des demandes de règlement, qui demande à licbêander déprogrammai» règlement de la facture. /.'Échéanci er crée ensuite une demande de règlement l'applii .itum

< )n crée un diagramme de séquence en se plaçant au début du flot du cas d'utilisation, puis en le parcourant étape par étape et en déterminant les interactions entre objets de conception et instances d'acteur nécessaires à sa réalisation. Dans la plupart des cas, les objets trouvent


demande alors à l'application Iniilrnienl des

factures de faire passer la facture à l'état Pour règl 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

des demande

parcourirQ

parcourlrFactures()

vérilierFacture

obtenir Infos

Î

: G est tonnait i de commandi s Exploration!)

Conception CHAPITRE

9 Wm2

Il s'agit, pour commencer, d'identifier les sous-systèmes nécessaires à la réalisation du cas d'utilisation. • Étudiez les classes d'analyse prenant part à la réalisation-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-systèmes de conception pouvant remonter à ces paquetages d'analyse. .

obtenirFaclureQobtenlrlnfosConflrmatlonQ ' QPtenlrinfosFafûjeQ planifier le r è g l e m e n t de ta facture | planrfierRèglemerrtffacture)

: Demande le règlement défmirÉtatDeLaFacture(PourRègiement} ^ I définlrËtat(PourRèglemenl}

juin 9.36 Oframme de séquence lin lure.

des objets de conception exécutant

une partie de la réalisation

du cas d'utilisation

Régler

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 décrits dans les étiquettes des diagrammes ou faire l'objet de diagrammes d'interaction qui leur seront dédiés. En ajoutant des informations, l'ingénieur de cas d'utilisation découvrira 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 délais d'inactivité lorsque des nœuds ou des connexions s'interrompent ;

• Étudiez les exigences particulières de la réalisation-analyse de cas d'utilisation correspondante. Identifiez les classes de conception réalisant ces exigences partit Lllli Pl s'il y en a. Identifiez ensuite les sous-systèmes de conception contenant t es i la .. Réunissez les sous-systèmes participant à une réalisation de cas d'utilisation dans Il I gramme de classes associé à cette réalisation, que vous emploierez ensuite pOUl (aifl apps raître les dépendances entre ces sous-systèmes et les interfaces employée: ilau i i réalisation. Figure 9.37 Les lignes de vie du diagramme du centre (a) représentent les soussystèmes et montrent les i messages reçus et envoyés I par les sous-systèmes. Les autres diagrammes (betc) représentent les conceptions internes des sous-systèmes et montrent la façon dont ces messages (dans a) sont reçus et envoyés par les éléments internes des sous-systèmes. Le diagramme (a) peut être conçu avant (b et c).

• entrées erronées introduites par des acteurs humains ou machines ; S o u s - s y s t è m e s et interfaces prenant part à la réalisation du cas d'utilisation

• messages d'erreur générés par le middleware, le logiciel système ou le matériel. 9.5.2.3

R é g l e r la facture

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

Jusqu'à présent, nous avons conçu les cas d'utilisation comme des collaborations entre différentes 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-systèmes y prenant part et/ou d'interfaces de sous-systèmes. Par exemple, i l peut être nécessaire, dans le cadre d'un développement descendant, d'exprimer les exigences pesant sur les sous-systèmes et leurs interfaces avant que leur contenu n'en soit déterminé. Dans d'autres cas, i l faudra pouvoir remplacer facilement un sous-système et sa conception interne spécifique par un autre sous-système doté d'une conception interne différente. On pourra alors décrire une réalisation-conception de cas d'utilisation à plusieurs niveaux de la hiérarchie des sous-systèmes (voir la figure 9.37).

La figure 9.38 montre un diagramme de classes comprenant les sous-systèmes, les interfaces et leurs dépendances impliqués dans la première 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

,11 III mime île

i,n.,

les

nés, les

«sous-système de conception» IU de l'acheteur

•

O

H

Règlement

sous-système de conception» Gestion des demandes de règlement

>(. )

rnctum

9.5.3

Activité

: concevoir

Conception CHAPITRE

9 Wkm

une classe

L'objectif de la conception d'une classe est de créer une classe de conception remplissant son rôle dans les réalisations 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-même, mais également :

lin l:lllll li|lllllll~ GIMIIIDII ilim Imliiiini

rl leurs \t

• ses opérations ; • ses attributs ;

«sous-système de conception» Gestion de l'échéancier Gestion de l'échéancier

• les relations auxquelles elle prend part ; • ses méthodes (qui en réalisent les opérations) ; • ses états imposés ;

9.5.2.4

Description des interactions entre s o u s - s y s t è m e s

Une fois que l'on dispose d'une esquisse des sous-systèmes requis par la réalisation du cas d'utilisation, i l faut décrire la manière dont les objets des classes qu'ils contiennent dialoguent au niveau des sous-systèmes. On utilise pour cela des diagrammes de séquence contenant les instances des acteurs participants, les sous-systèmes et leurs échanges de messages. L'approche adoptée pour cette démarche est semblable à celle décrite dans la section 9.5.2.2, avec, toutefois, les différences suivantes :

• ses dépendances par rapport à des mécanismes génériques de conception ; • les exigences s'appliquant à son implémentation ; • la réalisation correcte des interfaces qu'elle doit fournir. Figure 9.39 Entrées

et

O

O

résultat

de la conception

• les lignes de vie (annexe A) dans les diagrammes de séquence dénotent des sous-systèmes et non des objets de conception ;

d'une

classe.

Réalisation-conception de cas d'utilisation v

• chaque sous-système identifié dans la section 9.5.2.3 doit être cité par au moins une ligne de vie dans un diagramme de séquence ;

Classe de conception [esquisse]

• si un message est affecté à une opération d'interface, il peut être utile de qualifier ce message à l'aide de l'interface fournissant l'opération. Cette qualification est nécessaire lorsqu'un sous-système fournit plusieurs interfaces et qu'il est impératif de déterminer l'interface utilisée dans le message. 9.5.2.5


Concevoir 77 une classe

Classe de conception [complète]


Formulation des exigences d ' i m p l é m e n t a t i o n

Q "

I )ans cette étape, nous allons procéder à la formulation de toutes les exigences pesant sur une réalisation de cas d'utilisation, comme les exigences non fonctionnelles identifiées en conception, mais qui devront être gérées par l'implémentation. Bfflfl

Classe d'analyse [complète]

9.5.3.1 É b a u c h e d e la classe de conception

Exigences d ' i m p l é m e n t a t i o n sur le cas d'utilisation Régler la facture

La première étape consiste à esquisser une ou plusieurs classes de conception à parfit des entrées fournies par les classes d'analyse et/ou par les interfaces. Lorsqu'on dispose d'une interface comme entrée, le plus simple est en général d'attribuer une classe de coin cpiion pour fournir cette interface.

Voici un exemple d'exigence d'implémentation imposée par la réalisation du cas d'utilisation Régler la facture : Un objetde la classe (active) Traitement des demandes de r è g l ement doit pouvoir prendre en compte 10 clients acheteurs différents sans qu'aucun d'entre eux soit victime du moindre

Si l'on dispose, en revanche, d'une ou plusieurs classes d'analyse comme entrée, la mellmili utilisée dépendra du stéréotype de la classe d'analyse :

retard de traitement.

• la conception des classes frontières dépend des technologies d'interface spécifiques utilisées. Par exemple, les classes frontières conçues en Visual Basic impliqueront des classes de conception stéréotypées 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
conception représentant les « contrôles », éventuellcnicnl des coniioles AciivcX, dans l'interface utilisateur. Notez également que certains outils récents de conception d'interfaces utilisateur permettent de créer les interfaces de façon visuelle, directement à l'écran, ce qui rend implicite la création des classes de conception correspondantes. Tout prototype d'interface utilisateur existant constitue une entrée essentielle pour cette étape ; • la conception des classes entités représentant des informations persistantes (ou de classes ayant d'autres exigences de persistance) impose souvent de recourir à une technologie de hase de données spécifique. I l peut s'agir, par exemple, de créer des classes de conception correspondant aux tables d'un modèle de données relationnel. L'utilisation d'outils de modélisation actuellement disponibles permet d'automatiser en partie ce processus, bien que cette opération puisse se révéler assez délicate. Elle peut nécessiter l'adoption d'une Stratégie de persistance, susceptible de faire surgir un grand nombre de problèmes de conception, en particulier si l'on cherche à établir une correspondance entre un modèle de données relationnel et un modèle de conception orienté objet. Ces problèmes pourront nécessiter à leur tour l'intervention d'autres travailleurs (des concepteurs de base de données, par exemple), d'activités (la conception de bases de données) et de modèles (les modèles de données) dans le processus de développement. Ces cas dépassent le cadre de cet ouvrage ; • la conception des classes de contrôle est délicate. Comme ces classes encapsulent les séquences, la coordination des autres objets et, parfois, la pure logique métier, i l faut prendre en considération les aspects décrits ci-dessous.

Conception Mff CHAPITRE y Mm

• les responsabilités de toutes les classes d'analyse auxquelles la classe de conception remonte. Une responsabilité implique souvent une ou plusieurs opérations. En outre, si des entrées et des sorties sont décrites pour ces responsabilités, elles peuvent être utilisées comme première esquisse des paramètres formels et des valeurs de résultat des opérations ; • les exigences particulières 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 modèle de conception, éventuellement par l'intégration d'un nui anisrni générique de conception ou d'une technologie telle qu'une technologie de base dedonnées ; • la ou les interfaces que fournit la classe de conception, qui doit également en lu opérations ;

I.

• les réalisations-conception de cas d'utilisation auxquelles participe la classe i von lu section 9.5.2). Les opérations d'une classe de conception doivent prendre en charge tous les rôles que < | me la classe dans les différentes réalisations de cas d'utilisation. On trouvera ces rôles en pai courant les réalisations de cas d'utilisation et en allant voir si la classe et ses objets figurent dans les diagrammes et les descriptions de flots d'événements-conception des réalisations. jljJIJJIJ

O p é r a t i o n s de la classe Facture La classe Facture participe à plusieurs réalisations de cas d'utilisation, comme celles des cas

- Les problèmes de distribution. Si la séquence doit être distribuée et gérée par plusieurs nœuds du réseau, il faudra peut-être plusieurs classes de conception sur différents nœuds pour réaliser la classe de contrôle.

d'utilisation Régler la facture, Envoyer des relances et Facturer l'acheteur. Chacune de ces réalisations lit ou modifie l'état des objets Facture. Le cas d'utilisation Facturer

l'acheteur crée et soumet des Factures. Le cas d'utilisation Régler la facture envoie les Fa et u res au règlement, et ainsi de suite, si bien que chaque réalisation de cas d'utilisation fait un usage différent des objets Facture. En d'autres termes, la classe Facture et ses objets jouent différents rôles dans ces réalisations de cas d'utilisation.

- Les problèmes de performances. I l n'est pas toujours justifié qu'une classe de contrôle soit réalisée par plusieurs classes de conception indépendantes. Elle pourra tout simplement être réalisée par les mêmes classes de conception que celles qui réalisent certaines classes frontières et/ou entités proches.

Les ingénieurs de composants avaient d'abord pensé implémenter ces changements d'état en une seule opération, appelée définirÉtat, dont un paramètre indiquerait l'action désirée et l'état cible (par exemple, défi ni rÉtat ( PourRègl ement)). Mais ils ont finalement préféré implémenter des opérations explicites pour chacune des transitions d'état. Ils ont également décidé 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 opérations suivantes (iloul cita

- Les problèmes transactionnels. Les classes de contrôles encapsulent fréquemment des transactions. Les classes de conception leur correspondant doivent alors intégrer la technologie de gestion transactionnelle utilisée. Les classes de conception identifiées dans cette étape doivent se voir attribuer des dépendances de traçabilité 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.

cune modifie l'état de la Transacti on commerciale) : Créer, Soumettre, l'Ianl 11er ni '.<> i der. Ces opérations ne sont toutefois que des opérations virtuelles qui ilélinissitiil une signature. Les classes sous-types de la classe Transacti on comme n i a le doiviml chacune définir une méthode concrète réalisant ces opérations.

9 . 5 . 3 . 2 Identification d e s o p é r a t i o n s

Dans cette étape, nous allons identifier les opérations qui doivent être fournies par la classe de conception et les décrire dans la syntaxe du langage de programmation. La visibilité de chaque opération doit être spécifiée : par exemple, public, protected, private en C++. Les principales entrées de cette étape sont les suivantes :

I

e n c h a î n e m e n t s d ' a c t i v i t é s principaux mu II

. . Il

Ml

«»<• Facture, rti lion

lf n lii/c cl / « Ml MM i/ll V//l' «m i luirge.

Transaction commerciale

+créerO +soumettre() +planifier() +solder{) 7Â—

Facture

I e comportement des objets de certaines classes dépend étroitement de l'état de l'objet. Ces 1 lasses sont mieux décrites 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 nécessaires à la classe de conception et les décrire dans la syntaxe du langage de programmation. Un attribut spécifie une propriété d'une classe de conception et sa présence est souvent impliquée et nécessitée par les opérations de la classe (telles qu'elles ont été décrites dans la section précédente). Les conseils suivants vous seront utiles lors de l'identification des attributs : • prenez en considération les attributs de toutes les classes d'analyse auxquelles la classe de conception remonte. I l arrive que ces attributs fassent naître le besoin de créer un ou plusieurs attributs dans la classe de conception ; • les types d'attributs disponibles sont limités par le langage de programmation ; • lorsque vous choisissez un type d'attribut, essayez d'en réutiliser un qui existe déjà ; • une même instance d'attribut ne peut être partagée par plusieurs objets de conception. Si cela est absolument nécessaire, l'attribut doit être défini en tant que classe à part ; • si une classe de conception devient difficilement compréhensible en raison de ses attributs, certains d'entre eux peuvent être placés dans une classe à part ; • si les attributs d'une classe sont trop nombreux ou trop complexes, ils peuvent être présentés dans un diagramme de classes à part ne montrant que le compartiment des attributs.

Conception Wff CHAPITRE

9

WL

Le nombre de relations entre classes doit être réduit le plus possible. I l ne s'agit pas de modéliser sous forme d'associations ou d'agrégations avant tout les relations du monde réel, mais plutôt celles appelées à répondre aux exigences des diverses réalisations de cas d'utilisation. Notez également que, étant donné que les questions de performances doivent être gérées pendant la conception, i l peut être nécessaire de modéliser des chemins de recherche optimaux à travers les associations ou les agrégations. Rappelez-vous les conseils qui suivent lors de l'identification et du raffinement des assot la tions et des agrégations. • Considérez les associations ou les agrégations impliquant la ou les classes d'analyse correspondantes. Il arrive que ces relations (du modèle d'analyse) entraînent la Itél CSSltl d'une ou de plusieurs relations correspondantes (dans le modèle de conception) impliquant la classe de conception. • Affinez la multiplicité des associations, les noms de rôles, les classes d'association, li rôles ordonnés, les rôles qualifiés et les associations n-aires en fond ion des possibilités du langage de programmation choisi. Par exemple, les noms de rôles sont susceptibles de devenir des attributs de la classe de conception lors de la génération 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 nécessitera de nouvelles associations dotées de la multiplicité appropriée 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 généralisations doivent utiliser la sémantique définie par le langage de programmation. Si celui-ci ne prend pas en charge la généralisation (ou l'héritage), on peut utiliser à la place des associations et/ou des agrégations pour assurer la délégation (par exemple, l'envoi d'un message demandant l'exécution d'une tâche, l'exécution de cette tâche et la réception d'un message de confirmation depuis des objets de la classe la plus spécifique vers des objets de la classe la plus générique. 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 même façon et prennent en cltaign dus ci aie plus général (voir la figure 9.41).

Les objets de conception dialoguent ensemble par le biais de diagrammes de séquence. Ces interactions nécessitent souvent des associations entre les classes qu'elles relient. L'ingénieur de composants doit donc étudier les échanges de messages dans les diagrammes de séquence et déterminer les associations requises. On pourrait utiliser des instances d'association pour détenir les références à d'autres objets et grouper les objets en agrégations pour l'échange de messages.

opérations similaires. Tous deux sont des spécialisations d'un objet ir,i n s .u 1 imi

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 e n c h a î n e m e n t s d ' a c t i v i t é s principaux / -ARTIE II

(jure 9.41 mxsaction vmmcrciale U'iu'nilise Facture i i nimande. Îrz que ces u'm'inlisations tintent également 'ii \ modèle imilvsi' entre les IIWI'.I d'analyse mrspondantes.

Figure 9.42 Diagramme d'états-transitions pour la classe Facture.

f

Créée

Conception CHAPITRE

9

j +soumettreO

Ên attente j

+schedule() +planifier()

D

[dépassement : au-delà de la dernière limite de règlement]

9.5.3.6 Description d e s m é t h o d e s

Pour règlement j En retard J

Au cours de la conception, on peut utiliser des méthodes pour spécifier la façon dont les opérations seront réalisées. Ces méthodes peuvent, par exemple, définir un algorithme et sont exprimées soit en langue naturelle, soit en pseudo-code, selon ce qui convient le mieux.

+solder{)

+solder()

Néanmoins, la plupart des méthodes temporelles ne sont pas créées pendant la conception, mais au cours de l'implémentation, directement dans le langage de programmation. Tout simplement parce que c'est le même ingénieur de composants qui doit concevoir et implémenter la classe, ce qui évite d'avoir à transmettre des spécifications telles que les spécifications de méthode.

Soldée

è

Notez que si l'outil de conception prend en charge une génération de code fluide des méthodes sur les classes de conception, les méthodes peuvent être spécifiées directement dans l'outil de conception à l'aide du langage de programmation. Mais ceci est ensuite considéré comme une activité d'implémentation et n'est donc pas traité par la conception. Pour de plus amples détails, reportez-vous au chapitre 10, plus particulièrement à la section 10.5.4, qui aborde l'activité d'implémentation des classes.

J

Une facture est créée lorsqu'un vendeur veut qu'un acheteur règle une commande. La facture est ensuite soumise à l'acheteur et son état devient En attente. Lorsque l'acheteur décide 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 réglée, son état est Soldée.

Les exigences qui n'ont pas été prises en compte dans les étapes précédentes vont maintenant être gérées. À cettefin,étudiez les exigences imposées par les réalisations 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 particulières pesant sur toute classe d'analyse à laquelle remonte la classe de conception. Ces exigences particulières devront souvent être gérées par la classe de conception.

Certains objets de conception sont pilotés par l'état dans lequel ils se trouvent : c'est ce dernier qui détermine leur comportement lors de la réception d'un message. Dans de tels cas, i l est intéressant d'employer un diagramme d'états-transitions pour décrire les différentes transitions de l'état d'un objet de conception. Ce diagramme constitue ensuite une entrée précieuse pour l'implémentation de la classe de conception correspondante.

9.5.3.8 Gestion d e s exigences p a r t i c u l i è r e s

9.5.3.7

WUIJJU

Description d e s é t a t s

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 créés, soumis, planifiés et soldés.

lypfflH

Emploi d'un m é c a n i s m e de conception pour gérer une exigence particulier!] Les objets Facture doivent être accessibles à partir de plusieurs nœuds, a la lois depuis le

Comme pourtous les objetsTransacti on commerci aie, ces changements d'état suivent une

Serveur acheteur et depuis le Serveur vendeur. Facture n'est pas une classe active, mais

séquence stricte. Par exemple, une facture ne peut être planifiée avant d'avoir été soumise.

elle doit être conçue pour un système distribué. Dans notre exemple, nous avons implémenté

Cette séquence de changements d'état peut être définie par un diagramme d'états-transitions,

cette distribution des objets en faisant de la classe Facture une sous-classe de la classe abs-

comme le montre la figure 9.42.

traite java nommée java. rmi. server .Uni castRemoteObject, qui prend en charge RMI (Remote Method Invocation) (voir la figure 9.43). Notez que ce mécanisme de conception est identifié et décrit par l'architecte dans l'activité de conception architecturale.

r

I « • e n c h a î n e m e n t s d ' a c t i v i t é s principaux

i

II

fun u A3 i-i, i\ ki classe ilnivenl être i "est pourquoi MI îles sous-types de |/lMi

UnicasIRomotoObJort

5

Figure 9.44 Entrées et résultat de la conception d'un sous-système.

•

iitlHrmoleObject.

Description de * l'architecture [vue du modèle de conception]

Sous-système [esquisse]

Pour la gestion de ces exigences, servez-vous si possible de tous les mécanismes génériques de conception à votre disposition, tels qu'ils ont été identifiés par l'architecte.

Conception CHAPITRE

9

O O

Ingénieur de composants Sous-systèmo [complet] Concevoir sous-système

O

Inlnrlm <• [complotl

( 'cpcndant, i l peut être plus adapté de retarder la gestion de certaines exigences jusqu'à l'implémentation. Ces exigences doivent alors être signalées en tant qu'exigences d'impléniciilation pour la classe de conception.

O '


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'implémentation pour la classe Traitement des demandes de

règlement. • Un objet de la classe doit pouvoir prendre en compte 10 clients acheteurs différents sans qu'aucun d'eux soit victime du moindre retard de traitement.

9 hA

Activité

: concevoir

un

sous-système

I a conception d'un sous-système poursuit les objectifs suivants (voir la figure 9.44) : • s'assurer que le sous-système est aussi indépendant que possible des autres sous-systèmes cl/ou de leurs interfaces ; • s'assurer que le sous-système fournit les interfaces voulues ; • s'assurer que le sous-système remplit sa mission, c'est-à-dire qu'il offre une réalisation salisfaisante des opérations définies 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

9.5.4.2

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

Les opérations définies par les interfaces que fournit un sous-système doivent prendre en charge tous les rôles que le sous-système assume dans les différentes réalisations de cas d'utilisation. Même si elles ont été esquissées par les architectes, i l est possible que ces interfaces réclament quelque raffinement de la part de l'ingénieur de composants, aufilde l'évolution du modèle de conception et de la conception des cas d'utilisation. N'oubliez pas qu'un sous-système et ses interfaces peuvent être employés dans diverses réalisations de cas d'utilisation par les ingénieurs de cas d'utilisation, ce qui impose de nouvelles exigences sur les interfaces (voir la section 9.5.2.4). L'approche adoptée pour l'actualisation des interfaces et de leurs opérations est semblable à celle utilisée pour l'actualisation des classes de conception et de leurs opérations, décrite 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

On peut considérer qu'un sous-système remplit sa fonction lorsqu'il offre une réalisation satisfaisante des opérations définies par les interfaces qu'il fournit. Même s'il a été esquissé par les architectes, le contenu du sous-système peut nécessiter quelque amélioration de la part de l'ingénieur de composants, à mesure qu'évolue le modèle de conception. Certaines questions d'ordre général doivent être prises en considération :

• pour clarifier la façon dont la conception interne d'un sous-système réalise ses intérim. ou ses cas d'utilisation, on peut créer des collaborations entre éléments contenus dans ce sous-système. Ceci permet de justifier les éléments contenus dans le sous-système.

Faites en sorte de réduire le plus possible les dépendances par rapport aux autres sous-syslemcs et/ou interfaces. Vous pouvez toujours envisager de déplacer les classes qui seraient trop dépendantes d'autres sous-systèmes de ces sous-systèmes.

• pour chaque interface fournie par le sous-système, des classes de conception ou d'autTM sous-systèmes au sein de ce sous-système doivent également fournir l'intérim e en question ;

II est nécessaire de définir et d'actualiser les dépendances d'un sous-système à l'égard d'autres sous-systèmes dont les éléments possèdent des associations originaires d'éléments de ce sous-système. Néanmoins, si ces autres sous-systèmes fournissent des interfaces, les dépendances (relation d'utilisation) doivent plutôt être déclarées par rapport à ces interfaces. Il vaut mieux dépendre d'une interface que d'un sous-système, car un sous-système peut très bien être remplacé par un autre doté d'une conception interne différente, alors qu'il ne sera pas forcément nécessaire de changer d'interface.

i iniinements d ' a c t i v i t é s principaux m II

Classe de conception fournissant une interface dans un sous s y s t è m e Le sous-système Gestion des factures par l'acheteur fournit l'intiiilace i .n i m >• I in génieur de composants responsable de ce sous-système décide de laisser la classe i ai t u n réaliser cette interface (voir la figure 9.45). On aurait aussi bien pu faire réaliser l'interface pai une quelconque autre classe de conception, puis utiliser la classe Facture.

Conception CHAPITRE

9

• La vue architecturale du modèle de conception, avec ses éléments significatifs sur le plan architectural. Comme nous l'avons indiqué plus haut, les éléments du modèle d'analyse significatifs sur le plan architectural servent de spécification lors de l'ébauche des éléments du modèle de conception significatifs sur le plan architectural. La conception se traduit également par le modèle de déploiement, qui décrit toutes les conli gurations réseau sur lesquelles le système doit être distribué. Le modèle de conception com prend les éléments suivants : • les nœuds, leurs caractéristiques et les connexions ; • une première correspondance des classes actives sur les nœuds ; • la vue architecturale du modèle de déploiement, avec ses éléments signilicalils soi |< p l u architectural.

R é s u m é d e la c o n c e p t i o n Le pi mcipal résultat de la conception est le modèle de conception qui tente de préserver une .uIK line du système imposée par le modèle d'analyse et sert de plan d'élaboration et de Mr.miction à l'implémentation. Le modèle de conception se compose des éléments Indiqués ci-dessous. • I es sous-systèmes de conception et de service et leurs dépendances, interfaces et contenu. I es sous-systèmes de conception des deux couches supérieures (c'est-à-dire de la couche ipécifique à l'application et de ta couche générale aux applications) sont esquissés à partir des paquetages d'analyse (section 9.5.1.2, paragraphe « Identification des sous-systèmes d'application »). Certaines des dépendances entre sous-systèmes de conception sont issues des dépendances entre les paquetages d'analyse correspondants (section 9.5.1.2, paragraphe « Définition des dépendances entre sous-systèmes »), tandis qu'une partie des interfaces dérive des classes d'analyse (section 9.5.1.2, paragraphe « Identification des interfaces de sous-système »). • I es classes de conception, y compris les classes actives, et leurs opérations, attributs, i dations et exigences d'implémentation. Certaines classes de conception significatives sur le plan architectural sont définies à 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 même que certaines classes actives sont issues de classes d'analyse (section 9.5.1.3, paragraphe « Identification des classes actives »). D'une manière générale, les classes d'analyse servent de spécification lors de l'ébauche des classes de conception (section 9.5.3.1).

9.7

Comme nous le montrerons dans les chapitres suivants, les modèles de conception et de déploiement sont considérés comme les principales entrées des activités ultérieures d'impie mentation et de tests. • Les sous-systèmes de conception et de service seront implémentés par des SOUS-systèmes d'implémentation contenant les véritables composants : fichiers de code source, scripts, binaires, exécutables et autres éléments du même type. Ces sous-systèmes d'implémentation présenteront une relation de traçabilité un-à-un (isomorphe) avec les sous-systèmes de conception. • Les classes de conception seront implémentées par des composants fichiers contenant le code source. I l n'est pas rare que plusieurs classes de conception soient implémentées par un seul et unique composant fichier ; cela dépend du langage de programmation choisi. Par ailleurs, les classes de conception actives renvoyant à des processus indépendants serviront d'entrée lors de l'identification des composants exécutables. • Les réalisations-conception de cas d'utilisation seront utilisées lors de la planification et de l'exécution par étapes limitées et gérables de l'effort général d'implémentation, qui débouchera sur des « constructions ». Chaque construction implémentera principalement un ensemble complet ou partiel de réalisations de cas d'utilisation. • Le modèle de déploiement et les configurations réseau serviront lors de la distribution du système par le déploiement de composants exécutables sur des nœuds.

Références 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 »,

Object-Oriented Software Engineering: A Use-Case Driven Approach, Reading. M A Addison-Wesley, 1992 (quatrième édition révisée, 1993).

• Les réalisations-conception de cas d'utilisation, qui décrivent la façon dont les cas d'utilisation sont conçus en termes de collaborations au sein du modèle de conception. D'une manière générale, les réalisations-analyse de cas d'utilisation servent de spécification lors de l'ébauche des réalisations-conception de cas d'utilisation (section 9.5.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 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 Spécification, Object Management Group, Framingham, MA, 1998. Internet : www.omg.org.

1 0 Implémentation

10.1 I n t r o d u c t i o n L'implémentation part des résultats de la conception pour implémenter le système sous forme de composants, c'est-à-dire de code source, de scripts, de binaires, d'exécutables et d'autres éléments du même type. Heureusement, l'armature de l'architecture du système a été créée pendant la conception. Le principal objectif de l'implémentation est donc d'étoffer l'architecture et le système dans son ensemble. Pour être plus précis, les objectifs de l'implémentation sont les suivants : • planifier les intégrations du système nécessaires à chaque itération. Nous adoptons une démarche incrémentale ; l'implémentation du système revient donc à une succession d'étapes courtes et parfaitement gérables ; • distribuer le système en faisant correspondre les composants exécutables à des nœuds du modèle de déploiement. Cette répartition s'appuie avant tout sur les classes actives identifiées au cours de la conception ; • implémenter les classes et les sous-systèmes de conception identifiés au cours de la conception. Les classes de conception doivent, en particulier, être implémentées sous forme de composants fichiers contenant du code source ; • tester les composants unité par unité, puis les intégrer en les compilant et en les reliant les uns aux autres pour former un ou plusieurs exécutables avant de leur faire suhii les lests d'intégration et les tests système. Ce chapitre et les suivants présentent la réalisation 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'activités est très proche de celle adoptée pour l'enchaînement il'acliviii i conception.


figure 10.1 liimiilleurs uiir/uits tlims

et impliqués

l"implémen-

inii-(|i.iif,i, 6grnt( /•lien syrill.NHi

I

ttlllon.

ri):;|>oii!..ihli' nisnl) «l<•

I Modèle Description de Modèle de d'implémentation l'architecture déploiement

Plan de construction des intégrations

Composant Sous-nystômo d'implémentation

Interface

Implémentation CHAPITRE

10

Mm

10.3 A r t e f a c t s 10.3.1 Artefact : modèle

d'implémentation

Le modèle d'implémentation décrit la façon dont les éléments du modèle de conception, tels que les classes de conception, sont implémentés par des composants de type fichiers de code source, exécutables, etc. I l présente également l'agencement des composants en fond ion des mécanismes de structuration et de modularisation disponibles dans l'environnenn m d'implémentation et le ou les langages d'implémentation utilisés, ainsi que les dépeiuliiiu es qui lient les composants les uns aux autres. Le modèle d'implémentation définit une hiérarchie, comme l'indique la ligure I0.3 Il est représenté par un système d'implémentation montrant le sous-syslèinc «le niveau siqu rieur du modèle. L'utilisation d'autres sous-systèmes offre, par conséquent, un moyen >ti découper le modèle en portions plus gérables.

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 Si l'implémentation est au cœur des préoccupations des itérations de construction, elle intervient également lors de l'élaboration - pour la création de l'architecture exécutable de référence - et au cours de la transition -pour la prise en compte d'anomalies apparues tardivement, par exemple celles qui sont détectées à la livraison de la version bêta du système (indiquée dans la figure 10.2 par un pic dans la colonne de transition).

Les artefacts du modèle d'implémentation font l'objet de descriptions détaillées dan li sections qui suivent. Figure 10.3 Le

modèle

d'implémentation

ligure 10.2

Phases

l'oint de • i invergence ae de convergence / implémentation.

Enchaînements d'activités

Création

, Élaboration ,

Construction

est une de

Transition

hiérarchie

sous-systèmes

d'implémentation

i n c i

dotés

de


Système d'implémentation

composants et

Besoins

d'interfaces.

Analyse Conception | Implémentation Composant

Interface

Tests Itérations préliminaires

Iter. #1

iter. #2

Iter. #n

Iter. #n+1

Iter. #n+2

iter. #m

70.3.2 Artefact :

iter. #m+1

composant

Un composant est l'« empaquetage » d'éléments de modèle, tels que les classes de COtl ception du modèle de conception [5]. Parmi les stéréotypes standard, citons :

Itérations

• « e x é c u t a b l e », qui désigne un programme pouvant s'exécuter sur un nœud ; Le modèle d'implémentation illustrant l'implémentation réelle du système sous forme de composants et de sous-systèmes d'implémentation, il est naturel de le conserver tout au long du cycle de vie du logiciel.

• « f i c h i e r », qui désigne un fichier contenant du code source ou des données ; • « bi bl i o t h è q u e », qui désigne une bibliothèque statique ou dynamique ; • « t a b l e », qui désigne une table de base de données ; • « document », qui désigne un document.

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

Il est possible, lors de la création de composants dani Ull Mvim UMUl d'implémentation donné, de modifier ces stéréotypes afin qu'ils reflètent 111 qui "Ipfl ••• n véritablement les composants. Les composants présentent les caracléi isin|in••• suivante-, • ils entretiennent des relations de traçabilité avec les élément! de modèle qu'ils implémentent ; • i l n'est pas rare qu'un composant implémente plusieurs éléments tels que des classes de conception ; néanmoins, le mode de création précis île celte traçabilité dépend de la structuration et de la modularisation prévues pour les fichiers de code source, selon le langage de programmation utilisé ;

BUfl

Traçabilité d'un composant avec une classe de conception


10

il peut exister des dépendances de compilation entre composants, indiquant quels sont les composants nécessaires pour compiler un composant spécifique. jflfHfl

Dépendances de compilation entre composants Dans le système interbancaire, le composant (fichier) VirementsEntreComptes.java se compile en un composant (exécutable) Vi rementsEntreComptes.cl ass (voir la figure 10.6). 1

Figure 10.6 Dépendances de compilation entre deux composants.

ZD «fichier» T"^ VirementsEntreComptes.java 1\

Dans le système interbancaire, la classe de conception Vi rements entre comptes est im«compilation»

plémentée par le composant de code source Vi rementsEntrecomptes. java, car une convention et la pratique courante de Java imposent de créer un fichier de code source « .java » pour chaque classe, même si cette règle n'est pas toujours respectée. Quoi qu'il en soit, cette

' Igure 10.4 lijiendances de . ruçabilité entre < omposants et fiasses de onception.

"H VirementsEntreComptes.class

ception et d'implémentation (voir la figure 10.4).

Z3 «exécutable»

implémentation est modélisée par une dépendance de traçabilité entre les modèles de con-


Virements entre comptes


«fichier» VirementsEntreComptes.java

les composants fournissent les mêmes interfaces que les éléments de modèle qu'ils implémentent ;

jflgff

10.3.2.1

Stubs

Un stub (ou bouchon) est un composant dont l'implémentation, minimale ou dédiée à un objectif précis, peut être utilisée pour développer ou tester un autre composant dépendant du stub. Vous en trouverez une définition semblable dans [1]. On peut utiliser les stubs pour réduire le plus possible le nombre de nouveaux composants nécessaires à chaque nouvelle version (intermédiaire) du système, ce qui limite les problèmes d'intégration et simplifie les tests d'intégration (voir la section 10.5.2, « Activité : intégrer le système »). Figure 10.7 Contenu et associations clés des sous-systèmes.

Interfaces en conception et en implémentation

Sous-système d'implémentation

Dans le système 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 implémente la classe Virements entre comptes (voir la

réaliser

figure 10.5). Figure 10.5 / ts composants i.mrnissent les ncmes interfaces que les classes i[lt 'ils

Modèle de conception Virements entre comptes

<-

Modèle d'implémentation I «fichier»

«trace»

VirementsEntreComptes.java

à

~5

implémentent.

Composant

1. Pour être plus précis, le composant est en fait interprétable par la machine virtuelle Java.

Virements

Virements

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


0,3.3 Artefact : sous-système

d'implémentation

I .es sous-systèmes d'implémentation offrent un moyen de léparlii les nileini i il odèle d'implémentation en portions plus gérables (voir la ligure 10.7). Un sous syslèmi peul clic Cl institué de composants, d'interfaces et d'autres sous-systèmes (de façon récursive). Il peut, en outre, réaliser - et par conséquent fournir - des interfaces représentant les fonctions exportées sous forme d'opérations. II est important de comprendre qu'un sous-système d'implémentation se manifeste par un « mécanisme d'empaquetage » dans l'environnement d'implémentation, par exemple : • un paquetage en Java [2] ; • un projet en Visual Basic [3] ; • un répertoire de fichiers dans un projet C++ ; • un sous-système dans un environnement de développement intégré tel que Rational Apex ; • un paquetage de la vue de composants dans un outil de modélisation visuelle tel que Rational Rose. I ,a notion de sous-système d'implémentation bénéficiera d'une sémantique légèrement ilIniée lorsqu'elle s'exprimera dans un environnement d'implémentation. Toutefois, nous aborderons dans ce chapitre l'implémentation sur un plan générique applicable à la plupart des environnements d'implémentation. I ,cs sous-systèmes d'implémentation sont très fortement liés aux sous-systèmes de conI eplion du modèle de conception (voir le chapitre 9, section 9.5.4, «Activité : concevoir un sous-système »). En fait, un sous-système d'implémentation doit avoir une traçabilité un-àiin (isomorphe) avec le sous-système de conception correspondant. Rappelez-vous qu'un sous-système de conception définit déjà : • les dépendances par rapport à d'autres sous-systèmes et/ou interfaces d'autres soussystèmes ; • les interfaces que doit fournir le sous-système ; • les classes de conception ou, de façon récursive, les autres sous-systèmes de conception au sein du sous-système qui doivent fournir les interfaces que propose le sous-système lui-même. ( 'es aspects sont importants pour le sous-système d'implémentation correspondant, parce qu'il doit : • définir des dépendances analogues envers les autres sous-systèmes d'implémentation et/ ou interfaces (correspondants) ; • fournir les mêmes interfaces ; • définir les composants ou, de façon récursive, les autres sous-systèmes d'implémentation contenus dans le sous-système qui doivent fournir les interfaces que propose le soussystème lui-même. La figure 10.8 clarifie la relation entre les modèles de conception et d'implémentation.

Figure 10.8

10

Wtm

Les changements intervenant dans la manière dont les sous-systèmes fournissent et utilisent les interfaces, ou affectant les interfaces elles-mêmes, sont décrits dans l'enchaînement d'activités de conception (veuillez vous reporter au chapitre 9, section 9.5.4, « Activité : concevoir un sous-système »). Ils ne sont donc pas traités dans l'enchaînement d'activités d'implémentation, bien qu'ils influent également sur le modèle d'implémentation. Notez que la correspondance que nous venons de décrire vaut également pour les soie, i y i tèmes de service du modèle de conception. Les sous-systèmes d'implémentation remontant à ces sous-systèmes de service résideront par conséquent à un niveau inférieur dans la lue rarchie du modèle d'implémentation et rempliront le même rôle que les sous systèmes ili service en question : ils permettront de structurer le système en fonction des sen u iv qui celui-ci propose. C'est pourquoi les sous-systèmes d'implémentation qui remoiileiii n il< sous-systèmes de service du modèle de conception sont susceptibles d'cncapsulei des i uni posants exécutables fournissant les divers services du système.

Sous-système d'implémentation du modèle d'implémentation ayant une traçabilité un-à-un avec un soussystème de conception du modèle de conception. Les sous-systèmes des différents modèles fournissent la même interface (a) et dépendent de la même interface (fi). Les composants du sous-système d'implémentation implémentent les classes du soussystème de conception.



10.3.4 Artefact : interface Les interfaces sont décrites en détail dans le chapitre 9. On peut employer les mêmes mlei faces dans le modèle d'implémentation pour spécifier les opérations implémentées put les composants et les sous-systèmes d'implémentation. Par ailleurs, comme nous l'avons lait remarquer plus haut, les composants et les sous-systèmes d'implémentation peuvent avuii des « dépendances d'utilisation » vis-à-vis des interfaces (figure 10.9).

i.... ,.,.< h.iinements d ' a c t i v i t é s principaux


11„ | imposant réalisant (et, par conséquent, fournissant) une Interfai r rjoil lm| ton ,,, innent toutes les opérations définies par cette interface. De même qu'un sous système d'implémentation fournissant une interface doit également contenir les compoiantl ou, de manière récursive, les autres sous-systèmes qui proposent cette interlacc.

wii

elés

< réaliser

I/III e


Interface

Composant

S o u s - s y s t è m e d'implémentation fournissant une interface Le système interbancaire dispose d'un sous-système d'implémentation nommé Gesti onDesComptes (un paquetage Java), qui fournit l'interface Virements (voir la figure 10.10).

in lu i . v \ifme nlle\(

GestionDesComptes

'omptes

l'Interface

a Virements

«Sous-système d'implémentation.

10.3.5 Artefact : description d'implémentation)

de l'architecture (vue du

10

modèle

La description de l'architecture contient une vue architecturale du modèle d'implémentation (annexe C), qui en décrit les artefacts significatifs sur le plan architectural (voir la figure 10.12). Les artefacts énumérés ci-dessous sont généralement considérés comme importants sui le plan architectural. • La décomposition du modèle d'implémentation en sous-systèmes, avec leurs inlcrlai es i i leurs dépendances mutuelles. D'une manière générale, cette décomposition est fondamentale pour l'architecture. Mais, comme les sous-systèmes d'implcntentation mit une traçabilité un-à-un avec les sous-systèmes de conception, qui son! susceptible! de figurer dans la vue architecturale du modèle de conception, i l est généraleincnl lili di décrire les sous-systèmes d'implémentation dans la vue architecturale du motleli d'implémentation. • Les composants clés, comme ceux qui remontent à des classes de conception significatives sur le plan architectural, les composants exécutables cl les composant! généraux, centraux, ceux qui implémentent des mécanismes génériques de conception dont dépendent d'autres composants. 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 modèle d'implémentation. Figure 10.12 Vue du

architecturale modèle


d'implémentation.

m

II If

vue architecturale

package GestionDesComptes

public Interface Virements {

' fini I r sous-

// interfaces fournies :

m r

Virements,

nllrsl

public Compte creer(Client titulaire, Solde argent,

omptes.

id_compte NumeroCompte);


public vold Depot (Montant argent, String raison) public vold Retrait (Montant argent, String raison); }

10.3.6 Artefact : plan de construction

des

intégrations

Il est très important de construire le logiciel de façon incrémentale, par île. étapes l'ai îles a gérer dont chacune ne laisse apparaître que des problèmes limités d'intégration ou île tests Le résultat de chaque étape est appelé « construction ». Il s'agit d'une version exél Utabll du système, en général d'une partie spécifique du système. Chaque construction est I II lUlti soumise à des tests d'intégration (comme le décrit le chapitre 11) avant la mise au poinl 'le la construction suivante. Afin d'anticiper toute construction défaillante (par exemple, une traction ne réussissant pas les tests d'intégration), 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

10.4.1 Travailleur : architecte

• on peut créer très tôt une version exécutable du système, au lieu d'attendre une vécu m plus complète. Les tests d'intégration débutent alors très vile, cl la version exécutable permet de faire une démonstration des caractéristiques du système aux membres de l'équipe interne comme aux intervenants extérieurs ;

10.4 T r a v a i l l e u r s

irôle de version afin qu'il soit possible de revenir à une construction précédente Cette approche incrémentale présente divers avantages :

• les anomalies sont plus faciles à localiser pendant les tests d'intégration, car seule une partie du système, petite et gérable, vient enrichir une construction existante. Il est même fort probable (mais ce n'est pas toujours le cas) que les anomalies soient précisément liées à cette partie ajoutée ou modifiée ; • les tests d'intégration ont tendance à être plus exhaustifs que ceux pratiqués à l'échelle du système global, car ils portent sur des parties plus limitées et mieux maîtrisées. L'intégration incrémentale (annexe C) est à l'intégration système ce que le développement itératif contrôlé est au développement logiciel en général : l'un et l'autre s'appuient sur des incréments de fonctions relativement limités et gérables. Si l'on se replace dans le contexte d'un développement itératif, chaque itération donnera lieu à au moins une construction. Mais les fonctions destinées à être implémentées par une itération spécifique sont souvent trop complexes pour être intégrées en une seule construction. À l'inverse, i l est possible que l'on doive créer une séquence de constructions au sein même de l'itération, chacune représentant un pas en avant et une étape gérable par l'ajout d'un modeste incrément au système. Chaque itération ajoutera au système un incrément plus important, éventuellement formé de l'accumulation de plusieurs constructions (voir le chapitre 5).


10

mm

Au cours de la phase d'implémentation, l'architecte est responsable de l'intégrité du modèle d'implémentation, dont il doit s'assurer de l'exactitude, de la cohérence et de la lisibilité yU, baies. Dans le cas de l'analyse et de la conception de vastes systèmes complexes, il est pos sible qu'un autre travailleur prenne en charge les responsabilités du sous-système de niveau supérieur (c'est-à-dire le système d'implémentation) du modèle d'implémentation Le modèle est jugé correct lorsqu'il implémente les fonctions décrites par le modèle .I, . on ception, ainsi que toute exigence supplémentaire (pertinente), et uniqucnicni i ei fol I L'architecte est également chargé de l'architecture du modèle d'implcincntalion. < v i ,, h de l'existence des parties de ce modèle significatives sur le plan architectural, telles qn i II figurent dans la vue architecturale du modèle. Rappelez-vous que celle vue lait paiiie de la description de l'architecture du système (voir la figure 10.13). Figure 10.13 Responsabilités de

l'architecte

au cours de l'implémentation.


Un plan de construction de l'intégration décrit la séquence de constructions requise dans une itération. Plus précisément, ce type de plan décrit, pour chaque construction, les éléments suivants : • les fonctions devant être implémentées par la construction. I l s'agit d'une liste de cas d'utilisation et/ou de scénarios (complets ou partiels), comme nous l'avons indiqué dans les chapitres précédents. Cette liste peut mentionner des exigences supplémentaires ;

vue architecturale

• les parties du modèle d'implémentation affectées par la construction. I l s'agit d'une liste des sous-systèmes et composants nécessaires à l'implémentation des fonctions que doit livrer la construction.


vue architecturale


Enfin, l'implémentation livre un résultat important : la correspondance des composants exe cutables avec les nœuds. C'est l'architecte qui est responsable de celle correspondance, décrite dans la vue architecturale du modèle de déploiement. Pour de plus .impies détail! consultez le chapitre 9, section 9.3.7, « Artefact : modèle de déploiement ».

La section 10.5.2, « Activité : intégrer le système », décrit une approche système pour la création d'un plan de construction des intégrations.

Notez que l'architecte n'est pas responsable du développement continu et de la m. aiain i des divers artefacts figurant dans le modèle d'implémentation, qui sont du ressort de l'inu.i nieur de composants concerné.

J !


10.4.2 Travailleur : ingénieur

de

composants

L'ingénieur de composants définit et actualise le code source d'un ou de plusieurs compo sants fichiers, en s'assurant que chaque composant implémente la bonne l'onction (par exemple, telle qu'elle a été spécifiée par les classes de conception). En général, l'ingénieur de composants est également chargé de veiller à l'intégrité d'un ou de plusieurs sous-systèmes d'implémentation. Ces derniers ayant une traçabilité un-à-un avec les sous-systèmes de conception, la plupart des changements affectant ces sous-systèmes seront pris en charge pendant la conception. Mais l'ingénieur de composants doit quand même s'assurer que le contenu (par exemple, des composants) des sous-systèmes d'implémentation est juste, que leurs dépendances vis-à-vis d'autres sous-systèmes et/ou interfaces sont exactes et qu'ils implémentent correctement les interfaces qu'ils fournissent (voir la figure 10.14).

Figure 10.15 Responsabilités d'un intégrateur système.


10

o

E n c h a î n e m e n t d'activités

1

O f_J Ingénieur de composante

l'implé-

mentation.


f~J Intégrateur système responsable de

1 Plan de construction de l'intégration

10.5

Après avoir décrit, dans les sections précédentes, le travail d'implénicntatioii en teinii t.i tiques, nous allons maintenant envisager le comportement dynamique du diagramme d'au n vités (voir la figure 10.16).

D'une manière générale, i l est souhaitable de confier à l'ingénieur de composants chargé d'un sous-système la responsabilité des éléments de modèle (par exemple, des composants) que contient ce sous-système. En outre, pour instaurer un développement parfaitement fluide, i l semble naturel que le même ingénieur de composants porte la responsabilité d'un sous-système et de son contenu tout au long des enchaînements d'activités de conception et d'implémentation. Cet ingénieur doit, par conséquent, concevoir et implémenter les classes sous sa responsabilité. Figure 10.14 Responsabilités d'un ingénieur ,le composants pendant

Le principal objectif de l'implémentation est, précisément, d'implémenter le système. C'est l'architecte qui lance le processus en esquissant les composants clés du modèle d'implémentation. Ensuite, l'intégrateur système planifie les intégrations du système nécessitées par l'itération en cours sous forme de séquence de constructions. I l décrit, pour chacune de ces constructions, les fonctions à implémenter et indique les parties du modèle d'implémentation (c'est-à-dire les sous-systèmes et les composants) qui seront concernées. Les exigences imposées aux sous-systèmes et aux composants de la construction sont ensuite implémentées par les ingénieurs de composants, et les composants qui en résultent sont testés individuellement, puis intégrés dans une construction par l'intégrateur système. Ce dernier transmet la nouvelle construction aux testeurs d'intégration, qui lui font subir des tests d'intégration (voir le chapitre 11). Les développeurs peuvent alors commencer l'implémentation de la construction suivante, en prenant en considération les anomalies détectées dans la construction précédente.

O Composant

10.4.3 Travailleur : intégrateur

Interface

système

L'intégration du système dépasse les attributions de l'ingénieur de composants. Cette responsabilité revient à l'intégrateur système, qui planifie la séquence de constructions nécessitée par chaque itération et l'intégration de chaque construction une fois ses diverses parties implémentées. Cette planification se traduit par un plan de construction des intégrations (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.

J


igure 10.16 . enchaînement d'activités de l'implémentation, vec les availleurs y prenant part et leurs activités. r

_

: implémenter


10

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 modèle d'implémentation »). Figure 10.17 Entrées et résultat de l'implémentation de l'architecture. Modèle de conception

O

D


--> Modèle de déploiement

Implémenter un sous-système

-*0.5.1 Activité

l'architecture

..7

S

,-' CompoHiinl [esquisse et tWonlimlloiiHMil correspondance nvm: l«a mmtiU|

g»^»*.

Architecture d'implémentation

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 |

Description de l'architecture [vues des modèles de conception et de déploiement]

L'implémentation de l'architecture a pour objectif de délimiter le modèle d'implémentation et son architecture : • en identifiant les composants significatifs sur le plan architectural, tels que les composants exécutables ; • en assurant la correspondance des composants avec des nœuds dans les configurations réseau appropriées. Souvenez-vous que c'est pendant la conception de l'architecture (voir le chapitre 9, section 9.5.1, «Activité : conception architecturale ») que sont esquissés les sous-systèmes de conception, avec leur contenu et leurs interfaces. On utilise ensuite, au cours de l'implémentation, des sous-systèmes d'implémentation ayant une traçabilité un-à-un avec ces soussystèmes de conception et fournissant les mêmes interfaces. L'identification de ces sous-systèmes d'implémentation et de leurs interfaces est donc relativement évidente et ne sera pas traitée ici. La principale difficulté de l'implémentation consiste à créer, au sein des sous-systèmes d'implémentation, des composants qui implémentent les sous-systèmes de conception correspondants. Au cours de cette activité, l'architecte précise et actualise la description de l'architecture, ainsi que les vues architecturales des modèles d'implémentation et de déploiement. 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

Il est assez pratique, pour lancer le travail d'implémentation, d'identifier les composants significatifs sur le plan architectural tôt 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 dès le départ avec une certaine évidence lors de l'implémentation des classes, tout simplement parce qu'ils se contentent d'offrir un moyen de regrouper l'implémentation de ces classes dans des fichiers de code source. C'est pourquoi les développeurs doivent veiller à ne pas identifier un nombre trop élevé de composants à ce stade et à ne pas se fourvoyer dans les détails, sous peine d'avoir à refaire toute une partie du travail au moment de l'implémen-

Identification des composants exécutables et correspondance avec les nœuds Pour identifier les composants exécutables pouvant être déployés sur des nœuds, on prend en compte les classes actives déterminées pendant la conception et dont chacune se voit affecter un composant exécutable représentant un processus lourd. I l peut également être question de détecter d'autres composants fichiers et/ou binaires nécessaires à la création de composants exécutables, bien que l'importance de cette opération soit relativement secondaire. RWflJfj u

m

Identification des composants exécutables Le modèle de conception comporte une classe active nommée Traitement des demandes

m

de r è g l ement. La phase d'implémentation permet l'identification d'un composant exécutable correspondant appelé TraitementDesDemandesDeRègl ement (voir la figure 10.18). Figure 10.18



On utilise des classes actives pour identifier les composants exécutables.

Modèle d'implémentation TraitementDesDemandes DeRèglement

PARTIE

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

f

m

II

Un examen plus approfondi des modèles de conception et île ileploieineni pet met de vériflet si des objets actifs sont affectés à des nœuds. Si c'est le cas. les compoitntl I) .1 e Iraça bilité avec les classes actives correspondantes doivent être déployés sut les mêmes uu-utls. BfflgH

Déploiement de composants sur des nœuds


et

I line 10.19

résultat

de l'intégration système.

en

: Serveur acheteur

de forment

une base



10

O

D Intégrateur système

Plan de construction de l'Intégration

w w

-

Intégrer système

essentielle à cette

,-7 le

activité. Modèle de conception

r

N œ u d s avec leurs instances de composant

affectés à des déploiement «séquence

Exigences supplémentaires-.

de cas

d'utilisation du

Un objet actif de la classe Traitement des demandes de r è g l e m e n t est affecté au nœud

N œ u d s avec leurs objets actifs

du

Les

réalisationsconception modèle

Serveur acheteur.

conception

Étant donné que le composant Trai tementDesDemandesDeRègl ement implémente la classe Traitement des demandes de r è g l e m e n t (voir l'exemple précédent), il doit être, lui aussi, déployé sur le nœud Serveur acheteur (voir la figure 10.19).

|

\.. s objets actifs

: Serveur acheteur

i

Modèle d'implémentation [constructions ultérieures!

Modèle d'implémentation [constructions précédentes]

• -mis impliquent I f

des donne lieu

. omposonts. des demandes de règlement

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

des demandes de règlement «exécutable»

Nous allons aborder, dans cette section, les moyens de planifier le contenu d'une construction ultérieure, que l'on se fonde sur une construction existante ou que l'on parte de zéro. Nous considérons également que l'on nous fournit un certain nombre de cas d'utilisation et/ ou de scénarios (c'est-à-dire de chemins à travers des cas d'utilisation) et d'autres exigences devant être implémentées dans l'itération en cours.

La correspondance des composants sur les nœuds est particulièrement significative pour l'architecture du système et doit être décrite dans la vue architecturale du modèle de déploiement.

0.5.2 Activité

: intégrer

le

Vous trouverez ci-dessous quelques critères applicables à une construction venant après une autre construction. • La construction doit ajouter des fonctions par rapport à la construction précédente à travers l'implémentation de cas d'utilisation complets ou de scénarios de ces cas d'utilisation. (Pour plus de clarté, nous emploierons cas d'utilisation pour cas d'utilisation et/ou scénario dans le reste de cette liste.) Les tests d'intégration 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).

système

L'intégration du système a pour objectifs : • la création d'un plan de construction de l'intégration décrivant les constructions nécessitées par une itération et les exigences pesant sur chacune d'elles ;

I.

• l'intégration de chaque construction avant qu'elle ne soit soumise aux tests d'intégration.

• La construction ne doit pas comprendre une trop grande quantité de composants nouveaux ou affinés, car cette abondance pourrait rendre l'intégration de la construction cl la conduite des tests d'intégration particulièrement délicates. Si nécessaire, on peul implémenter certains composants en tant que stubs, afin de réduire le plus possible le nombre de nouveaux composants introduits dans la construction (voii la seeiiiui 111 1 ' I « Stubs »).

I I

• Chaque construction doit se fonder sur la précédente et se développer de façon asi eiulann et latérale dans la hiérarchie des sous-systèmes en couches. Cela signifie que les premières constructions doivent partir des couches inférieures (les couches de uiiildlcwiu * et de logiciel système), tandis que les constructions suivantes remontent en direction de II couche générale aux applications et de la couche spécifique à l'application. Pourquoi 7

I I


II

Tout simplement parce qu'il est difficile d'implémentci des i posants dâQI IfU OM supérieures avant que les composants nécessaires
Tenez compte de l'impact qu'a l'implémentation des besoins sur ces sous-systèmes d'implémentation et sur les composants au-dessus de la construction en cours. Notez que ces besoins sont exprimés sous forme de sous-systèmes et de classes de conception, comme l'indique l'étape 3. Évaluez si cet impact est acceptable ou non en fonction des critères énoncés plus haut. Si c'est le cas, planifiez l'implémentation du cas d'utilisation dans la construction suivante ; sinon, reportez-la à une construction plus tardive.

4.

Identifiez les sous-systèmes d'implémentation et les composants du modèle d'implémentation remontant aux sous-systèmes et aux classes de conception trouvés au cours de l'étape 2.

3.

Identifiez les sous-systèmes et les classes de conception prenant part à la réalisationconception de cas d'utilisation.

2.

implémentation CHAPITRE

10

10.5.2.2 I n t é g r a t i o n d'une construction

Si la construction a été correctement planifiée selon les indications de l'étape précédente, son intégration doit être relativement directe. I l faut recueillir les versions appropriées de sous-systèmes d'implémentation et des composants, les compiler et les lier en uni' <,« traction. Notez qu'il peut être nécessaire d'effectuer la compilation de bas en li.un rapport à la hiérarchie en couches, l'existence de dépendances de compilation dM fil supérieures envers les couches inférieures n'étant pas à exclure. v

La construction qui en résulte est ensuite soumise aux tests d'intégration, pull >" Il I système si elle a passé les premiers avec succès. Il s'agit de la dernière constiui sein d'une même itération (voir le chapitre 11).

10.5.3 Activité

: implémenter

un

sous-système

Le propos de l'implémentation d'un sous-système est de s'assurer que , ,• sou remplit son rôle dans chaque construction, selon les prévisions du plan îles i onsliin lions
o

résultat

sous-systèmes.

des

l'implémentation

de

D

Plan de construction de l'intégration <.


N

Sous-système d'implémentation [implémente pour une construction]

Description de l'architecture [vue du modèle d'implémentation]

- 'T'implémenter -. un sous-système

Sous-système de conception [conçu]

Les résultats doivent apparaître dans le plan de construction de l'intégration et être communiqués aux ingénieurs de composants responsables des sous-systèmes d'implémentation et des composants concernés. Ces ingénieurs peuvent alors commencer l'implémentation des sous-systèmes d'implémentation et des composants en question dans la construction en cours (comme le décrivent les sections 10.5.3, « Activité : implémenter un sous-système » et 10.5.4, «Activité: implémenter une classe»), puis les tester unité par unité (comme le décrit la section 10.5.5, « Activité : effectuer les tests unitaires »).

Interface [implémentée pour une construction]

Interface [conçue]

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

Enfin, les sous-systèmes d'implémentation et les composants sont transmis pour intégration à l'intégrateur système (voir la section suivante).

sous-systèmes

On considère qu'un sous-système remplit ses objectifs lorsque les beioim a Implémi i dans la construction en cours et ceux qui affectent le sous-système sont eoneeien pli mentes par des composants de ce sous-système. Si le contenu du sous-système (par exemple, les composants qu'il renferme) Ml di I Il les architectes, i l peut nécessiter quelque amélioration de la pari de l'ingénieu! dl l ompu



sants, en fonction de l'évolution du modèle d'implémentation. Cette amélioration peul l OU cerner les aspects décrits ci-dessous.

Notez que si le sous-système de conception contient (de façon récursive) d'autres sous-systèmes de conception exigés par la construction en cours, la méthode est identique : chacun de ces sous-systèmes de conception doit alors être implémente par un sous-système d'implémentation correspondant détenu par le sous-système d'implémentation considéré.

f

• Chaque classe du sous-système de conception correspondant nécessaire a la eonslnn lion en cours doit être implémentée par des composants du sous-système d'iiuplenicnlalion (voir la figure 10.22).

r

10

Figure 10.23 Une interface


exigée par une construction


(a)

doit également

être

fournie par un sous-système d'implémentation.

• Chaque interface fournie par le sous-système de conception correspondant et nécessaire à la construction en cours doit également être fournie par le sous-système d'implémentation. Ce dernier doit, par conséquent, détenir soit un composant, soit (de façon récursive) un sous-système d'implémentation fournissant l'interface en question (voir la figure 10.23). r Igure 10.22 / r.v classes de


Interfaces nécessaires à la construction en cours


c onctptton «sous-système d'implémentation»

"(luises par une I ' (instruction sont • •nplémentées

S o u s - s y s t è m e fournissant une interface

par

îles ci imposants.

1

«fichier»

Figure 10.24 Gestion des factures par l'acheteur |

Le composant

ï

Traitement des •«fichier»

factures fournit l'interface

Facture. Traitement des factures

Classes nécessaires à la construction en cours

À partir de là, les ingénieurs de composants peuvent commencer à implémenter les éléments indispensables par des composants du sous-système (comme le décrit la section l u i «Activité : implémenter une classe») et à les tester par unité (comme le décrit la section 10.5.5, « Activité : effectuer les tests unitaires »).

I

Le sous-système résultant de ce processus est alors transmis pour intégration ;i riniep.iaieiu système (comme le décrit la section 10.5.2, « Activité : intégrer le système »).

1

i



5.4 Activité

: implémenter

une

classe

• esquisser un composant fichier qui contiendra le code source ;

ï

L'objectif de cette activité est d'implémenter une classe de conception dans un i nmposnnl fichier et s'articule autour des étapes suivantes (voir la figure 10.25) :

I

i

• générer le code source à partir de la classe de conception et des relations qu'elles entretient avec d'autres éléments ; • implémenter les opérations de la classe de conception sous forme de méthodes ; • s'assurer que le composant fournit les mêmes interfaces que la classe de conception. Bien qu'ils ne soient pas décrits ici, cette activité comprend également la prise en compte de divers aspects de maintenance de la classe implémentée, comme la correction des anomalies une fois la classe testée.

Iguro 10.25

O

es et résultat Mlmi>lémenJ 'l .l'une classe.

n Ingénieur de composants Classe de conception [conçue] Implémenter une classe

Composant [Implémente]

O"'

ï

Interface [fournie par la classe de conception]

10

tions est générée ; les opérations elles-mêmes restent à implémenter (voir la section 10.5.4.3, « Implémentation des opérations »). Notez également que la génération de code à partir des associations et des agrégations peut se révéler très délicate et que ses modalités varieront en fonction du langage de program mation. Par exemple, i l est courant qu'une association navigable dans un sens soit impie mentée par une « référence » entre objets ; cette référence sera alors représentée ce m attribut de l'objet référant, attribut qui sera nommé d'après le nom de rôle à I extrémité de l'association. La multiplicité de cette extrémité indiquera, a son tout, | | l'attribut (de la référence) 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

Chaque opération définie par la classe de conception doit être implémentée. a moins qu'elle ne soit « virtuelle » (ou « abstraite ») et implémentée par des descendants (tels que d types) de la classe. On utilise le terme méthodes pour désigner rimplciiiciiiiiiinii des opérations [5], dont on trouvera des exemples avec les méthodes Java |2|, les méthode'. Visual Basic [3] et les fonctions membres C++ [4]. L'implémentation d'une opération suppose de choisir un algorithme approprié et des slrue tares de données adaptées (comme des variables locales de la méthode), puis de coder les actions requises par l'algorithme. N'oubliez pas que la méthode peut avoir été spécifiée en langue naturelle ou en pseudo-codé au cours de la conception de la classe (bien que ce soit rare et que cela représente souvent une perte de temps ; voir la section 9.5.3.6). Quoi qu'il en soit, toute « méthode de conception » peut, bien entendu, être utilisée comme entrée pour cette étape. Notez également que les états décrits pour la classe de conception peuvent influer sur l'implémentation des opérations, puisque l'état de la classe détermine le comportement de celle-ci lors de la réception d'un message.

appropriées

Le code source implémentant une classe de conception réside dans un composant fichier. I l faut par conséquent esquisser ce composant fichier et en délimiter la portée. I l est assez courant d'implémenter plusieurs classes de conception dans un même composant fichier. Rappelez-vous néanmoins 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 créera un composant fichier « java » pour chaque classe d'implémentation. D'une manière générale, les composants fichiers choisis doivent prendre en charge la compilation, l'installation et la maintenance du système.

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

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

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

I'

Pendant la conception, une grande partie des informations concernant la classe de conception et ses relations sont exprimées dans la syntaxe du langage de programmation, ce qui simplifie considérablement la génération de certaines parties du code source qui implémente la classe en question. Ceci vaut, en particulier, pour les opérations et les attributs de la classe, ainsi que pour les relations qu'entretient la classe. Toutefois, seule la signature des opéra-

Le composant résultant de ce processus doit fournir les mêmes interfaces que la ou les classes de conception qu'il implémente. Vous en trouverez un exemple dans la section 10.3.2, « Artefact : composant ».

10.5.5 Activité

: effectuer les tests

unitaires

Le propos de cette activité est de tester les composants implémentés en tant qu'unités inilivi duelles (voir la figure 10.26). Les types de tests suivants sont effectués : • les tests des spécifications, ou « tests boîte noire », qui vérifient le comportement du composant observable de l'extérieur ; • les tests de structure, ou « tests boîte blanche », qui vérifient rimpléincnlalion interne île l'unité.

,


Hgure 10.:26 et résultat

.•jurées

îles tests d mité.

â

Ingénieur de composants Composant [implémente]

.=7 Effectuer les tests unitaires

Composant [testé par unité]


10

mgj mm

• de valeurs situées en dehors des classes d'équivalence acceptables, comme le retrait d'une valeur supérieure ou inférieure à la portée autorisée ; • de valeurs interdites, comme le retrait de -140 ou de A. En choisissant les tests à effectuer, l'ingénieur de composants doit s'efforcer de couvrir toutes les combinaisons de classes d'équivalence d'entrées, d'états et de sorties, comme le retrait de 140 FF: • 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 ; • d'un compte ayant un solde de 130,10 FF, ce qui n'aboutira à aucun retrait ;

O " Interface

• d'un compte ayant un solde de 150 FF, ce qui aboutira à un retrait de 140 FF.

Notez que certaines unités peuvent subir d'autres tests, comme des tests de performances, d'usage de la mémoire, de charge et de capacité. Enfin, i l convient de pratiquer des tests d'intégration et des tests système pour s'assurer que plusieurs composants se sont bien comportés lors de leur intégration (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

On effectue des tests des spécifications pour vérifier le comportement du composant sans s'intéresser à la façon dont est implémente ce comportement au sein du composant. Les tests des spécifications examinent alors les sorties que le composant produira à partir des entrées données et en fonction d'un état de départ spécifique. La gamme des combinaisons d'entrées, d'états de départ et de sorties possibles étant souvent considérable, i l devient difficile de les tester une à une. On préfère répartir ces gammes d'entrées, de sorties et d'états en classes d'équivalence. Une classe d'équivalence est un ensemble de valeurs d'entrée, d'état ou de sortie pour lesquelles un objet est censé se comporter de manière identique. En testant un composant pour chaque combinaison de classes d'équivalence d'entrées, de sorties et d'états de départ, 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 considérablement réduit. BMS

Classes d'équivalence L'état d'un compte présente trois classes d'équivalence : Vi de, Sol de n é g a t i f (éventuellement à découvert) et Sol de posi t i f. De même, les arguments d'entrée peuvent être répartis en deux classes d'équivalence : Z é r o et Nombres p o s i t i f s . Enfin, les arguments de sortie se répartissent 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.

Le résultat 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 testées pour une seule valeur dans une classe d'ni|iil valence. L'ingénieur de composants doit alors choisir de tester des cas présentant 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 même classe d'équivalence d'entrées, par exemple 3,14 FF. L'ingénieur de composants élabore ensuite des gammes semblables de cas de tests pour d'autres classes d'équivalence de valeurs d'entrée, 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

Les tests de structure permettent de vérifier le fonctionnement interne d'un composant. L'ingénieur de composants doit s'assurer, au cours de ce type de test, qu'il teste tout le code. Chaque instruction doit donc être exécutée au moins une fois. I l faut également veiller à tester les chemins les plus intéressants à travers le code, c'est-à-dire ceux qui sont le plus couramment empruntés, les plus stratégiques, les plus improbables à travers les algorithmes et ceux qui sont associés à un niveau de risques élevé. EffijH

Code source Java pour une méthode La figure 10.27 montre une implémentation (simplifiée) de la méthode de retrait définie pai la classe Compte.

L'ingénieur de composants doit choisir des valeurs pour les tests à partir : • de valeurs normales situées dans la portée autorisée 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 situées à la frontière 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é ;

V

PARTIE

KISIMI

I i "

jmmfmm

o h a î n e m e n t s d ' a c t i v i t é s principaux II

Figure 10.27 Code source Java pour une méthode de retrait simple définie par la classe Compte.

public class Compte {

public Retrait argent(Montant crgent) {

3

private Solde argent = new Argent (0)

2

//Dans cet exemple, le Compte n'a qu'un solde

1

//On vérifie ensuite qu'on ne retirera pas un montant négatif

7

if solde >= montant

6

//aussi important que le retrait demandé

5

//Il laut d'abord s'assurer que le solde est au moins

4

8

10.6

then { try{

return montant

12

solde = solde - montant;

11

//Traitent des échecs réduisant le solde

15

catch (Exception exc) {

14

18

Implémentation

pjpjj

cTJÂTnl^FTôWm l'implémentation

Comme l'indiquera le chapitre suivant, le modèle d'implémenlalic)ii c eue,mm I enti, , pritl cipale des activités ultérieures de tests. Pour être plus précis, chaque c onsluu lion issue de l'implémentation subit des tests d'intégration et, éventuellement, des lests système au c de la phase de tests.

10.7

} }

R é s u m é de

L'implémentation a pour principal résultat le modèle d'implémentation, composé des élé ments suivants : • les sous-systèmes d'implémentation et leurs dépendances, interfaces et contenu ; • les composants, y compris les composants fichiers et exécutables, et leurs dépend.ni M mutuelles. Les composants sont testés unité par unité ; • la vue architecturale du modèle d'implémentation, avec ses éléments significatifs sui li plan architectural. L'implémentation se traduit également par un raffinement de la vue archiici lui,il. du Ii li de déploiement, qui fait apparaître la correspondance des composants exéc iilnbli nvi i li nœuds du réseau.

then {if montant >= 0

9 10

}

13

//... à définir...

16 17

else {return 0}

19

Références KEN ARNOLD et JAMES GOSLING, The Java Programming Language, Reading, MA,

2

IEEE Std 610.12. 1990.

1

Addison-Wesley, 1996. ANTHONY T. M A N N , Visual Basic5—Developer's

3

Guide, Indianapolis, IN, SAMS

Publishing, 1997.

20 21

BJARNE STROUSTRUP, The C+ + Programming Language, 3 édition, Reading, MA, Addison-Wesley, 1997.

4

else {return 0}

e

22

Il faut s'assurer, en testant ce code, que toutes les instructions i f sont évaluées successive-

J. RUMBAUGH, M . BLAHA, W. PREMERLANI, F. EDDY et W. LORENSEN, ObjectOriented Modeling and Design, Englewood Cliffs, NJ, Prentice Hall, 1991.

6

The Unified Modeling Language for Object-Oriented Development, Documentation set, ver. 1.1, Rational Software Corp., Septembre 1997.

5

ment avec t r u e et avec f al se, et que tout le code est exécuté. 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 système exécute les lignes 10 à 13; • retrait de -500 FF d'un Compte dont le solde est de 100 FF, où le système exécute la ligne 21 ; • retrait de 500 FF d'un Compte dont le solde est de 100 FF, où le système exécute la ligne 19 ; • déclenchement d'une exception lorsque le système exécute l'instruction sol de = solde - montant, où le système exécute les lignes 14 à 17.


I

r

11

r Test

! 11.1 I n t r o d u c t i o n

I

L'enchaînement d'activités des tests s'attache à la vérification des résultats de l'implémentation en testant chaque construction, aussi bien les constructions internes et intermédiaires que les versions finales du système, livrables à l'extérieur. Vous trouverez une excellente présentation générale des tests dans [2]. Les divers objectifs que poursuit la phase de tests sont énumérés ci-dessous.

I

• Planifier les tests nécessaires pour chaque itération, y compris les tests d'intégration et les tests système. Les tests d'intégration doivent être menés sur chaque construction d'une itération, tandis que les tests système ne sont exigés qu'à la fin de l'itération.

I

• Concevoir et implémenter les tests en créant des cas de test spécifiant ce qui doit être testé, des procédures de test précisant les modalités d'exécution des tests, et enfin des composants de test exécutables destinés à automatiser les tests, si possible.

1

• Effectuer les divers tests et prendre systématiquement en compte les résultats de chacun d'eux. Les constructions faisant apparaître des anomalies sont retestées et éventuellement renvoyées à d'autres enchaînements d'activités principaux, comme la conception ou l'implémentation, afin que les anomalies significatives puissent être corrigées.

I

Nous allons présenter, dans ce chapitre, les conditions de réalisation 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'activités est très proche de celle adoptée pour l'enchaînement d'activités d'impie mentation.

4


II

Figure 11.1 Travailleurs et artefacts impliqués dans les tests.

•"i Inynnlnur d « composants

i .'M.i .,, d'Intégration

n «yHt

11.2 de converties tests.

Test CHAPITRE

11

Phases Enchaînements d ' a c t i v i t é s principaux

/

r u s p o i i M i h l i ' iJi'

Analyse Modèle des tests

Cas de test

Procédure de test

Évaluation Plan des tests des tests

Composant de test

X Anomalie

Conception

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 S'il est possible de commencer à planifier les tests dès la phase de création, lorsqu'on délimite la portée du système, ils interviennent avant tout au moment où chaque construction (comme résultat de l'implémentation) doit subir des tests d'intégration et des tests système. Ce qui signifie que les tests mobilisent l'attention à la fois pendant l'élaboration, lors du test de l'architecture de référence exécutable, et pendant la construction, lors de l'implémentation de la masse du système. Pendant la phase de transition, l'attention se porte principalement sur la correction des anomalies détectées au cours des premières utilisations et sur les tests de non-régression (voir la figure 11.2). En raison de la nature itérative du développement, certains des cas de test spécifiant les modalités de test des premières constructions peuvent également servir de cas de test de nonrégression, dont ils définissent les conditions pour les constructions plus tardives. Le nombre de tests de non-régression requis augmente par conséquent de façon constante aufildes itérations ; les dernières itérations en nécessitent un volume substantiel. I l est donc naturel d'actualiser le modèle des tests tout au long du cycle de vie du logiciel, bien que ce modèle subisse constamment des évolutions dues : • à la suppression des cas de test devenus obsolètes (ainsi que des procédures et des composants de test correspondants) ; • au raffinement de certains cas de test en vue de les transformer en cas de test de nonrégression ; • à la création de nouveaux cas de test pour chaque construction ultérieure.

iter. #2

Iter. #n

Iter. #n+1

lier Iter. I Iter. #n+2 I •m I «in.

I

Itérations

11.3 A r t e f a c t s 11.3.1 Artefact : modèle

des tests

Le modèle des tests décrit avant tout les conditions dans lesquelles les composants exécutables (tels que les constructions) du modèle d'implémentation subissent des tests d'intégration et des tests système. I l peut également indiquer les modalités de tests de certains aspects spécifiques du système (par exemple, si l'interface utilisateur est utilisable et cohérente ou si le manuel d'utilisation du système remplit sa fonction). Ce modèle se compose d'un ensemble de cas de test, de procédures de test et de composants de test, comme l'illustre lafigure11.3. Les sections suivantes présentent en détail les artefacts du modèle des tests. Notez que si ce modèle est important, c'est-à-dire s'il contient un grand nombre de cas de test, de procédures de test et/ou de composants de test, i l pourra être utile d'y introduire des paquetages afin qu'il reste gérable. Il s'agit là d'une extension relativement simple du modèle des i c s i s . qui ne sera pas traitée dans ce chapitre. Figure 11.3 ^Modèle des tests.

FD+-

Modèle des tests

Système de test

0

I


11.3.2 Artefact : cas de test Un cas de test spécifie une manière de tester le système, en pin c.ani i r qui doit e n avec quelles entrées ou quel résultat et sous quelles conditions (voit la figure M l |.„ tique, les tests peuvent porter sur n'importe quelle exigence ou collection d'exigences système dont l'implémentation justifie la réalisation de tests dont l'exécution sera maté lement possible et n'entraînera pas un coût insupportable. Vous trouverez, ci-dess quelques exemples de cas de test courants. • Un cas de test spécifiant les conditions de test d'un cas d'utilisation ou d'un scénario spécifique de ce cas d'utilisation. Ce type de test comprend la vérification du résultat de l'interaction entre les acteurs et le système, la satisfaction des pré et postconditions spécifiées par le cas d'utilisation, et le respect de la séquence d'actions édictée par le cas d'utilisation. Notez qu'un cas de test fondé sur un cas d'utilisation spécifie généraleme un test « boîte noire » du système (c'est-à-dire un test du comportement du système observable depuis l'extérieur). • Un cas de test spécifiant les conditions de test d'une réalisation—conception de cas d'utilisation ou d'un scénario particulier de la réalisation. Ce type de test peut compren la vérification de l'interaction entre les composants implémentant le cas d'utilisation. Notez que les cas de test fondés sur une réalisation de cas d'utilisation spécifient généralement un test « boîte blanche » du système (c'est-à-dire un test de l'interaction interne entre les composants du système). Figure 11.4 Un cas de test peut être dérivé d'un cas d'utilisation du modèle de cas d'utilisation ou d'une réalisation de cas d'utilisation du modèle de conception, auxquels il est, par conséquent, lié par une relation de traçabilité.

O

Modèle des tests

---<£>

Cas de test [test boîte blanche]

Réalisation-conception de cas d'utilisation [issu du modèle de conception]

Régi er

Cas de test [test boîte noire]

Cas d'utilisation [issu du modèle des cas d'utilisation]

Test CHAPITRE

11

Entrées •

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é reçue par le vendeur. Le prix confirmé du VTT est de 2 000 FF, port et manutention compris.

•

Une facture (n° 12345) a bien été reçue 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 référence au compte n° 22-222-2222, destinataire du montant facilité Ce tantipln présente un solde actuel de 963 456,00 FF et doit être détenu par le vendout.

•

Le compte n° 11-111-1111 de l'acheteur présente un solde de 2 500 FF.

Résultat •

L'état de la facture doit être devenu Sol dée (pour indiquer qu'elle a été rénlnit).

Le solde du compte n" 22-222-2222 du vendeur doit être passé à 965 956,00 FF.

•

Le compte n' 11 -111 -1111 de l'acheteur doit présenter un solde de 500 FF.

•

Conditions •

Aucun autre cas d'utilisation (ou instance de cas d'utilisation) ne doit être autorisé à accéder aux comptes pendant l'exécution de ce cas de test.

Notez que certains cas de test peuvent être très proches et ne diverger que par une seule valeur d'entrée ou de résultat, notamment lorsqu'il s'agit de cas de test vérifiant différents scénarios d'un même cas d'utilisation. I l peut alors être souhaitable de spécifier ces cas de test sous forme de matrice, en représentant chaque cas de test par une ligne et chaque plage de valeurs d'entrée ou de résultat par une colonne. Ce type de matrice pourra offrir une intéressante vision d'ensemble des cas de test similaires et constituer une entrée utile à la création ultérieure de procédures de test et de composants de test (voir les sections 11.3.3 et 11.3.4). D'autres cas de test, destinés à tester le système dans son ensemble, peuvent être spécifiés ; quelques exemples en sont donnés ci-dessous. • Les tests d'installation vérifient que le système peut être installé sur la plate-forme du client et qu'il fonctionne correctement une fois installé. • Les tests de configuration vérifient que le système fonctionne correctement dans diverses configurations, notamment dans des configurations réseau différentes.

Cas de test Les ingénieurs de tests proposent un ensemble de cas de test pour tester le cas d'utilisati l a f a c t u r e , en consacrant chaque cas de test à un scénario du cas d'utilisation.

L'un des cas de test proposés est le règlement 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.

• Les tests de robustesse tentent de provoquer l'échec du système afin de meilre au |0U1 Wl points faibles. Les ingénieurs de tests identifient les cas de test qui essaient d'utillseï le système dans des conditions anormales : mauvaise configuration réseau, capacité matérielle insuffisante ou charge de travail « impossible » . • Les tests de stress identifient les problèmes que rencontre le système en cas de manque .1. ressources ou de concurrence pour l'utilisation des ressources.

Pour être complet, ce cas de test doit préciser les entrées, le résultat escompté et les autre conditions pertinentes pour la vérification du scénario du cas d'utilisation.

alenient appelés « 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

On trouvera la plupart de ces cas de tes. en examinant le. ,.,, d'util], ,„„„ section H.5.2 revient plus en détail sur ce sujel.

11.3.3 Artefact : procédure

de test

Une procédure de test spécifie les conditions d'exécution 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 spécification des conditions d'inten manuelle avec un outil d'automatisation pour créer des composants de test exécutables ( la section 11.3.4). (

Il arrive que les conditions d'exécution d'un cas de test soient spécifiées par une procéV de test, mais i l est souvent utile de réutiliser une même procédure de test pour plusieurs de test et de réutiliser plusieurs procédures pour un seul cas de test (voir la figure 11.5). Figure 11.5 Les procédures de lest sont liées aux cas de test par des associations plusieurs-àplusieurs.

• spécifie les conditions d'exécution 1.

Cas de test

P r o c é d u r e de test

5

U

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

Test 11

Mml

• le Compte doit correspondre au compte spécifié dans le cas de test [22-222-2222]. 4. Cochez la case Autoriser le règlement pour lancer le règlement de cette facture. La boîte de dialogue Règlement de la facture s'affiche. 5. Etc. (La suite spécifie les conditions d'exécution du chemin complet du cas d'utilisation Régi er la facture par l'intermédiaire de l'interface utilisateur en fournissant un certain nombre d'entrées au système, et ce qui doit être vérifié dans les sorties du système.)

Notez que cette procédure de test peut également servir à d'autres cas de tcsl soudain, qui ne diffèrent que par leurs valeurs en entrées et celles de leur résultat (c'est a due les » ali m entre crochets). En outre, cette procédure de test s'apparente à la description de Ilot d i vi m ments du cas d'utilisation Régler la facture (voir la section 7.4.3.1 ), niais elle compri ml des informations complémentaires: les valeurs d'entrée à utiliser a pailu du . a d niili sation, la façon de saisir ces valeurs dans l'interface utilisateur cl les élément: a venin-1 I f m i

1..*

P r o c é d u r e s gé né r a le s de test Au moment de suggérer des procédures de test, les concepteurs de tests remarquent quu plu sieurs cas d'utilisation (et les cas de test permettant de les vérifier) commencent par la validation d'objets dès le début du cas d'utilisation, comme la comparaison de la facture à la confirmation de commande.

LXJ— Procédure de test

Ils proposent alors une procédure généraledetestappeléeValider les objets métier et destinée à tester de telles séquences. Cette procédure spécifie que les objets à valider doivent d'abord avoir été créés (en lisant dans un fichier les valeurs qu'ils doivent prendre, puis en les créant dans la base de données). Elle indique ensuite que l'objet actif qui valide les objets métier doit être invoqué (comme le Gestionnai re de commandes dans le cas d'utilisation Régi er 1 a facture). Elle précise, enfin, que le résultat de la validation doit être comparé au résultat escompté (tel qu'il a été décrit dans le fichier mentionné).

2 K 2îof l u l T ™ , "' « ^'utilisation Régler 2 000-VTT de l exemple précèdent (section 11.3.2). La première partie rie 1 procédure de test est spécifiée comme suit (le texte entre crochets „ • p a s * spécification, puisqu'il apparaît déjà dans le cas de test). * l e

Cas de test pris en charge : Régi er 2 000-VTT.

Les concepteurs de tests proposent également une procédure de test appelée Véri fier l'échéancier; elle précise les modalités de test de la programmation d'une facture et vérifie ensuite que l'envoi en règlement de la facture provoque bien un virement entre comptes.

1. Dans la fenêtre principale, sélectionnez le menu Parcouri r les factures. La fenêtre Requête d'exploration des factures s'ouvre. 2. Dans le champ État de la facture, sélectionnez En attente et cliquez sur le bouton! Requête. La fenêtre Résultats de la requête s'affiche. Vérifiez que la facture spécifiée dans le cas de test (n° 12345) apparaît bien dans la fenêtre Résultats de la r e | |

Sachant que plusieurs cas d'utilisation effectuent des virements entre comptes, les concepteurs de tests créent une procédure de test à part, nommée Véri fier les virements entre comptes, afin de spécifier les conditions de vérification des virements.

quête. 3. Sélectionnez la facture à régler spécifiée en double-cliquant dessus. La fenêtre Détai 1 s î de la facture concernant la facture en question s'affiche. Vérifiez les champs suivants : I

• l'État doit être En attente ;

11.3.4 Artefact : composant

de test

On utilise les composants de test pour tester les composants du modèle d'implémentation (voir le chapitre 10) en fournissant les entrées de test, en contrôlant et en surveillant l'exé

• le Montant de la facture doit correspondre au montant spécifié dans le cas de test [2 000 FF] ;

Les composants de test peuvent être mis au point à l'aide d'un langage de script OU d'Utl langage de programmation, ou encore être enregistrés par un outil d'automatisation des tl II

• le N * de confirmation de commande doit correspondre au numéro indiqué dans le cas j de test [n° 99765] ;

Un composant de test automatise tout ou partie d'une ou de plusieurs procédures di h si (voir la section 10.3.2 et la figure 11.6).

• la Date de règlement doit être vide;


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 implémentés à laide de la le. luiul,,^,. j ! Si plusieurs composants de test exercent des interactions complexes, enlre eux ou ave. U composants ordinaires du modèle d'implémentation, on peut avoir recours a un •• modèle : conception des tests » à part (semblable au modèle de conception ; voir la section 9 3 pour modéliser les composants de tests et en fournir des vues de haut niveau. Bien n »| puisse être utile, ce type de modèle n'est pas traité dans cet ouvrage. s

(

( ) h

CHAPITRE

Test 11

évalue les tests d'intégration et les tests système une fois qu'ils ont été effectués (voir la figure 11.7). Notez que les concepteurs de tests n'exécutent pas les tests, mais s'occupent de leur prépa ration et de leur évaluation. Deux autres types de travailleurs, les testeurs d'intégration et le testeurs système, sont chargés de réaliser les tests.

u

U

I

figure 11-7 Responsabilités

ffun

Figure 11.6

• automatise

Les composants

1..*

concepteur

jt tests dans

de

test sont liés aux procédures

ïenchaînement

1..*

Jbf activités

de test Composant de test

par des associations

tests

des

O n Ingénieur de tests

/

i

\

responsable de

des

tests-

Procédure de test

Modèle des tests

plusieurs-àplusieurs.

11.3.5 Artefact : plan des

11.4.2 Travailleur : ingénieur

Le plan des tests décrit les stratégies de tests, ainsi que leur calendrier et les ressources mises à leur disposition. La stratégie des tests définit le type et les objectifs des tests à effectuer pour chaque itération, le niveau requis de test et de couverture du code, et enfin le pourcentage des tests devant livrer un résultat spécifique.

Évaluation Plan des tests don t
Procédure de test

Cas de test

de

composants

Les ingénieurs de composants sont responsables des composants de test qui automatisent certaines procédures de test (toutes les procédures de test ne peuvent être automatisées), car la création de tels composants peut réclamer de sérieuses compétences en programmation (déjà exigées de la part de l'ingénieur de composants dans l'enchaînement d'activités d'implémentation ; voir la section 10.4.2).

11.3.6 Artefact : anomalie

11.4.3 Travailleur : testeur

Une anomalie désigne une anomalie du système, telle que le symptôme d'un échec logiciel ou un problème découvert lors d'une réunion de révision. Elle permet d'exprimer tout ce que les développeurs doivent consigner en tant que symptôme d'un problème du système à suivre et à résoudre.

11.3.7 Artefact : évaluation

d'intégration

Les testeurs d'intégration sont chargés d'effectuer les tests d'intégration nécessaires pour chaque construction produite au cours de l'enchaînement d'activités d'implémentation (voir la section 10.5.2). Ces tests permettent de vérifier que les composants intégrés à une construction fonctionnent correctement ensemble. C'est pourquoi ils sont souvent dérivés des cas de test spécifiant les modalités de test des réalisations-conception de cas d'utilisation (voir la section 11.3.2).

tests

Lévaluation des tests consiste à évaluer les résultats de l'ensemble des tests : la couverture • des cas de test, la couverture du code et l'état des anomalies.

Les tests d'intégration font apparaître des anomalies, présentées par le testeur d'intégration. Notez qu'un testeur d'intégration teste le résultat (c'est-à-dire une construction) créé par un intégrateur système dans l'enchaînement d'activités d'implémentation. Certains 1 hel's de projet choisissent, par conséquent, d'attribuer ces responsabilités aux mêmes peis. .nues alin de réduire le plus possible les chevauchements entre les compétences requises

11.4 T r a v a i l l e u r s

11.4.1 Travailleur : concepteur

de tests

11.4.4 Travailleur : testeur

Le concepteur de tests doit veiller à l'intégrité du modèle des tests et s'assurer que celui-ci remplit bien son rôle. D est également chargé de planifier les tests, en leur fixant des objectifs adaptés et en définissant le calendrier de leur déroulement. Enfin, non seulement i l sélectionne et décrit les cas de test et les procédures correspondantes requises, mais de plus i l

système

Le testeur système est chargé d'effectuer les tests système exigés pour une COnsttl >n représentant le résultat (exécutable) de toute une itération (voir la section 10.3 2). Ll Wll système servent avant tout à vérifier les interactions entre les acteurs et le système ils sont


II

donc souvent dérivés des cas de test spécifianl les modalités de lest dos , as d'titili ,| Toutefois, d'autres types de tests s'appliquent à l'ensembli du système (voit section 11.3.2). sa

Les tests système font apparaître des anomalies, présentées par le lestent système. En raison de la nature même des tests système, les personnes agissant en tant que testa' système n'ont pas besoin d'en savoir très long sur les fonctionnements internes du systèm Ils doivent, en revanche, parfaitement connaître le comportement du système observa depuis l'extérieur. Certains tests système peuvent donc être réalisés par d'autres membres l'équipe du projet (les spécificateurs de cas d'utilisation), ou même par des parties extern (les clients bêta).

I

Test CHAPITRE

11

En exploitant en tant qu'entrées ces cas, procédures et composants de test, les testeurs d'intégration et les testeurs système testent chaque construction et font apparaître toute anomalie détectée. Ces anomalies sont ensuite reversées dans les autres enchaînements d'activités, tels que ceux de conception et d'implémentation, et transmis aux ingénieurs de tests, qui procèdent à une évaluation systématique des résultats des tests.

.5.1 Activité

: planifier les tests

L'objectif est de planifier les tests (voir la figure 11.9) réalisés pour une itération : • en décrivant une stratégie de test ; • en estimant les exigences imposées par les tests, comme les ressource» hum. système nécessaires ;

11.5 Enchaînement d'activités

• en fixant le calendrier des tests.

Après avoir, dans les sections précédentes, décrit les tests en termes statiques, nous allons maintenant utiliser un diagramme d'activités (figure 11.8) pour en examiner le comportement dynamique Le principal objectif de l'enchaînement d'activités des tests est, évidemment, de réaliser et d'évaluer les tests tels qu'ils sont décrits par le modèle des tests. Ce sont les ingénieurs de tests qui sont à l'origine de cet enchaînement d'activités, puisqu'ils planifient les tests à effectuer dans chaque itération. Ils décrivent ensuite les cas de test nécessaires à la réalisation de ces tests et les procédures correspondantes. Puis les ingénieurs de composants créent, dans la mesure du possible, des composants permettant d'automatiser certaines de ces procédures. Le même processus se répète pour chaque construction issue de l'enchaînement d'activités d'implémentation. Figure 11.8

leurs

Pour dresser le plan des tests, les ingénieurs de tests puisent à diverses sonnes I i Ii l< des cas d'utilisation et les exigences supplémentaires les aident à lixci un ordre itilupli i les tests et à estimer les efforts qu'ils requièrent. De son côté, le conceptem de tests utilise comme entrées d'autres artefacts, tels que le modèle de conception. Les concepteurs de tests mettent sur pied une stratégie générale de lests poui l'itération quel type de tests réaliser, quand et comment les exécuter, comment déterminer s'ils ont clé concluants. EflfflH

O

Enchaînement d'activités

des

tests, avec les

D

Ingénieur de tests

travailleurs y prenant part et activités.

o

D

Testeur d'intégration

O

D

Testeur système

\r \s tests \n

\

ai

Stratégie des tests système pour la dernière itération de la phase d'élaboration Au moins 75 % des tests doivent être automatisés, 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. Critères de succès : 90 % des cas de test réussis. Aucune anomalie de priorité moyenne à élevée restée sans solution.

Évaluer les tests

j

Le développement, l'exécution et l'évaluation subséquente de chaque cas, procédure et composant de test exige un investissement temporel et financier. Comme i l est impossible de tester l'intégralité d'un système, i l faut repérer les cas, procédures et composants de test garantissant le meilleur retour sur investissement en termes d'amélioration de la qualité [3|. Le principe de base consiste à mettre au point des cas et des procédures de test ayant un nombre de chevauchements minimal afin de tester les cas d'utilisation les plus Importants Bl les exigences associées auxrisquesles plus sérieux.

\ \

\

Effectuer les tests système

O

I

n

Implémenter les tests


i



et

résultat

de la planification


des tests.

ô

Ingonloui
résultat

ception


Test 11

O £7 Ingénieur de tests


-A Planifier ,"^7 les tests 7!

- 7 ®


Plan des tests

Cas de

-A -> Modèle de conception

^

Concevoir les tests

'kl

E r "

Description de l'architecture [vues architecturales / des modèles]

Description de l'architecture [vues architecturales des modèles]



: concevoir

CHAPITRE

11.10 W


•

Modèle d'analyse


11.5.2 Activité

i

mini" do i.-..

Plan des tests [stratégie et calendrier des tests]

les tests

La conception des tests (voir la figure 11.10) a pour objectif :

Les concepteurs de tests commencent par examiner un diagramme de séquence faisant partie

• d'identifier et de structurer des procédures de test indiquant les conditions de réalisati des cas de test.

Cas de test d'intégration

• d'identifier et de décrire des cas de test pour chaque construction ;

d'une réalisation-conception de cas d'utilisation pour le cas d'utilisation Régi er la facture. La figure 11.11 montre la première partie de ce diagramme (voir la section 9.5.2.2).

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

Les cas de test d'intégration servent à vérifier l'interaction des composants les uns avec autres après leur intégration au sein d'une construction (voir la section 10.5.2). La plup des tests d'intégration peuvent être dérivés des réalisations-conception de cas d'utilisatio' puisque ces réalisations décrivent les interactions entre classes et entre objets (et, par cons quent, entre composants). Les ingénieurs de tests doivent créer un ensemble de cas de test permettant d'atteindre, av un minimum d'efforts, les objectifs fixés par le plan des tests. Ils essaient, pour ce fair d'identifier un ensemble de cas de test présentant le moins de chevauchements possible et testant chacun un chemin ou un scénario intéressant à travers une réalisation de cas d'utilisation.

Figure 11.11 première

partie

'un diagramme iséquence 4a'

pour

de demande de règlement

des demandes de règlement

: Confirmation de commande

des factures

"

réalisation-

conception du cas d'utilisation

Régler

parcourir factures

parcourlr()

parcourirFactures()

la facture. vérifierFacture

Gestionnaire de commandes

obtenirlnfos ExplorationQ

1

obtenirlnfosConfirmatlonO

obtenirFactureQ obtenirlnfosFacturo()

Pour créer les cas de test d'intégration, les testeurs d'intégration considèrent en priorité les diagrammes d'interaction des réalisations de cas d'utilisation. Ils recherchent diverses combinaisons d'entrées et de sorties d'acteurs et d'état de départ du système formant des scénarios intéressants qui mettent à contribution les classes (et, par conséquent, les composants) figurant dans les diagrammes.

-tj

Notez qu'un même diagramme de séquence peut offrir plusieurs « séquences • dlftéinniii'. selon, par exemple, l'état de « départ » du système et les entrées de l'acteur. En considérant le diagramme de séquence de la figure 11.11, on peut par exemple, remarquer que de nnm breux messages ne seront pas envoyés s'il n'y a pas de Facture dans le système.

Les enchaînements d'activités principaux PARTIE II Un cas de test dérivé d'un diagramme de séquence tel que celui ci pinmai! déi n | „, lités de test d'une séquence intéressante à travers cedia'jiniiiiiiiiiMiitxpiiiiinul l'élal dedép requis du système, les entrées effectuées par l'acteui et tout ce qui sciail susceptible de lan la séquence. M!

(

n i

Une fois les tests d'intégration correspondants effectués, on formule les véritables interao tions des objets au sein du système (par exemple, en éditant une trace de l'exécution 014 t l'exécutant pas à pas). Puis on compare ces interactions réelles avec celles du diagrantl d'interaction : si elles ne sont pas identiques, c'est qu'une anomalie a été détectée.

11.5.2.2 Conception des cas de test système Les tests système servent à vérifier que le système fonctionne correctement dans so ensemble. Chaque test système teste principalement des combinaisons de cas d'utilisatio instanciés sous différentes conditions : i l peut s'agir de différentes configurations matérielles (processeurs, mémoire principale, disques durs, etc.), de différents niveaux de charge: système, d'un nombre varié d'acteurs et de diverses tailles de bases de données. En mettant au point les cas de test système, les concepteurs doivent privilégier les combinaisons de cas d'utilisation :

Test mm CHAPITRE 11 K cas de test, ce qui permet de disposer rapidement et précisément d'un ensemble resserré de procédures de test pour un grand nombre de cas de test. La plupart des cas de test vont tester plusieurs classes issues de plusieurs sous-systèmes de service (puisque les cas de test sont fondés sur les cas d'utilisation ou sur les réalisations de cas d'utilisation), mais chaque procédure doit, si possible, spécifier le moyen de Icslci les classes provenant d'un seul sous-système de service. Plusieurs procédures de lest peuvent néanmoins définir les conditions de test de tout un sous-système de service. ( 'Inique 1 n: di test impliquera alors plusieurs procédures de test, éventuellement une pour chiqui IOU système de service testé par le cas de test. L'alignement des procédures de test sur ICK HIIIIN systèmes de service facilite la maintenance des procédures. Lorsqu'un soie, l y i t i Il service change, les répercussions de ce changement sur les procédures de lest i n oui llmlii aux procédures de test utilisées pour la vérification de ce sous-syslème 1 le servit 1 lundi qui les autres procédures de test ne subiront aucun impact.

B U

Procédure de test Le sous-système de service Comptes fournit la fonction permettant de procédot il dos mou vements entre comptes. Cette fonction prend part à plusieurs réalisations 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 modalités de test des mouvements entre comptes seront définies pat une procédure de test appelée V é r i f i e r les virements entre comptes. La procédure spécifiée par V é r i f i e r les virements entre comptes prend comme paramètres d'entrée l'identité de deux comptes et le montant à virer, puis valide ce virement en demandant le solde des deux comptes impliqués avant et après le virement.

• devant fonctionner en parallèle ; • susceptibles d'être exécutés en parallèle ; • susceptibles de s'influencer les uns les autres s'ils sont exécutés en parallèle ; • impliquant de nombreux processus ; • utilisant fréquemment les ressources système telles que les processus, les processeurs, les bases de données et les logiciels de communication, éventuellement de façon complexe et imprévisible. On trouvera, par conséquent, un grand nombre de cas de test système en examinant les cas d'utilisation, en particulier leurs flots d'événements et leurs exigences particulières (comme les exigences de performances).

11.5.2.3 Conception des cas de test de non-régression Certains cas de test issus des constructions précédentes peuvent servir de tests de nonrégression aux constructions ultérieures, mais pas tous. Pour être exploitables et contribuer au maintien de la qualité du système, les cas de test doivent faire preuve d'assez de souplesse pour réagir correctement aux changements affectant le logiciel à tester. Comme la souplesse requise par un cas de test de non-régression peut avoir un coût en terme de développement, i l faut veiller à la rentabilité de cette transformation.

11.5.2.4 Identification et structuration des procédures de test Les concepteurs de tests peuvent prendre les cas de test un par un et suggérer des procédures de test pour chacun d'eux. O n essaiera autant que possible de réutiliser des procédures de test existantes ; i l peut donc être nécessaire de modifier ces procédures afin qu'elles spécifient les conditions d'exécution d'un cas de test inédit et/ou modifié. Les concepteurs de tests doivent aussi faire en sorte de créer des procédures de test réutilisables avec plusieurs

Les concepteurs de tests créent huit cas de test pour le cas d'utilisation Régi er la facture et quatorze pour le cas d'utilisation Effectuer des virements entre comptes. La procédure de test V é r i f i e r les virements entre comptes spécifie les conditions d'exécution de tous les cas de test (ou d'une partie d'entre eux).

11.5.3 Activité

: implémenter

les tests

L'objectif de l'implémentation des tests est d'automatiser, dans la mesure du possible, les procédures de test en créant des composants de test (toutes les procédures de test ne peuvent pas être automatisées) ; voir la figure 11.12. O n crée des composants de test en utilisant comme entrées les procédures de test, dans les conditions décrites ci-dessous. • Lorsqu'on utilise un outil d'automatisation des tests, on exécute ou l'on spécifie les actions décrites par les procédures de test. Ces actions sonl ensuite consignées 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 procédures de test comme principales spécifications de l'effort de programmation Note/ que cette programmation peut réclamer des compétences assez pointues. Souvent, les composants de test prennent en entrée des volumes importants de donner 1 tester et produisent en sortie des volumes comparables de données comme résultais des lests Il est appréciable de disposer d'un mode de visualisation clair et intuitif de ces données, 11I111


d'être en mesure de les spécifier correctement c l i r i i i i . i | i i r i n les résultai utilise à cet effet des applications de tableurs et de bases de de ces Figure 11.12 Entrées et résultat de V implémentation des tests.

CD

Cas de test.

di i ,

2. 3.

O

O


4.

CHAPITRE

Test 11

Comparez les résultats des tests aux résultats escomptés et examinez les résultats de tests qui s'éloignent de ceux qui étaient prévus. Rendez compte des anomalies détectées à l'ingénieur 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 résultats globaux de l'effort général de test (comme le décrit la section 11.5.6).

LXJ Procédure de test

Implémenter

•->s: Composant de test

D ' " "


11.5.5 Activité

.

système 11.5.1.2)

requis Dtl hiqui Itl 1

Les tests système sont menés de façon analogue aux tests d'intégration (voir la section pré cédente).

d'intégration

Figure 11.14 "ntrées et s tests

Entrées et résultat

C D

Cas de test


L'objectif est de réaliser les tests système (voir la section ration et d'en exprimer les résultats (voir la figure 1 1 . 1 4 ) .

Les tests système peuvent débuter 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. système satisfait aux objectifs de qualité de l'intégration fixés par le plan dei t»StS DOUt l'itération 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 résultat prévisible).

Modèle d'implémentation [construction à tester]

11.5.4 Activité

Cette activité permet de réaliser les tests d'intégration (voir la section 11.5.2.1) que doit subir chaque construction créée au cours d'une itération (voir la section 10.5.2) et de formuler les résultats de ces tests (voir la figure 11.13). Figure 11.13 (Us lests d'intégration. Lxj Procédure de test

o O

résultat système.

Cas de test

O £7

Effectuer les tests d'intégration

Testeur système

Lxj Procédure de test

Testeur d'intégration

| #* yl

Composant de test

s*

>x

Anomalie

Effectuer les tests système

Composant de test

Anomalie



Les tests d'intégration sont effectués selon la séquence décrite ci-dessous. 1. Effectuez les tests d'intégration pertinents pour la construction en exécutant manuellement les procédures de test pour chaque cas de test ou en exécutant tous les composants de test qui automatisent ces procédures.

Les enchaînements d'activités principaux PARTIE

II

11.5.6 Activité

: évaluer

les tests

L'objectif de cette activité est d'évaluer les lests menés an sein «I une iiciation (von figure 11.15). Figure 11.15 Entrées de

et

O

O

résultat

Test Engineer

l'évaluation.

CHAPITRE

Test 11

• l'assouplissement des critères d'évaluation des tests, si les objectifs de qualité ont placé la barre trop haut pour l'itération en cours ; • l'isolement des parties du système qui semblent présenter un niveau de qualité acceptable et leur présentation comme résultat de l'itération en cours. Les parties ne répondant pas aux critères de qualité doivent être révisées et testées de nouveau. Les concepteurs de tests documentent la complétude et la fiabilité des tests, ainsi que tel actions suggérées, dans une description de l'évaluation des tests.

Test Plan

11.6 Test Model

Evaluate Test

Résumé des tests Le principal résultat des tests est le modèle des tests, qui décril la manière dotll N

Test Evaluation [for an itération]

Il

système. Ce modèle contient les éléments suivants : • les cas de test, qui spécifient ce qui doit être testé dans le système ;

X

• les procédures de test, qui spécifient la façon d'exécuter ces cas de lesl .

Defect

• les composants de test, qui automatisent les procédures de

lest

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 enchaînements d'activités prlm Ipaux, tell que ceux de conception et d'implémentation.

Les concepteurs de tests évaluent les résultats des tests en comparant ces résultats aux objectifs fixés dans le plan des tests. Ils préparent également les métriques leur permettant de déterminer le niveau de qualité du logiciel et les tests restant à effectuer. Le concepteur de tests doit examiner en particulier deux métriques :

11.7

Références

3

Bill H E T Z E L , The Complète Guide to Software Testing, deuxième édition, Wellesley, MA, QED Information Sciences, Inc., 1988.

• la fiabilité, reposant sur l'analyse des tendances se dégageant des anomalies détectées et des tests s'exécutant avec un résultat prévisible.

2

IEEE Std 610.12. 1990.

1

• la complétude des tests, dérivée du degré de couverture des cas de test et de celui des composants testés. Cette métrique indique le pourcentage des cas de test exécuté et le pourcentage de code testé ;

Robert V. BlNDER, « Developing a test budget », Object Magazine, 7(4), juin 1997.

Pour déterminer la fiabilité du système, les concepteurs de tests créent des diagrammes de tendances générales des anomalies illustrant la répartition des types spécifiques d'anomalies (tels que les anomalies inédites ou fatales). Ils peuvent également élaborer des diagrammes de tendances indiquant le ratio de tests exécutés avec réussite (c'est-à-dire les exécutions de test générant les résultats escomptés). Les tendances générales des anomalies sont souvent similaires d'un projet à l'autre. Par exemple, le nombre d'anomalies nouvelles surgissant lorsqu'un système subit des tests augmente en général assez rapidement au début des tests, puis se stabilise au bout d'un certain temps, pour finir par s'infléchir progressivement. En comparant la tendance observée à celles issues de projets antérieurs, i l est possible de prévoir l'effort nécessaire pour atteindre un niveau de qualité satisfaisant. À partir de l'analyse de ces tendances, les concepteurs de tests peuvent suggérer un certain nombre d'actions : • l'exécution de tests supplémentaires pour localiser un plus grand nombre d'anomalies, si la mesure de fiabilité laisse penser que le système n'est pas encore prêt ;

1

artie III Un développement itératif et incrémental Un système logiciel passe par un certain nombre de eyt les de déV( lop pement pendant sa durée de vie. Chacun de ces cycles donne lieu ,i un. nouvelle version du produit livrée à des clients cl utilisateurs et donl la première risque d'être la plus délicate à élaborer. Cette première version pose, en effet, les fondations du système, c'est-à-dire son architecture. Elle explore un nouveau territoire, susceptible d'entraîner des risques graves. Un cycle de développement présente donc un contenu différent selon le stade du cycle de vie global auquel est parvenu le système. Dans les versions plus tardives, un changement spectaculaire de l'architecture peut signifier un travail supplémentaire dans les premières phases. Dans la plupart de ces versions tardives, toutefois, si l'architecture d'origine peut être étoffée, le nouveau projet ne fera que s'ajouter à ce qui existe déjà. En d'autres termes, une version tardive du produit sera construite au-dessus de la version précédente. L'idée qu'il vaut mieux traiter les problèmes dès le début de chaque cycle de développement, et non à la fin, commence à faire son chemin On applique le terme d'itération aux séquences de résolution des pro blêmes dans les phases de création et d'élaboration, ainsi qu'à chaque série de constructions de la phase de construction. Les risques ne se présentent pas dans un emballai'.' sophistiqui accompagné d'une carte de visite glissée sous un j o l i rose feu! les identifier, les délimiter, les surveiller et les réduite. El il VBUl mit s'attaquer en premier aux risques les plus graves. De même, l'ordrt dans lequel s'ajoutent les itérations doit être soigneusement reflet ni, afin que les problèmes les plus importants soient résolus en picnuei En bref, faites d'abord le sale boulot. I I . C I H I

I I

U

La deuxième punie de l'ouvrage .1 • )«•> ill . liai un î l e s eneliaînem d'activités séparément. I.a ligure 0 .' moiiliail. pat exemple, l'attend, accordée à l'enchaîncmenl d'activités 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 troisième partie, expliquei les diverses associations possibles de ces enchaînements d'activités, selon le stade du cycle de vie auquel on se trouve. Le chapitre 12 décrit, .l'abord, | points communs à toutes les phases, c'est-à-dire ce qui traverse toutes les phases, comme la planification d'une itération et la définition de critères d'évaluation pour cette itération, l'établissement d'une liste de risques, l'affectation d'un ordre de priorité aux cas d'utilisation et l'évaluation des itérations. Les chapitres suivants s'attardent ensuite sur chaque phase. e s

Dans la phase de création (chapitre 13), l'activité se concentre sur le premier enchaînement d'activités, celui des besoins, et ne porte que peu d'attention aux deuxième et troisième enchaînements (ceux d'analyse et de conception). Cette phase ne s'aventure que très rarement dans les deux derniers enchaînements d'activités : ceux d'implémentation et de tests. Dans la phase d'élaboration (chapitre 14), alors que l'activité s'appesantit encore sur la finalisation des besoins, les enchaînements d'analyse et de conception se voient accorder plus d'attention, puisqu'ils sous-tendent la création de l'architecture. Pour obtenir une architecture de référence exécutable, i l faut aussi qu'une partie de l'activité soit consacrée aux enchaînements d'activité d'implémentation et de tests. Dans la phase de construction (chapitre 15), l'enchaînement d'activités des besoins s'amenuise considérablement, l'analyse s'allège, tandis que les trois autres enchaînements d'activités mobilisent l'essentiel de l'attention.

Figure 12.1 L'enchaînement d'activités

12 Enchaînement d'activités de l'itération générique Nous revenons, dans ce chapitre, sur la notion d'itération générique, abordée dans le chapitre 5. Le propos de ce chapitre est de dégager le modèle commun qui caractérise les itérations des quatre phases, malgré leur apparente diversité. Ce modèle générique sert de pivot à la mise au point des itérations concrètes, dont le contenu change pour refléter les objectifs spécifiques de chaque phase (voir la figure 12.1).

de

l'itération générique de décrire

comprend : ® la planification des itérations © les enchaînements d'activités principaux ® l'évaluation des itérations

permet les

enchaînements d'activités

Enfin, dans la phase de transition (chapitre 16), l'importance respective des enchaînements d'activités dépend des retours des tests d'acceptation ou des bêta tests. Par exemple, si les bêta tests dévoilent des anomalies dans l'implémentation, une grande partie de l'activité sera consacrée à l'améhoration des enchaînements d'activités d'implémentation et de tests.

des

itérations pour

concrètes

chaque

phase.

1

Le dernier chapitre, le chapitre 17, revient au thème central du livre. E nous suffit d'un chapitre pour montrer comment divers écheveaux (enchaînements d'activités, phases, itérations) finissent par tisser un processus adapté au développement de logiciels stratégiques. Ce chapitre consacre également quelques paragraphes à la gestion de ces relations et à la transition au Processus unifié.

L'enchaînement d'activités de l'itération générique se compose de cinq en, li. principaux: besoins, analyse, conception, implémentation et tcsls, auxquels l'ajOUMM II planification, qui les précède, et l'évaluation, qui les suit (les chapitres 6 1 I I de. 1 n . n i ipa rément chaque enchaînement d'activités principal). Dans ce chapitre, n o n . ail.«il nou pencher sur la planification, sur l'évaluation et sur les autres activités communes I (OUI II enchaînements d'activités.

Un d é v e l o p p e m e n t itératif et i n c r é m e n t a l PARTIE

III

La planification est indispensable tout au long du cy< le de développement Mali poui af nifier, encore faut-il savoir ce qu'il y a à faire... I.es cinq cm hainemcnls d'activités prin cipaux fournissent un point de départ. La gestion des risques, c'est B due leui identification et leur réduction par la réalisation de l'ensemble de cas d'ulilisaiiou c orrespondants, est un autre aspect fondamental de la planification. Bien sûr, aucun plan ne saurait être < oinp| | sans l'estimation des ressources nécessaires. Enfin, l'exécution de chaque itération et dechaque phase doit absolument être évaluée. e

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 développement, c'est-à-dire processus et des outils ;

tics

• le déploiement d'un produit sur un site client ; • la prise en compte des retours des utilisateurs.

12.2 Les phases constituent la première division du travail

12.1 Le besoin d'équilibre Chaque moment du cycle de vie d'un projet de développement logiciel est marqué par la simultanéité de plusieurs séquences d'activités. On travaille à la mise en place de nouvelles fonctions, on échafaude l'architecture, on reçoit les retours des utilisateurs, on réduit les risques, on prévoit la suite, etc. I l faut, à tout moment, équilibrer et synchroniser ces différentes séquences d'activités pour en dominer la complexité.

Le premier pas vers la division du processus de développement l o r i c i c l , on a .n chronologiquement en quatre phases : création, élaboration, construction Bl trini phase est ensuite divisée en une ou plusieurs itérations. Ce chapitre esquisse In un de ces phases et itérations, abordées en détail dans les quatre chapitrai luivantl

Les développeurs divisent le travail, bien trop complexe dans sa globalité, en portions plus facilement compréhensibles. Sur l'ensemble du cycle de vie du développement, la tâche est ainsi répartie en phases et, au sein de ces phases, en itérations, comme l'indique la deuxième partie du présent ouvrage.

12.2.1 La phase de création

Au sein de chacune de ces itérations, l'équipe du projet cherche à trouver un équilibre entre les diverses séquences d'activités. I l s'agit donc de se concentrer sur les points essentiels de chaque itération. Or, ces points essentiels varient en fonction du stade du cycle de vie auquel on est parvenu : i l faut donc les sélectionner et y consacrer la majeure partie des efforts. Tout en équilibrant ces séquences d'activités, i l faut également s'assurer qu'elles sont d'importance comparable, afin de pouvoir les hiérarchiser et les synchroniser avec efficacité. I l semble que l'impossibilité d'atteindre un tel équilibre et une exécution efficace soit à l'origine de l'échec de plus d'un cycle de vie de développement itératif et incrémental.

établit

la

a i 1

i

r Ituqtn nl<

faisabilité

Le premier objectif de cette phase est de procéder à l'étude de rentabilité : le projet vaut il la peine d'être entrepris ? Cette étude s'enrichira d'informations complémentaires dans la phase d'élaboration. La phase de création ne propose pas une étude complète du système envisagé. Elle ne vise qu'à dégager le faible pourcentage de cas d'utilisation qui prendront en charge l'étude initiale. La création de cette étude s'articule autour de quatre étapes, décrites ci-dessous.

Décrivez et esquissez l'architecture candidate du système, en particulier les parties inédites, risquées ou complexes du système. Cette étape s'arrête généralement à la description de l'architecture et crée rarement un prototype exécutable. La description de l'architecture se compose des premières vues approximatives des modèles. L'objectif est ici d'affirmer la crédibilité de la mise au point, dans la phase suivante, d'une architecture stable du système envisagé. I l n'est pas question de construire l'architecture dans cette phase ; le but est simplement de montrer qu'elle est réalisable. Sa construction représente le résultat principal de la phase d'élaboration.

2.

Délimitez la portée du système proposé : définissez les frontières du système et commencez à identifier les interfaces avec d'autres systèmes situés au-delà de ces frontières.

1.

Les premières itérations traitent avant tout des risques majeurs, des cas d'utilisation essentiels, des problèmes d'architecture, du choix de l'environnement de développement, de toutes les activités nécessitant des recherches, tandis que les itérations plus tardives s'attachent aux activités de développement, aux problèmes d'implémentation, de tests, d'évaluation des performances et au déploiement du système. L'association harmonieuse et équilibrée de toutes ces activités est une tâche délicate. C'est précisément ce qui explique l'incroyable complexité du développement logiciel. Comprendre et équilibrer ces diverses séquences d'activités : voilà bien l'objet de chaque itération. Certaines de ces séquences d'activités ont été identifiées dans le Processus unifié et décrites en tant qu'enchaînements d'activités principaux. I l existe d'autres séquences qui, bien que n'ayant pas été formellement identifiées, pourraient être abordées d'une façon similaire. Par exemple :

4.

• la préparation d'une offre destinée à des clients ;

3. Identifiez les risques les plus sérieux, ceux qui affectent la capacité à construire le système, et voyez si l'on peut envisager un moyen de les réduire, éventuellement dans une phase ultérieure. On ne considère, dans cette phase, que les risques concernant II faisabilité, ceux qui compromettent la réussite 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.

• l'interaction avec les clients à propos de nouveaux besoins et exigences ; • la compréhension du contexte d'un système par l'élaboration d'un modèle du métier ;

Démontrez aux clients et aux utilisateurs potentiels que le système propose est en mesure de résoudre leurs problèmes 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

itératif et

incrémental


III

phase de création, on peut construire un prototype nom apporter la preuve que la solution répond au problème des clients et des futurs utilisateurs ( le p ype lait la démonstration des idées maîtresses du nouveau système, en s'allac haut pailiculici ement à son utilisation : les interfaces utilisateur et/ou quelques nouveaux algorithmes intéressants. Il marque une tendance à l'exploration, dans le sens ou il démontre une solution possible mais qui ne sera pas forcément 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 généralement évolutif, c'est-àdire susceptible d'être amélioré dans la phase suivante. Ces efforts se poursuivent jusqu'au point où il apparaît rentable de développer le produit. On montre ainsi que le système produira, dans des limites assez larges, un revenu ou un autre type de valeur proportionnel à l'investissement nécessaire à sa construction. En d'autres termes, la première ébauche de l'étude de rentabilité est achevée. Elle se précisera dans la phase suivante, l'élaboration. L'objectif est de réduire le plus possible le budget et les délais consacrés à cette phase pour arriver à la conclusion que le système est réellement faisable. Dans le cas d'un système largement inédit dans un domaine peu exploré, cette recherche peut mobiliser des délais et des efforts considérables et s'étendre sur plusieurs itérations. En revanche, si les risques et les inconnues concernant un système courant dans un domaine établi, ou l'extension d'un système existant, sont minimes, la réalisation de cette première phase peut durer quelques jours seulement.

12.2.2 La phase d'élaboration de réalisation »

s'intéresse

à la «

capacité

12

Ils élaborent une offre abordant les questions de calendrier, de personnel et de budget dans les limites fixées par les pratiques du métier.

5.

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 %.)

4.

Les besoins et l'architecture (en analyse, conception et implémentation) repiesc l'essentiel du travail des phases de création et d'élaboration.

12.2.3 La phase de construction

« construit » le

i

système

L'objectif général de la phase de construction est tout entier conlenu dan p pal jalon : la capacité opérationnelle initiale. I l s'agit de livrer un produit prêt 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'itérations supérieur à ceux des phases précédentes. Il semble que, dans bien des cas, la construction dure trop longtemps en raison d'une miU vaise préparation des besoins, de l'analyse et de la conception. Les développeurs sont donc obligés de bricoler dans leur coin et mettent plus longtemps à satisfaire aux besoins et à éliminer les anomalies (bogues). L'un des grands avantages que présentent les approches de l'ingénierie logicielle qui s'appuient sur un développement itératif, incrémental, à phases multiples est d'équilibrer l'affectation des ressources et des délais tout au long du cycle de vie (voir la section 12.1). La phase de construction comprend les activités suivantes :

La phase d'élaboration livre comme principal résultat une architecture stable, qui guidera le système tout au long de sa future vie. Cette phase pousse également l'étude du système proposé jusqu'à une planification très fidèle de la phase de construction. Pour satisfaire ces deux objectifs généraux - l'architecture et l'estimation fidèle des coûts - , les membres de l'équipe effectuent les tâches énumérées ci-dessous.

Ils définissent les niveaux de qualité à atteindre, par exemple en termes de fiabilité (taux d'anomalies) et de temps de réponse.

3.

Ils identifient les risques les plus significatifs, ceux qui sont de nature à bouleverser le plan, le coût et le calendrier des phases suivantes, et les réduit à des activités dont les délais et les budgets peuvent être estimés.

2.

Ils créent une architecture de référence couvrant toutes les fonctions du système significatives sur le plan architectural et les caractéristiques importantes pour les intervenants, comme le décrit le chapitre 4. Cette architecture de référence se compose des artefacts des modèles, de la description de l'architecture et de l'implémentation exécutable. Elle ne démontre pas seulement la possibilité de construire une architecture stable, mais englobe toute l'architecture.

1.

Finalisation de l'analyse (il peut rester à analyser plus de la moitié des cas d'utilisation au début de la phase de construction), de la conception, de l'implémentation et des tests (il peut en rester 90 % à effectuer).

2.

Extension de l'identification, de la description et de la réalisation des cas d'utilisation à l'ensemble des cas d'utilisation.

1.

3. 4.

Préservation de l'intégrité de l'architecture (modification si nécessaire). Surveillance des risques critiques et significatifs identifiés dans les deux premières phases et, en cas de matérialisation, réduction de ces risques.

12.2.4 La phase de transition aborde l'environnement

utilisateur

La phase de transition commence souvent par la version bêta : la société de devcloppcmcnl distribue le produit logiciel, alors capable d'un fonctionnement initial, à un échantillon d i n i lisateurs réels représentatif. Le fonctionnement dans le contexte plus ardu des soi létél lltill satrices représente souvent une épreuve bien plus difficile pour l'étal de devcloppcmcnl icel du produit que son utilisation dans le royaume protégé des développeurs. La transition comprend les activités suivantes : • préparation des activités, comme la préparation 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

• recommandations au client sur la mise à jour de rcnvimiinciucnl (matériel, systèmes 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 première documentation pour les utilisateurs de la version bêta ; • adaptation du logiciel afin qu'il puisse fonctionner avec les paramètres réels de l'environnement utilisateur ; • correction des anomalies détectées après les retours des testeurs de la version bêta ;


12

figure 12.2 Les cinq enchaînements \ se i répètent dans chaque itération, précédés par la planification et suivis de l'évaluation.

^

Besoins

^

^

Analyse

^

^

Conception ^

^

Implémentation^

^

i Itération générique

• modification du logiciel à la lueur des problèmes qui n'avaient pas été prévus. Comprend on pltn (Kl plnnllliaitlmi ai» n, ® ru.ilu M 11. ,

La phase de transition s'achève 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 réunion post mortem destinée à : • dégager les « leçons » du projet, en débattre, les évaluer et les consigner comme référence pour l'avenir ; • consigner les questions d'utilisation dans la version ou la génération suivante.

12.3

L'itération générique revisitée Nous faisons une distinction entre enchaînements d'activités principaux et enchaînements d'activités d'itération. Les premiers - les enchaînements d'activités des besoins, d'analyse, de conception, d'implémentation et de tests - font l'objet des chapitres 6 à 11. Dans le Processus unifié, ces enchaînements d'activités ne se produisent pas une seule fois, comme c'est théoriquement le cas dans le modèle en cascade, mais ils reviennent à chaque itération, comme enchaînements d'activités de l'itération. Cependant, à chaque fois, les détails en sont différents : ils traitent les questions centrales à chaque itération.

12.3.1 Les enchaînements à chaque itération

d'activités

principaux se

répètent

L'itération générique comprend les cinq enchaînements d'activités principaux (besoins, analyse, conception, implémentation 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 précédant l'itération, la section 12.8 aborde l'évaluation de chaque itération et les chapitres 13 à 16 évoquent ensuite en détail la façon dont les cinq enchaînements d'activités s'appliquent à chaque phase.

12.3.2 Les travailleurs prennent part aux d'activités

enchaînements

Nous avons parfois évoqué le développement logiciel comme étani complexe I a figure 12.3 propose une vision d'ensemble simplifiée de ce processus. Même dans celle optique, la figure est loin d'être simple, et la réalité, comme vous le savez, est encore plus compliquée. Dans ce chapitre, nous n'allons pas détailler la façon dont chaque travailleur produit les artefacts dont i l est responsable, ni décrire la nature même de chaque artefact. Les engrenages de la figure 12.3 symbolisent ce travail, tandis que les flèches reliant les activités représentent les relations temporelles (pour plus de détails, voir les chapitres 6 à 11). Les enchaînements d'activités principaux, qui englobent les travailleurs et les activités qu'ils exécutent, sont représentés par les cercles tracés à la main. L'ingénieur de composants, par exemple, analyse une classe et un paquetage dans l'enchaînement d'activités d'analyse, conçoit une classe et un sous-système dans l'enchaînement d'activités de conception, implémente une classe et un sous-système et effectue des tests unitaires dans l'enchaînement d'activités d'implémentation. Malgré cette simplification, la figure 12.3 donne une idée de ce qui relève d'une itération. Par exemple, en partant du coin supérieur gauche, un analyste système identifie les cas d'utilisation et les acteurs, et les structure au sein d'un modèle de cas d'utilisation. Puis un spécificateur de cas d'utilisation vient détailler chacun de ces cas d'utilisation, tandis qu'un concepteur de cas d'utilisation prototype les interfaces utilisateur. Enfin, l'architecte définit l'ordre de priorité des cas d'utilisation à développer dans une itération en prenant en consi dération les risques impliqués.


III


12

Dans les chapitres suivants, la figure 12.3 est complétée par les éléments nécessaires à la représentation des enchaînements d'activités de chaque phase, qui suivent tous le modèle de cette figure générique. L'attention se portant sur différents aspects selon les phases, les enchaînements d'activités des itérations correspondantes varient en degré.

12.4 La planification précède l'action Quand nous nous trouvons au début de la phase de création, nous savons au moiltl choses : • nous allons mener le projet à bien par une série d'itérations se déploj Ull lui QUBtrt phases ; • nous disposons des informations concernant le système proposé q u i nos prédécesseurs (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 itération (plan d'itération). Au début, les informations étant limitées, ces d e u x plaie, c o u tiennent peu de détails, mais ils s'enrichissent progressivement, à mesure que l'on avam e dans les phases de création et d'élaboration. Nous allons d'abord expliquer la planification des phases et des itérations et le moyen d'évaluer chaque itération. Puis les sections 12.5 et 12.6 évoqueront respectivement l'impact des risques sur ce plan et le moyen de réduire ces risques en sélectionnant les cas d'utilisation adéquats. Enfin, l'affectation des ressources sera traitée dans la section 12.7. Figure 12.3 avance

Le temps

des travailleurs

Les

titres

de gauche

sont à

recensés

verticalement

à gauche

et à droite

et identifient

chaque

« travée

».

droite.

Vous pouvez constater que les activités exécutées dans le « cercle » des exigences varieront en fonction de l'emplacement de l'itération par rapport au processus de développement dans son ensemble. Dans la phase de création, par exemple, les travailleurs limitent la description détaillée des cas d'utilisation et l'attribution d'un ordre de priorité à la stricte proportion de cas d'utilisation nécessaire à cette phase. Les quatre premiers enchaînements d'activités se suivent à peu près chronologiquement, même s'il peut y avoir des chevauchements. Les trois travailleurs impliqués dans l'enchaînement d'activités d'analyse conduisent le projet jusqu'à la conception. Néanmoins, l'enchaînement d'activités des tests commence très tôt, avec la planification, par l'ingénieur de tests, de ce qui doit être fait. Dès qu'on dispose de suffisamment d'informations, l'ingénieur de tests conçoit les tests dans l'enchaînement d'activités d'implémentation. Au fur et à mesure de l'intégration des composants ayant subi les tests unitaires, le testeur système et le testeur d'intégration peuvent tester les résultats de plusieurs niveaux d'intégration. L'ingénieur de tests évalue ensuite si les tests prescrits par ses soins se sont révélés adaptés.

12.4.1 Planifier les quatre

phases

Nous savons, d'après les prescriptions du Processus unifié, ce qu'implique chaque phase. Dans le plan du projet, notre tâche consiste à traduire ces prescriptions en actions concrètes. • Affectation des délais. I l s'agit de définir les délais attribués à chaque phase et de fixer à chacune d'elles une date d'achèvement. Bien que déterminés avec précision, ces délais peuvent rester quelque peu incertains au début de la phase de création, mais ils doivent s'affermir grâce aux informations accumulées. Après tout, nous ne sommes pas tenus de faire une offre définitive avant la fin de la phase d'élaboration. • Jalons majeurs. Une phase s'achève lorsque les critères définis au préalable sont a l l a n t s Si ces critères peuvent, au début, s'apparenter à des devinettes savantes, ils se m u n i r . m toutefois de notre expérience antérieure dans le domaine (jusqu'au point o ù le .\u envisagé se démarque des précédents), des spécifications de performance! q u i a i r u . , atteindre le système et des capacités de nos équipes de développement logil le! • Itérations par phase. Au cours de chaque phase, le travail progresse a travail OU plusieurs itérations. Le caractère général de chaque itération transparaît dan I. plu encore approximatif du projet.

mm

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ÏÏI

• Plan du projet. Le plan du projet trace les grandes lignes d'un « plan de roule abordant le calendrier, les dates et les critères des jalons majeurs, ci enfin II décomposition des phases en itérations.

p 'notai

r l

,

On peut s'attendre à rencontrer quelques difficultés dans la première ilcralion de la phase de création. Outre l'itération elle-même, i l faut traiter les aspects énumérés ci-dessous. • Personnaliser le Processus unifié pour l'adapter au projet et sélectionner les outils permettant d'automatiser le processus.


12

§m WM

• Jalons mineurs (annexe C). La satisfaction des critères préalablement définis (de préférence à la date prévue) indique l'achèvement de chaque itération. • Plan d'itération (annexe C). Les activités de chaque itération sont consignées dans un plan précis de l'itération. Les personnes devant agir en tant que travailleurs sont affectées au début de chaque itération. Le nombre d'itérations prévu pour chaque phase varie, essentiellement en fonction de II complexité du système envisagé. Un projet extrêmement simple pourra clic M I C I H a I avec une seule itération par phase, alors qu'un projet plus complexe en exigci a lop.iqm nu m un nombre supérieur. Par exemple :

• Commencer à réunir les personnes possédant les compétences requises par le projet. • Établir des relations permettant de former une équipe vraiment efficace.

• Phase d'élaboration (annexe C) : deux itérations ; la première effccluein passe sur l'architecture et la seconde aboutira à l'architecture de réfèrent e

• Percevoir la nature du projet, tâche qui sera plus délicate 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 créer la génération suivante.

• Phase de création (annexe C) : une itération, essentiellement consacrée il lu di I de la portée du système.

• Comprendre le domaine, souvent inconnu pour l'équipe.

• Familiariser l'équipe avec les outils adaptés au processus personnalisé et au projet.

12.4.2 Planifier les

i

• Phase de construction (annexe C) : deux itérations, afin de s'assura qui II qui en résultent fonctionnent de façon satisfaisante.

li n n -

'

• Phase de transition (annexe C) : une itération.

itérations

Chaque phase consiste en une ou plusieurs itérations. La planification des itérations passe par un série d'étapes assez comparables à celles qui permettent de planifier les phases. • Calendrier des itérations. I l s'agit de définir les délais attribués à chaque itération et de fixer à chacune d'elles une date d'achèvement, d'abord approximative, puis de plus en plus précise grâce à l'accumulation des informations.

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'itérations et la durée de chacune variera, selon la taille du système, d'une semaine à environ trois mois.

12.4.3 Penser à long terme

• Contenu des itérations. Alors que le plan du projet esquisse les itérations prévues en termes généraux, la planification de l'objet de chaque itération gagne en précision à mesure qu'approche la date de début d'une itération. Le contenu d'une itération se dégage des points suivants : - Quels sont les cas d'utilisation que doit remplir, au moins partiellement, l'itération ? - Quels sont les risques techniques qu'il est temps d'identifier, de traduire sous forme de cas d'utilisation et de réduire ? - Tous les changements de besoins ou les anomalies ayant pu être corrigées doivent être pris en compte. - Quels sont les sous-systèmes qui doivent être, partiellement ou complètement, implémentés ? (Ce point varie en fonction de la phase examinée. La phase d'élaboration identifie la plupart des sous-systèmes et toutes les classes significatives sur le plan architectural, alors que la phase de construction étoffe le comportement des sous-systèmes, ce qui donne lieu à des composants plus complets.)

La longue période pendant laquelle le système est susceptible de durer peut être témoin de changements radicaux : l'émergence de nouvelles technologies, de nouvelles interfaces avec l'environnement du système ou des plates-formes évoluées. Par ailleurs, les planificateurs doivent examiner les éventuels besoins d'adaptation du métier à d'autres organisations, telles que des filiales ou des partenaires de fusion. Inutile, toutefois, de spéculer jusqu'à l'absurdité sur l'avenir. Certes, personne n'imagine de construire une architecture système rigide en sachant pertinemment qu'elle devra être modifiée à l'avenir ; mais ce n'est pas non plus la peine de doter le système d'une flexibilité inutile qui ne servira jamais à rien.

12.4.4 Planifier les critères

d'évaluation

Les itérations sont courtes par rapport aux projets traditionnels. Pour éviter qu'elles ne se prolongent indéfiniment, les chefs de projet doivent, en plus de fixer un calendrier, esquissa les objectifs clés de chaque itération. Pour la satisfaction de ces objectifs, ils établlstenl d e s critères indiquant le degré de réalisation de l'itération. Ces critères, tels que la i .u.u n i e . tique minimale définie à un point donné, mobilisent l'attention sur l'itération en qui Itiotl I facilitent son achèvement en temps et en heure. Voici quelques exemples de ces ci 1

Le plan de l'itération en cours est intégralement détaillé, tandis que celui des itérations suivantes se précise à la lueur des informations récoltées. Le détail des itérations suivantes peut se limiter aux connaissances alors disponibles :

• besoins fonctionnels, exprimés sous forme de cas d'utilisation ; • exigences non fonctionnelles, associées aux cas d'utilisation qu'elles

e o n c c i lient


III

• exigences non fonctionnelles, non spécifiques a un i as d'ulile.al des exigences supplémentaires comme le décrit la scciiou (> /

eccniées dani

L'un des objectifs d'une itération du début peul consister, pm exemple, a levei toute* ambiguïtés de la formulation des besoins par le client. Ce type de critère préi ise ce que planificateurs attendent de cette itération en termes mesurables, ci ic le niveau de pei mances, ou observables, comme l'ajout d'une fonction souhaitée. Le responsable du projet définit à l'avance des critères d'évaluation pour chaque itération c i l pour la phase elle-même. Chacune doit se terminer par un point d'achèvement parfaitement clair, qui permettra aux développeurs de s'apercevoir que leur tâche est terminée Ces p^mu i d'achèvement constituent en outre des jalons qui permettront aux responsables d'apprécié! la progression du travail. En gros, les critères d'évaluation se répartissent en deux catégories : les exigences vérifiables et les critères plus généraux. Comme le décrit en détail le chapitre 11, les ingénieurs de tests participent au dévelop-j pement dès la phase de création. Ils déterminent les caractéristiques des cas d'utilisation susceptibles d'être confirmées par des tests. Ils planifient les cas de test qui définissent les tests « d'intégration et les tests de non-régression, ainsi que les tests système. Dans un développement itératif, le cycle de tests est, lui aussi, itératif. Chaque construction créée au sein d'une itération peut être sujette à des tests. Les ingénieurs de tests enrichissent et précisent les tests exécutés pour chaque construction et constituent de la sorte un corpus de tests qui permettra d'effectuer plus tard des tests de non-régression. Les premières itérations introduisent un plus grand nombre de nouvelles fonctions et de nouveaux tests que les itérations ultérieures. A mesure que se poursuit l'intégration des constructions, le nombre de tests nouveaux diminue, tandis que de plus en plus de tests de non-régression sont exécutés en vue de valider l'implémentation accumulative du système. Les premières constructions et itérations réclament donc davantage de planification et de conception de tests, alors que celles qui viennent plus tard s'appesantissent plutôt sur l'exécution et l'évaluation des tests.


12

1 5 Les risques affectent la planification du projet

I • •

La manière dont on planifie le développement d'un nouveau système est, dans une des largi mesure, influencée par les risques entrevus. L'une des premières étapes, au tout début de la phase de création, 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 déle m a t, système pourra être construit ou non. Puis, à mesure qu'avancera le travail daie. I. mières phases, on en viendra à estimer ce que seront les risques sif.nilicatils c est a d m ceux qui doivent être réduits afin d'établir un calendrier et un budget cl il nlli mdi objectif de qualité.

i2.5-1 Gérer

une liste des

risques

C'est une chose de savoir vaguement que le développement 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 éléments ci-dessous : MmÊ

• Description : commencez par une brève description, que vous enrichirez progressivement. • Priorité : affectez-lui une priorité, en commençant par critique, significatif ou courant. L'allongement de la liste vous amènera sans doute à créer d'autres catégories.

Bf • Impact : quelles sont les parties du projet ou du système qui seront touchées 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 matérialise ? 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 données, 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 développement itératif. Les risques sont triés par degré de gravité ou en fonction de leur effet sur le développement, et traités dans l'ordre. Comme nous l'avons déjà répété haut et fort, les risques à traiter en premier sont ceux qui sont susceptibles de provoquer l'échec du projet. Certains risques ne se prêtent pas à une résolution simple et demeurent longtemps sur la liste des risques, Il peut être utile, comme le pratiquent certaines entités de développement, de placei en tête de liste le palmarès des dix risques les plus graves afin d'y consacrer toute l'attention iiécessauc

Les critères généraux ne sont pas réductibles aux chemins à travers le code pouvant. ne testés. Ils peuvent toutefois, dans un premier temps, être perçus dans des prototypes, puis dans la série de constructions et d'itérations. Les utilisateurs, les intervenants et les développeurs peuvent considérer les affichages et les interfaces utilisateur graphiques avec plus : de perspicacité qu'ils ne peuvent examiner les informations statiques contenues dans les artefacts des modèles. Ces critères d'évaluation indiquent les moyens de vérifier que les besoins et les exigences imposés à une itération ont été développés de façon satisfaisante. Ils spécifient, en termes:; observables ou vérifiables, ce qu'attend le responsable du projet de l'itération en question. Ils s'inspirent, à l'origine, de la déclaration d'intention et gagnent en précision à mesure que les cas d'utilisation, les scénarios de cas d'utilisation, les exigences de performances et les cas de test expriment concrètement ce que doivent être les incréments successifs.

La liste des risques n'est pas un instrument statique. Elle s'étoffe avec la découvcile de non veaux risques et s'allège à mesure qu'en sont éliminés d'autres ou que l'on ilepassi li i.» i du développement auquel un risque particulier est susceptible de se concrétisa I 1 o 1 sable du projet organise des réunions régulières, souvent en parallèle avec les évaluai des itérations, pour revoir l'état des risques majeurs, tandis que d'autres r e s p o n s a l ù i animent les réunions concernant les risques moins sérieux.


III

12.5.2 Les risques affectent le plan des

itérations

Au cours de la phase de création, les risques critiques sont Identiflél et les membres I l'équipe tentent de les réduire. Ils en explorent la nature en allant |usqu'au stade où ils peuvent mettre au point un plan des itérations. Pour disposer des Informations permettant • réaliser ce plan, i l est possible qu'ils doivent, par exemple, développa les quelques cas d'utilisation liés à ce risque et les implémenter dans le prototype de mise a l'épreuve du concept. En fournissant certaines entrées, ils voient ensuite que le prototype génère ur.~ sortie inacceptable (un tir prématuré, par exemple), soit un risque critique. (Ces entrées doivent rester dans la gamme d'entrées spécifiée, ou éventuellement à la lisière, et néanmoins livrer une sortie inacceptable.) Outre les conséquences qu'ont les risques les plus graves sur la réussite d'un projet, tous les risques ont un retentissement sur le calendrier, le coût ou la qualité. Certains de ces risques peuvent être suffisamment graves pour allonger les délais ou accroître l'effort nécessaire audelà des prévisions, à moins qu'ils ne soient réduits avant que ces résultats indésirables ne se matérialisent. 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 coûts mais affecte d'autres facteurs, tels que la qualité ou les performances.

12.5.3 Planifier les actions à entreprendre

face aux

risques

Le principe général est d'entreprendre, face aux risques, des actions planifiées. Les phases, et les itérations qui les composent, offrent un mécanisme de planification de ces actions. Par exemple, prévoyez de traiter les risques touchant la capacité à construire le système dès la ou les itérations de la phase de création : soit vous les éliminez (si possible), soit vous disposez au moins d'un plan permettant de les circonscrire. D'après notre expérience, l'autre solution, qui consiste à ne pas planifier la résolution des risques, fonctionne assez mal. En l'absence d'une volonté réfléchie d'agir sur les risques très tôt, ceux-ci se manifestent généralement tard dans le déroulement du développement, au moment des tests d'intégration et des tests système. A ce stade, la résolution de problèmes graves, susceptibles de réclamer d'importantes modifications du système, risque de retarder la livraison de plusieurs semaines, voire plus. L'approche itérative, qui prévoit l'élaboration de prototypes, de constructions et d'artefacts dès la première phase, permet de mettre au jour les risques lorsqu'il est encore temps de les atténuer. Nous avons parfaitement conscience que certaines catégories de risques sont difficiles à identifier et à décrire. 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 impliquées dans le projet se laissent abuser par un battage médiatique surestimant ce qui peut réellement être effectue au prix envisagé et dans les délais souhaités. Si certains risques « sortent des écrans de contrôle », le projet ne peut plus les planifier dans des itérations et les réduire dans un semblant d'ordre.


12

Quelle qu'en soit la raison, i l arrive que certains risques soient négligés jusqu'à un moment tardif du développement, en particulier lorsque l'équipe du projet manque d'expérience en matière de gestion des risques. La pratique et l'expérience aidant, les équipes améliorent leut capacité à séquencer 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 deuxième itération doivent être traités au plus tard pendant la première Iti ration de cette phase. L'objectif est que chaque itération de la phase de c o n s i n u i déroule 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 résolu rapidement

12.6 Définition d'un ordre de priorité pour les cas d'utilisation Nous allons aborder, dans cette section, la sélection des cas d'utilisation désuni a . n< employés comme pilotes dans une itération. Rappelez-vous que dans le l'une, .us unlflt chaque itération est pilotée par un ensemble de cas d'utilisation. Il serai! d'ailleun plui |uiti de dire qu'une itération est pilotée par un ensemble de scénarios de cas diuilisaliou Plus juste, parce que les premières itérations n'exploitent pas nécessairemcnl des cas d'utilisation complets. On ne prend alors que les scénarios ou les chemins pertinents pour la tflchc en cours de réalisation. I l arrive que, lorsque nous parlons de sélectionner des cas d'utilisation, nous fassions en fait allusion aux seuls scénarios de ces cas d'utilisation qui nous intéressent à ce moment-là. Cette sélection donne lieu à la définition d'un ordre de priorité pour les cas d'utilisation (voir la section 7.4.2). Les cas d'utilisation sont ainsi hiérarchisés, classés selon l'ordre dans lequel ils (ou leurs scénarios) doivent être traités dans les itérations, et ce sur plusieurs itérations. Dans les premières itérations, certains cas d'utilisation (ou scénarios) sont classés, mais la plupart n'ont pas encore été identifiés. Une fois identifiés, ils sont classés à leur tour. Ce classement se traduit par une liste hiérarchisée des cas d'utilisation. Ce sont les risques qui gouvernent ce classement. Les cas d'utilisation sont, en effet, classés 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 système dans les dernières phases représente un risque qui doit être évité. Ne pas construire le système approprié constitue un risque qu'il faut réduire très tôt en identifiant les véritables besoins. Le processus de sélection est donc piloté par les risques. Après leur identification, les risques sont placés 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 implémente, permet de le réduire < 'e c as d uldi sation est donc inséré dans la liste de classement des cas d'utilisation ;i nu niveau | UTM pondant à son degré de risque. Dans les premières itérations, l'activité de classement des cas d'utilisation l'attai hi W •> tiellement aux risques liés à la portée du système et à l'architecture. Les itérationi llltérlt un voient ensuite la sélection des cas d'utilisation destinés à é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


III

exemple, les cas d'utilisation dépendants d'autres cas d'utilisation apparais* m plus h dans le classement et sont donc développés après les autrel POUI U t i l évocation de l'approche itérative comme tentative pilotée par les risques, consulte/ la sei lion •> t. | . trois sections ci-dessous traitent maintenant des trois catégories de risques les risques spé cifiques, les risques architecturaux et les risques liés aux besoins et aux exigences. u s

lL

12.6.1 Risques

spécifiques

à un produit

s

particulier

Il s'agit du type de risques, c'est-à-dire des risques techniques, abordé dans la section 5.3.1. Ces risques sont transposés en cas d'utilisation qui, s'ils sont correctement réalisés, permettent de les réduire. 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 spécifique au traitement d'un certain type de risques. Certains risques architecturaux, par exemple, sont examinés dans la phase de création, 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 gérés un par un, et réduits avant que leur présence n'entrave la progression du développement.

12.6.2 Risques

de créer

une architecture

inadaptée

L'un des risques majeurs est de construire un système incapable d'évoluer élégamment dans les phases suivantes ou sur l'ensemble de sa durée de vie, c'est-à-dire de créer une architecture ne sachant pas réagir aux changements. Ce risque est explicitement traité dans les phases de création et d'élaboration : on s'assure que l'on dispose de l'architecture appropriée et que l'on peut donc la figer (sauf pour y introduire de menus changements imposés par la phase de construction). C'est ce que nous entendons dans le paragraphe précédent, 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 création et d'élaboration traiteront explicitement de l'architecture. Comment déterminer les cas d'utilisation fondamentaux pour l'obtention de l'architecture appropriée ? Comment réduire 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 tâches ou fonctions qu'est censé accomplir le système. Posez-vous la question suivante : « Pourquoi construisons-nous ce système ? » La réponse est contenue dans les cas d'utilisation critiques, c'est-à-dire ceux qui comptent le plus pour les utilisateurs du système. Les cas d'utilisation ayant d'importantes exigences non fonctionnelles - performances, temps de réponse, etc. - ressortissent également à cette catégorie. Ces cas d'utilisation permettent en général d'ébaucher le squelette du système, auquel i l suffit ensuite d'ajouter le reste des fonctions nécessaires (voir la section 7.2.4). Vous trouverez, ci-dessous, les autres catégories de cas d'utilisation. • Les cas d'utilisation secondaires. Ces cas d'utilisation viennent suppléer 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

impact modeste sur l'architecture, i l peut être nécessaire de les développer tôt dans le processus de développement. I l peut par exemple s'agir d'un intervenant exprimant le besoin de consulter certaines données, telles que les frais de transactions décrits 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 réduire le risque de ne pas satisfaire aux véritables exigences. • Les cas d'utilisation de confort (agréables à 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 itérations des phases de créai al d'élaboration. Si c'est le cas, leur présence ne joue qu'un rôle 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, même s'ils ne sont pas présents en permanence. I l peut r h e n , , , , |, i, traiter, car ils affectent l'architecture lorsqu'ils sont présents. 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 impératif 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 coût de développement du produit peut être estimé avec précision dans le premier cycle. I l faut à tout prix éviter de s'apercevoir trop tard qu'on ne pourra pas accueillir une fonction récemment découverte. 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 système. En pratique, on identifie en moyenne quelque 80 % des cas d'utilisation, qui sont ensuite intégrés au modèle des cas d'utilisation, mais qu'il n'est généralement pas nécessaire de détailler un par un. I l suffira, dans la plupart des projets, d'en décrire 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 détailler 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 décrire avec précision au moins 80 % d'entre eux.

12.6.3 Risque

de ne pas bien comprendre

les

besoins

Autre risque grave : celui qui consiste à créer un système ne faisant pas ce que les utilisa teurs attendent précisément de lui. Les moyens de traiter ce risque figurent également dans le processus. On vérifie, à l'issue de la phase d'élaboration, qu'on est bien en train «le voie, truire le système souhaité. Cette investigation ne doit pas être reportée, car la phase de , . ne, traction met enjeu des sommes considérables. Quels sont les cas d'utilisation permettant de s'assurer que l'on développe bien le système qui conviendra à ses utilisateurs 7 Quels ' o u i les cas d'utilisation garantissant que le système pourra évoluer dans les phases s u i v i ii prendre en charge toutes les exigences imposées par la première version 7 Aucune Ion. non ne doit rester dans l'ombre. I l faut savoir si ce que l'on construit peut évoluer.


III

La première partie de la réponse réside, bien entendu, dans la juste appréhension des besoins et des exigences. On peut, pour cela, créer un modèle du métier (ou, dans certains l I I un modèle du domaine, plus restreint). La seconde partie consiste à construire, pai le biais des premières itérations et de divers prototypes, le système qu'exigent les utilisateurs et a sus citer leurs réactions le plus tôt possible. Seule l'utilisation réelle permet de s'assurer qu'on a construit le système voulu. MjiJJIJ

S y s t è m e de facturation et de r è g l e m e n t


12

• De combien de mois les premières phases vont-elles retarder ce qu'on considère généralement comme la « véritable activité » du développement logiciel, c'est-à-dire la construction ?

12.7.1 Les projets

diffèrent

énormément

Ce n'est un secret pour personne que le moment où un projet de système logiciel est prêt à entrer en développement varie énormément d'un projet à l'autre. Prenons quatre exemples.

2.

Lorsque le chef de projet examine l'ordre des itérations, il ne doit donc pas négliger l'importance de cette fonction. D'un côté, s'il s'aperçoit que la facturation de ces frais représente une simple fonction dans le cas d'utilisation en cours ne posant aucun problème particulier aux développeurs, il peut estimer qu'il n'est pas nécessaire de la traiter pendant la phase d'élaboration et qu'il peut, en toute sécurité, la reporter à la phase de construction. D'un autre côté, s'il découvre que cette fonction présente un certain nombre de problèmes internes compliqués (indépendants des autres cas d'utilisation), il doit prévoir de la traiter dans une itération de la phase d'élaboration. L'un de ces « problèmes compliqués » pourrait venir, par exemple, de l'exigence du client de voir cette facturation de frais résolue de prématurément.

1. Un produit totalement nouveau ou sans précédent dans un domaine inexploré (greenfield project). Personne ne sait grand-chose de ce qui doit être fait, ni même s'il est possible de le faire. La matière dont on dispose est assez maigre. I l va donc falloir se reposer sur quelques personnes expérimentées et jouer un peu aux devinettes. Dans un tel contexte, la société ou la personne qui demande la création de ce système est, en un sens, responsable du financement des phases de création et d'élaboration. Ces phases doivent presque être financées comme de la recherche, c'est-à-dire sur la base d'un coût supplémentaire. On n'en sait pas assez pour garantir le respect d'un calendrier ou d'un budget précis dans les phases de création et d'élaboration. Dans ce type de situation, la définition de la portée, l'élaboration d'une architecture candidate, l'identification des risques critiques et la préparation d'une étude de rentabilité exigent du temps dans la phase de création. De même, la satisfaction des objectifs de la phase d'élaboration, qui consistent à mener le projet au stade où la phase de construction pourra être planifiée, prendra encore plus de temps.

On pourrait considérer, dans le système de facturation et de règlement, que la banque décide 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'intégration 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 rôle clé dans l'élaboration de l'architecture appropriée. Elle pourra être traitée comme une extension d'autres cas d'utilisation ou associée à plusieurs cas d'utilisation couvrant cette facturation de frais. Pour les développeurs, 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 extrêmement important que les cas d'utilisation concernant cette facturation de frais soient correctement implémentés avant la livraison. C'est pourquoi cette fonction est classée comme risque élevé et qu'elle acquiert, de ce fait, une grande importance.

12.7 Ressources nécessaires Tout en sentant confusément que le plan itératif du développement logiciel fondé sur les phases possède des mérites considérables, vous vous posez peut-être encore quelques questions : • A quel prix vont revenir les phases de création et d'élaboration, que ce soit en termes d'efforts de développement ou en matière 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 ?

Un type de produit déjà réalisé, dans un domaine où les produits précédents fournissent des exemples, mais aucun composant réutilisable. Si ces produits précédents servent de guide à l'architecture candidate, i l peut falloir plusieurs jours avant de s'assurer que l'architecture précédente convient vraiment. Dans de telles circonstances, la phase de création sera probablement brève (quelques semaines). Elle pourra n'exiger la présence que d'une ou deux personnes d'expérience à plein temps et se nourrira sans doute des connaissances d'autres personnes expérimentées que devra consulter cette équipe réduite. Ce type de produit ayant été réalisé par le passé, l'existence de risques majeurs est peu probable. I l faudra peut-être, néanmoins, consacrer plusieurs jours à s'en assurer.

3. Un produit patrimoine existe, mais i l doit être actualisé et migrer, par exemple, d'un gros système vers une plate-forme client-serveur. Dans une certaine mesure, on peut encapsuler et utiliser certaines parties du code existant dans le nouveau système. L'équipe de création doit trouver une architecture candidate. Comme d'autres organisations ont déjà réutilisé des produits existants, l'équipe sait ce qu'elle a à l'aire Toutefois, si l'organisation chargée 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 référence, identifier une interface entre le nouveau système et l'ani len I partir des cas d'utilisation et de la découverte des sous-systèmes - l'un de ces ms systèmes étant une encapsulation des parties du système existant qui n'ont pas besoin d'être modifiées. 4.

Des composants existent, soit sur le marché, soit en interne. L'organisation logicielle s'attend à pouvoir élaborer un pourcentage important du nouveau système (entre 50 et

rjaffjaaM Un d é v e l o p p e m e n t itératif et i n c r é m e n t a l

KfilOi

PARTIE

II!

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 réutilisables et nouveaux composants, mais aussi etilie systèmes externes et utilisateurs. Le développement de composants exige du lemps et des efforts et i l est possible que l'équipe rencontre des risques. Dans l'ensemble, toutefois, le développement à base de composants est plus rapide el moins onéreux que le développement ex nihilo. Ces exemples ne visent pas à définir des catégories distinctes. Ils représentent plutôt des positions de chevauchement. I l nous faut donc penser en termes de point de départ. De quelle expérience peut-on justifier dans le domaine de l'application ? Sur quelle base de composants réutilisables 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 système distribué (alors qu'on ne connaît que les systèmes mono-plateforme) ?

12.7.2 Voici à quoi ressemble

généralement

un


12

Figure 12.5 les imposées projet

conditions par

encore

complexe

un plus

exigent

d'augmenter

60%

la

part du travail des

et

6% 24% 8%

délais

phases

premières

aux

consacrée

par rapport

aux

Création-20%

Elaboration-33%

Constructlon-6u%

ll.M.IIIUM

suivantes.

fS

FWfftf IN

Nous nous empressons de préciser que les pourcentages apparaissant daltl 11 rlgUI hypothétiques et ne sauraient être appliqués arbitrairement à des projet! m l . l l l \ plutôt à démontrer que plus un projet présentera d'inconnues, plus il devra i oniat n i di temps et d'énergie aux phases de création et d'élaboration. Dans notre exemple, nous con crons plus de temps aux deux premières phases qu'aux deux dernières. Toutefois, lei effort! consentis n'ayant pas le même impact, i l n'est pas nécessaire d'accroître les ressources dans les mêmes proportions, même si elles augmentent aussi. En même temps, le travail cl les délais accordés au projet augmentent globalement.

projet...

Malgré les incertitudes que peuvent introduire différents points de départ, le cycle initial de développement d'un projet de taille moyenne répartira grosso modo les efforts et les délais comme l'indique la figure 12.4. En général, pour l'élaboration de l'architecture et la réduction des risques, le développement par phases fait porter une grande partie l'effort sur les parties frontales du cycle, contrairement à l'approche en cascade.

L'utilisation de cadres génériques (frameworks) écourte de façon spectaculaire la construction, mais a en revanche peu d'effet sur les premières phases. Si l'on envisage de faire de la réutilisation, les phases de création et d'élaboration seront plus longues, mais les fonctions déjà disponibles sous forme de cadres génériques n'auront pas à être analysées et conçues, si bien que, en fin de compte, le projet nécessitera des délais et des efforts moindres.

Figure 12.4 /principal de travail temps

bloc et de demeure

la phase

12.7.4 Une nouvelle ligne de produits exige de

mais

, onstruetion,

de

dans

1rs trois

nécessitent des délais

et

non

Construction-50%

Transition-10% Temps

besoins

l'expérience

Dans la plupart des cas - à coup sûr pour les systèmes innovants ou délicats - , l'équipe doit récolter des informations en plus de celles dont elle dispose déjà. Les spécialistes du domaine du système envisagé constituent la source la plus naturelle où puiser ces informations. Même si l'on possède une liste détaillée des besoins et des exigences, l'équipe doit mener des entretiens avec ces spécialistes afin de dégager l'architecture et d'accorder toute son attention aux risques. L'identification des spécialistes représente déjà, à 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 forcément ce que peut laue un système informatique.

autres

phases aussi

tles efforts

Elaboration-30%

négligeables.

12.7.3 À projets complexes,

supérieurs

Quels seront les effets si l'on prend l'hypothèse d'un projet plus ambitieux et plus complexe (avec de nouvelles fonctions, une architecture distribuée ou, par exemple, un fonctionnement en temps réel), employant de surcroît une nouvelle technologie sous-jacente ? I l faudra certainement un plus grand nombre d'itérations. I l faudra aussi consacrer plus de temps et d'efforts aux phases de création et d'élaboration. Ces deux phases sont donc susceptibles de s'allonger, comme le montre la figure 12.5.

Une erreur courante lorsqu'on commence à travailler sur une nouvelle ligne de produits i on siste à négliger de réutiliser les connaissances. L'essentiel des connaissances soi le loin non nement réel de l'entreprise se trouvant dans la tête de ses employés plutôt que d u dl documents (qu'on ne lit pas, de toute façon, la plupart du temps...), la réutilisation dei naissances revient en fin de compte à « réutiliser » les personnes d'expéricni 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, à défaut de connaître II ligna dl produits.

mmm lin d é v e l o p p e m e n t itératif et i n c r é m e n t a l mum

PARTIFÏÏI

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 compétents et les plus expérimentés. Mais, eu même 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 entrées d'argent. Il est impossible de trancher simplement ce dilemme. Les responsables hiérarchiques de ces personnes d'expérience sont déchirés 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 années. Ils y sont psychologiquement attachés. Et la plupart d'entre eux répugnent souvent à risquer de compromettre leurs affaires en cours en « cédant » leurs principaux collaborateurs au nouveau projet. Si bien que l'équipe du projet ne comptera que quelques personnes d'expérience, qui ne seront pas forcément 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 débarrasser. Ces responsables nouvellement promus doivent alors étoffer leurs équipes d'un grand nombre de nouvelles têtes, parfois fraîches émoulues de l'université. Outre leur inexpérience, ces nouveaux venus sont porteurs d'une culture particulière : ils ont tendance à considérer tout ce qui est ancien (c'est-à-dire ce que fait l'entreprise) comme complètement dépassé. Seul l'innovation compte. Les jeunes recrues ne perçoivent pas toujours l'importance des questions qui n'ont pas été traitées à l'école : par exemple, les méthodes de production et la gestion du cycle de vie. Nous avons constaté que, souvent, les entreprises n'arrivent pas à affecter au développement d'une nouvelle ligne de produits les talents nécessaires à la mise sur le marché d'une version complète en temps et en heure. Les déficiences ne sont généralement pas corrigées avant la deuxième génération du produit. Par essence, la première génération se résume souvent à une expérience en direct sur le terrain, même si ce n'était pas forcément l'intention de l'entreprise au départ.

12.7.5 II faut payer le prix des ressources

utilisées

La mobilisation d'une équipe travaillant sur les deux premières phases, aussi réduite soitelle, nécessite des fonds. En fait, la difficulté à obtenir des crédits destinés à prendre en charge ces deux phases était, jusqu'à présent, l'un des facteurs qui conduisaient les organisations logicielles à s'engager prématurément dans la phase de construction. Ce qui aboutissait parfois à des échecs retentissants et largement médiatisés. D'où ces fonds proviennent-ils ? • Dans le cas d'une société éditrice d'un produit destiné à être commercialisé, les crédits viennent du budget des « frais généraux » et sont, par conséquent, sous le contrôle 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 développement des futurs produits.


12

mm

• Dans le cas d'une société développant un produit pour un client en interne, le coût des deux premières phases provient soit de son propre budget de frais généraux, soit de fonds versés directement par le client, soit encore de fonds alloués par la direction. On notera que les deux dernières méthodes de financement supposent que des responsables extérieurs à la société de développement comprennent la valeur des deux prenucie , phases et y consacrent des fonds. • Dans le cas d'une société développant un produit destinée à un entreprise clients totalement indépendante, le coût des deux premières phases pourra clic p u s eu haï gl BU son propre budget de frais généraux. Mais la société ne disposera de surplui a de p. M l I que si elle a intégré cette dépense dans des offres faites par le passe Ni le projet suivent entre dans le cadre de l'activité normale de la société, 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 paraît rail Ilbll qui le client contribue aufinancementdes deux premières phases. t

Bref, un travail essentiel s'accomplit au cours des deux premières phaiei il lit temps et de l'argent. Mais i l réclame aussi la coopération du client < 'elle COOpi ration qui revient à mettre à la disposition de la société de développcmcnl tontes les m l o i m a i i o n , elle a besoin, coûte aussi de l'argent (même si cette dépense n'entre pas formellcmenl dani les comptes).

12.8 Évaluer les itérations et les phases Pour tirer tous les bénéfices possibles du travail itératif, le projet doit évaluer ce qui a été accompli à la fin de chaque itération et de chaque phase. C'est le responsable du projet qui est chargé de cette évaluation. I l y procède non seulement pour évaluer l'itération ellemême, mais aussi pour promouvoir deux autres objectifs : • replanifier l'itération suivante à la lueur de ce que l'itération achevée a appris à l'équipe et effectuer les changements nécessaires ; • modifier le processus, adapter les outils, poursuivre la formation et entreprendre d'autres étapes, comme le suggère l'expérience de l'itération évaluée. Si le premier objectif d'une évaluation est d'examiner ce qui a été accompli à l'aune des critères d'évaluation définis au préalable, le second s'attache à vérifier la progression par rapport au plan de l'itération ou au plan du projet ; • Le travail avance-t-il dans le respect des budgets et des délais ? • Satisfait-il aux exigences de qualité, selon ce que révèlent les tests ou l'observation pat les intervenants concernés du fonctionnement des prototypes, des composants, des constructions ou des incréments ? Dans l'idéal, le projet répond aux critères définis. Le responsable du projet disinbue alois les résultats de l'évaluation aux intervenants concernés et classe le document, qui M M i l pi actualisé, puisque chaque évaluation fera l'objet d'un document à part.


III

12.8.1 Les critères

ne sont pas

remplis

Les évaluations se déroulent rarement sans encombre. Bien souvcnl, une iiéralinn n'aura atteint un niveau suffisant de satisfaction des critères et le projet risque d'avou a n-|>n-iu) une partie du travail dans l'itération suivante (ou dans une itération tardive plus appropriés] Il peut s'agir :

rc

eux-mêmes


12

Notons que, dans un développement basé sur les composants, la métrique (c'est-à-dire le nombre de lignes de code écrites) ne constitue pas un indicateur fiable de la progression : un développeur peut très bien réutiliser des briques de base (sous-systèmes, classes et compo sants) déjà conçues et l'écriture de quelques lignes de codes suffit parfois à amener des progrès sensibles.

12.8.4 Évolution

• de modifier ou d'étoffer le modèle des cas d'utilisation ; • de modifier ou d'étoffer l'architecture ; • de modifier ou d'étoffer les sous-systèmes développés jusqu'à présent ; • de rechercher d'autres risques ; • d'apporter à l'équipe certaines compétences ou connaissances. Ou alors, i l faudra simplement accorder des délais supplémentaires pour mener à bien le plan existant. Si tel est le cas, le projet pourra rallonger le temps consacré à la première itération. Mais il faudra alors fixer une date d'achèvement ferme.

12.8.2 Les critères

Il faut, toutefois, penser à considérer les critères d'évaluation eux-mêmes. I l est possible que l'équipe ait établi ces critères à un moment où elle ne disposait pas de toutes les informations pertinentes. Le déroulement de l'itération peut avoir fait émerger de nouveaux besoins ou fait apparaître l'inutilité des besoins retenus au départ. Les évaluateurs auront peut-être à modifier les critères, sans se borner à vérifier s'ils ont été atteints.

12.8.3 L'itération

de l'ensemble

des

modèles

Une des caractéristiques essentielles du développement itératif par phases est révolution d. l'ensemble des modèles. Cette évolution contraste avec le modèle en cascade, dsUM lequel on imagine que l'expression des besoins est d'abord menée à bien, puis l'analysi l I lin I dl suite. Dans le développement itératif, les modèles évoluent ensemble, de . on. eil les diverses phases. Dans les premières itérations, certains m o d è l e . lOfll M .o. pu rapport aux autres. Par exemple, le modèle des cas d'utilisation est plie, nviinei qui h modèle d'implémentation. On n'assiste plus à l'évolution d'un modèle imlcpendiiu dit modèle suivant, mais on envisage l'évolution d'un état du sysieme dans ,i uibli \ i un état plus avancé du système dans son ensemble, comme l'illustre la ligure i2,5, < ihaqui itération, et peut-être chaque construction au sein d'une itération, représente une avanoél ' l ' l'état de l'ensemble du système. Cette évolution se reflète dans le moiivemenl p i o g i e s s d vers la finalisation de l'ensemble des modèles. 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 débuts du projet et envisager les mérites propres de la phase de création.

suivante

Un jalon majeur (annexe C) marque l'achèvement d'une phase, le stade auquel non seulement l'équipe du projet, mais aussi les intervenants, et en particulier les responsables financiers et les représentants des utilisateurs, s'accordent à considérer que le projet a atteint les critères 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'itération ou la phase, auxquels s'ajoutent certaines des personnes affectées à l'itération suivante) effectue les tâches suivantes : • i l prend note du fait que le travail est prêt pour l'itération suivante ; • si des améliorations sont nécessaires, i l détermine les itérations suivantes auxquelles elles doivent être affectées ; • i l planifie en détail l'itération suivante ; • i l actualise le plan, avec moins de détails, pour les itérations venant après l'itération suivante ; • i l met à jour la liste des risques et le plan du projet ; • i l compare le coût et les délais réels de l'itération avec ceux qui avaient été prévus.

13 La phase de création lance le projet Le propos général de la phase de création est de lancer le projet. Avant la création, le projet n'est peut-être qu'une vague idée en l'air. Cette idée peut être stimulante si elle est Iota lement inédite dans un domaine innovant. Elle peut être relativement soporifique s'il s'agit de la énième version d'un produit existant. La création peut se borner à la rédaction d'une déclaration d'intention, à l'esquisse d'une architecture à l'aide de divers diagrammes et à la réalisation d'une étude de rentabilité raisonnable. Elle peut être aussi complexe qu'un véritable projet de recherche. En résumé, la phase de création ne peut être réduite à un unique stéréotype. A l'issue de la phase de création, même si le système est nouveau, non seulement vous avez délimité le problème à résoudre, mais vous êtes allé assez loin pour acquérir la certitude qu'il est à la fois possible et souhaitable de développer le système. Bien sûr, cette certitude ne vous appartient pas en propre. Le travail effectué pendant la phase de création offre au client (ou à ses représentants), à l'organisation de développement et aux autres intervenants l'assurance que l'architecte et les développeurs seront en mesure de réduire les risques critiques, de formuler une architecture candidate et d'élaborer l'étude de rentabilité initiale.

13.1 La phase de création en bref L'objectif de la phase de création est de pousser l'étude de rentabilité jusqu'au stade propre a justifier le lancement du projet. I l faut d'abord, pour procéder à celle élude, délimita la portée du système envisagé et cerner le champ d'investigation du projet de développement Cette portée est indispensable pour saisir l'étendue même 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 coûts, des délais et des retours sut investis .enient tous les ingrédients de l'étude de rentabilité.


III

On tente alors d'ébaucher un début d'architecture, juste l e qu II ftUl p Si quéril la titude qu'il existe une architecture - nommée architecture candidate capable de prcndi charge la portée du système. On s'efforce également d'anticiper un éventuel fiasco. Nombre de projets difficiles mu trébuché parce qu'ils étaient confrontés à des risques critiques, parfois aussi tardivement qu'au moment de l'intégration et des tests du système, qu'il était impossible de réduire dans le respect des budgets et des délais encore disponibles. Qu'on le veuille ou non, les incertitudes, ou les risques, existent. La seule alternative consiste à les réduire très tôt, à limiter la portée du système ou à accroître les délais et les ressources (c'est-à-dire le budget) afin d'éviter les risques irréductibles. Par ailleurs, on s'évertue à réaliser l'étude de rentabilité initiale afin de considérer le système proposé d'un point de vue économique, c'est-à-dire d'effectuer les premières estimations de budget, de calendrier et de retour sur investissement. On se demande alors : • si les gains générés par l'utilisation ou la vente du produit logiciel feront plus que compenser le coût de son développement ; • 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 développement, c'est-à-dire d'un processus et d'outils. Bien entendu, l'environnement de développement d'une organisation logicielle est l'aboutissement d'années d'efforts, dont l'essentiel intervient avant le début d'un projet donné. On adapte, toutefois, le Processus unifié au type de système en cours de développement et le niveau de compétence de l'organisation de développement chargée de réaliser le travail. C'est là le genre de questions que doit traiter la phase de création.

13.2 Premiers stades de la phase de création Commencez à planifier ; développez la vision du système et commencez à édifier vos critères d'évaluation.

13.2.1 Avant le début

de la phase de

création

Avant même le début de la phase de création, vous saviez plus ou moins ce que vous alliez faire. Quelqu'un - un client, votre service du marketing, ou même un membre de votre propre service de développement - a émis une idée et l'a justifiée au point de la mettre en chantier. La teneur du travail effectué avant la phase de création varie considérablement : elle couvre un certain champ, qui peut s'articuler autour des trois pôles spécifiques évoqués ci-dessous. • Les organisations logicielles réalisant des produits destinés à la vente dans le commerce. Le volume d'informations de départ peut être assez substantiel. Il est plus que probable que le marketing et la direction auront consacré au produit à venir des études extensives, complétées par des études techniques menées par des membres de l'équipe de

La phase de c r é a t i o n lance le projet CHAPITRE

13

développement. En d'autres termes, on aura déjà procédé à une partie de la phase de création. • Les organisations logicielles réalisant des systèmes pour d'autres services d'une même entreprise, soit le type même de l'organisation de développement en interne. ( )n rencontre, grosso modo, deux types de situations. Dans le premier cas, un semer m SOI le besoin d'un système logiciel et demande au service de développement de le p u n i Le service demandeur fournit alors une description du système souhaite, sans avou forcément une idée très claire des ramifications du logiciel, lin d'autres le l'organisation logicielle dispose de peu d'informations au moment ou dobuii la plia création. Dans le second cas, la direction générale estime néccssaiie la mitt SU i Il d Ull système à l'échelle de l'entreprise et a affecté un groupe d'ini'eiuei ie inetiei a I l ,l< possibilités que doit offrir ce système. La phase de création peui alors ( une bonne compréhension des besoins et des exigences. • Les organisations logicielles réalisant des systèmes pour des clients I appel il nlîn initial regorge souvent de détails 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 très parcellaire de ses besoins. Si le produit représente une évolution d'une version antérieure, l'essentiel du travail de pli nification de la première itération du nouveau projet aura été effectue lors de la dernière u< ration du cycle précédent. Dans le cas d'un projet globalement nouveau, toutefois, les pères du projet souhaiteront voir leur concept mené plus loin. Ils auront peut-être déjà procédé à une estimation approximative du travail nécessaire, obtenu des fonds couvrant la phase de création et fixé un calendrier.

13.2.2 Planifier la phase de

création

Le début d'un projet nous place toujours face à un dilemme. Des personnes bien intentionnées vous conseillent de planifier, mais vous n'avez guère 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 réunies avant le début 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 extrêmement limités de la phase de création. En d'autres termes, limitez cette recherche à ce qu'il vous faut pour réalisa les uh|ci n i . . t. de cette phase, résumés dans la section 13.1. Puis faites une tentative de plan DOUI l larilli ' les besoins et les exigences portant sur ces objectifs de départ et les détaille! dan d'utilisation correspondants. Prévoyez de créer une architecture candidate, qui dl Wl i borner à démontrer la faisabilité du projet et ne proposer par conséquent qui qui Iqu.

a


III


esquisses des vues architecturales. Dès que vous le pourrez, essaye/ il'eiiihlu le Lui n 'ji vous faudra une ou, dans certains cas, deux itérations. u

Gardez à l'esprit que ce plan initial est provisoire. Il se modifiera progrcssiveiiicni pi nu lunir compte des informations accumulées. Essayez, bien entendu, de termina la phase J création dans les délais et les budgets alloués au départ par la direction (ou le i lient) Comme les responsables ont dû, forcément, fixer ces chiffres à partir de connaissance! limitées, pensez à les informer (ainsi que tout autre intervenant) de la progression du travail au cours de cette phase. I l pourra se révéler nécessaire de revoir ces chiffres. e

13.2.3 Élargir

la vision du

système

Il est possible, au début du cycle de vie, que l'équipe n'ait à sa disposition guère plus qu'une déclaration d'intention d'une page. Celle-ci contient une liste de caractéristiques (voir la section 6.3), quelques informations sur les performances, une connaissance très pauvre des risques que pourront rencontrer les développeurs, éventuellement une vague référence à une possible architecture (la simple mention « client-serveur » ou quelque chose du même ordre) et des chiffres ronds et parfaitement aléatoires en guise de budget et de délais (par exemple, 10 millions d'euros sur deux ans). Cette équipe de départ peut se composer du responsable du projet, de l'architecte, d'un ou deux développeurs expérimentés, d'un ingénieur de tests (en particulier si les tests jouent un rôle important), et certainement de représentants du client ou des utilisateurs. La première étape consiste à étoffer la déclaration d'intention afin qu'elle guide la phase de création. Voilà qui est facile à dire, mais un peu plus difficile à mettre en œuvre. C'est pourquoi il faut absolument que soient impliqués des représentants de tous les intérêts en jeu. C'est aussi pourquoi i l faut qu'il s'agisse de gens d'expérience. C'est encore pourquoi i l faut qu'ils prennent en compte différents points de vue et ne se rallient pas à un timide compromis. C'est pourquoi, enfin, il faut un peu de temps pour réfléchir sérieusement à cette tâche extrêmement délicate. N'oubliez pas qu'on ne recherche pas un consensus, mais la meilleure réponse. Les réponses adéquates proviendront d'un responsable, de la personne chargée de gérer les fonds accordés au projet, mais aussi d'un responsable conseillé par des spécialistes parfaitement informés.

13

cas, les critères d'évaluation resteront plutôt généraux. Ils se préciseront au fil de l'itération et de l'accumulation progressive des informations. Nous proposons, toutefois, quelques ci I tères d'évaluation généraux pour les quatre objectifs de la phase de création. Délimiter la portée du système Nul doute que la vision initiale donne quelque idée de la portée du système, mais elle n. i , définit pas précisément. Dans la phase de création, le projet trace une ligne exacte deI i.un ce qui doit se trouver à l'intérieur du système envisagé et ce qui doit rester;) rcxlciiciu l'iu sont identifiés les acteurs externes, qui peuvent être d'autres système! OU des i im avec lesquels le système va dialoguer. La nature de cette interaction Bit déflllil I élevé. Les questions abordées ici sont les suivantes : • Sait-on avec clarté ce qui doit figurer à l'intérieur du système 7 • Les acteurs sont-ils tous identifiés ? • La nature générale des interfaces (interfaces utilisateur cl protocoles de . i est-elle définie ?

i

u

• Les éléments situés dans la portée du système peuvent-ils constitua letU MUllUfl système capable de fonctionner ? Lever les ambiguïtés sur les besoins et les exigences nécessaires dans cette phase Les « besoins et exigences », au début de la phase de création, peuvent aller d'une vision générale sommaire à une description textuelle de plusieurs pages. Ces premières exigences sont toutefois susceptibles de receler quelques ambiguïtés. L'évaluation doit prendre en compte les questions suivantes : • Les quelques exigences (fonctionnelles et non fonctionnelles) des cas d'utilisation nécessaires pour atteindre les objectifs de cette phase ont-elles été identifiées et décrites en détail ? • Les autres exigences ont-elles été identifiées et décrites en détail dans les exigences supplémentaires (voir la section 6.7) ? Établir une architecture

candidate

• Cette architecture satisfait-elle les besoins des utilisateurs ?

De même, dans le cas de systèmes véritablement originaux, la phase de création peut être longue et coûteuse.

L'expérience nous enseigne qu'on peut se tourner assez rapidement vers les fonctions nouvelles ou réclamant des performances sans précédent. I l faut alors sélectionner, parmi ces fonctions, celles qui sont susceptibles de compromettre le développement de tout le système. Pour ces quelques fonctions, on développe au moins une architecture capable île fonctionna Les critères d'évaluation sont les suivants :

Dans le cas d'un produit similaire à un produit antérieur, i l peut s'agir simplement d'établir cette proximité, ce qui ne prendra que quelques jours. Certaines phases de création ne durent qu'une journée (dans le cas, par exemple, du deuxième cycle d'un produit simple existant), alors que celle d'un projet totalement nouveau pourra prendre plusieurs mois.

13.2.4 Définir

les critères

d'évaluation

Une fois que le responsable du projet dispose d'un volume suffisant d'informations pour présenter un plan à granularité fine de la première itération, i l en profite pour fixer les critères d'évaluation permettant d'établir que l'itération a atteint ses objectifs. Ce plan à granularité fine peut en réalité être assez grossier en raison de la rareté des informations. Si c'est le

• Est-elle susceptible de fonctionner ? (Considérez ce critère par rapport au degic d'accomplissement auquel est parvenue l'architecture candidate. Aucun prototype n'ayant été préparé, la description de l'architecture candidate sera jugée sur ses promesses di fonctionnement.) Pour répondre à cette question, il faut examiner plusieurs points. L'architecture p o u i i a i . II. utiliser de façon adaptée la technologie (bases de données, réseau, etc.) sui l a q u e l l e i M

Un d é v e l o p p e m e n t itératif et i n c r é m e n t a l PARTIE III

devra reposer? Pourra-t-elle fonctionner correctement 7 Tonna l clic exploite! lei tes sources disponibles ? Sera-t-elle fiable, tolérante aux pannes et robuste ' Saura i elle réagu aux changements? Évoluera-t-elle sans heurts lorsque des besoins et .les exigences s'ajouteront ? Réduire les risques critiques Les risques critiques sont ceux qui, s'ils n'étaient pas réduits, compromettraient la réussite du projet. L'évaluation doit examiner les points suivants : • Les risques critiques ont-ils tous été identifiés ? • Les risques identifiés ont-ils été réduits ou est-il prévu de le faire ? Dire qu'un risque critique a été réduit ne signifie pas nécessairement qu'il a été entièrement éliminé dans cette phase. Cela peut signifier que le client préfère modifier les exigences concernées, plutôt 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 détails pourront être précisés 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 réduire au maximum la gravité si jamais i l se concrétisait. Enfin, i l peut également être question d'élaborer un plan visant à circonscrire le risque pour répondre à sa matérialisation éventuelle. Aucune de ces questions ne saurait être tranchée par un jugement simple et mécanique, au moins dans les situations inhabituelles. Le principal objectif de la phase de création est de parvenir à un stade du processus de développement qui permettent au chef de projet, à la hiérarchie 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 création. 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.

13.3 Enchaînement d'activités de l'itération typique de création

13.3.11ntroduction

L a phase de c r é a t i o n lance le projet CHAPITRE

aux cinq enchaînements

d'activités

13

principaux

Le principal objectif de la phase de création 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 définir la portée du système envisagé, esquisser une architecture, identifll l les risques susceptibles de compromettre la réussite du projet et tracer les grandei ligm d'un plan de réduction de ces risques. Si l'on propose un nouveau type de système. , l t peut-être en présenter la nature et l'utilisation en construisant un prototype, pins | »\ un prototype (généralement jetable) de mise à l'épreuve du concept. Des prototypi pi u m également être utilisés sélectivement pour la gestion et la réduction des riiqui i ||i d'abord les domaines à haut risque, puis on prototype les parties essentielles du avec des fonctions délicates ou des problèmes connus de performant 61 OU de nablllli Un I dans un système de négoce financier tolérant aux pannes, il pourra être Utile di i ni i très tôt un mécanisme de récupération après panne. L'essentiel de la phase de création s'accomplit dans le premiei enchaînai I |t dvltl celui des besoins, comme l'illustre la figure 13.1, tandis qu'une partie du iiav.nl .vu dans les enchaînements d'activités d'analyse et de conception. Les cmiiameni, ntl d II 11 vitésfinalsd'implémentation et de tests, en revanche, ne représentent qu'une pan m a t i n a l e Il s'agit, dans cette phase, de faire la démonstration 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. L'analyste système identifie les acteurs et les cas d'utilisation définissant la portée du système, auxquels l'architecte attribue un ordre de priorité en sélectionnant ceux qui sont pertinents pour l'architecture candidate. L'architecte rédige ensuite une description initiale de l'architecture candidate. Les spécificateurs de cas d'utilisation détaillent certains chemins des cas d'utilisation identifiés. Les cas d'utilisation décrits de façon précise et détaillée sont ceux qui présentent de l'intérêt pour la compréhension de la portée du système, de l'architecture candidate et des risques critiques, c'est-à-dire ceux qui permettent d'élaborer l'étude de rentabilité initiale. Ce travail débouche sur la création du premier modèle des cas d'utilisation dans le cas d'un développement « tout neuf » (green-field), ou d'une nouvelle version de ce même modèle si l'on reprend le développement d'un système existant. On peut aussi dresser un classement des cas d'utilisation, comme l'indique le chapitre 12. L'enchaînement d'activités d'analyse voit la création d'un premier modèle d'analyse pour la majeure partie des cas d'utilisation ou des scénarios de cas d'utilisation traités dans la phase de création. Ce modèle d'analyse est fondamental pour une compréhension limpide des oai d'utilisation. I l permet également d'appréhender ce qui sous-tend la première ébam lie de l'architecture.

La phase de création voit la réalisation de trois ensembles d'activités. L'un est la planification des itérations, que décrivent les sections 12.4 à 12.7 et la section 13.2.3 ; le deuxième regroupe les cinq enchaînements d'activités principaux et est abordé brièvement dans la section 13.3.1, puis largement dans la section 13.4 ; enfin, le troisième est la sélection de l'environnement de développement adapté au projet, auquel est consacrée la section 13.3.2. Par ailleurs, la section 13.5 décrit l'étude de rentabilité initiale et la section 13.6 les évaluations de cette phase.

366


III

Figure 13.1

Ressources

Le travail effectué pendant une itération de la phase de création passe par les cinq enchaînements d'activités principaux. Les tailles relatives des rectangles se contentent d'indiquer les enchaînements d'activités qui mobilisent le plus d'attention et ceux qui en nécessitent le moins.

Enchaînements d'activités principaux ^

Besoins

^

Analyse

^

Conception ^

lmplémenlalio^~

de

développement


13

367

projet, soit à l'échelle de l'entreprise, pour prendre en charge les besoins inhabituels du projet. Les services renvoient à l'administration du système, à la sauvegarde des données cl aux télécommunications. La phase de création marque le début de l'activité visant à installer renvironnemeni tic développement de l'organisation logicielle au cœur 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 développement tout en fournissant I. ii.iv.nl ,, dans cette phase.

13.3.3 Identifier les risques

Se concentrent sur la définition de la portée du s y s t è m e pour la réalisation d'une é t u d e de rentabilité Enchaînements d'activités des itérations de création

S'il s'agit d'un système nouveau ou sans précédent, l'équipe de la phase de création peut élaborer un prototype d'exploration destiné à démontrer les idées maîtresses en assemblant rapidement des éléments. Un tel prototype vise à exposer les concepts impliqués, et non à se transformer en implémentation finale ; en d'autres termes, i l sera très 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 ingénieurs de composants n'auront aucun problème à implémenter l'algorithme en question dans des composants capables des performances exigées. L'itération peut s'achever par la description de l'architecture candidate s'accompagnant de l'ébauche des vues des modèles, dès que le chef de projet détermine que l'architecture candidate paraît capable de fonctionner et que les risques ne sont pas critiques ou sont réductibles. Ce sera le cas si l'architecture a été bien établie grâce à l'expérience antérieure du projet et aux intervenants.

13.3.2 Adapter le projet à l'environnement

L'environnement de développement se compose d'un processus, des outils mettant en œuvre ce processus et des services destinés aux projets : les services de configuration et d'amélioration du processus, de sélection, d'acquisition et de fabrication des outils, de formation et de monitorat. Les outils en question sont ceux qui prennent en charge les enchaînements d'activités principaux de besoins, d'analyse, de conception, d'implémentation et de tests, ainsi que les outils d'administration de gestion des projets (planification, estimation, suivi), de gestion de configuration et des changements, de génération de documents et de prise en charge en ligne du processus. Outre ces outils, dont beaucoup ont une vocation généraliste et sont fournis par des éditeurs, i l est possible de développer des outils spécialisés, soit dans le cadre du

critiques

Nous avons consacré les sections 12.5 et 12.6 à l'identification cl a la rédiii lion doi qm affectant le développement. Dans la phase de création, ce son i les risques ci un |u. i un souhaite identifier et réduire ou dont on cherche éventuellement a planifie] la réduction l a section 13.2.4 a montré ce que l'on entend par réduire un risque critique D ait ibaolumenl primordial d'identifier les risques de cette ampleur au cours de la pltase de . realion Ni l'on détecte un risque de ce type mais qu'on n'entrevoit aucun moyen tic le réduit, m de plan susceptible de le circonscrire, i l faut envisager d'abandonner le projet.

13.4 Exécuter les enchaînements d'activités principaux : des besoins aux tests Cette partie du chapitre décrit plus en détail les activités de cette phase dans le cadre d'un projet « tout neuf », c'est-à-dire d'un produit entièrement nouveau, sans aucun antécédent. L'extension d'un produit existant est, évidemment, beaucoup plus simple. Chaque itération est une mini-cascade déclinant les cinq enchaînements d'activités principaux, des besoins aux tests. La deuxième partie de l'ouvrage a consacré un chapitre à chacun de ces enchaînements d'activités, et même deux chapitres au premier d'entre eux. Nous allons à nouveau, dans cette section, dédier une sous-section à chacun de ces enchaînements, mais en les considérant cette fois comme intégrés à la phase de création. Pour bien délimiter notre champ d'intervention, nous avons tracé à la main deux « patatoïdes » sur la figure 13.2. L'une regroupe les activités visant à identifier la portée du système, l'autre celles permettant la compréhension de l'architecture candidate. Les noms de travailleurs apparaissant dans cette figure désignent le rôle qu'assume chaque collaborateur au cours du développement. Dans cette phase, néanmoins, l'équipe . a en. ...e réduite et chacun peut incarner plusieurs travailleurs.

I


O £7 Analyste système

III

/ÉB * Identifier•les acteurs et les cas d'utilisation

\

o

O

Spécificatei de cas d'utilisatloi

B 1er


t

un cas d'utilisation

Planifier les tests

Tests

BesQffns , D é f i n i r la p o r t é e du s y s t è m e W

o

•

Implémentation

w J^c /

O

Concepteur d'Interface utilisateur

Testeur système

E s q u i s s e r l'architecture candidate

/

/ Impiémenter une classe

\

» tracées

du système

à la main regroupent les principales activités

et esquisse de l'architecture


13

grande distribution, les nouvelles caractéristiques proviennent de la demande du marché, auxquelles s'ajoutent les possibilités de fonctions suggérées par les travailleurs de l'organisation de développement elle-même. Certaines caractéristiques 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 earaciéi i>. tiques, décrite au chapitre 6. Comprendre le contexte du système Si le client dispose d'un modèle du métier (ou d'un modèle du domaine), celui Ci r m I In exploité dans la phase de création. En l'absence d'un tel modèle, en revanche e ||i li client à en créer un, même si cela demande du temps et des ressources dépassant l u i • m ceux dont dispose un simple projet. Soyez ferme. Il faut identifier les cas d'utilisation pour les systèmes métier 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 entités de travail et les entités métier). Vous devez, globalemt ni V l)ll réalisé 50 à 70 % du modèle du métier avant de vous lancer dans la m o d è l e . . u t Util! • des cas d'utilisation pertinents. Il est impossible de développer un logiciel sans i i aitu I. processus qu'il est censé mettre en œuvre. Formuler les besoins fonctionnels Les besoins fonctionnels sont représentés sous forme de cas d'utilisation, comme le décrivent le chapitre 7 et la section 13.4.1.1.

, ^1

Implémenter sous-système

uFpImoIdes portée

13.4.1 Formuler les

de la phase de création

: définition

de la

candidate.

besoins

Dans la phase de création, l'attention se porte essentiellement sur le premier enchaînement d'activités principal, celui des besoins, qui consiste à identifier et à décrire en detafi les cas d'utilisation intéressants pour cette phase. Cet enchaînement d'activités aborde les thèmes suivants, décrits dans le chapitre 6 : 1.

I

Recensement des besoins et des exigences candidats à la liste de caractéristiques du système.

I

Formulation des exigences non fonctionnelles liées.

4.

Compréhension du contexte du système. Formulation des besoins fonctionnels pertinents sous forme de cas d'utilisation.

2. 3.

Recenser les besoins et exigences candidats Les caractéristiques exigées trouvent souvent leur origine dans l'expérience qu'ont les clients ou les utilisateurs de systèmes antérieurs ou de même type. Dans le cas de produits

Formuler les exigences non fonctionnelles Les exigences non fonctionnelles spécifiques à un cas d'utilisation sont associées au cas d'utilisation qu'elles concernent (voir les sections 6.3 et 7.2.3.2). Celles qui sont spécifiques à un objet du modèle du métier ou du modèle du domaine renvoient à un terme du glossaire accompagnant le modèle des cas d'utilisation (section 6.3) ; celles, beaucoup moins nombreuses, qui sont plus générales, figurent dans la liste des exigences supplémentaires (section 6.7). Parmi ces exigences plus générales, certaines sont essentielles à la sélection de la plate-forme, du logiciel système et de l'architecture des middleware, et joueront un rôle primordial dans cette phase (voir la section 4.3, « Cas d'utilisation et architecture »).

13.4.1.1 Formuler les besoins sous forme de cas d'utilisation Revenons maintenant à la figure 13.2 pour nous pencher sur les activités qui y sont évoquées. Dans cette section, nous allons expliquer la manière de formuler les besoins sous forme de cas d'utilisation à travers les activités indiquées par la figure 13.2. Identifier les acteurs et les cas d'utilisation (voir la section 7.4.1) L'exhaustivité des besoins, ou la finalisation du modèle des cas d'utilisation, dépasse l< moyens dont dispose la phase de création. Les travailleurs impliqués dans cette phi t doivent, tout d'abord, dégager la fraction de cas d'utilisation nécessaire a son ai i ouipli sèment, puis les décrire en détail, comme l'indique le chapitre 7. L'identification di d'utilisation est abordée dans la section 12.6.

rj


III

De nouveau, le problème de la phase de création csl de si' limita essentiellement ., détail 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 présentent pas d'intérêt pour la portée du système et l'architecture candidate, qui n'impliquent aucun i isque critique ou qui ont peu d'effet sur l'étude de rentabilité initiale. Pour sélectionner les cas d'utilisation à exploiter au cours de la phase de création, le chef de projet travaille en collaboration avec l'analyste système et l'architecte. La tâche de l'analyste système consiste à rendre possible la définition de la portée du système, tandis que l'architecte devra s'intéresser à chaque cas d'utilisation afin d'éliminer ceux qui n'ont pas à être envisagés plus précisément. L'architecte doit également se préoccuper des risques critiques et significatifs et identifier les cas d'utilisation nécessaires à la planification du travail d'architecture, qui fait l'objet de la phase suivante. Les efforts requis pourront être très limités dans certaines parties du système dont l'architecte aura étudié les cas d'utilisation dans des systèmes antérieurs et saura, par conséquent, qu'ils ne présentent pas d'intérêt 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 considération à ce stade. Définir un ordre de priorité pour les cas d'utilisation (voir la section 7.4.2) Puis l'architecte considère le modèle des cas d'utilisation et fournit des entrées au chef de projet chargé de créer le plan du projet ou le plan des itérations. Ce travail s'effectue parallèlement à celui des enchaînements d'activités principaux de chaque phase : on peut, en effet, planifier les itérations à venir tout en détaillant les cas d'utilisation identifiés. Le plan des itérations est le résultat final reflétant l'ordre de priorité des cas d'utilisation associés aux objectifs de cette phase. Décrire en détail un cas d'utilisation (voir la section 7.4.3) Tout en acceptant la réalité de cette limitation du travail, nous réaffirmons néanmoins l'importance qui doit être accordée à la finalisation de toutes les branches des cas d'utilisation concernés dans la phase de création, c'est-à-dire des cas d'utilisation nécessaires à la définition de la portée du système, ainsi qu'à la planification de la réduction des risques et de la création de l'architecture de référence. On croit trop souvent comprendre les besoins et les exigences alors que l'on est en train de passer à côté de certains, absolument essentiels. De même, on a fréquemment tendance à penser que les avantages qu'apporte la description détaillée des cas d'utilisation n'en valent pas le prix, ce qui est une profonde erreur de jugement.

IG

L'objectif est de savoir où l'on va. Cela n'implique toutefois pas de mener à leur terme un nombre considérable de cas d'utilisation. Comme on ne crée généralement pas de prototype architectural dans cette phase, i l n'est pas nécessaire de procéder à l'implémentation et aux tests. Si, néanmoins, vous souhaitez faire la démonstration des principaux concepts en créant 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 expliquée par la suite. Il pourra être nécessaire de décrire en détail environ 10 % de la masse des cas d'utilisation dans le modèle des cas d'utilisation.


13

371

Cela signifie tout simplement que, si l'on examine un grand nombre de cas d'utilisation, seuls les plus pertinents seront décrits en détail. Par exemple, si l'on sélectionne 50 % du total final des cas d'utilisation en tant que cas potentiellement pertinents et que l'on s'aperçoit que seulement 20 %, en moyenne, des scénarios de chacun de ces cas d'utile.. doivent être détaillés, on n'aura abordé en profondeur que quelque 10 % de toute la m . des cas d'utilisation. L'idée est d'essayer de maintenir le coût et les délais de la phase di création à un faible niveau. La valeur exacte de ces pourcentages sur des projetl Indh Idlit I dépend de leur difficulté ou de leur caractère atypique. Tous les besoins fonctionnels devant être pris en considération dans cette phase s sentes sous forme de cas d'utilisation, comme l'explique le chapitre /

pu

Prototyper l'interface utilisateur (voir la section 7.4.4) - Ne présente aucun intérêt dans cette phase. Structurer le modèle des cas d'utilisation (voir la section 7.4.5) - Ne mobilise pas l'attention à ce stade.

13.4.2 Analyse Les objectifs de l'enchaînement d'activités d'analyse sont, d'une manière générale, d'ana lyser les besoins, de les préciser et de les structurer au sein d'un modèle objet faisant office de première ébauche du modèle de conception. Dans cette phase, cet enchaînement se traduit par la création d'un modèle d'analyse initial ; ce dernier permet de définir précisément les cas d'utilisation et sert de guide à l'esquisse de l'architecture candidate, qui sera étoffée dans la phase d'élaboration. Cela signifie, bien sûr, qu'une très faible partie du modèle d'analyse (environ 5 %) sera achevée au cours de la phase de création. On pourrait caractériser le modèle d'analyse dans la phase de création comme une sorte de brouillon : il n'est qu'une première étape vers la vue architecturale de ce modèle. Procéder à l'analyse architecturale (voir la section 8.6.1) L'objet de la phase de création consiste à sélectionner les cas d'utilisation ou les scénarios de cas d'utilisation qu'il faudra étudier avec attention dans le cadre de la création, en veillant principalement à les comprendre et à les préciser. À partir de cet ensemble initial de cas d'utilisation et de scénarios, l'architecte bâtit une première version simple du modèle d'analyse pour les parties concernées du système. Inutile de viser à l'exhaustivité ou à la pet fection. I l n'est pas forcément indispensable de continuer à enrichir ce modèle dans la phase suivante : on peut très 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 réalité les cas d uiili sation partagent les ressources, telles que les bases de données ou les processeurs, au sein du système. Or, le modèle d'analyse dévoile ces ressources partagées. Il faut dont palfol pousser l'analyse suffisamment loin pour résoudre ces conflits.

I


13.4.3

III


13

Concevoir un cas d'utilisation (voir la section 9.4.2)

Concevoir une classe et concevoir un sous-système Là encore, si l'on procède à l'une ou l'autre de ces activités au cours de cette phase, c'est île façon tout à fait minime.

Analyser une classe et analyser un paquetage Si l'on procède à l'une ou l'autre de ces activités au cours de cette phase, c'esl de façon lout à fait minime.

Dans la phase de création, le travail de conception des cas d'utilisation reste tout à fait mai ginal.

On peut, dans l'enchaînement d'activités de celle Itération, 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 détaillera ensuite la moitié, soit environ 5 % de la masse totale,

Conception

3.4.4

Implémentation

D'un côté, certains prétendent qu'on ne peut être sûr 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 réellement. D'un autre côté, la volonté de maintenu les équipes cl li di in un niveau minimal commande d'interrompre les enchaînements d'activités de la phase d. création dès qu'existe la description d'une architecture qui semble marcher. Il ivvicui au chef de projet de déterminer jusqu'où développer l'architecture candidate.

S'il faut développer un prototype de démonstration, on emploiera des modules préfabriqués, des langages de quatrième génération ou toute technique de développement rapide permettant de montrer la validité du concept envisagé. La démonstration d'interfaces utilisateur et d'algorithmes inhabituels présente l'intérêt de convaincre tous les intervenants que le projet vaut la peine d'être poursuivi. Ce prototype est présenté à des utilisateurs représentatifs en vue de s'assurer qu'il satisfait à leurs besoins et d'effectuer les changements nécessaires à la lueur de leurs remarques.

La portée de cet enchaînement d'activités dépend des décisions prises précédemment r » Il chef de projet. Doit-il mettre un terme à la phase de création une lois qu'il dilj Ultl description de l'architecture candidate ?

L'objectif principal de l'enchaînement d'activités de conception dans cette phase consiste à esquisser un modèle de conception afin d'intégrer l'architecture candidate à la description de l'architecture préliminaire.

1

Procéder à la conception architecturale (voir la section 9.4.1) Le propos de l'enchaînement d'activités de conception est de mettre au point une première esquisse (ou esquisse initiale) du modèle de conception, première étape vers la vue architecturale du modèle de conception réalisant les cas d'utilisation (identifiés précédemment dans l'enchaînement d'activités des besoins) sous forme de collaborations entre sous-systèmes/ classes. Nous tenons à identifier les interfaces (et tout au plus à en définir quelques opérations) entre sous-systèmes/classes, même s'il s'agit d'une simple esquisse de la conception. Ces interfaces ont en effet de l'importance, car elles constituent le cœur de l'architecture. I l faut en outre définir les mécanismes génériques de conception nécessaires en tant que couches sous-jacentes des sous-systèmes qui réaliseront les cas d'utilisation identifiés. On sélectionne enfin le logiciel système et les infrastructures préfabriquées (frameworks) à utiliser, qui forment la couche de middleware (voir la section 9.5.1). Ce modèle de conception initial doit être créé même s'il se borne à une simple esquisse, puisque nous nous arrêtons, dans cette phase, à la description de l'architecture candidate. Le modèle de conception ne réalise pas seulement les besoins fonctionnels représentés par les cas d'utilisation désignés, mais aussi les exigences non fonctionnelles, telles que les performances, susceptibles d'entraîner des risques. Si le système proposé doit être déployé sur des nœuds, l'architecte concevra une version à petite échelle du modèle de déploiement, limité, par exemple, aux nœuds soumis à des impératifs de performances ou aux connexions entre nœuds. A ce stade, le chef de projet pourra demander à un ingénieur de cas d'utilisation de modéliser certaines parties de deux nœuds ainsi que l'interaction entre ces deux nœuds où se situe la difficulté.

Dans la plupart des cas, le chef de projet décidera de s'arrêter à la description de l'architecture candidate : i l ne sera donc pas nécessaire de mettre en œuvre l'enchaînement d'activités d'implémentation. La mise au point d'un prototype de démonstration (jetable) pourra cependant se révéler utile. Le projet devra alors appliquer un enchaînement d'activités d'implémentation, même si celui-ci reste limité.

13.4.5 Tests En parallèle avec les activités d'analyse, de conception et d'implémentation, comme le montre la figure 13.2, les ingénieurs de tests se familiarisent avec la nature générale du système envisagé. Ils détermine les tests qui seront nécessaires et mettent au point quelques tests provisoires. Les tests demeurent toutefois extrêmement limités dans la phase de création, comme l'indiquent les figures 11.2 et 13.1, la vocation du prototype de démonstration exploratoire étant avant tout illustrative. Le chef de projet peut néanmoins estimer utile de procéder à 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 création, que l'on dispose d'une an In tecture candidate et que les risques critiques peuvent être surmontés, il est temps île H d la vision du projet en termes économiques par l'étude des besoins en ressources, d Invt ii sements nécessaires, des projections de revenus et de l'acceptation (en interne o u i pal l' marché. Cette étude de rentabilité présente deux facettes : l'une est l'offre qui scia soi SU client, l'autre s'intéresse aux gains économiques que doit générer l'utilisation du produil


III

13.5.1 Tracer les grandes lignes de l'offre Les formules d'estimation qui sous-tendent l'offre commerciale dépendenl généralement i la « taille » du produit final. À l'issue de la phase de création, 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 réelle d'un pourcentage substantiel, de 50% exemple. À la fin du projet, cette première estimation risque donc de diverger du coût ré dans les mêmes proportions. Prenez, par exemple, les cas d'utilisation comme mesure de la taille dans un objectif d'estimation. Le nombre d'heures-homme nécessaire à la conception, à l'implémentation et aux i tests d'un cas d'utilisation peut varier d'une centaine à quelques milliers. Plusieurs facteu peuvent expliquer un tel écart : s u u

h'

• le style : si les développeurs concentrent un plus grand nombre de caractéristiques au sein d'un même cas d'utilisation, celui-ci sera plus puissant qu'un cas d'utilisation moyen mais risquera d'être plus coûteux en heures-homme ; • la complexité du système proposé : plus le système sera complexe, plus i l risquera de coûter cher (pour une taille donnée). Voyez si vous pouvez simplifier le système en réduisant le nombre de fonctions ; • la taille : un cas d'utilisation d'un système modeste sera généralement plus simple à réaliser qu'un cas d'utilisation d'un système ambitieux. Ce facteur peut aller jusqu'à multiplier par dix le nombre d'heures-homme par cas d'utilisation ; • le type d'application : les systèmes temps réel à contraintes extrêmes fonctionnant dans un environnement distribué, par exemples les systèmes tolérants aux pannes/à haute disponibilité, influent sur le coût par cas d'utilisation selon un facteur de 3 à 5 par rapport à des applications SIG sur une plate-forme client-serveur. Cette liste ne prétend pas à l'exhaustivité. Les organisations de développement et les intervenants peuvent affiner les variables d'estimation en constituant leur propre base d'expérience. En l'absence d'une telle base, nous vous suggérons de procéder comme vous l'avez toujours fait. À ces estimations s'ajoute ensuite celle des coûts et des délais d'apprentissage d'une nouvelle approche, de l'utilisation de nouveaux outils et de l'adoption des autres caractéristiques nouvelles du Processus unifié. I l suffit à une organisation d'une ou deux expériences avec le Processus unifié pour constater une baisse vertigineuse des coûts, une réduction spectaculaire des délais de mise sur le marché et une amélioration notable de la qualité et de la fiabilité du système. En principe, les équipes de projet ne sont pas en position de rédiger l'étude de rentabilité finale à la fin de la phase de création. Trop peu de facteurs sont alors réunis. Le Processus unifié délivrant l'« offre ferme » à la fin de la phase d'élaboration, nous appelons l'étude de rentabilité de la phase de création étude de rentabilité initiale. Cette étude initiale doit se contenter, sans entrer dans le moindre détail, 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 création 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.


13

375

Néanmoins, l'étude de rentabilité reste toujours une préoccupation dans les projets que les entreprises envisagent sérieusement : elle nécessite toujours des recherches approfondie Les besoins en personnel et en délais des premières itérations doivent être finani n i e pris en charge. On néglige trop souvent le besoin qu'ont les chefs de projet, d a n s le | » , mières itérations, de données sur lesquelles fonder le travail et le calendriei des proji I futurs. Il est donc impératif de garder la trace des métriques adaptées à 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 création 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| .

.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 générer 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 période sui laquelle sVm leront les ventes doivent être déterminés par le marketing et tranchés pal les responsables Dans le cas d'un logiciel à usage interne, en revanche, il faudra demander aux services c on cernés d'évaluer les économies qu'ils espèrent réaliser. La marge d'erreur est généralement assez large, mais au moins cette estimation offre-t-elle une base permettant de comparer les gains envisagés aux coûts identifiés. Pour un produit logiciel commercial, l'étude de rentabilité devra inclure un ensemble d'hypothèses de base sur le projet, ainsi que l'ordre de grandeur du retour sur investissement dans le cas où ces hypothèses se confirmeraient. Pour garantir des chances raisonnables de rentabilité, les responsables estiment souvent le retour sur investissement en prenant, par mesure de sécurité, la valeur la plus pessimiste. À ce stade, l'étude de rentabilité est généralement possible : i l paraît profitable de poursuivre le projet. L'important, au moment de conclure la phase de création, n'est pas d'avoir des chiffres exacts, mais d'acquérir la certitude que le système ne débordera pas le cadre des moyens économiques de l'organisation et de son ou ses clients. On ne dispose alors pas des informations détaillées 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 précise. Ces hypothèses seront réexaminées à la fin de la phase d'élaboration, une fois le projet défini plus précisément.

6 Évaluer les itérations dans la phase de création Vers la fin de la phase de création, dès qu'il dispose des informations adéquates, le I hel de projet fixe les critères qui lui permettront d'évaluer le niveau d'achèvcmeni de la prei itération et de la phase dans son ensemble, comme l'explique en détail la section I i .' -I I I désigne également un groupe (qui peut se limiter à deux personnes) chargé d'évâluet I I phase. Ce groupe d'évaluation comprend généralement un représentant du client OU des u n

PARTIE

HM

u n développement itératif et incrémental

mm

III

lisateurs. Les projets d'une certaine ampleur pourront rctptciii la pn-.cn.c .le représenta de tous les intervenants concernés. Certains de ces critères pcuvcnl se révélei hors de p | dans le cadre du plan original. En voici quelques exemples : ()

• extension du modèle des cas d'utilisation jusqu'au point nécessaire dans celle phase ;

La phase de création lance le projet CHAPITRE

13

377

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 référence, qui comprend alors une description de l'architecture et des versions de tous les modèles. C'est ainsi que l'on progresse à travers les itérations indispensables à la phase de création (s'il en faut plus d'une). On peut supposer qu'il y aura une seule itération, mais les cas ...n. plexes peuvent en exiger plusieurs. On décide ensuite de ce qui doit être fait dans chaqu. n. ration, des besoins à implémenter et à tester et, en conséquence, des risques a red

• élaboration d'un prototype exploratoire de mise à l'épreuve du concept en étal de démonstration ; • suspicion d'une détection seulement partielle des risques critiques ; • fait que certains risques critiques déjà recensés n'aient pas été correctement réduits ou suffisamment couverts par un plan visant à les circonscrire. Le chef de projet transmet ces critères encore incomplets aux itérations suivantes et modifié en conséquence les plans et les calendriers des itérations concernées. Par exemple, il faudra peut-être que l'équipe s'adjoigne, dans une prochaine itération, les services de collaborateurs possédant certaines compétences ou un certain type d'expérience. L'évaluation de la phase de création débouche sur une décision absolument cruciale : faut-il poursuivre le projet ou l'abandonner ? Après examen des objectifs de cette phase (portée^ risques critiques, architecture candidate), il est décidé 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 décision de poursuivre. En revanche, celle d'abandonner le projet devra être prise dès que les éléments permettant de justifier cet abandon seront réunis. Il est vain de perdre son temps en efforts inutiles. Mais cette décision 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 représentants des utilisateurs. Il est toujours possible que le client trouve une solution de contournement au problème.

13.7 Planifier la phase d'élaboration La fin proche de la phase de création marque le début de la planification de la phase d'élaboration, alors que se précise 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 précise que ne le permettaient les données limitées de la phase de création ; cette offre servira en outre à sélectionner l'architecture. La proportion généralement nécessaire à l'élaboration de l'offre commerciale est d'environ 80 %. Il faudra peutêtre analyser la moitié de ces 80 % de cas d'utilisation pour acquérir une parfaite compréhension des besoins. La création de l'architecture de référence pourra nécessiter jusqu'à 80 % des cas d'utilisation afin de s'assurer qu'aucun élément d'importance n'aura été négligé. Sur ces 80 %, ori sélectionne la partie significative de la masse totale des cas d'utilisation sur laquelle reposera la conception de l'architecture de référence. Ces cas d'utilisation significatifs représentent une proportion plus faible de la masse totale que les 80 % recherchés : 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 %

L'expérience montre qu'une partie importante de la conception et de l'implérnentado au point dans la phase de création, 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 regroupés dans le tableau 13.1.

Ions . es p.

Tableau 13.1 : Exploitation des cas d'utilisation.

50%

50 à 70 %

Cas d'utilisation identifiés

Modèle du métier O complet

0

Phase de création

1

100%

Phase de construction

Près de 100 %

Phase d'élaboration

Masse des cas d'utilisation décrits

10%

Au moins 80 % 40 à 80 % 100%

100%

Masse des cas d'utilisation analysés

5%

Masse des c a s d'utilisation conçus, implémentés et testés

Un faible pourcentage pour un prototype de mise à l'épreuve du concept

20 à 40 % 100% si maintenus

Moins de 10 % 100%

Phase de transition 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 décrire plus en détail, qui I I I N sortit à l'activité détailler 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.

378


III

13.8 Éléments à livrer à l'issue de la phase de création La phase de création livre : • une liste des caractéristiques ; • une première version d'un modèle du métier (ou du domaine) décrivant le contexte .lu système ; • une ébauche des modèles constituant une première version du modèle des cas d'utilisation, du modèle d'analyse et du modèle de conception, tandis que les modèles d'implémentation et de tests resteront plus rudimentaires. I l existe également une première version des exigences supplémentaires ; • un premier projet de description de l'architecture de référence accompagné d'esquisses des vues des modèles des cas d'utilisation, d'analyse, de conception et d'implémentation ; • éventuellement, un prototype exploratoire de mise à l'épreuve du concept, démontrant l'utilisation du nouveau système ; • une liste initiale des risques et une liste de classement des cas d'utilisation ;

14 La phase d'élaboration fabrique l'architecture de référence

• les grandes lignes d'un plan concernant tout le projet et prévoyant les différentes phases ; • une première esquisse de l'étude de rentabilité comprenant : le contexte professionnel et les critères de réussite (projection des revenus, notoriété sur le marché, estimation du projet). En principe, les intervenants ont désormais une compréhension 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 détail la phase suivante. Les résultats obtenus dans cette phase sont affinés 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 système envisagé, une architecture qui en englobera les parties innovantes ou délicates ; • nous avons identifié les risques les plus graves - les risques critiques - , que nous avons explorés avec suffisamment d'attention pour acquérir la certitude que le système est faisable ; • nous avons établi une étude de rentabilité initiale suffisamment détaillée pour permettre le passage à cette deuxième phase et avons obtenu l'assentiment des différents intervenants, en particulier de ceux qui financent le projet.

.1 La phase d'élaboration en bref Nos principaux objectifs sont les suivants : • dégager 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 référence afin de guider le travail des phases de construction et de transition et prolonger ce lil condui teiu dans les générations 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 détailler le plan du projet.

L'


III CHAPITRE

Pour atteindre ces objectifs, nous considérons une vue en coupe •• d'un kilomètre 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 nécessaire 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 considérer une vue en coupe « d'un kilomètre de profondeur sur 3 cm de largeur » des points les plus délicats du système. Les architectes du système doivent identifier dès que possible les parties les plus périlleuses et lancer des « éclaireurs » sous forme de prototypes ou de pilotes pour identifier et gérer les risques. (H

11

r

Les décisions architecturales sont prises à partir d'une compréhension du système dans son ensemble : sa portée 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 modèle des cas d'utilisation, par rapport à l'architecture. Le modèle des cas d'utilisation et l'architecture sont élaborés de concert et s'influencent mutuellement (voir la section 4.3). Dans la phase d'élaboration, l'attention se porte principalement sur la formulation de l'architecture de référence, ce qui implique de combler environ 80 % des cas d'utilisation et de traiter les risques faisant obstacle à cet objectif. L'environnement de développement se voit également enrichi, non seulement pour permettre la conduite des activités propres à cette phase, mais aussi pour préparer 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 nécessaires à l'élaboration d'une étude de rentabilité fiable, commencée dans la phase de création.

14

d'élaboration. En s'appuyant sur une connaissance actualisée des ressources, du calendrier et des personnes disponibles, le chef de projet modifie le plan de l'itération et le plan de la phase.

14.2.2 Constituer

l'équipe

Tout ce qu'a découvert l'équipe à l'œuvre dans la phase de création 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 « mémoire de I i qinpi t outre, d'autres compétences passent au premier plan de l'élaboration Par exampli II pet sonnes ayant une connaissance opérationnelle des briques de base leuidi ..iM. . d. \ indispensables. D'ailleurs, l'équipe d'élaboration est généralement un peu plut lltl| que l'équipe de création. On embarque de nouvelles recrues. I.c ehel de pi*.in ,i

-

|<

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

développement

À la lueur des développements de la phase de création et de ceux prévus dans la phase d'ela boration, le chef de projet continue à mettre en œuvre les changements de r environnement de développement, d'abord traitée par la section 13.3.2. 14.2.4 Définir

les critères

d'évaluation

Les critères spécifiques auxquels doit satisfaire une itération ou la phase d'élaboration tout entière sont propres à chaque projet, mais on peut en examiner les résultats en termes d'objectifs de la phase.

14.2 Premiers stades de la phase d'élaboration Pour commencer, la phase de création transmet à la phase d'élaboration un plan en décrivant les grandes lignes, un modèle des cas d'utilisation partiellement rempli et une description de l'architecture candidate, auxquels peuvent éventuellement s'ajouter les prémices d'un modèle d'analyse et d'un modèle de conception. I l vaut mieux ne pas compter réutiliser ces modèles, qui peuvent toutefois servir de guide. L'une des tâches de la phase d'élaboration consiste à enrichir ces modèles, là encore non pas de façon complète, mais jusqu'au stade qui permettra de dégager l'architecture de référence. On pourra également disposer d'un prototype de mise à l'épreuve du concept démontrant l'utilisation du système, mais qui ne servira pas de base à la construction dans la phase suivante. Ce prototype est généralement mis au point le plus vite possible dans l'unique objectif d'établir la faisabilité du système.

14.2.1 Planifier la phase

d'élaboration

Il est possible que la planification de cette phase, menée à la fin de la phase de création, ne soit pas tout à fait complète. Souvent, les ressources qui seront disponibles dans la phase d'élaboration ne sont pas entièrement connues avant le début de cette phase. Dans certains cas, i l s'écoule un laps de temps entre la fin de la phase de création et le début de la phase

14.2.4.1 Développer les besoins et les exigences Les critères d'évaluation sont indiqués ci-dessous. • Les besoins et exigences, les acteurs et les cas d'utilisation nécessaires à la conception de l'architecture de référence, à l'identification des risques significatifs et à la prise en charge de l'étude de rentabilité et de l'offre commerciale ont-ils été identifiés ? • Ont-ils été suffisamment détaillés pour que les objectifs de cette phase soient atteints ?

14.2.4.2 Établir l'architecture de référence Les critères d'évaluation sont indiqués ci-dessous. • L'architecture de référence exécutable satisfait-elle non seulement aux besoins ei aux exigences formellement exprimés jusqu'à présent, mais aussi aux besoins ressentis pai li intervenants face à une architecture de référence en état de fonctionnement 7 • L'architecture de référence paraît-elle assez robuste pour résister à la phase de construction et à l'ajout des caractéristiques que pourront nécessiter les versions ultérieures ?


14.2.4.3 Réduire les risques significatifs Les critères d'évaluation sont indiqués ci-dessous. • Lesrisquescritiques ont-ils été réduits comme il convient, c'est-à-dire soil éliminés, soit circonscrits dans le cadre d'un plan adéquat ? • Tous lesrisquessignificatifs ont-ils été identifiés (voir l'identification des risques significatifs dans les sections 12.2.2 et 12.5) ? • Les risques significatifs ont-ils été explorés au point d'être sous tutelle ? • Les risques figurant toujours sur la liste des risques pourront-ils être facilement évacués dans la phase de construction ?

14.2.4.4 Estimer la valeur de l'étude de rentabilité Les critères d'évaluation sont indiqués ci-dessous. • Le projet est-il suffisamment défini pour que l'on puisse en déterminer le coût, le calendrier et le niveau de qualité ? • Le projet, tel que le décrit l'étude de rentabilité, est-il susceptible de produire le retour sur investissement ou de répondre au taux d'obstacle à l'investissement prescrit par le secteur I d'activité ? • En bref, sommes-nous prêts à signer un contrat de forfait (ou l'équivalent en développement interne) ?

14.3 Enchaînements d'activités de l'itération typique d'élaboration L'itération typique se compose des cinq enchaînements d'activités, comme l'illustre la figure 14.1. Ces enchaînements d'activités ont, certes, déjà été décrits dans la deuxième partie de cet ouvrage, mais ce chapitre ne s'intéresse qu'au rôle qu'ils jouent dans l'élaboration. Là encore, quatre ensembles d'activités sont en parties menées en parallèle. Le premier de ces ensembles regroupe les enchaînements d'activités principaux ; le deuxième s'attache à la planification des itérations, décrite par les sections 12.4 à 12.7 et par la section 14.2.1 ; le troisième est celui d'évaluation, abordé dans les sections 12.8 et 14.6 ; enfin, le dernier consiste à parfaire la préparation de l'environnement de développement, préalablement présenté dans la section 13.5. Dans cette section, nous nous contenterons de fournir une présentation générale des enchaînements d'activités principaux et de leur rôle dans l'élaboration, sur lesquels nous reviendrons plus en détail dans la section 14.4. Au cours de la « conception architecturale », seuls les besoins et exigences pertinents sur le plan architectural sont formulés, analysés, conçus, implémentés et testés. On prête peu d'attention aux détails non pertinents sur le plan architectural, qui sont repoussés à la phase de construction. L'architecture de référence née de ces efforts ne sera qu'un système minimal. En lui-même, ce système ne fera pas grand-chose, sauf dans les parties qui doivent être implémentées suffisamment en détail pour s'assurer du fonctionnement de l'architecture dans son ensemble. L'architecture de référence est mise au point en une, deux ou, dans les

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

cas extrêmes, plusieurs itérations, selon la portée du système, les risques, le degré de non veauté, la complexité de la solution technique et l'expérience des développeurs. 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 Foi muler différemment, on pourrait dire que la phase d'élaboration affronte les risques u , h niques architecturaux... en implémentant 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 réduire ou d'estimer les elloits et I, i, m,, nécessaires à cette réduction. En réalité, les risques ne seront pas élimiiu s i. tut li i i d'utilisation les englobant n'auront pas été implémentés, 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 COUTJ de la I l. i, besoins, de l'analyse et de la conception ; i l faut comprendre la plupart ,!e bai cevoir le système. En comparaison, l'implémentation et les tests exigent moins >I. sources. Figure 14.1 < Le travail d'une . itération de la phase d'élaboration traverse les cinq enchaînements d'activités principaux.

Ressources


Besoins

^

Analyse

^

Conception ^

Implémentatior^

Tests

^

4 Se concentrent sur l'architecture Enchaînements d'activités des Itérations d'élaboration

14.3.1 Formuler et affiner la plupart des

besoins

Que signifie ici formuler la plupart des besoins? Nous avons ouverl le débet 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 décrire en détail 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 décrire en détail tOUI • I U que l'on a identifiés : on sait d'expérience que certains sous-systèmes peuvent être iinmedia tement conçus (sur le plan architectural), qu'ils ne contiennent aucun risque et qu'ils peuvent faire l'objet d'une offre précise. 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

mmm PARTIE III

Sur la masse des cas d'utilisation décrits en détail, environ la moitié doivent être exami très attentivement en analyse. Parmi ces derniers, il suffira généralement de ne prendre compte qu'une partie des scénarios à concevoir, à implémenter cl a leslei poui eial l'architecture et réduire les risques. Examinez le tableau 13.1 ; le but est de Ibrmulei besoins en vue d'atteindre ces objectifs, sans aller au-delà.

14.3.2 Développer

l'architecture

de

référence

L'architecte assigne un ordre de priorité aux cas d'utilisation et mène les activités d'analyse de conception et d'implémentation au niveau architectural, comme le décrivent en détail les chapitres 8, 9 et 10. D'autres travailleurs se chargent des activités 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 conçoivent les classes et les sous-systèmes (voir le chapitre 9). Les ingénieurs de tests s'attachent à établir l'environnement de tests et à tester les composants et toute l'architecture de référence mettant en œuvre les cas d'utilisation significatifs sur le plan architectural.

14.3.3 Procéder

à des itérations

tant que l'équipe

est

réduite

Tant que l'équipe reste limitée, comme elle l'est pendant l'élaboration, c'est le moment de procéder à des itérations et d'essayer différentes solutions (technologies, infrastructures, structures, etc.). Si le projet représente une gageure, i l faudra peut-être trois ou quatre itérations 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 système de manière incrémentale. Une seule itération pourra suffire si le système est modeste et simple, tandis qu'il en faudra plusieurs dans le cas d'un système vaste et complexe. Le nombre d'itérations supplémentaires dépend de considérations telles que la complexité du système et de l'architecture de référence devant le guider, et la gravité des risques.


14

d'utilisation pour permettre l'établissement d'une offre juste et précise. I l convient, en outre, de clore cette phase avec une architecture de référence exécutable et stable, susceptible d'être enrichie dans la phase de construction. I l faut par conséquent prêter plus d'attention a la qualité et à l'extensibilité que ne l'exigeait la phase de création. Le début de cette itération consiste à explorer les risques et à identifier les cas d'utile... comme le décrit le chapitre 12. I l s'agit de couvrir environ 80 % des besoins et des e s t afin de détecter ceux ayant de l'importance pour l'architecture, mais aussi de rMMmblci ul fisamment d'informations pour faire une offre. D'une manière générale, il tant b i e i proportion de cas d'utilisation pour identifier les 10% nécessaires au de*velop| il l'architecture de référence. On considère, dans le projet hypothétique suivant, un système modérément c ompl. i iloiii l'architecture de référence naîtra en une seule itération. O n suppose qu'il l'tgll d dl loppement « tout neuf » (green field). Comme nous l'avons déjl liqué II i ht I dl |il(i|i i dispose des premiers éléments d'un plan du projet et d'un plan d Iti rttion n loti détaillé pour la première itération, issus de la phase de création, l a première 4U| étoffer le plan de l'itération en collaboration avec l'archilecle et les piiui ipnux d. m loppeurs. 1111

La description qui suit s'articule autour des cinq enchaînements d'activités C e scqiien cément des enchaînements d'activités pourrait laisser penser qu'ils doivent Impérativement se suivre, alors que diverses tâches peuvent être effectuées en parallèle, comme le montre la figure 14.2. Figure 14.2 Les « patatoïdes > tracées à la main regroupent les principales activités de la phase d'élaboration.

Les itérations se poursuivent jusqu'à ce que l'architecture parvienne à un niveau stable, c'est-à-dire qu'elle représente le système de façon acceptable et qu'elle ait atteint le point où les probabilités de changements sont assez faibles.

14.4 Exécuter les enchaînements d'activités principaux : des besoins aux tests La phase d'élaboration poursuit le travail amorcé dans la phase de création. Mais s'il suffisait, pendant la création, de démontrer qu'il serait possible de construire une architecture dans une phase ultérieure, i l s'agit maintenant de commencer à la réaliser. Nous allons revisiter ce qui a déjà effectué, en ayant conscience qu'assez peu d'éléments seront véritablement réutilisables. I l s'agit désormais de rechercher non seulement les cas d'utilisation représentant des risques critiques, mais également ceux qui présentent de l'intérêt pour l'architecture. Deuxièmement, i l faut parvenir à une couverture beaucoup plus large des cas


III

14.4.1 Formuler les

besoins

Nous allons, dans cette section, identifier, hiérarchiser, détailler cl structurel les c a s d'u sation (pour un traitement plus détaillé des besoins, voir les chapitres 6 et 7).

14.4.1.1 Identifier les cas d'utilisation et les acteurs L'analyste système identifie des cas d'utilisation et les acteurs supplémentaires, au-delà ceux recensés dans la phase de création (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 nécessaire d'en détailler autant. On peut les identifier presque tous (les fameux 80 %), mais on n'en décrit qu'une fraction, et l'on n'analyse que certaines parties des cas décrits. Par comprendre, nous entendons comprendre ce qui compte sur le plan architectural et s'assurer qu'aucun élément susceptible d'influer sur l'architecture ou sur l'offre commerciale n'est resté dans l'ombre.


14

14.4.1.3 Assigner un ordre de priorité aux cas d'utilisation L'enrichissement du modèle partiel des cas d'utilisation élaboré dans la phase de création suit deux fils conducteurs : d'une part, compléter un plus grand nombre de cas d'utilisation de l'autre, exploiter l'architecture de référence (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 activités doivent quand même se coordonner. Les décisions que I 'on prend alors sont influencées par le niveau de priorité affecté aux risques perçus cl pai l'onln dans lequel on décidera de poursuivre le développement (voir le chapitre 7, section / I ' «Activité: définir un ordre de priorité pour les cas d'utilisation», et le chapilie I section 12.6, «Définition d'un ordre de priorité pour les cas d'utilisation • i A parti) du modèle des cas d'utilisation, l'architecte produit une vue qui figurera dans la d. si iq i. l'architecture. 1

14.4.1.4 Détailler un cas d'utilisation

14.4.1.5 Structurer le modèle des cas d'utilisation

14.4.1.2 Prototyper les interfaces utilisateur

Les spécificateurs de cas d'utilisation complètent les cas d'utilisalii •< essnues a I. préhension totale des besoins et indispensables à la création de l'an Inici nue de réfén m i Pour de plus amples informations sur les spécificateurs de cas d'utilisation, reportaiTOUSSU chapitre7, section7.4.3, «Activité : détailler un cas d'utilisation ». Dans cette phase, nous allons limiter nos efforts aux descriptions préliminaires des cas d'utilisation complexes cl significatifs sur le plan architectural. En général, on ne s'attarde pas sur l'intégralité des cas d'utilisation sélectionnés : on se borne à en détailler les scénarios nécessaires à cette phase. Inutile de pousser la description au-delà du strict nécessaire. Toutefois, comme nous l'avons indiqué précédemment, dans certains cas complexes i l faudra détailler presque tous les scénarios et les cas d'utilisation, soit près de 100 % de la masse des cas d'utilisation.

La proportion de besoins formulés dépend également du degré de fidélité exigé. Si l'on est sur le point de faire une offre forfaitaire, i l faudra sans doute détailler un plus grand nombre de cas d'utilisation, éventuellement jusqu'à 80 % d'entre eux. Pour certains systèmes complexes, i l peut être nécessaire d'identifier presque tous les cas d'utilisation et d'en détailler 80 %. Si l'on finance soi-même le projet, on pourra s'arrêter à un pourcentage plus faible, ce qui aura cependant pour effet d'augmenter les risques. I l revient aux responsables de décider si l'on peut accepter un niveau de risques plus élevé en échange de délais et d'efforts moindres consacrés à la phase d'élaboration. Ce serait, peut-être inconsciemment, « économiser un franc et en dépenser 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.

Une autre activité liée à la formulation des besoins consiste à identifier les interfaces utilisateur (voir la section 7.4.4). On ne se soucie des interfaces utilisateur au cours de l'élaboration que si celles-ci présentent un intérêt sur le plan architectural, ce qui est rarement le cas. Il arrive toutefois qu'elles aient un caractère unique, d'une façon ou d'une autre. Si c'est le cas, i l sera peut-être nécessaire de créer votre propre infrastructure (framework) d'interfaces utilisateur. Ce sera indispensable, par exemple, si le système que vous cherchez à développer est lui-même une infrastructure d'interfaces utilisateur ; ou bien si le système en question utilise des protocoles de communication particuliers, pouvant influer sur l'architecture en termes de performances ou de temps de réponse. Il existe enfin une autre raison de créer une interface utilisateur même si celle-ci n'est pas significative pour l'architecture : pour vérifier, de la bouche même des véritables utilisateurs, qu'elle fonctionne bien. Cette solution extrême ne sera toutefois retenue que si la valeur du système n'a pas été prouvée au cours de la phase de création. En règle générale, i l n'est pas utile de prototyper les interfaces utilisateur pendant la phase d'élaboration.

4

L'analyste système révise le travail qu'il a effectué et recherche les similitudes, les simplifications et les opportunités susceptibles d'améliorer la structure du modèle des cas d'utilisation. I l emploie des mécanismes tels que l'extension et la généralisation (voir la section 7.4.5) pour obtenir un modèle mieux structuré et plus compréhensible. Le modèle pourra se révéler plus simple à modifier, à étoffer et à entretenir, puisqu'on y limite, par exemple, les redondances. I l arrive, toutefois, que l'analyste ne perçoive pas tout de suite la meilleure structure, mais qu'il doive attendre le passage des cas d'utilisation dans les enchaînements d'activités d'analyse et de conception. Structuration du m o d è l e des cas d'utilisation En travaillant sur le modèle des cas d'utilisation, les développeurs découvrent que plusiouis cas d'utilisation présentent des réalisations 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 réutilisable Soumettre la t r a n s a c t i o n commerciale, introduit par la restructuration du modèle des cas d'utilisation. Lorsqu'ils procèdent à la rôa lisation des cas d'utilisation, les développeurs réutiliseront la réalisation de Soumettre 1 a t r a n s a c t i o n commerci al e. Les transactions commerciales impliquées dans cet ensemble


III

de cas d'utilisation, telles que Facture, Commande et ton I i rnui l. i mi
C


14

a n

C C N A N

M

Renégociation des besoins

:

14.4.2 Analyse Nous allons maintenant compléter l'ébauche du modèle d'analyse tracée dans la phase de création (pour une description complète de l'analyse, voir le chapitre 8), dont il faudra peutêtre 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 préciser afin d'acquérir une meilleure compréhension des soubassements de l'offre commerciale.

Adapter les besoins et les exigences à l'architecture À mesure que l'on formule des besoins supplémentaires (c'est-à-dire que l'on complète de nouveaux cas d'utilisation), les connaissances accumulées sur l'architecture en cours de développement permettent de procéder plus intelligemment (voir la section 4.3). L'estimation de la valeur et du coût de chaque nouvelle suggestion de besoin ou de cas d'utilisation se fait à la lumière de l'architecture de référence dont on dispose alors. C'est l'architecture qui nous dit si tel ou tel besoin sera simple ou difficile à implémenter.

Imaginons une entreprise commercialisant un logiciel d'analyse de portefeuilles d'actions appelé Portfolio-Plus, destiné à des clients privés. 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 réel. Pour demeurer concurrentiel, Portfolio-Plus doll pouvoir recevoir les cotations au même 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 considérable Uni solution moins onéreuse consisterait à utiliser l'API développée précédemmenl pour i les entrées d'un tableur Excel. Il suffirait d'implémenter 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 société, où se trouveraient les cotations demandées pai l'utilisât* travail se limiterait alors à trois tâches : générer 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 réalité

L'exemple suivant montre les possibilités de réutilisation dans un contexte réel et l'impact que peuvent avoir les négociations sur le projet.

Après avoir étudié la situation que créerait 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 sémantique) serait susceptible de simplifier le fonctionnement de l'implémentation. Pour quelle raison ? Tout simplement parce que cette modification amènerait une conception plus compatible avec l'architecture existante. Tout changement de ce type devra faire l'objet d'une négociation avec le client.

En négociant les besoins avec le client à la lueur d'une architecture disponible, on parvient à construire des systèmes de qualité supérieure à moindre coût. Cette amélioration peut être illustrée par un exemple typique concernant une entreprise de télécommunications. Le client avait préparé une liste précise de besoins sous une forme équivalant à des cas d'utilisation. D'après ses estimations, il apparaissait que la construction du système à partir d'une base personnalisée aurait nécessité 25 années-homme. Le fournisseur de logiciels a pu démontrer aux dirigeants de l'entreprise de télécommunications qu'en modifiant leurs besoins pour les aligner sur l'architecture existante, ils pouvaient obtenir un résultat similaire, sinon d'identique. Mais surtout, les frais de développement étaient réduits de 90 % !

Tandis qu'avancent l'analyse, la conception, l'implémentation et les tests du système, toutes les modifications de la conception doivent être alignées sur l'architecture déjà en place dans le modèle de conception existant. Il faut, pour cela, prendre en compte les sous-systèmes, composants, interfaces, réalisations de cas d'utilisation, classes actives, etc., existant déjà. C'est à cette condition que l'on pourra créer, de manière rentable, une nouvelle conception à partir de ce dont on dispose.

L'entreprise de télécommunications a donc décidé de conserver cette architecture. Elle a obtenu un système qui était en fait un produit standard, légèrement modifié pour prendre an compte ses besoins propres. Cette option a permis d'économiser 20 années-homnn i de deve loppement. En plus, l'entreprise n'a pas eu à faire face au coût permanent do m.iinlcM. des logiciels et matériels personnalisés et a pu, au contraire, se reposer sur les services de maintenance incomparablement plus abordables fournis avec le produit standard.

I


III

K

14

mm


14.4.2.2 Analyser un cas d'utilisation La différence entre ce que souhaitait au départ le client et ce qu'il a flnalemenl accepté d'acheter est le résultat d'une restructuration des cas d'utilisation effectuée pai le fournlsseui De légères modifications des interfaces utilisateur, des moyens de surveillance différents des principaux processus, un changement des mesures et des présentations du flot du trafic, etc., expliquent cette incroyable baisse des coûts de 90 %. En plus, le client a obtenu davantage de fonctions qu'il n'en avait réclamées ; il a en effet acquis, pour un prix inférieur, ce que des clients précédents avaient largement financé. Si le fournisseur a pu maintenir à un faible niveau le prix de ces fonctions supplémentaires, c'est qu'il les avait déjà implémentées et testées.

Cette section aborde les activités 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 représentent en général moins de 10 % de la masse des cas d'utilisation. On analyse également les cas d'utilisation afin de les comprendre plus précisément et de cerner leurs interférences mutuelles. I l se peut qu'on ait, au total, à examiner environ 50 % de la masse des cas d'utilisation décrits en détail.

14.4.2.1 Procéder à l'analyse architecturale Dans la phase de création, 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 généralement pas très loin. I l faut maintenant pousser cette analyse pour démontrer qu'il est possible de prendre en charge une architecture complète, c'est-à-dire une architecture de référence exécutable. Dans cette optique, l'architecte procède à une première décomposition (de haut niveau) du système en paquetages d'analyse, à partir de la vue architecturale du modèle des cas d'utilisation, des besoins associés, du glossaire et de la connaissance du domaine disponible sous forme de modèle du métier (ou d'un modèle du domaine simplifié). Il identifie les paquetages spécifiques à l'application et ceux qui sont généraux aux applications : ce sont les plus importants du point de vue du problème. Tout en examinant les cas d'utilisation « pilotes » dans la vue architecturale du modèle des cas d'utilisation, l'architecte peut identifier des paquetages de service et des classes d'analyse évidents et significatifs pour l'architecture.

Beaucoup de cas d'utilisation, tels qu'ils apparaissent uniquement dans le modèle des l as d'utilisation, ne sont pas clairement compréhensibles (voir la section 8.6.2). Ils doivent 6tT précisés par des classes d'analyse qui figurent dans le contexte des besoins, niais qui ne ., mi pas forcément directement implémentées. Cette nécessité se ressent particulièrement poui les cas d'utilisation complexes et ceux exerçant une influence mutuelle, c'est à due ceux qui dépendent 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é préalablement fournie! pat d lUUTi cas d'utilisation. Les cas d'utilisation intéressants pour l'architecture et ceux qu'il est important d prendre sont donc précisés par le biais de classes d'analyse. Les autres i as il util qui ne sont pas pertinents pour l'architecture ou pour la compiéliension des lu soin m sont ni affinés, ni analysés. Les ingénieurs de cas d'utilisation se conlenieni de I. . , ompri ndr précisément et de s'assurer qu'ils n'ont aucun impact. Ils sauront comment MM M i l moment où i l faudra les réaliser, c'est-à-dire pendant la construction. Il n'est pas nécessaire de pousser très loin la description des cas d'utilisai uni signifie utils ou complexes : i l suffît que les analystes comprennent ce qu'expriment les cas d'utilisation, c'est-à-dire l'architecture de référence et l'étude de rentabilité. Si l'on a examiné 80 "/, des cas d'utilisation pour en comprendre le rôle dans le système et décrit 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 ingénieurs de cas d'utilisation commencent ensuite à trouver les classes d'analyse réalisant les cas d'utilisation. Us utilisent comme entrées les classes significatives pour l'architecture identifiées par l'architecte et leur affectent des responsabilités. Une grande partie du travail d'analyse des cas d'utilisation consiste à parcourir chaque cas d'utilisation du modèle des cas d'utilisation et à le préciser par des classes et les responsabilités 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 Régi er la facture dans la première itération, les développeurs suggèrent une classe pour la programmation et la réalisation des paiements (l'Échéancier) ayant les responsabilités suivantes :

De même, tout en s'appuyant sur les besoins collectifs des cas d'utilisation, i l recherche les mécanismes sous-jacents nécessaires à l'implémentation des cas d'utilisation. I l identifie les mécanismes génériques d'analyse (voir la section 8.6.1.3), parmi lesquels les collaborations génériques (voir le chapitre 3) et les paquetages génériques. Les collaborations génériques comprennent des fonctions telles que la récupération après erreur et le traitement des transactions, tandis que les paquetages génériques regroupent des fonctions comme celles de persistance, d'interfaces utilisateur graphiques et de distribution des objets. L'architecte est désormais en position d'améliorer la vue du modèle d'analyse.

• créer une requête de paiement ; • déclencher le virement à la date d'échéance. Il est possible que, dans une itération ultérieure, les développeurs se rendent complu qi •! te classe doit comporter d'autres responsabilités. L'ajout de ces nouvelles responsabilités ne doit pas nécessiter la restructuration de la classe. Un bon modèle d'analyse doit pomintlin d'ajouter de nouvelles responsabilités sans avoir à jeter ce qui existe ou, pin;, ;i nisiini luiei dans des itérations ultérieures les classes déjà identifiées. Ces responsabilité:; ptuiiitini l'he par exemple :

•

Un d é v e l o p p e m e n t itératif et i n c r é m e n t a l

M\


• assurer le suivi des règlements programmés ; • envoyer à une facture une notification l'informant que son règlement a été programmé, puis effectué (facture soldée).

À partir de ce travail d'analyse des cas d'utilisation, l'architecte sélectionne les classes significatives sur le plan architectural, qui forment ensuite le socle de la vue architecturale du modèle d'analyse.

14.4.2.3 Analyser une classe Les ingénieurs de composants affinent les classes identifiées dans les étapes précédentes. Ils fusionnent les responsabilités qui leur ont été allouées à partir de différents cas d'utilisation, identifient les mécanismes d'analyse disponibles et vérifient l'utilisation qu'en fait chaque classe (voir la section 8.6.3).

14.4.2.4 Analyser un paquetage Comme nous l'avons fait remarquer plus haut, dans l'analyse architecturale l'architecte prend en considération les services du système 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 ingénieurs de composants prennent la responsabilité des paquetages ; ils les précisent et en assurent la maintenance (voir la section 8.6.4).

14.4.3

Conception Cette phase voit généralement la conception et l'implémentation de moins de 10 % de la masse des cas d'utilisation. Ce faible pourcentage ne représente qu'une fraction de l'ensemble des cas d'utilisation identifiés dans cette même phase. La phase d'élaboration limite la conception au niveau architectural : on ne conçoit donc que les cas d'utilisation, les classes et les sous-systèmes ayant de l'importance pour l'architecture. Les paquetages d'analyse et les sous-systèmes de conception sont essentiels à la définition des vues architecturales. De nombreux classificateurs peuvent avoir de l'importance pour l'architecture ou ne pas en avoir ; les paquetages et les sous-systèmes en ont généralement. (Voir le chapitre 9.)

14.4.3.1 Procéder à la conception architecturale L'architecte est chargé de concevoir les aspects du système significatifs pour l'architecture tels qu'ils apparaissent dans la vue architecturale du modèle de conception (voir la section 9.3.6). La vue architecturale du modèle de conception comprend les sous-systèmes, les classes, les interfaces et les réalisations des cas d'utilisation significatifs pour l'architecture, figurant dans le modèle des cas d'utilisation. Les autres aspects de la conception sont du ressort de l'ingénieur de cas d'utilisation et de l'ingénieur de composants. L'architecte identifie l'architecture en couches (y compris les mécanismes génériques de conception), les sous-systèmes et leurs interfaces, les classes de conception significatives pour l'architecture, et les nœuds de configuration, traités dans les sections qui suivent. Identifier l'architecture en couches - L'architecte poursuit le travail commencé dans la phase de création et conçoit l'architecture en couches. I l réexamine les couches de logiciel système et de middleware, abordées dans la section 9.5.1.2, et sélectionne les produits qui

14

devront être utilisés. I l peut aussi intégrer des systèmes existants développés par sa propre entreprise ; dans ce cas, il devra identifier les parties réutilisables et les interfaces requises 11 sélectionne également les produits des couches inférieures comme implémentalions des mécanismes de conception correspondant aux mécanismes d'analyse identifiés d u r |< étapes précédentes (voir la section 14.4.2.1). N'oubliez pas que nous désignons pai m t l nismes de conception les mécanismes du système d'exploitation sur lesquels doit Font tionner le système proposé: les langages de programmation, les systèmes de finse .1, données, les ORB (Object Request Brokers), etc. Les mécanismes de conception I vanl être utilisés par le produit sont limités par l'environnement d'implémentation (in | les construire, soit acquérir des produits les mettant en œuvre. Il s'agit souvent dl tèmes des couches de middleware et de logiciel système d'une areliitcs une e u, n, i , construction ou leur sélection peut s'effectuer parallèlement à rencbaînemenl il m II' ||i d'analyse. Les ingénieurs 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

P°

u r

| a

distribution des objets

Java RMI sert à la distribution des objets : le paquetage j d v d . nu i scia utilise ikiin; lïléi;iimii de la phase d'élaboration pour implémenter le cas d'utilisation Soumettre la transaction commerciale.

Identifier les sous-systèmes

et leurs interfaces

L'architecte se tourne ensuite vers les couches supérieures de l'architecture, proches des couches d'applications. À partir des paquetages du modèle d'analyse, i l identifie ainsi les sous-systèmes correspondants devant figurer dans le modèle de conception. En principe, i l tentera de faire de chaque paquetage de service du modèle d'analyse un sous-système de service dans le modèle de conception ; les paquetages d'analyse de plus haut niveau deviendront des sous-systèmes dans le modèle de conception. Si cette approche donne de bons résultats dans certains cas, on peut parfois constater un décalage entre l'analyse et la conception. I l se peut que, dans certaines situations, un paquetage d'analyse ne corresponde pas à un sous-système de conception mais à un système hérité (ou à une partie de ce système). Au lieu d'une correspondance un-à-un, i l est possible que le système hérité réalise en totalité ou en partie plusieurs paquetages d'analyse, ou qu'un paquetage d'analyse corresponde à plusieurs systèmes hérités, situation débouchant finalement sur une relation plusieurs-à-plusieurs. Dans d'autres situations, l'architecte pourra sélectionner des briques de base comme des infrastructures préfabriquées (frameworks), développées en interne ou acquises auprès de fournisseurs externes. Ces briques risquent de ne pas s'intégrer exactement à la structure de paquetages proposée par le modèle d'analyse ; i l est donc possible que l'aiclniei te .m sélectionner pour la conception architectarale une structure de sous-systèmes quelque peu différente 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 identifiées, il sélectionne i .Iles qui


III

comptent pour l'architecture, comme les classes actives, et les deci il l'architectare.

dans

la

,1e

a upiiou de

Dans le cas d'un système distribué, identifier les nœuds et leur configuration réseau L'architecte tient compte des besoins du système en matière de concurrence et de distribution en étudiant les threads et les processus requis, ainsi que le réseau physique des processeurs et des autres unités. Les cas d'utilisation déjà conçus, en particulier tels qu'ils apparaissent dans les diagrammes d'interaction, constituent une entrée essentielle à cette tâche. Dans les diagrammes d'interaction, l'architecte affecte les objets utilisés à des classes actives, qui sont, à leur tour, affectées aux processeurs et autres périphériques. Cette étape permet de distribuer les fonctions, au sens logique et physique du terme. L'architecte dresse une nouvelle version des vues architecturales du modèle de conception et du modèle de déploiement, qui figurent toutes deux dans la description de l'architecture.

14.4.4


14

395

rations ultérieures. Les ingénieurs de composants intègrent les différents rôles de chaque classe dans une classe cohérente, comme l'indique la section 10.3.

14.4.3.4 Concevoir un sous-système Les ingénieurs de composants conçoivent les sous-systèmes issus de la conception architec turale. L'architecte en profite pour actualiser en conséquence la vue architecturale di dele de conception.

Implémentation Cet enchaînement d'activités permet d'implémenter et de tester les composant 1 l i | i, pour l'architecture, en travaillant à partir des éléments de conception p a t i n e u r , lui II pl m architectural. I l se traduit par l'architecture de référence, généralement Implémenti l i p de moins de 10 % de la masse des cas d'utilisation. Nous allons traiter, d a n s , elle s a , |, activités d'implémentation architecturale, d'implémentation d'une classe et d système, et d'intégration du système (voir le chapitre 10.)

14.4.3.2 Concevoir un cas d'utilisation Les cas d'utilisation significatifs pour l'architecture sont désormais conçus sous forme de sous-systèmes de conception, de sous-systèmes de service ou de classes de conception (voir la section 9.5.2). (Les autres cas d'utilisation identifiés, détaillés et analysés 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 différences essentielles. En analyse, i l s'agissait d'analyser et d'affiner les cas d'utilisation et d'obtenir une spécification robuste, capable de réagir aux changements et réutilisable. Cette spécification devait servir de première ébauche à la conception. On avait tenté de dégager les responsabilités des classes d'analyse identifiées.

14.4.4.1 Procéder à l'implémentation architecturale Les composants nécessaires à l'implémentation des sous-systèmes de service sont Identifié! à partir des vues architecturales des modèles de conception et de déploiement. Les compo sants exécutables trouvent une correspondance avec les nœuds du réseau informatique siu lesquels ils seront exécutés. L'architecte illustre ensuite cette correspondance dans la vue architecturale du modèle d'implémentation (voir la section 10.5.1.)

14.4.4.2 Implémenter une classe et implémenter un sous-système

En conception, i l faut aller bien plus loin dans le détail. En passant de l'analyse à la conception, les ingénieurs de composants doivent adapter le modèle d'analyse en vue d'obtenir un modèle de conception opérationnel, celui-ci étant limité par les mécanismes de conception. Toutefois, les paquetages et classes d'analyse offrent un moyen direct d'identifier les sous-systèmes et les classes de conception. Une fois ceux-ci identifiés, on ne se borne pas à en décrire les responsabilités ; on retrace les interactions précises qui les lient les uns aux autres.

Au cours de l'enchaînement d'activités de conception, les ingénieurs de composants ont conçu un certain nombre de classes pertinentes pour la création de l'architecture de référence. Cette référence doit constituer une première version exécutable du système sur le point d'être construit. Dans cet enchaînement d'activités, les ingénieurs de composants implémentent ces classes sous forme de composants fichiers (il y a généralement un ou plusieurs composants pour un sous-système de service issu du modèle 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.)

Nous avions décrit, en analyse, le déplacement du point de vue d'un élément à l'autre dans l'exécution d'un cas d'utilisation. Plusieurs types de diagrammes d'interaction avaient été employés pour montrer ce mouvement. En conception, nous spécifions également les opérations utilisées pour la communication. Il faut alors déterminer les sous-systèmes, infrastructures préfabriquées ou systèmes existants à réutiliser, puis les opérations qu'ils fournissent. S'ils sont difficiles à comprendre, la conception manquera de clarté.

14.4.4.3 Intégrer le système À partir du faible pourcentage de cas d'utilisation devant être implémentés dans cette itération, l'intégrateur système établit la séquence d'intégration dans un plan de construction de l'intégration, puis i l intègre progressivement les sous-systèmes et les composants cônes pondants dans l'architecture de référence exécutable (voir la section 10.5.2.)

Cette activité aboutit à un ensemble de réalisations-conception de cas d'utilisation : chaque cas d'utilisation pertinent pour l'architecture est représenté par l'un de ces artefacts.

EXEMPLE

14.4.3.3 Concevoir une classe

Trois constructions L'intégrateur système suggère trois constructions initiales (voir la figure 14.3).

Il s'agit maintenant de concevoir les classes ayant participé aux réalisations de cas d'utilisation dans l'étape précédente. Notez que ces classes ne sont généralement pas complètes. ; elles prendront part à d'autres réalisations de cas d'utilisation qui seront créées dans des ite|


III

Figure 14.3 La première itération comprend trois constructions. Notez que la construction 2 intègre aussi les résultats de la construction 1.

B

14

mm


14.4.5 Tests L'objectif est ici de s'assurer du fonctionnement des sous-systèmes et de leurs interfaces i) tous les niveaux (les sous-systèmes de service comme les sous-systèmes de conception) et dans toutes les couches (de la couche de logiciel système à la couche spécifique n l'application) ; voir le chapitre 11. On ne peut, bien sûr, tester que les composants exét U tables. S'ils fonctionnent, on peut avoir bon espoir que le reste (les éléments des . m i n . modèles) fonctionne aussi. Débuter par les couches architecturales inférieures implique de tester ht d i s l i i h rjl objets, le stockage et la récupération (persistance) des objets, les objets coin u et d'autres mécanismes des couches inférieures du système. 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 testées en elles-mêmes ; il nous suffi) de testa I u ||gi qui font les couches supérieures des couches inférieures.

L'exemple montré dans la figure 14.3 consiste en trois constructions, soumises chacune à l'activité effectuer les tests d'intégration : 1. Les classes du sous-système Gestion des comptes, qui englobe le système bancaire hérité. 2. Les classes du Paquetage des factures de l ' a c h e t e u r impliquées dans le cas d'utilisation Régi er

1 a f a c t u r e , plus la première construction.

3. Les classes du Paquetage des

factures du vendeur et celles du Paquetage des

factures de l ' a c h e t e u r impliquées dans le cas d'utilisation Facturer l'acheteur. Ces sous-systèmes abritent à l'origine les classes génériques du cas d'utilisation abstrait Soumettre la

t r a n s a c t i o n commerciale, qui sont ensuite déplacées vers un sous-

système réutilisable par plusieurs autres sous-systèmes. Cette construction doit s'intégrer avec le paquetage Java

RMI.

Alors qu'on peut parfaitement envisager de travailler (avec quelque difficulté, toutefois) sans outils dans la phase de création, i l est pratiquement impossible de s'en passer dans la phase d'élaboration. Par exemple, on commence maintenant à être obligé de gérer des versions : i l est donc nécessaire 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 début de la phase d'élaboration, mais i l est peu probable d'en venir à bout sans placer l'architecture de référence sous le contrôle de certains outils. Autre exemple : certains travailleurs pourront utiliser le langage de « production » (disons Java) ainsi qu'un ensemble d'outils. Ce recours présentera l'avantage de mettre à l'épreuve l'environnement de développement et de familiariser les travailleurs avec de nouveaux outils et des méthodes in-onnues. I l y a plus de chances, dans un tel cas, que le premier incrément utilise l'infrastructure, c'est-à-dire le middleware et le logiciel système, du système final. Le prototype est, de même, plus susceptible d'évoluer vers le système réel.

Dans la couche spécifique à l'application et dans la couche générale aux applu allons li tests vérifient la façon dont la taille du système s'adapte à l'intégration de nouveaux soie, systèmes utilisant des interfaces déjà prises en charge.

14.4.5.1 Planifier les tests Un ingénieur de tests sélectionne les objectifs qui lui permettront d'évaluer l'architecture de référence. I l pourrait s'agir, par exemple, d'exécuter un scénario de cas d'utilisation dans un temps de réponse 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'ingénieur de tests identifie les cas de test nécessaires et met au point les procédures qui serviront à tester les intégrations ultérieures de sous-systèmes, puis l'architecture de référence dans son ensemble (voir la section 11.5.2.)

14.4.5.3 Effectuer les tests d'intégration Une fois les composants testés, ils peuvent être soumis aux tests d'intégration. Les testeurs d'intégration testent chaque construction (voir la section 11.5.4.)

14.4.5.4 Effectuer les tests système Lorsque le système, tel qu'il a été défini par les cas d'utilisation significatifs pour l'architecture, est intégré, i l est soumis aux tests effectués par le testeur système. Ce système (qui est une version du système final) constitue l'architecture de référence. Le testeur renvoie pour correction les anomalies détectées aux ingénieurs de composants ou à l'architecte I vou la section 11.5.5.)

Les ingénieurs de tests révisent les résultats des tests système pour s'assurer qu'ils iciu plissent les objectifs initiaux ou pour déterminer la façon dont il faudra modifia les i as i l test pour atteindre ces objectifs.


III

Des virements i n c o h é r e n t s créent un risque majeur Les tests système établissent que la plupart des fonctions semblent satisfaire aux objectifs de qualité fixés, à une exception près : lorsque les testeurs exécutent le cas d'utilisation Itég I or 1 a facture, certains résultats sont incorrects. Le système hérité contenu dans le sous-système Gesti on des comptes ne livre pas le résultat prévisible pour certains virements dont le montant n'est pas arrondi au franc près, par exemple 134,65 FF. En revanche, d'autres virements de ce type, comme celui d'un montant de 124,55 FF, fonctionnent très bien. Les testeurs attirent l'attention sur ce problème, que l'architecte désigne comme risque majeur. Le chef de projet nomme un groupe de travail chargé de le résoudre immédiatement.

14.5 Elaborer l'étude de rentabilité La raison qui sous-tend la réduction des risques et la création de l'architecture de référence 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 fixées sur le plan commercial. Ces limites sont de deux natures. L'une est l'estimation des délais, du travail et des coûts pour un niveau de qualité donné. L'autre est le retour sur investissement (ou une métrique comparable) indiquant que le système envisagé sera une réussite sur le plan économique. À l'issue de la phase de création, l'organisation de développement ne peut juger des mérites 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 réduire considérablement ce spectre. L'équipe peut maintenant rédiger une offre et élaborer l'étude de rentabilité dans le cadre plus précis de la pratique professionnelle.

II II

\

14.5.1 Préparer

l'offre

commerciale

L'équipe de développement est censée mener à bien la phase de construction à partir d'un réfèrent commercial, qui peut être un contrat avec un client externe, une relation avec un autre service de la même entreprise ou le développement d'un produit destiné à la vente à un large public.

I

Nous observons que l'estimation des logiciels repose souvent sur la taille du projet et sur la productivité des équipes de développement. La productivité des équipes découle de l'expérience acquise sur des projets antérieurs, alors que l'estimation de la taille se fonde sur les leçons tirées de la phase d'élaboration. Pour faire une estimation réaliste, i l faut poursuivre la phase d'élaboration jusqu'à obtenir une vision claire du travail à effectuer dans la phase de construction. C'est précisément ce qu'apporte l'architecture de référence. Deuxièmement, si le projet présente des risques d'une certaine ampleur, ceux-ci doivent être examinés attentivement jusqu'à ce que l'on puisse déterminer le temps et les efforts que coûtera leur résolution.

II 1


14.5.2 Actualiser le retour sur

14

investissement

Réduite à sa substantifique moelle, l'étude de rentabilité examine les points suivants : les gains générés par l'utilisation ou la vente du produit logiciel feront-ils plus que compenser le coût de son développement ? Le produit arrivera-t-il à temps sur le marché (ou dans l'appli cation interne) pour garantir ces revenus ? Les équipes chargées du développement 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 idéale permettant de calculer les gains que générera le logiciel. Dans le cas d'un logiciel commercialisable, la question du nombre d'exemptaites vendu d u prix auquel ils seront vendus et de la période sur laquelle se dérouleront les veilles i I du ressort du service du marketing et devra être tranchée par les responsables I linis le i i d'un logiciel à usage interne, l'équipe du projet peut demander aux services conoemél d i Htlltli les économies escomptées. La marge d'erreur dans l'estimation des gains pou util l i i généralement assez large, mais l'exercice fournit au moins une base pcrmellanl d e i oinpatei les gains potentiels aux coûts. 1

14.6 Évaluer les itérations de la phase d'élaboration Une fois terminée, chaque itération est évaluée par rapport aux critères fixés dans le plan d'itération mis au point avant le début de l'itération, comme l'indique la section 14.2.5. L'équipe d'évaluation examine les résultats de chaque itération pour vérifier que la référence représente effectivement une architecture susceptible de remplir les objectifs originels et de réduire les risques. S'il doit y avoir plusieurs itérations, le résultat de la première d'entre elles pourra n'être qu'une ébauche relativement grossière de cette architecture. Cette ébauche peut aussi se composer de vues architecturales assez précises des différents modèles : cas d'utilisation, analyse, conception, déploiement et implémentation. Le résultat de la deuxième itération constitue la deuxième ébauche de l'architecture. Et l'itération finale produit l'architecture de référence. A l'issue de chaque itération, le chef de projet, généralement en coordination avec le groupe d'évaluation, compare ce qui a été réellement accompli aux critères prédéfinis. Si le projet ne satisfait pas à ces critères, le chef de projet doit le réorienter, comme l'indique le chapitre 12. Cela peut se traduire, dans la phase d'élaboration, par le report d'activités ma chevées à l'itération suivante. Le fait que le chef de projet ait amené le client et les autres intervenants à s'accorder sut l a réalisation de chaque jalon mineur permet d'atténuer 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 modèle en cascade. I ,c client, de • côté, aura eu l'occasion de livrer progressivement ses impressions sur les modèles e m de développement. Maintenant, à la fin de la phase d'élaboration, l'évaluation permet de convaincre les inlervi nants que cette phase a réduit les risques les plus graves et qu'elle a bâti une architecture de

II II


III

référence stable. Elle les convainc que le système peut être construil scion les ici mes du plan du projet et de l'offre commerciale concernant la phase de construction.

n


14

14.8 Principaux éléments à livrer La phase d'élaboration doit livrer les éléments suivants :

14.7 Planifier la phase de construction Vers la fin de la phase d'élaboration, le chef de projet commence à planifier en détail la première itération de construction et à exposer la suite en termes plus généraux. Le nombre d'itérations requis dépend de la taille et de la complexité du projet. Les chefs de projet en prévoient généralement deux ou trois, parfois quatre ou plus dans le cas d'un projet vaste et complexe. Es esquissent au sein de chaque itération un certain nombre de constructions, chacune ajoutant une partie relativement modeste à ce qui a déjà été fait. La gestion de projet doit encore traiter un grand nombre de risques figurant sur la liste des risques. Le chef de projet prévoit l'ordre de recherche des risques restants afin de les réduire un à un avant qu'ils n'apparaissent dans la séquence de constructions ou d'itérations. Le principe opératoire reste le même : réduire les risques avant qu'ils ne fassent irruption dans la séquence de constructions. La phase d'élaboration n'aura que partiellement rempli les modèles. Le chef de projet envisage l'ordre dans lequel seront abordés les cas d'utilisation et les scénarios restants et celui dans lequel seront complétés les différents modèles. Cette préoccupation conduit au séquencement des constructions et des itérations. Sur de vastes projets, pour réduire les délais en employant davantage de collaborateurs, le chef de projet répartit le travail pouvant être accompli par les travailleurs dans des travées parallèles. Le développement de systèmes industriels d'envergure oblige l'équipe du projet à trouver des voies de travail parallèles en raison des contraintes temporelles qu'impose ce type de projet. L'équipe recherche un moyen de déployer un grand nombre de collaborateurs, souvent par dizaines.

• de préférence, un modèle complet du métier (ou du domaine) décrivant le contexte du système ; • une nouvelle version de tous les modèles : modèles des cas d'utilisation, d'analyse, de conception, de déploiement et d'implémentation. (À la fin de la phase d'élaboration, 001 modèles seront complets à moins de 10 %, à part le modèle des cas d'utilisation et le modèle d'analyse, qui peuvent englober plus de cas d'utilisation (parfois jusqu'à B0 91 i pour garantir que les besoins ont été appréhendés. 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é négligé et que l'on peut estimer le coût de leur Introduction I • une architecture de référence exécutable ; • unedescriptionderarchitecture,aveclavuedesmodèlesdecasd'ulilisaiion d ' U t l de conception, de déploiement et d'implémentation ; • une liste des risques actualisée ; • le plan du projet pour les phases de construction et de transition ; • un premier manuel d'utilisation (facultatif) ; • une étude de rentabilité complète, accompagnée de l'offre commerciale.

Ce moyen repose sur les sous-systèmes établis dans l'architecture de référence. Dans l'enchaînement d'activités de conception (inspiré par les paquetages d'analyse), on trouve des sous-systèmes à différents niveaux. Les sous-systèmes ont des interfaces : l'un des objectifs de plus haut niveau consistait précisément à identifier et à définir ces interfaces. Les interfaces sont au cœur de l'architecture. Une fois les sous-systèmes et les interfaces identifiés et spécifiés, on est paré pour organiser le travail en parallèle. Un individu a la responsabilité d'un sous-système de service dans un sous-système de conception. Un groupe a la responsabilité d'un sous-système de conception. Si les individus ou les groupes réduits doivent bénéficier d'un niveau raisonnable d'indépendance, i l faut que les interfaces limitant leurs territoires soient solides. Pour souligner l'importance de ces spécifications d'interface, on les appelle parfois contrats. Un contrat engage les développeurs 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 intégrable. Plus tard, les développeurs peuvent remplacer un sous-système par un autre, tant qu'ils n'enfreignent pas le contrat d'interface. La construction de sous-systèmes s'interconnectant par le biais d'un contrat d'interface (ou de l'équivalent) s'apparente largement, par le principe, à la construction de systèmes de systèmes, évoqués dans l'encadré « Modélisation de vastes systèmes » de la section 7.2.3.

»

15 La construction aboutit à la capacité opérationnelle initiale Le premier objectif de cette phase est de livrer un produit logiciel sous forme de version opérationnelle initiale, parfois appelée version bêta. Ce produit doit atteindre un niveau de qualité adapté à l'application et être conforme aux besoins exprimés. La construction doit, en outre, s'inscrire dans les limites du plan stratégique (business plan). À la fin de la phase d'élaboration, nous avons amené le système proposé au niveau d'une architectore de référence exécutable. Les phases précédentes ont réduit les risques critiques et significatifs pour les ramener à des niveaux de pure routine, gérables dans le cadre du plan de la construction. Au cours de la phase d'élaboration, l'équipe du projet a posé les fondations des éléments significatifs pour l'architecture des modèles de conception et de déploiement, c'est-à-dire les sous-systèmes, les classes (actives), les composants et les interfaces les reliant. Ces fondations englobent également les réalisations des cas d'utilisation significatifs. Une telle partition s'est effectuée à partir de la description détaillée d'une proportion de cas d'utilisation ne dépassant guère 10 % de la masse totale des cas d'utilisation. Rappelez-vous que la quasi-totalité des besoins (en principe autour de 80 %) a été formulée, mais ne nécessitait pas une description complète pour atteindre les objectifs de la phase d'élaboration. C'est à cela que nous allons désormais nous atteler dans la phase de COIU truction.

15.1 La phase de construction en bref À partir d'une architecture de référence exécutable et à travers toute une série d'ileial s ci d'incréments, l'équipe intervenant dans la phase de construction met au point un produit logiciel prêt à assurer un début de fonctionnement dans l'environnement utilisateur, souvent désigné sous le terme de tests bêta. Elle complète la description des cas d'utilisation cl des scénarios restants, modifie la description de l'architecture si nécessaire, et poursuit les enchaînements d'activités à travers des itérations supplémentaires pour parvenir à un equi

WfWM U" BVUMÉI

d é v e l o p p e m e n t itératif et i n c r é m e n t a l

PARTIE

1

III

~

libre entre les modèles d'analyse, de conception et d'implémentation butin, clic imèe sous-systèmes et les soumet à des tests, avant de passer à l'intégration du système dans ensemble, qui sera à son tour testé. 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 création et d'élaboratk une activité de recherche, la phase de construction s'apparente, elle, au travail de déveli pement. L'attention, qui s'était concentrée jusque-là sur la constitution d'une base de ci naissances nécessaire à l'élaboration du projet, se tourne désormais vers la construction effective d'un système ou d'un produit dans le respect des paramètres de budget, de charge de travail et de délais.

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

cation, à la fin de la phase d'élaboration. Qu'on le veuille ou non - en général, 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 délais fixés par les intervenants.

c

Pendant la phase de construction, le chef de projet, l'architecte et les principaux développeurs s'assurent que les cas d'utilisation ont été hiérarchisés, regroupés en constructions et en itérations, et développés dans un ordre permettant d'éviter les retours en arrière. Ils actualisent en permanence la liste des risques afin qu'elle reflète l'état actuel des risques réels encourus par le projet. Leur objectif est d'achever cette phase en ayant réduit tous les risques (hormis ceux qui surgiront du fonctionnement et seront traités en phase de transition). L'architecte veille en permanence à ce que la construction soit conforme à l'architecture et, si nécessaire, modifie cette architecture pour intégrer 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 reçoit, 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. La première est l'écart temporel qui peut séparer les phases d'élaboration et de construction. Les responsables financiers du projet peuvent donner immédiatement leur accord au démarrage 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 très 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 réunir 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 intégralement renouvelée, qui prendra en charge la phase de construction.

m , " g

•

Autres circonstances susceptibles de changer : les fonds et les délais accordés au projet sont inférieurs à ceux prévus dans la phase d'élaboration. Il est possible que la portée du projet ait été revue à la baisse pour s'accorder au budget et aux délais, mais ce n'est pas forcément le cas. Ce que nous voulons dire, c'est que, au début de la phase de construction, les circonstances peuvent s'écarter (un peu ou beaucoup) de celles qui ont servi de base à la planifi-

15.2.1 Constituer l'équipe

de la phase

Dans la phase de construction, le travail dépasse largement le cadre de l'architecture (c'est à-dire des éléments de modèle significatifs pour l'architecture). Les sous-systèmes de service identifiés par l'architecte dans la phase d'élaboration ne sont pas completl lia n'implémentent que les principaux cas d'utilisation et leurs scénarios essentiels. I c i lui de projet affecte des ressources supplémentaires à ce travail. L'architecture de référence, avec sa représentation des sous-systèmes et des intei la> <••. titue la source à laquelle va puiser le chef de projet pour répartir le travail ( UltCjUI OU système tombe sous la responsabilité d'un développeur agissant en tant qu'ingénieui dl composants. Normalement, comme nous l'avons indiqué dans le chapitre 9, le dévcloppcui responsable d'un sous-système est également responsable des classes que contient i elul i i I l n'est guère habituel qu'un développeur ait la responsabilité d'une seule classe . c e sciait pousser la division du travail un peu loin. Pour l'essentiel, la phase de construction mobilise les travailleurs suivants : ingénieur de cas d'utilisation, ingénieur de composants, ingénieur de tests, intégrateur système, testeur d'intégration et testeur système. Par rapport à la phase d'élaboration, le nombre de personnes agissant en tant que travailleurs a considérablement augmenté, passant souvent du simple au double, comme le montre la section 12.7. Le tableau 13.1 indique, pour chaque enchaînement d'activités, le volume approximatif de travail restant à effectuer dans la phase de construction : 60 % en analyse et 90 % dans les enchaînements de conception, d'implémentation et de tests. Outre les travailleurs cités dans le paragraphe précédent, l'architecte continue à être disponible, bien qu'il consacre généralement moins de temps à cette phase. D'autre part, comme il reste environ 20 % des besoins à formuler, l'analyste système et le spécificateur de cas d'utilisation ont encore du travail.

15.2.2 Définir

les critères

d'évaluation

Les critères spécifiques que doit remplir une itération ou la phase de construction dans son ensemble sont propres à chaque projet. Ils ont en effet été fixés pendant le développement des cas d'utilisation. Comme nous l'avons fait remarquer dans les chapitres précédents, les cas d'utilisation eux-mêmes correspondent à des besoins fonctionnels. Mais ils porlenl éga lement en eux des exigences non fonctionnelles (par exemple, des exigences de peilm mances) et servent à réduire les risques. Chaque construction ou itération implémcnli un ensemble de cas d'utilisation. Les critères d'évaluation de cet ensemble de cas d'utilisation sont donc fondés sur les besoins fonctionnels et non fonctionnels liés à ce même ensi mbli de cas d'utilisation.

a


Ces critères d'évaluation liés aux cas d'utilisation permettent aux développeurs eus mêmes de définir clairement à quel moment achever une construction ou une itération.

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

Ressources

D'autres éléments naissent de la phase de construction, pour lesquels il faudra prévoir des critères d'évaluation. Deux exemples en sont donnés ci-dessous. Documentation

utilisateur

Une première ébauche des documentations écrites destinées aux utilisateurs finals (guides d'utilisation, texte de l'aide, notes de version, manuels de l'utilisateur et du technicien) est élaborée pendant la phase de construction. Le critère d'évaluation est le suivant : ces documents aideront-ils suffisamment les utilisateurs pendant la phase de transition ? Matériel

y Besoins

\

y> Analyse


Conception

^ Implémentatio^)

Tests

^

S'attachent au développement du système

pédagogique

La phase de construction crée également une première esquisse du matériel pédagogique 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 critère d'évaluation doit permettre de déterminer si la capacité opérationnelle initiale fait preuve d'une maturité et d'une stabilité suffisantes pour que des versions bêta soient distribuées aux utilisateurs, sans exposer ces derniers ni l'organisation responsable du développement à des risques inacceptables.

15.3 Enchaînements d'activités de l'itération typique de construction L'itération typique se compose des cinq enchaînements d'activités, comme l'illustre la figure 15.1. Ces enchaînements d'activités ont, certes, déjà été décrits dans la deuxième partie de cet ouvrage, mais ce chapitre ne s'intéresse qu'au rôle qu'ils jouent dans la construction. Là encore, quatre ensembles d'activités sont en partie menées en parallèle. Le premier de ces ensembles regroupe les enchaînements d'activités principaux ; le deuxième s'attache à la planification des itérations, décrite par les sections 12.4 à 12.7 et par la section 15.2 ; le troisième est celui de l'étude de rentabilité, abordée dans les sections 13.5 et 15.5 ; enfin, le dernier se consacre à l'évaluation, décrites dans les sections 12.8 et 15.6. Nous nous contenterons, dans cette section, de fournir une présentation générale des enchaînements d'activités principaux, sur lesquels nous reviendrons plus en détail dans la section suivante. Les premières itérations de la phase de construction s'attardent davantage sur les premiers enchaînements d'activités, au détriment des enchaînements plus tardifs. L'attention se déplace progressivement tout au long des itérations 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 déplacerait de gauche à droite, à mesure que l'attention se porte vers l'enchaînement d'activités d'implémentation.

Enchaînements d'activités des itérations de construction

Figure 15.1 Le travail d'une itération de la phase d'élaboration traverse les cinq enchaînements d'activités principaux. /.<• reste des besoins est détaillé et analysé, mais la charge de travail de ces deux enchaînements d'activités est relativement légère, l'essentiel du travail ayant été accompli dans les deux phases précédentes. La conception joue un grand rôle, et c'est dans cette phase qu'est effectuée la majeure partie du travail des activités d'implémentation et de tests. (La taille des blocs n 'a qu 'une vocation illustrative et varie selon les projets.)

Construire le système À ce stade, les besoins et l'architecture sont stables. On s'attache avant tout à compléter les réalisations de tous les cas d'utilisation, à concevoir les sous-systèmes et classes requis, à les implémenter sous forme de composants et à les tester à la fois un par un et au sein des constructions. Dans chaque construction, les développeurs prennent un ensemble de cas d'utilisation, tels qu'ils ont été établis par le chef de projet et l'intégrateur système, et procèdent à leur réalisation. Le développement itératif, piloté par les cas d'utilisation et centré sur l'architecture construit le logiciel à travers une série d'incréments de taille relativement modeste qui s'ajoutent, l'un après l'autre, à l'accumulation d'incréments précédente, afin de maintenir en permanence une construction exécutable. Ce type de développement ordonne la séquence d'itérations de façon progressive, de sorte que les constructeurs n'aient jamais à revenir en arrière sui les incréments précédents pour les retravailler. La construction du logiciel par des incréments relativement réduits facilite la gestion du projet. Elle limite la portée des enchaînements d'activités d'analyse, de conception, d'impie mentation et de tests au nombre minimal de questions et de problèmes identifiés dans nu seul incrément. Elle isole les risques, les anomalies et les corrections dans le champ I té d'une construction unique, et en simplifie ainsi la détection et le traitement. Les premières phases ont procédé à la recherche et à la réduction des risques critiques et significatifs, mais la gestion de projet compte encore un grand nombre derisquessur sa I isie

mm


III

En outre, d'autres risques sont susceptibles d'apparaître pendant que les développeurs mènent à bien les constructions et les itérations 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 légitimement 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 découvrir que les anomalies répétées dans les différents tests étaient provoquées par le compilateur. Le projet a encore pris du retard, jusqu'à ce que le fournisseur du compilateur détecte cette subtile anomalie et la corrige.

15.4 Exécuter les enchaînements d'activités principaux : des besoins aux tests Nous avons esquissé, dans la section précédente, le propos général de la phase de construction. Cette section va maintenant présenter plus en détail chacune de ces activités, en prenant pour guide la figure 15.2. Comme dans les chapitres précédents, cette section s'articule autour des cinq enchaînements d'activités. Si le découpage est séquentiel, là encore le travail des différents enchaînements d'activités s'effectue en parallèle, comme le rappelle la figure.

15.4.1

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

Les travailleurs prennent part à ces différents enchaînements d'activités, comme le suggérait la deuxième partie de l'ouvrage. Ils complètent les artefacts de l'architecture de référence ou des dernières itérations. Dans la phase d'élaboration, l'équipe du projet peut avoir conçu et implémente 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 compléter les modèles présentés dans les chapitres 4 et 5 (consulte/, la liguic '> / pour revoir le taux d'achèvement des modèles au fil des quatre phases). Chaque construction et chaque itération apportent leur lot de nouvelles réalisations de cas d'utilisation, de classes de sous-systèmes et de composants, qui viennent s'ajouter à la structure des modèles en evo lufion. Les sous-sections suivantes décrivent les enchaînements d'activités de façon léqui ntli 11 comme l'illustre la figure 15.2, bien que cette séquence ne reflète pas le mode d'inlei v< des différents travailleurs. Par exemple, la planification des lests est effectuée au clél Ii chaque itération, afin de déclencher le travail de test nécessaire à l'itération * lettC planifl cation des tests peut être effectuée avant même de détailler les cas d'utilisation, I.m.ils < la conception et l'implémentation. L'aspect concomitant du travail ne ressortant pas du texte qui suit, nous ne pouvons que rappeler, une fois encore, que les cinq enchaînements d ucli vités se répètent dans chaque itération.

Besoins Après cette introduction à la phase de construction, nous passons à l'identification des cas d'utilisation et des acteurs, au prototypage des interfaces utilisateur, à la description détaillée 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 décrit en détail seulement quelque 20 %, dont on a tiré une proportion encore plus faible (moins de 10 %, qu'il fallait implémenter à ce moment-là), alors suffisante pour établir l'architecture de référence. Dans la phase de construction, bien entendu, le but étant de mettre au point le système opérationnel initial, i l faut absolument achever la formulation des besoins (c'est-à-dire identifier et détailler la totalité de ces besoins). Identifier les acteurs et les cas d'utilisation En général, seule une faible fraction des cas d'utilisation et des acteurs reste à identifier dans la phase de construction (mois de 20 %). L'analyste système actualise, si nécessaire, les cas d'utilisation et les acteurs dans le modèle des cas d'utilisation. Prototyper l'interface utilisateur En règle générale, les phases de création 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 démonstration. Quoi qu'il en soit, i l faut maintenant concevoir les interfaces utilisateur. L'étendue de la tâche dépendra du type de système qu'il s'agit de- cous traire.

a


III

Pour certains systèmes - en particulier ceux dans lesquels certains cas d'ulilisalion exigeai une interface utilisateur extrêmement 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 nécessaire) et le faire tester par les utilisateurs. Ce prototype sera ensuite remodelé en fonction des réactions des utilisateurs, jusqu'à ce qu'il réponde à leurs besoins. La conception de l'interface utilisateur fait partie de l'enchaînement d'activités des besoins et non de celui de conception (malgré ce que son nom peut suggérer) et doit être effectuée avant de passer aux enchaînements d'activités suivants. Le prototype devient ensuite la spécification d'interface utilisateur (pour de plus amples détails, voir le chapitre 7 ) . Pour les systèmes destinés à une large diffusion dans le commerce, i l est indispensable de construire un prototype de l'interface utilisateur, même si celle-ci n'est pas très complexe. Le coût du remplacement d'une interface non satisfaisante sur le terrain serait beaucoup trop important. Assigner un ordre de priorité aux cas d'utilisation Dans la phase d'élaboration, nous avons classé les cas d'utilisation nécessaires au développement de l'architecture de référence. A mesure que sont identifiés les cas d'utilisation dans cette phase, ils s'ajoutent à la liste, classés par ordre de priorité (voir les sections 12.6 et 7 . 4 . 2 ) .

Détailler un cas d'utilisation Les spécificateurs de cas d'utilisation complètent la description détaillée des cas d'utilisation, dans l'ordre d'importance des cas d'utilisation et des scénarios restants. Structurer le modèle des cas d'utilisation L'analyste système peut souhaiter améliorer la structure du modèle des cas d'utilisation. Toutefois, comme le système dispose à ce stade d'une architecture stable, tout changement doit concerner en priorité les cas d'utilisation n'ayant pas encore été traités. Chaque modification d'un cas d'utilisation exige, en effet, une modification de la réalisation correspondante dans les modèles d'analyse et de conception.

15.4.2 Analyse

15.4.3


15

Comme l'indiquait le chapitre 8 (section 8.3), dans certains cas, le modèle d'analyse ne sera pas conservé après la première 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 même jusqu'au bout du projet et au-delà de la durée de vie du produit. Ce dernier cas étant le plus complexe, c'est celui que nous prendrons comme hypothèse. La différence esseniu II. entre les phases d'élaboration et de construction réside dans le fait que la phase de cane, truction complète le modèle d'analyse. Le modèle d'analyse hérité de la phase d'élaboration constituait la vue architecturale : i l s'intéressait dans une large mesure à l'architecture I eu, vue architecturale du modèle d'analyse ne représentera désormais plus qu'une partie du modèle dans son ensemble. La phase de construction aura permis de mettre en plat l II modèle d'analyse complet, dont la vue architecturale n'est qu'un sous ensemble. Procéder à l'analyse

architecturale

L'architecte ayant préparé la vue architecturale du modèle d'analyse a la hn de d'élaboration, i l n'a donc pas grand-chose à faire dans la phase de construction, actualisations nécessitées par les changements concernant l'architecture.

la plia., oulie

les

Analyser un cas d'utilisation Dans la phase d'élaboration, l'architecte n'a utilisé que les cas d'utilisation significatifs pou) l'architecture, qu'il a appliqués à la vue architecturale du modèle d'analyse. Dans chaque itération de la phase de construction, le modèle d'analyse s'enrichit des cas d'utilisation inclus dans cette itération. Analyser une classe Les ingénieurs de composants poursuivent le travail entrepris dans la phase d'élaboration. Analyser un paquetage Dans la phase de construction, l'architecte précise les paquetages identifiés dans la phase d'élaboration en fonction des besoins suscités par les nouveaux cas d'utilisation, tandis que l'ingénieur de composants actualise les paquetages en construction.

Conception Dans cette phase, nous allons concevoir et implémenter les 9 0 % de cas d'utilisation restants, ceux qui n'ont pas servi à développer l'architecture de référence. De nouveau, nous insistons sur le fait que cet enchaînement d'activités et les autres enchaînements se répètent à chaque itération.

Dans cette sous-section, nous allons revenir sur les activités d'analyse architecturale, d'analyse d'une classe et d'analyse d'un paquetage commencées dans la phase d'élaboration. Dans la phase précédente, i l suffisait de prendre en compte les cas d'utilisation significatifs pour l'architecture ou nécessaires à l'élaboration de l'offre commerciale. Pour donner au lecteur une idée du stade auquel on se trouve désormais, i l est probable qu'environ 4 0 % de la masse des cas d'utilisation ont été analysés dans la phase d'élaboration, ce qui représente environ la moitié de la masse des cas d'utilisation (environ 8 0 %) généralement nécessaire à 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 préoccuper de tous les cas d'utilisation, sans nécessairement étoffer en conséquence le modèle d'analyse.

Procéder à la conception

architecturale

Dans la phase de construction, l'architecte n'ajoutera, en règle générale, aucun sous-system, de conception ou de service. Ces éléments existent déjà dans l'architecture de référence, au moins sous une forme minimale. L'architecte peut éventuellement ajouter des sous-systèmes, s'ils sont équivalents ou cousu tuent des solutions de rechange à ceux qui sont déjà en place. Par exemple, s ' i l existe un sous-système pour un protocole de communication et que l'architecte ajoute un autre pio


tocole de communication ne nécessitant pas d'autres interfaces, il sera plus pratique de ci en un autre sous-système pour ce second protocole. Le comportement d'un sous-système de service peut généralement être dérivé de certaines parties d'un même cas d'utilisation ou d'un ensemble de cas d'utilisation liés les uns aux autres. On pourrait aussi formuler cette idée en disant qu'un sous-système de service joue un rôle dominant pour la réalisation d'un unique cas d'utilisation. Entre 40 et 60 % des responsabilités d'un sous-système 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 compléter les 20 % restants du sous-système de service dans la même construction ou s'il vaut mieux les laisser à une construction ultérieure. E peut être judicieux d'en autoriser tout de suite l'achèvement, alors même que les autres parties de ce sous-système sont empruntées à des cas d'utilisation classés à un niveau inférieur par rapport au cas d'utilisation dominant. Même si ces cas d'utilisation présentent un niveau de priorité inférieur et peuvent, de ce fait, être reportés, il sera peut-être plus efficace de finaliser le paquetage au moment où il entre en jeu.

15.4.4


15

l'autre tout au long du cycle de développement et transmis aux cycles futurs. Le modèle de conception est le « plan d'élaboration et de construction » du modèle d'implémentation et de l'implémentation elle-même.

Implémentation En partant essentiellement du modèle de conception, cet enchaînement d'activités impie mente tous les composants, auxquels il fait également subir les tests unitaires. Il d é b o m lie. après un certain nombre d'itérations, d'intégrations et de tests du système, sm la v,a •a,u, opérationnelle initiale, qui représente 100 % de la masse des cas d'utilisation. ( 'elle |0UI section aborde les activités d'implémentation architecturales, d'impléttientalion d'une , h . et d'un sous-système, de réalisation des tests unitaires et d'intégration du système C'est dans cet enchaînement d'activités qu'est effectuée 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 itérations, jusqu'à ce que, à la fin de la phase, tous l e s , (imposants soient « remplis ».

D'un côté, l'exploitation de cas d'utilisation de moindre priorité à ce stade permet à l'ingénieur de composants de développer tout le sous-système d'un coup. Il a donc plus de chances de le structurer correctement, puisqu'il l'a examiné en totalité. Si l'ingénieur de composants, ou un autre intervenant, doit revenir sur le sous-système dans une construction ultérieure pour exploiter le reste des cas d'utilisation de moindre priorité, il peut découvrir des divergences nécessitant un changement de toute la conception. Il est possible qu'il ait à réécrire le code parce qu'il ne s'articule pas bien avec le code issu des cas d'utilisation de moindre priorité. 11 est donc souhaitable d'inclure dans le sous-système des parties de cas d'utilisation devant être conçus plus tardivement si - et la précision est importante - on connaît d'avance l'impact qu'elles auront. Pourquoi ? Parce qu'il est préférable de finaliser un travail en une fois, plutôt que de le disséminer sur plusieurs itérations. D'un autre côté, l'exploitation des cas d'utilisation de moindre priorité dans une construction du début va à rencontre de notre philosophie générale, qui consiste à examiner en premier les cas d'utilisation de haute priorité. La règle générale est la suivante : s'il vous semble plus pratique de traiter quelques cas d'utilisation de faible priorité en même 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 : créer la bonne conception et ne pas implémenter ni tester tous les cas d'utilisation de faible priorité. Le chef de projet doit reporter ces tâches (conception, implémentation et test des cas d'utilisation de moindre priorité) à une cous traction ultérieure, où leur niveau de priorité les place naturellement. L'architecte améliore la vue architecturale des modèles de conception et de déploiement afin qu'elle reflète l'expérience acquise au cours de la phase de construction. Toutefois, comme il a généralement achevé l'architecture à la fin de la phase d'élaboration, i l se contente cette fois de l'actualiser. Pour une évocation des autres activités de cet enchaînement d'activités (conception des cas d'utilisation, des classes et des sous-systèmes), reportez-vous au chapitre 9. Inutile de préciser ici que la conception est l'une des préoccupations majeures (moins, toutefois, que l'implémentation) de la phase de construction, comme l'indique la figure 15.1. Elle donne lieu aux modèles de conception et de déploiement, conservés l'un et

Procéder à l'implémentation

architecturale

A ce stade, l'architecture est fermement établie. Le rôle de l'architecte, en dehors d'une sm veillance continue, se limite à quelques actualisations, si nécessaire. Implémenter une classe et implémenter un

sous-système

Les ingénieurs de composants implémentent les classes et les sous-systèmes dans le modèle d'implémentation. Ils implémentent également les classes représentées par des stubs nécessaires à l'élaboration des constructions. Effectuer les tests unitaires L'ingénieur de composants est chargé d'effectuer les tests unitaires sur les composants qu'il réalise et d'en corriger, si nécessaire, la conception et l'implémentation. Intégrer le système L'intégrateur système crée un plan de construction de l'intégration traçant les grandes lignes de la séquence de constructions. Ce plan présente les cas d'utilisation ou scénarios de cas d'utilisation que doit implémenter la construction et qui aboutiront aux sous-systèmes et composants. Les intégrateurs système préfèrent souvent commencer la construction par les couches inférieures de la hiérarchie d'une architecture en couches, comme les couches de logiciel système et de middleware (illustrées par la figure4.5). Les constructions suivantes é l u d e n t le système en allant vers le haut, en direction de la couche générale aux applications et de la couche spécifique à l'application. U est difficile d'assembler une construction sans que lei fonctions de prise en charge fournies par les couches inférieures soient en place. Par exemple, le département informatique d'une société de produits chimiques prévoyait dt réaliser en moyenne un incrément tous les quinze jours. On prétend que les projets 'le Microsoft Corporation livrent une construction par jour à partir du moment où du code a é t é

Un d é v e l o p p e m e n t itératif et i n c r é m e n t a l


fabriqué. Chaque construction est soumise à des tests (tests sur les éléments ajoutés et tests de non-régression sur le code déjà en place) pour s'assurer que le code en cours de développement fonctionne bien. Ce processus de refabrication quotidienne verdie chaque jour que les unités de code insérées (par un « check-in ») depuis la veille sont bien compatibles. Si cette pratique exhorte fermement les développeurs à ne pas « casser la construction », elle réduit toutefois la pression à long terme pesant sur l'organisation chargée de la réalisation du projet, puisque les problèmes d'intégration sont détectés au cours des tests, effectués en principe chaque soir, et résolus immédiatement après. Malgré les apparences, la création quotidienne d'une construction n'inflige pas forcément une contrainte insupportable à une équipe de projet. Les développeurs intègrent leur code (par un « check-in ») lorsqu'ils estiment qu'il est prêt. Inutile d'intégrer du code instable : on risquerait de briser la construction. La pression est tout de même présente, et chaque développeur doit intégrer son code en temps et en heure afin de rester conforme au plan de construction de l'intégration. La durée de chaque période de construction est laissée à l'appréciation de chaque organisation de développement. Le principe est de livrer des constructions à un rythme suffisamment soutenu pour bénéficier des avantages liés aux constructions fréquentes. Pour que chaque construction se maintienne dans des proportions modestes, l'intégrateur système a souvent recours à un stub ou à un pilote pour représenter un composant qui n'est pas encore construit. Un stub est un élément très simple qui se contente de donner une réponse à 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 même, 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 supplémentaires. L'intégrateur système 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 découvertes dans le plan de construction de l'intégration, en montrant à quel moment doit intervenir chaque construction pour respecter le calendrier de l'intégration et des tests. I l rassemble les classes complètes et les classes représentées par un stub en une construction exécutable, en accord avec le plan de construction. I l élargit le champ des refabrications successives, et charge les testeurs d'intégration de leur faire subir les tests d'intégration et les tests de non-régression. Dans l'étape finale de chaque itération, puis dans celle de la phase elle-même, l'intégrateur système lie le système dans son ensemble, qui subit ensuite les tests d'intégration et les tests de non-régression. Cette planification séquence l'ordre des constructions dans chaque itération et l'ordre des itérations au sein de la phase de construction. Les couches supérieures d'une architecture en couches entretenant souvent des dépendances de compilation avec les couches inférieures, i l est possible que les intégrateurs système doivent planifier la compilation de bas en haut.

15.4.5 Tests

15

une des principales activités de la phase, comme l'indique la figure 15.1. Si la responsabillti de mener les tests unitaires revient aux ingénieurs de composants, les ingénieurs de testl fournissent, pour leur part, une assistance technique. Mais ce sont bien les ingénieurs d. composants et leurs collaborateurs (le testeur d'intégration et le testeur système) qui soin chargés de tester les constructions, c'est-à-dire les incréments livrés par chaque itération puis la construction finale, qui constitue le système entier. Planifier les tests Les ingénieurs de tests sélectionnent les objectifs permettant de tester les construi cessives et, finalement, le système lui-même.

Ui

Concevoir les tests Les ingénieurs de tests trouvent un moyen de tester les besoins dans l'euscmbli di tractions afin de vérifier tous ceux pouvant être testés. Ils échafaudeni, dans ce but ili . c i e . e i des procédures de test. Parmi les cas et les procédures de test des constructions pic. edeuli ils sélectionnent ceux qui restent pertinents et les modifient de façon a soumettre les corn tructions successives à des tests de non-régression. Ils vérifient les composants devanl I tn testés ensemble, selon la planification établie au départ. L'objectif de ces tests d'intégration est de vérifier les interfaces entre les composants testés et de s'assurer que les composant! fonctionnent ensemble. Effectuer les tests

d'intégration

Les testeurs d'intégration exécutent les cas de test, suivant les procédures de test appropriées. Lorsque la construction réussit les tests, l'intégrateur système ajoute d'autres constructions, au fur et à mesure de leur disponibilité, que le testeur d'intégration peut continuer à tester. Lorsque les tests d'intégration détectent des défaillances, les testeurs les consignent et en informent le chef de projet. Celui-ci (ou son représentant, qui peut être l'intégrateur système puisqu'il dispose des connaissances techniques pertinentes) détermine l'étape suivante. I l peut être décidé, par exemple, d'approfondir le travail au sein de cette même construction, de reporter la correction à l'étape suivante ou, en particulier dans le cas d'une défaillance particulièrement grave, d'affecter des personnes spécialement qualifiées pour pousser les investigations. A la fin de la dernière itération de la phase de construction, le testeur système teste la version opérationnelle initiale. De nouveau, i l rend compte des défaillances au chef de projet, qui attribuera à l'ingénieur de composants responsable la tâche de les corriger. Évaluer les tests Les ingénieurs de tests vérifient progressivement les résultats des tests d'intégration cl des tests système à la fin de chaque construction, à la lueur des objectifs fixés au dépari dans le plan des tests (éventuellement modifié par les itérations ultérieures). 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 procédures de test concernés devront être modifié! en couse quence (voir la section 11.5.6).

, Les efforts entrepris par les ingénieurs de tests pour découvrir ce qui peut être efficacement testé et pour mettre au point les cas de test et les procédures permettant de réaliser ces tests, comme le décrit le chapitre 11, portent leurs fruits dans la phase de construction. C'est là


15.5 Maîtriser l'étude de rentabilité

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.7 Planifier la phase de transition

En revanche, les retours obtenus - risques, problèmes, pannes, suggestions - sont plui dlffl ciles à prévoir. Si une équipe a déjà quelque expérience des tests bêta, elle saura à peu pies a quoi s'attendre. Elle pourra alors estimer le nombre approximatif de personnes d'expérienOl qu'il faudra affecter à la prise en charge des problèmes mis au jour par les testeurs de In version bêta.

Le nombre de lignes de code réalisées constitue rarement une bonne mesure de la progression d'un développement basé sur les composants. L'un de ses objectifs étant de réutiliser des classes et des composants, un ingénieur de composants et d'autres travailleurs peuvent progresser rapidement dans les constructions et les itérations en écrivant très peu de code. L'achèvement des constructions et des itérations par rapport au plan représentera, dans ce cas, une mesure bien plus fiable des accomplissements réels.

L'équipe du projet ne peut s'attendre à planifier à l'avance la phase de transition de manière aussi détaillée que les phases précédentes. Les membres de l'équipe savent, bien entendu, qu'ils vont livrer pour évaluation des versions bêta (ou l'équivalent) à des utilisateurs sélectionnés. Cette partie de la phase - la sélection des utilisateurs, la reproduction du code de fonctionnement, la préparation des instructions de tests, etc. - peut être planifiée assez précisément.

L'un des propos de l'offre commerciale, préparée à la fin de la phase d'élaboration, est de servir de guide au chef de projet et aux intervenants dans l'exécution de la phase de construction. A cette fin, le chef de projet compare la progression réelle à la fin de chaque itération avec le calendrier, les efforts et le budget prévisionnels. Il revoit les données concernant la productivité du projet, la quantité de code établi, la taille de la base de données, ainsi que d'autres métriques.

Les divergences de plus de quelques pour cent, en particulier dans le sens négatif, doivent conduire le chef de projet à prendre des mesures correctives, tandis que des écarts plus importants commandent de réunir les différents intervenants. À mesure que le chef de projet affine sa connaissance du coût et des possibilités du produit au cours de la phase de construction, il peut estimer nécessaire d'actualiser l'étude de rentabilité et d'en communiquer la nouvelle version aux intervenants.

15.6 Évaluer les itérations et la phase de construction

15.8 Principaux éléments à livrer Les éléments à livrer sont les suivants : • le plan du projet pour la phase de transition ; • le logiciel exécutable lui-même : la version à capacité opérationnelle initiale. Il s'agit de la dernière construction de la phase de construction ; • tous les artefacts, y compris les modèles du système ; • une description de l'architecture entretenue et actualisée de façon minimale ;

L'objectif, c'est que les éléments à livrer qualifiés de complets le soient vraiment. Le fonctionnement du logiciel au sein de l'environnement utilisateur dans la phase de transition peut faire apparaître certaines erreurs dans ces éléments livrés. Ils devront donc être modifiés en conséquence.

• choisissent l'itération ultérieure à laquelle devra être reporté le travail non achevé ;

• l'étude de rentabilité reflétant la situation à la fin de la phase.

• comparent ce qui a été accompli au cours d'une itération à ce qui était prévu ;

• un premier manuel de l'utilisateur suffisamment détaillé pour guider les testeurs de la version bêta ;

Sur la base d'une révision des résultats des tests et d'autres critères d'évaluation, tels que ceux décrits dans la section 15.2.2, le chef de projet et un groupe d'évaluation :

• déterminent si la construction est prête ou non à passer à l'itération suivante ; • actualisent la liste des risques ; • complètent le plan de l'itération suivante ; • mettent à jour le plan des itérations venant après l'itération suivante ; • déterminent, à l'issue de la dernière itération de la phase, si le produit a passé avec succès les tests système et atteint sa capacité opérationnelle initiale ; • autorisent le passage à la phase de transition ; • actualisent le plan du projet.

16 La phase de transition finalise le produit Au moment où le projet entre en phase de transition, le système a atteint sa capacité opérationnelle initiale. Le chef de projet a jugé le système suffisamment fiable pour le faire fonctionner dans l'environnement utilisateur, bien que la perfection ne soit pas exigée. I l est possible, par exemple, que des problèmes, des risques et des anomalies non détectés lors des tests système, à la fin de la phase de construction, fassent leur apparition dans l'environnement utilisateur. I l se peut également que les utilisateurs découvrent tardivement qu'ils ont besoin de certaines fonctions. Si ces fonctions sont vraiment importantes et cohérentes avec le produit existant, le chef de projet peut accepter de les ajouter. Ces changements doivent, néanmoins, rester modestes, et leur introduction ne doit pas avoir d'impact sérieux sur le plan du projet. Si une fonction suggérée a un retentissement non négligeable sur le calendrier de développement, il faut s'assurer qu'elle est vraiment indispensable. Nous estimons qu'il est préférable, dans la plupart des cas, d'inscrire ce type de suggestions dans la liste des caractéristiques et de les reporter au cycle de développement suivant, c'est-à-dire au développement de la nouvelle version du système. Cette phase poursuit deux objectifs principaux : • répondre aux besoins, tels qu'ils ont été établis dans les phases précédentes, à la satisfaction des intervenants ; • gérer toutes les questions conditionnant le fonctionnement dans l'environnement utilisateur, y compris la correction des anomalies rapportées par les utilisateurs de la version bêta ou par les responsables des tests d'acceptation. Les tests d'acceptation incombent au client, qui peut toutefois les sous-traiter à une société spécialisée dans ce type de tests.


16.1 La phase de transition en bref La phase de transition s'attache à installer le produit dans l'environncmenl opérationnel. I a manière de procéder 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 bêta à des utilisateurs typiques répartis sur des sites « clients bêta » représentatifs. 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 opérationnels afin de : • vérifier si le système offre véritablement les services exigés par les entreprises et leurs utilisateurs ; • découvrir des risques non perçus ; • prendre acte de problèmes non résolus ; • détecter des défaillances ; • lever des ambiguïtés et combler des manques dans la documentation destinée 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 système ou les artefacts qui lui sont associés et prépare les phases suivantes de production, emballage, déploiement et lancement du système d'une manière générale. Dans cette phase, i l ne s'agit pas de chercher à reformuler le produit : les modifications importantes des besoins doivent avoir été intégrées par l'équipe du projet et par le client dans des phases antérieures. L'équipe recherche ici les déficiences mineures négligées dans la phase de construction et qu'il est possible de corriger dans le produit de référence existant. 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 parallèle le nouveau système et celui qu'il remplace, et à convertir les anciennes bases de données dans la nouvelle configuration. Dans le cas de produits destinés à de nombreux utilisateurs (le marché du « sous blister »), ces services sont inclus dans le programme d'installation proposé avec le produit et complétés par le service d'assistance aux clients. La phase de transition s'achève par la sortie du produit. 1. On peut mentionner deux autres possibilités : les tests alpha et la validation par des tiers. Les tests alpha sont semblables aux tests bêta, outre le fait qu'ils sont conduits au sein de la société développant le logiciel - en dehors, toutefois, du département de développement logiciel lui-même. Les personnes effectuant les tests alpha sont de véritables utilisateurs. Dans la validation par des tiers, une société spécialisée dans les tests mène des tests d'acceptation dans le cadre d'un contrat avec le client.

La phase de transition finalise le produit mm CHAPITRE

16

lai

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 détails, regrouper sous deux principaux archétypes : Développement par un éditeur logiciel d'un produit destiné à un marché Ce marché peut être très important, comme celui des ordinateurs personnels, ou plus rei treint, comme dans la production de composants réutilisables destinés à des éditeurs de pto grammes préfabriqués adaptables à chaque installation. Quelle qu'en soit la taille, ce type de marché génère une relation un-à-plusieurs (un éditeur pour de nombreux clients), qui influence le travail de la phase de transition. Développement par une SSII sous contrat avec un client unique Ce modèle se décline en plusieurs variations. Par exemple : • une société de développement travaillant pour un seul client sur un seul site , • une société de développement travaillant pour un client ayant un gi and noinhie d ,,y> tu • et de sites ; • une société de sous-traitance, telle qu'EDS, Computer Science ou Andersen < 'onsulling, développant pour un client unique un logiciel qu'elle adapte ensuite à d'autres sites ou clients ; • une structure de développement interne mettant au point des logiciels pour d'autres départements de la même entreprise dans le cadre d'un accord comptable spécifique. La relation entre la structure de la phase de transition et l'utilisateur ou le client varie en fonction de ces différents contextes. Elle débute, dans ces conditions, par une version opérationnelle initiale ayant subi des tests système 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 supplémentaires, comme des scripts d'installation, des programmes de conversion ou de migration des données, ou modifie ceux produits dans la phase de construction afin de préparer ce programme exécutable à franchir ses propres frontières.

16.2.1 Planifier la phase de transition Une équipe de projet ne peut guère espérer planifier la phase de transition à l'avance et très en détail comme elle a pu le faire avec la phase de construction. D'un côté, le chef de projet sait que cette phase va livrer à un certain nombre d'utilisateurs sélectionnés une version bêta (ou l'équivalent) mise au point dans la phase de construction, qui sera ainsi soumise à des tests. Cette certitude forme le fondement des premières planifications de la phase de transition. La production de cette version bêta suppose un certain volume de travail, notamment la rédaction de la documentation accompagnant les tests bêta, la sélection des utilisateurs bêta, etc. D'un autre côté, les retours provenant de ces tests vont générer 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 résolution des problèmes de transition.


En planifiant la phase de transition, le chef de projet s'attend à ce que la version opérai ion nelle initiale issue de la phase de construction nécessite quelques ajustements mineurs en retour des tests bêta. En fait, si le projet a été mené de façon itérative, ce sera le cas. Ce processus de développement permet en effet aux développeurs de faire des essais dés les premières phases et de détecter les erreurs de conception grâce aux tests menés sur les incréments du début et à l'observation de leur fonctionnement. De même, les erreurs évidentes doivent être localisées et corrigées construction après construction à mesure qu'avance le développement. En clair, i l est profitable de faire des retouches dès le début. Dans la phase de transition, à la suite d'un développement itératif, ces retouches ne doivent pas dépasser 5 %. Les chefs de projet doivent quand même s'attendre à un certain volume de retouches. I l y a toujours des omissions et des erreurs qui passent à travers toutes les vérifications. Les raisons énoncées ci-dessous peuvent conduire une équipe à sous-estimer la charge des retouches à prévoir : • une pression trop forte sur les délais, donnant lieu au syndrome du « vite fait, mal fait » , • l'absence de tests système adaptés et d'évaluation à la fin de la phase de construction ; • l'incapacité à se concentrer sur le travail considérable restant à fournir dans la phase de transition ; • la croyance que le simple fait d'envisager le besoin de retouches risque d'en provoquer la matérialisation ; • la tendance à considérer les retouches comme « négatives », aveu d'une incompétence de l'équipe du projet. La question du logiciel « bien assez bon » ou non peut surgir dans la planification de la phase de transition. C'est une réalité 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é reportée à une version ultérieure, et enfin les utilisateurs bêta 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 « réponses » à la question du logiciel « bien assez bon ». Premièrement, les phases et les itérations du Processus unifié visent à identifier les risques, à formuler les besoins précis et à planifier le projet en conséquence. Dans le Processus unifié, l'équipe du projet effectue ces tâches en coordination avec les utilisateurs et les clients, si bien que la version opérationnelle initiale (ou version bêta) s'approchera logiquement de ce qu'attendent les développeurs et les intervenants. Deuxièmement, comme ni l'équipe du projet ni les intervenants ne s'attendent à ce que la version opérationnelle initiale ne présente aucun défaut, ils prévoient quelques délais et ressources pour la phase de transition.

16.2.2 Constituer l'équipe

La phase de transition finalise le produit CHAPITRE

16

p a e m

423

de la phase de transition

L'objectif de cette phase étant de livrer une version aux utilisateurs, à des fins de tests bêla 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 légèrement différents. Analyser les retours de tests bêta ou de tests d'acceptation et tenter d'y apporter une réponii peuvent requérir l'intervention de personnes plus orientées vers les services que rompue', au développement à proprement parler. Pour juger des mérites d'un amélioration, même mineure, il faudra peut-être s'entourer d'experts spécialistes non seulement du s y s i e m e dans son ensemble, mais aussi de la nature même de l'application à laquelle il est destiné I >< même, lorsque les tests ne font que détecter les anomalies, il faut parfois l'aire preuve d'une exceptionnelle perspicacité pour les repérer dans l'ensemble du système ou ; oins dans la partie du système d'où elles semblent provenir. De plus, les documentations destinées au utilisateurs et les supports de formation, bien que mis en chantier dans la phase de i oie. truction, ont souvent besoin d'être réécrits par un rédacteur 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 préserver l'intégrité de l'architecture et, parfois (mais rarement), pour prendre en considération des modifications architecturales mineures.

16.2.3 Définir

les critères

d'évaluation

À la fin de la phase de construction, à l'issue des tests système, on a estimé que le produit offrait la capacité opérationnelle initiale ou, en d'autres termes, qu'il répondait aux conditions de la spécification des besoins. Pour la phase de transition, seules sont évaluées les questions émergeant dans cette phase. Elles sont, globalement, de cinq types. 1. Les utilisateurs de la version bêta ont-ils abordé les fonctions clés, par exemple celles représentées par tous les cas d'utilisation et impliquées dans le fonctionnement réussi du produit sur le terrain ? 2.

De même, le produit a-t-il passé avec succès les tests d'acceptation menés par le client ? Les critères de ces tests sont fixés par le contrat liant la structure de développement et le client. En outre, les tests d'acceptation exécutent en général le logiciel en mode de production pendant une période de temps déterminée d'un commun accord.

3. La documentation destinée aux utilisateurs est-elle d'un niveau de qualité acceptable ?

Enfin, les clients semblent-ils satisfaits du produit ? Nous commenterons plus longuement cette question dans la section 16.4.6.

5.

Les supports de formation (y compris les instructions à l'attention du formateur, s'il y en a) sont-ils prêts à l'emploi ?

4.

Enfin, l'application des deux premières « réponses » par l'équipe du projet en coopération avec les intervenants peut se traduire par une extension de la phase de transition ou par un report du travail imprévu au cycle de développement suivant.


16.3 Les enchaînements d'activités principaux jouent un rôle mineur dans cette phase Comme le montre la figure 16.1, l'activité est relativement faible dans les cinq enchaînements 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 modéré : i l suffira de corriger les problèmes détectés par les tests menés dans l'environnement utilisateur (pour de plus amples détails, voir la section 16.4). On ne doit pratiquement rien avoir à faire dans les enchaînements d'activités des besoins, d'analyse et de conception. Normalement, les activités de conception sont en recul dans la phase de transition. Tout au moins ne vont-elles guère au-delà de simples améliorations destinées à corriger problèmes ou anomalies, ou à effectuer des modifications (en principe, mineures) de dernière minute. I l s'agit, dans cette phase, de corriger les anomalies afin d'éliminer les défaillances entravant les premières utilisations, de s'assurer que ces corrections elles-mêmes sont valables, et de procéder à des tests de nonrégression pour vérifier que les corrections n'ont pas introduit de nouvelles anomalies. Ressources


16

_m

L'itération archétypale se compose des cinq enchaînements d'activités abordés dans les chapitres précédents. Dans ce chapitre, nous ne nous intéressons qu'au rôle que chacun d'eux joue dans la phase de transition. Plus généralement, quatre ensembles d'activités sont en parties menés en parallèle. Le premier de ces ensembles regroupe les enchaînements d'actl vités principaux ; le deuxième s'attache à la planification des itérations, décrite par lis sections 12.4 à 12.7 ; le troisième est celui de l'étude de rentabilité, abordée dans lu section 16.5 ; enfin, le dernier se consacre à l'évaluation, décrite dans les sectionl I et 16.6. Dans cette section, nous nous contenterons de fournir une présentation reneialc d, enchaînements d'activités principaux, sur lesquels nous reviendrons plus en détail due l i section suivante. 1

16.4 Activités de la phase de transition Les activités de transition s'articulent autour des axes suivants : • préparation de la véritable version bêta (ou des tests d'acceptation) a partir de la (de capacité opérationnelle initiale) issue de la phase de construction ;

veision

• installation (ou planification de l'installation) de cette version sur le site, avec réalisation d'activités sur le site, comme la migration des données de l'ancien système ; • 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 ; Analyse

Conception

_» Implémentation/»

Tests

Enchaînements d'activités principaux

S'attachent à ta livraison d'une version au client Enchaînements . d'activités des itérations de transition

Figure 16.1 Le travail d'une itération

identifiées,

d'activités

et de tests apparaissent au premier plan dans cette phase. C'est là que sont

corrigées

et retestées

principaux. (La d'activités détectées,

les anomalies mises au jour par les tests bêta et les tests d'acceptation.

Dans

de refaire une partie de la conception pour corriger ces anomalies, ce qui conduira

en revanche, reste pratiquement

d'activités

• détermination de l'achèvement du projet. Les détails de cette séquence d'activités 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 sélection et l'accompagnement des utilisateurs bêta représenteront une tâche considérable. En plus, en tant qu'utilisateurs réels, les personnes désignées 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 découvertes. Dans le second cas, le client sélectionnera probablement un site pour l'installation initiale, et les tests d'acceptation qui y seront menés suivront une procédure formelle, systématique et résultant d'un accord commun. Si des problèmes dépassant la portée du contrat en cours surgissent, les parties s'accordent sur un contrat de suivi.

de la phase de transition traverse les cinq enchaînements

taille des blocs n 'a qu 'une vocation illustrative et varie selon les projets.) Les enchaînements d'implémentation

certains cas, il sera nécessaire

à une légère augmentation de l'enchaînement

de conception. L'enchaînement

d'activités

des besoins,

inchangé.

Le déroulement des activités variera également selon que le produit sera le premier du genre (green-field) ou l'amélioration d'un produit existant ou semblable. Là encore, l'organisation chargée du développement sera amenée à adapter le processus aux circonstances auxquelles elle sera confrontée, comme nous l'avons expliqué dans le chapitre 2.

16.4.1 Livrer la version

bêta

La plupart des membres du premier cercle d'utilisateurs choisis pour les tests bêla (ou d'acceptation) seront des personnes expérimentées. L'équipe de transition demande a < i personnes de travailler en s'aidant d'une documentation relativement sommaire, mais [eut


fournit en revanche des instructions précises pour le compte rendu de leurs observations et des découvertes issues des tests. Très tôt dans la phase de transition, l'équipe du projet rassemble les documentations rédigées précédemment dont les utilisateurs bêta ou les testeurs d'acceptation auront besoin. Ces documentations sont complétées par des instructions bêta spécifiques. Enfin, l'équipe sélectionne les utilisateurs bêta, auxquels elle distribue la version bêta et toute documentation l'accompagnant.

16.4.2 Installer la version

bêta

Les activités menées sur le ou les sites de tests divergent selon qu'on se livre à des tests bêta ou à des tests d'acceptation. Les tests bêta se déploient généralement sur un grand nombre de sites, sur lesquels l'équipe de transition n'est pas présente. L'équipe doit émettre des instructions spécifiques sur la procédure d'installation du logiciel, son mode d'utilisation, les questions/problèmes sur lesquels doivent s'attarder les clients et utilisateurs bêta, et les règles à suivre pour rendre compte des anomalies ou problèmes détectés. 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 données ou sur la conversion des bases de données vers la nouvelle version. Le cas échéant, ces instructions doivent également prévoir le fonctionnement en parallèle de la version bêta et de l'ancienne version pendant une certaine durée. En revanche, dans le cas de tests d'acceptation, les membres concernés de l'équipe du projet seront sans doute présents. Un document formel indiquera les modalités de ces tests d'acceptation et sera complété par des communications informelles. Les anomalies et les problèmes seront corrigés sur place, si possible, ou renvoyés aux membres du projet possédant les compétences nécessaires.

16.4.3 Répondre

aux résultats

des

tests

L'équipe du projet recueille et analyse les résultats des tests afin d'envisager des mesures correctives. Ces résultats se répartiront vraisemblablement en deux catégories : d'un côté, les anomalies de code mineures, qu'il suffira de repérer et de corriger (bien que cela puisse être assez compliqué dans certains cas) ; de l'autre, les problèmes plus importants, susceptibles d'avoir de larges ramifications et de conduire à une modification de l'architecture. Défaillances - Une défaillance résulte en première instance d'une anomalie dans un composant. Mais i l faudra peut-être rechercher l'origine de cette anomalie dans un défaut de la conception, de l'analyse ou même d'un modèle antérieur. Si cette recherche se révèle difficile, l'équipe de transition devra peut-être faire appel à l'ingénieur de composants ou à d'autres personnes ayant effectué les premiers travaux dans ce domaine. Quoi qu'il en soit, une personne compétente doit corriger cette anomalie, qui doit de nouveau subir des tests système et des tests de non-régression réalisés 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 liée à d'autres anomalies non encore détectées ? • Peut-elle être corrigée sans que cela affecte l'architecture ou la conception ? • Sa correction n'a-t-elle introduit aucune autre anomalie ?

Problèmes de plus grande


16

K

envergure

Certaines des difficultés mises au jour par les tests bêta peuvent requérir une intervention plus importante qu'une simple correction d'anomalie, voire imposer une itération supplé mentaire, à l'issue des tests. Elles peuvent aussi suggérer des changements, des améliora fions ou des caractéristiques devant être gérées formellement (par exemple, pat l'intermédiaire d'un Bureau de contrôle des changes). Nous ne pouvons qu'insister, dans t. cas de figure, sur l'importance qui doit être accordée à la gestion de la configuration a mesure que sont implémentées ces modifications. Comme nous l'avons déjà dit auparavant les changements substantiels, de nature à dépasser les moyens disponibles, à iclardei l.i livraison ou à modifier l'architecture, doivent être, dans la mesure possible, repoi les au ev> li de développement suivant. I l reste essentiel de préserver l'intégrité architecturale du système pendant la COTTOI don de! problèmes 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 problème! I des anomalies respectent l'architecture. L'architecte (ou l'équipe d'architecture) vérifie que la prise en compte des problèmes n'est pas « expédiée », d'une façon qui pourrait être d o m mageable à l'architecture. Il faudra, pour parvenir à ce but, procéder à quelque ajustement de l'architecture. Si les activités de cette phase affectent l'architecture, la description devra en être actualisée par l'architecte. 1

Bien sûr, peu d'organisations de développement livrent des produits parfaits. C'est dans cet esprit que le chef de projet doit estimer les coûts et les retards qu'entraîneront certaines retouches et les intégrer dans l'étude de rentabilité.

16.4.4 Adapter le produit aux divers environnements

utilisateur

Comme nous l'avons indiqué plus haut, les organisations de développement livrent des produits dans deux contextes relationnels différents : les produits du marché (relation un-à-plusieurs) et ceux destinés à un client unique (relation un-à-un). L'une et l'autre de ces relations peuvent entraîner la nécessité de faire migrer des données ou de convertir des bases de données d'un système ancien vers le nouveau système. Relation avec le marché Le marché peut regrouper un ensemble extrêmement diversifié de contextes, pour lesquels l'équipe doit mettre au point différentes versions d'un programme exécutable. Parmi ces variantes, citons le pays, la langue, l'unité monétaire et autres unités de mesure. Si le produit doit s'exécuter sur différents nœuds opérationnels au sein d'un réseau, i l faudra peut-être le modifier pour chacun de ces nœuds. Comme les utilisateurs de la première version générale seront probablement moins expét i mentes que les utilisateurs de la version bêta, i l faudra que l'équipe étoffe la documentation des tests bêta pour l'adapter aux besoins des utilisateurs lambda. Les produits distribués sur le marché sont généralement installés par l'utilisateur ou pai l'administrateur système d'une société. Parfois, c'est un fournisseur local qui se charge de l'installation. L'équipe prépare les procédures d'installation et un script d'aide en ligne. < 'es procédures peuvent être relativement complexes, notamment dans les cas où le produit doit


être installé sur un certain nombre d'ordinateurs personnels ou de stations de travail reliés par un réseau intranet. Elles le sont encore plus lorsque certaines parties du produit sont installées sur différents nœuds qui doivent être montés d'une façon précise. Différents types de nœuds peuvent nécessiter différentes procédures d'installation. Relation avec un client unique La livraison d'un système à un client unique dans le cadre d'un contrat suit à peu près le même modèle que celui décrit ci-dessus, à quelques différences près. • Des représentants du client ont probablement participé aux phases antérieures et fourni des retours sur les incréments. • Ils ont observé les derniers tests système effectués dans les locaux du fournisseur de logiciel. • Ils ont pu participer à des séances d'évaluation constatant la réussite du jalon de construction.


16

429

• renforcer les explications figurant dans l'aide en ligne, notamment les informations guidant les utilisateurs confrontés à des installations infructueuses.

16.4.5 Finaliser les

artefacts

La phase de transition ne s'achève pas tant que l'équipe du projet n'a pas finalisé tous les artefacts, y compris les modèles et la description de l'architecture. Nous insistons notamment sur le fait que l'ensemble des modèles doit être complet dès 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 itérations et les phases successives, comme le décrit la section 12.8.4. Il sera amendé, si nécessaire, dans la phase de dans A la fin de cette phase, nous vérifierons, par l'utilisation réelle du produit, que tous les an. facts sont cohérents les uns avec les autres.

16.4.6 Quand le projet se termine-t-il ?

Dans le cas de produits destinés à être commercialisés, le chef de projet conclut que la grande majorité des clients seront satisfaits lorsque le projet aura tenu compte des retours des tests bêta. À ce stade, une version générale est émise. Dans la plupart des cas, bien sûr, l'environnement et le produit continuent à évoluer, mais l'organisation logicielle répond à cette évolution dans les versions suivantes ou, en cas de changement majeur, par un nouveau cycle de développement. Comme les produits réussis et les systèmes personnalisés évoluent généralement vers des révisions mineures, puis majeures, le projet, en ce sens, ne prend jamais réellement fin. La phase de transition se termine lorsque l'équipe du projet cède la responsabilité de la maintenance continue à un organisme de support.

• Des représentants du fournisseur ont observé le déroulement des tests d'acceptation et ont peut-être effectué des corrections sur place lorsque c'était possible. Dans le cas de problèmes plus délicats, ils ont rendu compte de la situation à leur société afin d'obtenir l'assistance d'experts dans la réalisation des changements ou des corrections.

La phase de transition prend fin non seulement une fois que le travail et tons les attelai i . sont achevés, mais lorsque le client est satisfait. Quand peut-on estimer que les utilisateurs sont satisfaits ? La réponse dépend du type de relation que l'on entretient avec le marché,

• L'organisation chargée du développement a sans doute assisté à l'installation du système sur le site initial du client. Dans le cas de vastes systèmes complexes, elle peut même avoir effectué l'essentiel de l'installation.

• Les tests d'acceptation prennent fin lorsque le client et son fournisseur estiment que le système répond aux exigences sur lesquelles ils s'étaient préalablement accordés. I l est possible, bien entendu, qu'apparaissent des besoins supplémentaires ou des modifications de ces besoins, qui pourront donner lieu à un contrat de suivi. Migration ou conversion des données Il s'agit souvent de remplacer un système existant, ce qui nécessite des procédures de migration des données ou de conversion des bases de données. Les données existantes peuvent se trouver dans un produit développé par le même éditeur ; i l sera, alors, très simple de les transférer dans le nouveau produit. En revanche, si ces données résident sur un produit mis au point par un autre éditeur, éventuellement concurrent, leur déplacement pourra être plus délicat. Les responsabilités de l'équipe de développement peuvent être de plusieurs ordres : • remplacer l'ancien système par le nouveau, soit avec une reprise complète des tâches existantes par le nouveau système, soit avec un fonctionnement en parallèle des deux systèmes jusqu'à ce que l'utilisateur soit satisfait du fonctionnement du nouveau système ; • transférer les données de l'ancien système vers le nouveau, avec un éventuel changement des formats de données ; • fournir les instructions guidant ces transferts et prévoir, dans la documentation, des tests permettant aux utilisateurs de vérifier que l'installation a été couronnée de succès ;

Dans le cas de produits développés sous contrat pour un client unique, le chef de projet conclut à la satisfaction du client lorsque le système réussit les tests d'acceptation. Cet aspect dépend évidemment de l'interprétation des besoins formulés dans le contrat original (signé à la fin de la phase d'élaboration), tel qu'il a pu être modifié au cours des dernières phases. Le client peut confier par contrat un certain type de support de maintenance à l'éditeur du logiciel, ou gérer lui-même sa propre maintenance, ou encore la sous-traiter à une partie tierce. Les détails peuvent diverger, mais la phase de transition est bel et bien terminée.

16.5 Achever l'étude de rentabilité Les coûts 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 supplémentaires permettant déjuger des mérites de l'étude de rentabilité sont désormais dis ponibles.


16.5.1 Maîtriser

la

progression

Le chef de projet compare la progression réelle de la phase au calendrier, aux coûts et au travail prévus pour cette phase. À la fin de la phase de transition, qui marque aussi la fin du projet en termes budgétaires, le chef de projet convoque un groupe pour revoir le véritable calendrier, le nombre d'heureshomme, le coût, le taux d'anomalies et toute autre métrique que pourra employer la société, par rapport aux chiffres prévus pour le projet dans son ensemble, afin : • de vérifier si le projet a atteint les objectifs prévus ; • de s'informer des raisons pour lesquelles ces objectifs n'ont pas été atteints (si tel est le cas) ; • d'ajouter les métriques du projet à la base de données de métriques de la société en vue d'une utilisation future.

16.5.2 Réviser

le plan

stratégique

L'objet de ce plan est d'anticiper la réussite économique du projet. Là encore, deux situations typiques se présentent : d'un côté, la production dans le cadre d'un contrat, de l'autre, la production à destination d'un marché. Dans le premier cas, la réussite est facile à définir : le prix stipulé dans le contrat a-t-il couvert tous les frais engagés sur le projet ? Bien sûr, cette question relativement simple peut se voir compliquée par diverses considérations : i l se peut que la société ait fait une percée dans un secteur duquel elle était absente, ou bien que certains des composants ou sous-systèmes produits dans le cadre de ce contrat permettent une réduction des coûts sur de futurs contrats. Dans le second cas, le plan stratégique est plus compliqué à établir. La réussite se mesure à la capacité du produit à atteindre des objectifs tels que le taux d'obstacles sur le capital investi dans le développement. À la fin de la phase de transition et du projet, toutes les données, telles que le niveau des ventes futures, ne sont pas encore disponibles, mais la société sait déjà ce qu'elle a dépensé et a une meilleure appréhension des perspectives qui s'offrent à elle. Le responsable du projet fait en sorte de réunir toutes les données disponibles et convoque une réunion pour les examiner.

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 développement dans son ensemble. Cette évaluation se démarque de celles menées à l'issue des phases précédentes pour deux raisons. D'abord, i l s'agit de la dernière phase ; i l n'existe aucune phase ultérieure à laquelle léguer le travail non terminé. Dans un système d'une certaine envergure, néanmoins, il y aura un groupe chargé du produit, auquel pourront être transmises quelques idées utiles. Ensuite, bien qu'il s'agisse de la dernière phase du cycle de développement actuel, i l est probable que d'autres cycles de développement suivront. Le groupe d'évaluation doit donc archiver les constatations qui pourront leur être utiles. Ces constatations ressortissent à deux catégories, évoquées par les sous-sections suivantes.

16.6.1 Évaluer

les itérations


16

431

et la phase

D'un côté, si l'organisation du projet a mené efficacement les trois premières phases, la phase de transition doit se dérouler sans heurts et s'achever dans les délais et les budgets alloués. Les tests bêta ne détectent que des anomalies mineures qui peuvent être i mu us l u tement corrigées. Le groupe d'évaluation fait peu de constatations susceptibles d'intéreili t le groupe chargé du produit ou l'équipe responsable du cycle de vie suivant. D'un autre côté, si l'organisation du projet n'a réussi ni à identifier tous les risques impôt tants, ni à créer une architecture capable de prendre en charge les besoins, ni à implémeniei une conception fournissant le système demandé, de telles déficiences éclaleioni ave, un, douloureuse évidence dans la phase de transition. En conséquence, le chef de projet i isqm d'avoir à allonger la phase de transition pour parvenir à un système offrant au m.me satisfaction minimale. I l est possible qu'il ait la rude tâche de soutenir auprès des utilisateur un système jugé « bien assez bon». I l faudra peut-être aussi qu'il reporte a une version ulte rieure des caractéristiques pourtant spécifiées à l'origine dans les besoins Bien entendu, ces défaillances donnent de la matière 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 négatives à 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 interprétées, i l peut nuancer son propos. Le plus important, pour la réussite future de l'organisation, est d'affronter les faits et de tirer toutes les leçons de l'expérience.

16.6.2 Post mortem du projet Contrairement à l'évaluation, la réunion post mortem est largement consacrée à l'analyse des réussites et des échecs de l'organisation du projet. L'objectif est de créer des archives qui permettront aux projets ultérieurs de s'organiser plus efficacement et de mener le processus de développement avec plus de réussite. • Les points concernant le système qui vient d'être développé doivent être consignés pour servir aux personnes chargées de la maintenance et à l'équipe de la prochaine version. Par exemple, si les raisons ayant présidé au choix de la conception utilisée sont généralemenl archivées, celles qui ont conduit à en rejeter d'autres peuvent être tout aussi utiles aux futures équipes. • Les points pertinents pour le processus de développement lui-même doivent être examinés attentivement : - Est-il nécessaire de compléter la formation générale ? - Quels sont les aspects requérant une formation spécialisée ? - Le monitorat doit-il se poursuivre ? - L'expérience acquise à travers ce projet sur certains aspects spécialisés du Processus unifié (voir le chapitre 2) offre-t-elle une vision plus claire, susceptible de bénéficier a des projets futurs ?

_ _ \

Un d é v e l o p p e m e n t itératif et i n c r é m e n t a l III

16.7 Planifier la version ou la génération suivante L'expérience de l'industrie du logiciel au cours des dernières décennies montre que peu de produits logiciels demeurent longtemps inchangés. Le matériel et les systèmes d'exploitation sur lesquels ils s'exécutent é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 sphère privée. La quasi-totalité des systèmes logiciels entrent presque immédiatement dans un nouveau cycle de développement, qui reprend les phases de création, d'élaboration, de construction et de transition.

16.8 Principaux éléments à livrer Les éléments que doit livrer cette phase sont très semblables à ceux de la phase de construction (voir le chapitre 15), entre-temps corrigés et désormais complets : • le logiciel exécutable lui-même, avec son programme d'installation ; • les documents légaux, tels que les contrats, licences, conditions de désistement et garanties ; • la version de référence du produit complétée et corrigée, avec tous les modèles du système ; • la description de l'architecture complétée et corrigée ; • la versionfinaledes manuels de l'utilisateur, du technicien et de l'administrateur système et des supports de formation ; • les coordonnées des services de support clientèle et les adresses Internet où trouver de plus amples informations, rendre compte des anomalies détectées et obtenir des renseignements sur les correctifs et les mises à jour.

17 Application optimale du Processus unifié Le développement de logiciels dans le cadre de systèmes stratégiques demeure extrêmemenl complexe, comme l'ont clairement fait apparaître les chapitres précédents. Dans ce dernier chapitre, nous voudrions une fois encore, à titre de révision générale, rassembler les diverses pièces du puzzle. Notre but est de montrer, de manière plus concise que dans les chapitres précédents, la façon dont ces différentes pièces s'assemblent pour former un processus opérationnel. Par ailleurs, nous élargirons notre propos à deux autres notions. D'abord, si le processus logiciel est complexe en lui-même, sa gestion le sera également. Ensuite, le passage d'une absence totale de processus ou d'un processus antérieur ad hoc au Processus unifié ne sera pas une mince affaire.

17.1 Le Processus unifié aide à gérer la complexité Avant tout, i l y a les quatre phases : création, élaboration, construction et transition. Au-delà des phases du cycle initial - puisque les systèmes logiciels d'envergure ne cessent d'évoluer - viennent les versions ultérieures et, pour les révisions exhaustives, les générations suivantes. Au sein de ces phases s'entremêlent les enchaînements d'activités, l'architecture, la gestion des risques, les itérations et les incréments, décrits ci-dessous. • U n développement logiciel piloté par les cas d'utilisation par le biais des enchaînements d'activités : besoins, analyse, conception, implémentation et tests. • U n développement guidé par l'architecture : l'armature des éléments structurels et comportementaux permettant une évolution élégante du système. • Un développement à l'aide de briques de base et de composants, autorisant un niveau élevé de réutilisation. • Un développement mené à travers les itérations et les constructions au sein de ces itérations, donnant lieu à une croissance progressive du produit.

L

' r mm Un d é v e l o p p e m e n t itératif et i n c r é m e n t a l JH

PARTIE

III

• Un développement qui maîtrise les risques. • Un développement visualisé et consigné grâce au langage UML (Unified Modeling Language). • Un développement 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é opérationnelle initiale et la livraison du produit [1].

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 délimité la portée du système ? Avez-vous établi ce qui doit se trouver à l'intérieur du système et ce qui doit rester à l'extérieur ? • Êtes-vous parvenu à un accord avec les intervenants sur les besoins essentiels du système ? • Entrevoyez-vous une architecture capable d'implémenter ces caractéristiques ? • Avez-vous identifié les risques compromettant la réussite du projet ? Voyez-vous un moyen de les réduire ? • L'utilisation du produit générera-t-elle des avantages justifiant l'investissement nécessaire à sa construction ? • Est-il réaliste d'entreprendre le projet ? • Les intervenants contribuent-ils à la satisfaction des objectifs ? Il appartient à la phase de création d'apporter une réponse à ces questions.

17.1.2 L'architecture

du cycle de vie

Le deuxième jalon clarifie l'architecture du cycle de vie du produit, à travers les questions formulées ci-dessous. • Avez-vous créé une architecture de référence exécutable ? Celle-ci est-elle robuste et capable de réagir aux changements ? Est-elle en mesure d'évoluer tout au long du cycle de vie du logiciel ? • Avez-vous identifié et réduit les principauxrisquesau point d'être certain qu'ils ne compromettront pas le plan du projet ? • Avez-vous développé le plan du projet à un degré permettant d'établir une offre réaliste prenant en compte le calendrier, les coûts et la qualité ? • Le projet, tel qu'il est planifié et budgété, va-t-il produire le retour sur investissement espéré ?

17.1.3 Capacité opérationnelle

Application optimale du P r o c e s s u s u n i f i é mm CHAPITRE

17

mm

initiale

Le troisième jalon établit que le produit a atteint une capacité opérationnelle initiale : le produit est-il doté des capacités lui permettant un fonctionnement initial dans l'environnement utilisateur et propices à la conduite de tests bêta ? C'est bien là, la question centrale du troisième jalon. Ce jalon se profile dans les conditions suivantes : une architecture de référence a été établie, les risques ont été répertoriés, un plan du projet a été élaboré et les ressources sont disponibles. I l s'agit donc, maintenant, tic pro céder à 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 déroulera en douceur. Il est fondamental, dans cette phase, de séquencer les constructions et les itérations. Pour que ce .séqueiieemeni soit efficace, i l faut que les prérequis de chaque nouvelle itération soient bien en place. Il faut également faire en sorte de ne pas avoir à revenir en arrière pour reprendre une Itération antérieure à la lueur de découvertes plus tardives. Toutefois, malgré tous les efforts produits pour éviter les problèmes, il en apparaîtra ton jours. I l faudra donc surmonter ici ces problèmes jour après jour. Il appartient a la phase de construction de construire le système.

17.1.4 Livraison

du

produit

Le quatrième jalon établit que le produit est prêt pour une diffusion sans restriction auprès des utilisateurs : le produit peut-il fonctionner avec succès dans un environnement utilisateur typique ? Une fois que l'on a atteint la capacité opérationnelle initiale, i l reste encore du pain sur la planche : mener les tests bêta et les tests d'acceptation, corriger les problèmes 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 tâches.

17.2 Les principaux thèmes Plusieurs thèmes sous-tendent le parcours à travers les quatre jalons majeurs et les lient les uns aux autres : les besoins, l'architecture, le développement basé sur les composants, le langage UML, les itérations et la gestion des risques. (L'ordre dans lequel ces différents thèmes sont recensés ne reflète pas leur importance respective. Ils sont tous importants et doivent se conforter mutuellement.) Identifier les véritables

besoins

Identifiez les véritables besoins en modélisant les cas d'utilisation, en procédant à l'analyse, en cherchant à recueillir des réactions, etc. Les cas d'utilisations constituent le meilleur moyen d'entrer de plain-pied dans le Processus unifié.

• Avez-vous obtenu l'accord des intervenants ? Il appartient à la phase d'élaboration d'apporter une réponse à ces questions.


Créer l'architecture appropriée Tout projet d'une taille respectable doit être centré sur l'architecture. L'architecture permet de scinder un système en plusieurs parties, qu'elle fait coopérer. Elle solidifie les interfaces entre ces diverses parties et permet aux équipes de travailler indépendamment les unes des autres, de part et d'autre de ces interfaces, qui sont ainsi préservées 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 éléments qui rendent possible le développement basé sur les composants. Les briques de base réutilisables permettent de réduire les coûts du développement, de raccourcir les délais de mise sur le marché et d'améliorer la qualité du produit. Réfléchir et communiquer en UML Le développement logiciel ne se borne pas à l'écriture de code. Le langage UML (ainsi que les autres caractéristiques du Processus unifié) fait du développement logiciel une discipline d'ingénierie.. I l s'agit d'un langage graphique qui offre aux informaticiens les moyens de réfléchir, de visualiser, d'analyser, de communiquer et de consigner. Sans un moyen de communication standard tel qu'UML, i l serait extrêmement difficile, non seulement de comprendre ce que font les autres personnes impliquées dans le développement, mais aussi de transmettre les informations d'une phase à l'autre, d'une version à l'autre et d'une génération à l'autre. Procéder par itérations Les itérations et les constructions procurent divers avantages : un découpage du travail en portions limitées, une répartition des ressources en groupes de travail réduits, un lien avec la gestion des risques, de fréquents points de contrôle et de retours. Gérer les risques Identifiez les risques (qu'ils soient critiques, significatifs ou courants), inscrivez-les sur une liste des risques et réduisez-les avant qu'ils ne surgissent dans le processus de développement.

17.3 Les responsables dirigent la transition vers le Processus unifié Le travail qui consiste à gérer et à contrôler un processus en cours en entraîne 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 désormais de nombreuses organisations ; toutefois, celles qui adoptent la notion de processus logiciel ne sont pas légion. Or, ces organisations développent des logiciels ; c'est donc qu'elles trouvent un moyen d'y parvenir. Mais elles ne suivent pas des procédures rationnelles et reproductibles. D'autres équipes disposent bien d'une sorte de processus

Mm

17

n

Application optimale du P r o c e s s u s u n i f i é CHAPITRE

logiciel, mais n'en sont pas forcément tout à fait satisfaites. Certes, ces dernières mettent au point des logiciels, parfois avec une exceptionnelle réussite, mais elles sentent confusément qu'il y a moyen de mieux faire. Et elles ont raison. Comment ces sociétés parviennent-elles à trouver la voie qui leur convient ? Ce n'est certes pas un individu isolé au bas de l'échelle hiérarchique qui est susceptible de provoquer cette transition. I l pourra toujours s'imposer comme le champion de la nouvelle culture, mais après que l'organisation dans son ensemble aura décidé de faire sa révolution interne. Non, cette décision incombe clairement au sommet de la hiérarchie de l'organisation de développement 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 procéder et qu'il serait utile d'en profiter. C'est à eux, encore, de sentir que la concurrence impose d'agir vite. Cet embryon d'idée leur sera peut-être soufflé par des confrères dont la société a déjà 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 développement logiciel et dans l'entreprise tout entière, le principal responsable doit absolument gagner l'adhésion d'autres cadres. I l peut, pour cela, rédiger un plan d'action plaidant en faveur de cette nouvelle orientation. I l suffira, en général, de faire le point sur la situation actuelle et d'expliquer qu'elle ne saurait durer plus longtemps : les coûts sont trop élevés, la qualité trop faible et, surtout, les délais de mise sur le marché beaucoup trop longs. Or, même si les logiciels sont destinés à un usage interne, on ne bénéficie pas assez tôt des avantages que confèrent de meilleurs logiciels face à la concurrence. Des améliorations de 5 % d'une année sur l'autre ne suffisent plus. I l est aujourd'hui possible d'obtenir des résultats nettement supérieurs en termes de coûts, de délais et de qualité. D'autres sociétés l'ont déjà montré. Les plaidoyers en faveur d'une action décisive conduisent à s'interroger sur la nature même de cette action. Les organisations de développement logiciel, en règle générale, ne sont pas impliquées dans l'élaboration de méthodes, d'outils, de briques de base ou de composants. Ce rôle revient à d'autres types d'organisation. I l s'agit, par exemple, de sociétés de fabrication et de commercialisation de composants, ou d'organisations, telles que SAP, fournissant des systèmes préfabriqués adaptables à chaque entreprise. (Un système préfabriqué est une infrastructure complète à laquelle le client, avec l'aide du fournisseur, apporte quelques modifications mineures pour répondre à ses besoins spécifiques.) D'autres sociétés, comme Rational Software Corporation, prennent en charge le Processus unifié. I l appartient au responsable du département logiciel de trouver l'aide dont a besoin son organisation. Les possibilités n'étant pas infinies, la plupart des structures de développement logiciel ne se voient offrir qu'une seule voie : celle du développement basé sur les composants. C'est au responsable, à nouveau, qu'il revient d'évaluer la situation et de déterminer s'il faut cssayei de faire le maximum par soi-même, comme dans les secteurs de la banque, de l'assurance, de la défense ou des télécommunications, ou s'il est préférable d'avoir recours à un système préfabriqué, qui s'articulera autour de briques de base réutilisables. Quelle que soit l'option choisie, il sera nécessaire, dans la plupart des cas, de développer en interne une part plus ou

H g Un d é v e l o p p e m e n t itératif et i n c r é m e n t a l Jn

PARTIE Iil

moins importante du système. Quelqu'un devra se charger d'acquérir ces briques de base. Quelqu'un devra se charger de les adapter aux besoins spécifiques de l'entreprise. Tout cela nécessite de suivre un processus. Et c'est bien souvent le Processus unifié qui s'imposera aux yeux de tous comme la réponse la plus appropriée.

17.3.2 La directive

de réingénierie

achève de

convaincre

Le responsable qui est à l'origine du changement de procédure doit expliquer de façon claire, détaillée et sans bla-bla, dans la directive de réingénierie, les raisons qui peuvent pousser la société à adopter un processus logiciel amélioré. Cette directive aborde les thèmes suivants : • la situation actuelle de l'entreprise et son évolution ; • les nouvelles attentes de ses clients ;

Application optimale du P r o c e s s u s u n i f i é MB CHAPITRE

17

mm,

survie dans le futur. Ces personnes doivent recevoir une première formation afin de pouvoir participer aux débats sur l'avenir de la société. I l ne faut, à aucun prix, qu'elles aient l'impression d'être mises à l'écart. Un tel sentiment pourrait compromettre la réussite même de cette transition. Avoir confiance en son propre avenir Les personnes impliquées dans cette transition sont des professionnels de l'informatique. Malgré une histoire très courte selon les standards habituels, ce domaine a déjà connu des transformations radicales. Certains éprouvent des difficultés à rester au fait de ces évolutions. Les cadres moyens, en raison des charges administratives auxquelles ils doivent faire face, ressentent particulièrement ce poids. Le fait de les rassurer sur leur avenir peut faciliter la transition. Les sociétés traditionnellement soucieuses du bien-être de leurs employés mai quent un avantage dans ce domaine. Mais toutes doivent avoir conscience de l'importance de cet aspect de la question.

• la concurrence à laquelle l'entreprise doit faire face ;

17.3.3 Mettre en œuvre la

• les défis qu'elle doit relever ;

transition

Le champion

• les risques qu'implique l'immobilisme ;

Le responsable informatique se trouve confronté à des questions de mise en œuvre,

• le diagnostic qu'imposent ces défis ; • les mesures que doit prendre l'entreprise, en particulier en matière de processus logiciel [2] . 1

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 premières 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 rôle des mentors, qui doivent savoir comment procéder et peuvent appartenir ou non à la société. Le lancement d'un nouveau projet avec un nouveau processus est tributaire de l'intégration complète de quatre types de prise en charge : le processus, les outils, la formation et les mentors. Continuité des projets existants Dans une société d'envergure où de nombreux projets sont en cours, les projets actuels et la plupart de ceux qui débuteront 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'entraîner un changement spectaculaire. En même temps, la directive de réingénierie 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 formés, en temps et en heure, et se verront affectés à des projets utilisant le Processus unifié. Mais la transition prend du temps. Et la société doit évidemment poursuivre son activité, condition tout aussi indispensable à sa 1. [2] décrit 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 réutilisation. L a psychologie q u i sous-tend cette directive vaut tout autant pour le processus logiciel.

Le premier problème est la constitution de la structure qui va mettre en œuvre la transition. Le responsable informatique étant déjà suffisamment occupé par ailleurs, i l faut qu'il puisse se reposer sur un ingénieur ayant les compétences techniques pour défendre é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 acquérir une telle connaissance, il doit suivre une formation et bénéficier de conseils personnalisés. Le champion peut être un chef de projet techniquement compétent. 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 société et montera volontiers au créneau pour défendre cette position. En même temps, i l doit jouir de la confiance des cadres soutenant son action, mais aussi des personnes impliquées dans le projet. I l s'entend aussi bien avec les responsables qu'avec les techniciens. D sait convaincre. S'il s'intéresse aux méthodes et processus, i l fait preuve d'une maturité suffisante pour éviter tout dogmatisme et ne pas vouloir tout recommencer à zéro avec « sa méthode à lui ». I l aura, au contraire, l'intelligence d'adapter le Processus unifié aux besoins spécifiques du premier projet. Il n'est pas indispensable que le champion ait déjà mené tout un projet avec le Processus unifié. C'est d'ailleurs peu probable, puisqu'il est censé travailler dans la société depuis assez longtemps. I l suffit qu'il en comprenne les implications ; on attend de lui qu'il éprouve un désir ardent de mettre en œuvre ce processus. Avec l'aide, évidemment, du chef de projet et du mentor, tous deux décrits 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 décrire, prenez le meilleur dont vous disposez et assurez-le de votre soutien indé


fectible), le responsable informatique a également besoin d'un chef de projet particulièrement compétent. Un chef de projet capable de sentir au plus profond de lui-même 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 réussir pour contrecarrer la perplexité que ne manquera pas de susciter l'adoption du nouveau processus. Le mentor La formation ne fait pas tout. En l'occurrence, elle ne remplace pas l'expérience 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 expérience de la gestion de projet, même si c'est un plus. I l doit réunir deux qualités spécifiques. L'une est la capacité à anticiper les problèmes susceptibles d'apparaître dans le projet. Cette capacité, bien entendu, repose sur son expérience antérieure de l'adoption du Processus unifié. L'autre est la faculté de coopérer avec les personnes très diverses qu'il va rencontrer, notamment le champion, mais aussi le chef de projet, les personnes impliquées dans le projet et la direction informatique. Par où commencer ? Le premier projet doit être un projet réel, dont les résultats auront de l'importance. Notre expérience des projets pilotes artificiels n'est, en effet, guère encourageante. Ils ont tendance à stagner et leurs résultats, quels qu'ils soient, ne font pas grande impression. Le premier projet doit au contraire être stratégique, mais soumis à des délais raisonnables. «Ah, amusant, vous dites-vous, mais tous les projets stratégiques sont urgents ! » Nous le savons. En fait, l'utilisation du Processus unifié permet d'avancer plus rapidement que les anciennes méthodes. Les risques étant détectés très tôt et l'architecture étant rapidement opérationnelle, la construction se déroule plus facilement. De plus, le premier projet sera guidé par des mentors, proclamés tels précisément en vertu de leur expérience du processus, et donc capables de mener à bien sa mise en œuvre. En fait, i l est plus prudent d'adopter l'approche complète sur un projet réel, sans pour autant tout bouleverser. Un nouveau processus, oui ; et aussi les outils qui vont avec (à condition qu'ils soient bien intégrés). Mais un nouveau système d'exploitation, une nouvelle technologie de base de données, un nouveau langage de programmation, une nouvelle plate-forme de système distribué... peut-être pas. Inutile d'accumuler les nouveautés, notamment des technologies qui ne cohabitent pas très bien. Selon les circonstances, vous pourrez accueillir une ou deux technologies nouvelles. Et ne choisissez pas un système trop complexe comme banc d'essai. Autres considérations Notre expérience nous livre quelques ultimes réflexions. • L'approche présentée dans ces pages ne reflète pas toujours celle que l'on suivra dans la réalité, mais elle décrit le moyen systématique d'adopter le Processus unifié.

Application optimale du P r o c e s s u s u n i f i é MB CHAPITRE

17

mm

• Certains arrivent parfois, i l faut le reconnaître, à réorganiser le processus logiciel petit à petit ; mais il vaut mieux ne pas y compter : la procédure est longue et l'échec est souvent au bout du chemin. • Quoi qu'il en soit, il est souhaitable que la transition se déroule sous un contrôle rigoureux pour parvenir à son terme. Les échecs dus à un manque de contrôle sont difficiles à rattraper.

17.4 Spécialiser le Processus unifié Le Processus unifié, tel qu'il est présenté dans cet ouvrage, ne constitue pas l'alpha et l'oméga sur le sujet. I l reste deux choses extrêmement importantes à en dire. D'abord, c'est une infrastructure préfabriquée. Elle doit être adaptée en fonction d'un certain nombre de variables : la taille du système enjeu, le domaine dans lequel doit fonctionner ce système, la complexité du système, enfin le niveau d'expérience, de compétences ou de connaissance du processus de l'organisation du projet et des personnes qui la composent. Deuxièmement, ce livre, aussi détaillé qu'il puisse vous paraître, n'offre qu'une présentation générale du pin cessus en marche. Pour l'appliquer, i l vous manque un nombre considérable d'informations. Nous abordons ces deux spécialisations dans les sections qui suivent.

17.4.1 Adapter

le

Processus

Les systèmes et produits logiciels, et les organisations qui les mettent au point, sont plus divers que jamais. En conséquence, s'il y a bien quelques constantes dans le Processus unifié, comme les quatre phases et les cinq enchaînements d'activités 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'itérations pour chaque phase en fonction du contexte ? À quel stade l'architecture candidate (ou la réduction des risques critiques, l'architecture de référence, l'étude de rentabilité, etc.) est-elle assez fermement établie ? La réponse à des questions telles que celles-ci dépend de la taille du système, de la nature de l'application, de l'expérience de l'organisation chargée du projet dans le domaine en question, de la complexité du système, de l'expérience de l'équipe du projet, des compétences des responsables logiciels, et même de la capacité des intervenants à coopérer les uns avec les autres. Par exemple, si le système est relativement modeste et que l'équipe du projet connaît bien le domaine (si elle a réalisé des versions précédentes ou des produits comparables), la phase de création peut être très brève. Les membres de l'équipe (et certainement les intervenants) savent qu'aucun risque critique ne viendra entraver la réussite du développement. Ils savent aussi qu'ils peuvent réutiliser une architecture ayant déjà servi. Quelques jours peuvent donc suffire pour terminer la phase de création en confirmant la portée du système et en s'assurant qu'aucun risque nouveau n'est apparu dans ce cadre.

• Une approche plus progressive, marquée par un nombre d'étapes supérieur, risquerait de tomber dans l'écueil inverse : la progression devient presque impalpable, les soutiens s'évaporent dans la nature et la transition échoue.


Prenons un autre exemple : celui d'un système vaste, complexe et inédit pour l'équipe du projet. On peut, dans ce cas, s'attendre à ce que la phase de création, ainsi que la phase d'élaboration, dure beaucoup plus longtemps et passe par un plus grand nombre d'itérations. Les variations sur ces thèmes sont aussi nombreuses que les systèmes à construire. C'est là qu'intervient l'expérience. C'est là que le chef de projet est bien inspiré de s'entourer de l'expérience de spécialistes 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

Nous l'avons déjà dit, le Processus unifié décrit dans ces pages ne donne qu'une idée sommaire du processus qu'il vous faudra suivre pour diriger une équipe travaillant au développement d'un système. 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 détaillées qui devront guider les membres de l'équipe dans leur travail quotidien. I l se contente de nommer certains des artefacts que crée/utilise le processus ; i l y en a d'autres. I l ne procure aucun modèle 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 révéler 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 précision que par des personnes livrées à elles-mêmes. L'ouvrage ne décrit pas précisément ces outils, ce à quoi ils servent, ni leur mode d'emploi. D'une manière générale, ce livre n'aborde que les grandes lignes du processus. I l décrit certains enchaînements d'activités, certains artefacts, certains travailleurs et certaines de leurs activités, enfin certains usages du langage UML.

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 éléments que doivent connaître les étudiants pour exploiter le Processus unifié et pour réfléchir et visualiser leurs idées à l'aide du langage UML. • Le monde du logiciel : les architectes, développeurs et autres professionnels peuvent passer directement d'un projet à l'autre, et même d'une société à l'autre, sans avoir à perdre du temps à s'adapter aux pratiques spécifiques à l'entreprise en question. • Le monde de la réutilisation : les projets peuvent réutiliser plus facilement des soussystèmes et des composants, car ils sont représentés 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 développement d'outils.

17.6 Profiter des avantages qu'offre le Processus unifié Etablissez fermement les besoins très tôt en faisant évoluer les cas d'utilisation avec la eoo pération des utilisateurs réels et des personnes chargées de l'ingénierie du processus. Passe/ ensuite des besoins aux enchaînements d'activités 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 générations du produit. Le tout par l'intermédiaire d'une architecture du cycle de vie à la fois compréhensible, réactive aux changements, robuste et capable d'évoluer dans les années à venir, puisque le Processus unifié est centré sur l'architecture. Développeurs comme intervenants, tirez des leçons des constructions et itérations successives, puisque le Processus unifié est itératif (annexe C) et incrémental.

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 développeurs individuels : c'est un processus rationalisé (par des ingénieurs pour des ingénieurs).

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 problème.

Accélérez le rythme du développement, réduisez les coûts et améliorez la qualité du produit grâce à la réutilisation de briques de base, puisque le Processus unifié est basé sur les composants.

Mais i l y a bien plus. Pour une version hautement développée, i l vous faut le processus Rational Unified Process, base de connaissances interrogeable en ligne comprenant environ 2 000 pages de données. Ce produit améliore la productivité de l'équipe en lui fournissant tout un arsenal de directives, de modèles et d'outils pour les activités les plus délicates du développement. Le processus s'intègre 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 personnalisés que prodiguent les mentors.

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 possibilités d'échange avec les catégories suivantes.

Réduisez le plus possible la probabilité que des risques critiques mettent en péril la réussite du projet ou que des risques significatifs n'en compromettent le budget ou le calendrier, puisque le Processus unifié est orienté vers la réduction des risques (annexe C).

Le fait de disposer d'une telle infrastructure de phases, d'itérations, de jalons et d'évaluations offre des points de repère qui permettent aux intervenants de savoir où en est le développement. Grâce à cette compréhension de l'état du développement et à leur connaissance du domaine de l'application, ils peuvent ainsi émettre des suggestions visant à d'éventuelles améliorations du système. Mais surtout, comme les premières phases prennent en considération les aspects essentiels, comme l'architecture et les risques, ils peuvent soumettre leurs idées à un moment où l'on peut encore en faire bon usage.


III

Aboutissement de 30 ans de pratique, le Processus unifié rassemble l'expérience de plusieurs experts éminents et d'organisations spécialisées. I l s'unifie autour d'un grand nombre d'applications et de techniques, et présente les caractéristiques suivantes : • i l est « visualisable » : les modèles et artefacts visuels employés par le Processus unifié sont exprimés dans le langage UML, ce qui confère au processus de nombreux avantages, puisqu'il permet une réutilisation intensive des logiciels et fournit des plans d'élaboration et de construction ; • i l est « outiliable » : la présence d'un processus unifié et d'un langage standard garantit un soutien financier à un outillage plus important qui, à son tour, améliore 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 à différents domaines d'application et aux besoins spécifiques de chaque organisation ; • i l est extensible : le Processus unifié ne limite pas ses utilisateurs à une seule façon de procéder, par exemple, à l'analyse des risques. Les utilisateurs peuvent trouver d'autres sources d'informations. Le Processus unifié se contente de leur proposer des repères logiques dans lesquels insérer les activités (en l'occurrence l'activité d'analyse des risques), de préférence tôt plutôt que tard dans le processus. Le Processus unifié assiste les organisations de développement de bien des manières. Le premier de ses avantages est d'établir les conditions d'une collaboration optimale entre les membres de l'équipe. Mais la synergie ainsi créée ne s'arrête pas là : le Processus unifié permet aussi à l'équipe du projet d'instaurer une coopération fructueuse avec les utilisateurs et les divers intervenants.

17.7 Références Ivar lACOBSON, Martin GRISS et Patrik JONSSON, Software Reuse: Architecture, Process

2

Barry BOEHM, « Anchoring the software process », IEEE Software, juillet 1996, p. 7382.

1

and Organization for Business Success, Reading, MA, Addison-Wesley, 1997. Walker ROYCE, Software Project Management: A Unified Framework, Reading, M A ,

3

Addison-Wesley, 1998.

A Présentation générale du langage UML A.1 Introduction Les branches les plus anciennes de l'ingénierie ont depuis longtemps compris l'intérêt de représenter les conceptions sous forme de graphiques. Dès les premiers temps de l'informatique, les programmeurs ont utilisé différents types de schémas ou, plus largement, de modèles pour présenter leurs idées. Les développeurs (de logiciels) ont besoin d'un moyen de communiquer leurs modèles, non seulement aux membres des équipes de projet, mais aussi aux intervenants extérieurs et, dans une perspective à plus long terme, aux développeurs des générations suivantes. I l leur faut un langage, certes pour communiquer, mais aussi pour définir le cadre de réflexion et d'analyse dans lequel pourra s'inscrire chaque développeur individuellement. Par ailleurs, i l est impossible, pour ces développeurs, de garder tout en tête pendant des mois et des années : 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 modélisation des logiciels, c'est-à-dire un langage de visualisation, de spécification, de construction et de documentation des artefacts de systèmes à forte composante logicielle. Fondamentalement, le langage UML permet aux développeurs de visualiser les produits de leur travail sous forme de plans d'élaboration et de construction ou de diagrammes standardisés. Par exemple, les principaux symboles et icônes utilisés dans la formulation des besoins sont une ellipse pour représenter un cas d'utilisation et un bonhomme stylisé pour désigner un utilisateur employant le cas d'utilisation en question. De même, l'icône centrale de la conception est le rectangle, qui figure une classe. Ces icônes 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 référence complète sur cette notation, tandis que [3] propose un guide de l'utilisateur. Mais audelà de cette notation graphique, le langage UML véhicule aussi du sens, c'est-à-dire une sémantique. Vous trouverez une présentation sommaire de cette sémantique à 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

définitions des principaux termes U M L réunies dans la section A.3. Pour une véritable description de la sémantique d'UML, nous vous renvoyons de nouveau aux ouvrages [2] et [3]. Autre référence traitant à la fois de la notation et de la sémantique d'UML, le jeu de documentations publiques d'UML [1], d'une nature plus formelle, toutefois. Pour terminer, [4] et [5] constituent d'autres références utiles.

A.1.1

contraintes. Les stéréotypes permettent de définir de nouveaux éléments en élargissant ou en affinant la sémantique d'éléments existants, tels que des éléments ou des relations (voir la section A . l . l ) . Les valeurs marquées permettent, quant à elles, de définir de nouvelles pro priétés d'éléments existants. Enfin, les contraintes offrent un moyen d'imposer des règles (par exemple, des règles de cohérence ou des règles métier) à des éléments et à leurs propriétés.

Vocabulaire Le langage U M L fournit un vocabulaire comprenant trois catégories d'archétypes, que nous ne mentionnerons ici que pour vous donner une idée d'ensemble de la structure élémentaire du langage : les éléments, les relations et les diagrammes. Il y a quatre catégories d'éléments : les éléments structurels, comportementaux, de regroupement et d'annotation. Ces quatre catégories s'articulent elles-mêmes de la façon suivante : sept types principaux d'éléments structurels (cas d'utilisation, classes, classes actives, interfaces, composants, collaborations et nœuds) ; deux types d'éléments comportementaux (interactions et machines à états) ; quatre types de regroupements (paquetages, modèles, sous-systèmes et infrastructures préfabriquées) ; enfin, un type principal d'éléments d'annotation (note).

A.2 Notation graphique Les dernières figures de cette annexe sont empruntées au Guide de l'utilisateur du langage UML, de Grady Booch, James Rumbaugh et Ivar Jacobson [3].

A.2.1 Éléments

structurels

Figure A.2

Classe

+ origine : Point

La deuxième catégorie, celle des relations, se décompose en trois types de classifications : dépendance, association et généralisation.

UML

Comportementaux

Structurels

Diagrammes

Dépendance Association Généralisation

Regroupement

Paquetage Modèle Sous-système Infrastructure préfabriquée

De cas d'utilisation De classes D'objets De s é q u e n c e De collaboration D'états-transitions D'activités De composants De d é p l o i e m e n t

Interface

Classes et interfaces.

déplacer(p : Ppjnt)__ + redimensionifër" (e : Échelle) + affiche n") # invaliderZoneO

Enfin, la troisième catégorie propose neuf types de diagrammes : les diagrammes de cas d'utilisation, de classes, d'objets, de séquence, de collaboration, d'états-transitions, d'activités, de composants et de déploiement. Figure A.1

Les objets sont soulignés. Les éléments abstraits sont en italique.

O

lApplication

Responsabilités - gérer l'état de la forme -- gérer les transformations de base de la forme

Vocabulaire du langage UML.

Interaction Machine à é t a t s

Cas d'utilisation Classe Classe active Interface Composant Collaboration Noeud

Figure A.3

compartiment supplémentaire

Collaboration

C a s d'utilisation

Cas d'utilisation et collaborations. (Notez que le nom des cas

_e Chaîne de responsabilités

d'utilisation, par

A. 1.2 Mécanismes

exemple, peut être

d'extensibilité

placé

Le langage UML fournit des mécanismes d'extensibilité, qui permettent à ses utilisateurs d'en affiner la syntaxe et la sémantique. U M L peut ainsi être adapté à un système, à un projet ou à un processus de développement spécifique, si nécessaire. Vous trouverez un exemple de ce type d'adaptation dans l'annexe B.

à

l'extérieur Des compartiments supplémentaires peuvent être utilisés pour montrer le contenu.

du symbole si cela convient

mieux.)

Ces mécanismes d'extensibilité se composent des stéréotypes, des valeurs marquées et des

|

Annexes

P r é s e n t a t i o n g é n é r a l e du langage UML ANNEXE

Figure A.4 Classes

actives,

Active Class

Component

Noeud

Figure A.6 Machine à états.

A

Machine à états

composants et Gestionnaire DesÉvénements f : FileAttenteDesX-^ Evénements

menas.

Imbriqué

garde

suspendre() viderQ prêt(3) [signalOK] transition interne

opérations

r

Classe active Composant Noeud Des compartiments supplémentaires peuvent être uîîiîsés pour montrer te contenu.

A.2.2 Éléments

Connecté

\

décroché / récupérerConnexionf)

comportementaux

Figure A.5 Interactions.

A.2.3 Éléments

de

regroupement

Interaction object Figure A.7 : BoiteAOutils a1 : exécuter(3) • i i

Paquetage

Paquetages.

-—— ligne de vie exécuter()

calIbackLoopO

étiquette de séquence

Des compartiments supplémentaires peuvent être utilisés pour montrer le contenu.

recursion

rappel Boucle ...

A.2.4 Éléments

d'annotation

Figure A.8

Note

Notes.

> Envisager l'utilisation du design pattern Broker ici. egb 11/12/97

I

L

J

Annexes

1


j .2.5 Relations de

A.2.8 Mécanismes

dépendance

jureA.9

Figure A.12

Dépendence

Mécanismes

lations de '

d'extensibilité.

tendance. i Titulaire

A

d'extensibilité

stéréotype

«conteneur» FileAttenteAction {version = 3.2} « ajoutera : Action) supprimer(n : Entier) «requête» longueur)) : Entier «fonctions d'aide» commander à nouveau!)

-z> cible

S .2.6 Relations

valeur marquée

{ajouter exécutions dans 0(1) fois)

contrainte

d'association

i-igure A.10

A.3 Glossaire

Association

Relations ISSOCiation.

n

o

multiplicité

m

0..1

fin

• Emploie

e : employeur jm f

navigation

acteur Ensemble cohérent de rôles que jouent les utilisateurs de cas d'utilisation dans leur interaction avec ces cas d'utilisation.

> fin employé losange vide pour les agrégations losange plein pour les compositions

f

Ispécificateur d'interface

action Spécification d'une instruction exécutable constituant une abstraction d'une procédure 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.

nom de rôle

action asynchrone

.2.7 Relations de

action synchrone

généralisation

activation ]ure A.11 .^lations

activité

Généralisation

de

discriminant

Requête dans laquelle l'objet expéditeur n'attend pas les résultats. Requête dans laquelle l'objet expéditeur attend les résultats.

Exécution d'une action.

État d'exposition d'un comportement.

agrégat

généralisation. -J> parent

Classe représentant le « tout » dans une relation d'agrégation.

agrégation Forme spéciale d'association spécifiant une relation tout-à-partie entre l'agrégat (le tout) et une partie le composant (la partie). association Relation structurelle décrivant un ensemble de liens, dans laquelle un lien est une connexion entre objets ; relation sémantique 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.

attribut Propriété nommée d'un classiflcateur décrivant une gamme de valeurs que peuvent détenir les instances de cette propriété. cardinalité

Nombre d'éléments d'un ensemble.

cas d'utilisation Description d'un ensemble de séquences d'actions, avec leurs variantes, effectuées par un système et donnant un résultat satisfaisant pour un acteur particulier. classe Description d'un ensemble d'objets partageant la même sémantique ainsi que les mêmes attributs, opérations et relations. classe abstraite Classe n'étant pas directement instanciée. classe active

Classe dont les instances sont des objets actifs. Voir processus, tâche, thread.

classe concrète

fmm

A

mm


la durée de vie ; ces parties peuvent également être supprimées de façon explicite avant la mort de la classe composite. concurrence Déroulement de deux ou plusieurs activités dans le même intervalle de temps. La concurrence peut être réalisée par l'entrelacement ou l'exécution simultanée d'au moins deux threads. condition de garde Condition devant être remplie pour permettre le déclenchement d'une transition associée. conteneur Objet destiné à contenir d'autres objets et fournissant des opérations permettant d'accéder à son contenu ou de le parcourir. contexte Ensemble d'éléments liés pour un objectif particulier, comme la spécification d'une opération.

Classe pouvant être directement instanciée.

classe d'association Élément de modélisation ayant à la fois les propriétés d'une association et celles d'une classe. Une classe d'association peut être vue comme une association ayant également les propriétés d'une classe, ou comme une classe ayant également les propriétés d'une association. classiflcateur Mécanisme décrivant les caractéristiques structurelles et comportementales. Les interfaces, les classes, les types de données, les composants et les nœuds sont des classificateurs. classification multiple Variation sémantique de la généralisation, dans laquelle un objet peut appartenir directement à plusieurs classes. client

Classiflcateur demandant les services d'un autre classiflcateur.

collaboration Société de classes, d'interfaces et d'autres éléments travaillant de concert pour fournir un comportement coopératif plus important que la somme de tous ses éléments ; spécification de la façon dont un élément, tel qu'un cas d'utilisation ou une opération, est réalisé par un ensemble de classificateurs et d'associations jouant des rôles spécifiques, utilisés d'une façon spécifique. commentaire Annotation associée à un élément ou à un ensemble d'éléments. composant Partie physique et remplaçable d'un système respectant et fournissant la réalisation d'un ensemble d'interfaces. composite

Classe liée à une ou plusieurs classes par une relation de composition.

composition Forme d'agrégation indiquant une forte relation de propriété et une durée de vie concomitante entre la partie et le tout ; des parties sans multiplicité définie peuvent être créées après la classe composite elle-même, mais une fois créées, elles en partagent

contrainte Extension de la sémantique d'un élément UML, permettant d'ajouter de nouvelles règles ou de modifier les règles existantes. déclencher décoration base.

Ou faire franchir. Exécuter une transition vers un état. Détail de la spécification d'un élément s'ajoutant à sa notation graphique de

délégation Capacité d'un objet à émettre un message adressé à un autre objet en réponse à un premier message. dépendance Relation de sémantique entre deux éléments, dans laquelle la modification d'un des éléments (l'élément indépendant) peut affecter la sémantique de l'autre élément (l'élément dépendant). diagramme Présentation graphique d'un ensemble d'éléments, le plus souvent rendu sous la forme d'un graphique associant des sommets (les éléments) et des arcs (les relations). diagramme d'activités Diagramme montrant le passage d'une activité à l'autre ; les diagrammes d'activités donnent une vue dynamique d'un système. 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 déclenchées par la réalisation 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 système. 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

Annexes

mm

A

mm


une vue statique d'un système ; diagramme montrant une collection d'éléments déclaratifs (statiques). diagramme de collaboration Diagramme d'interaction mettant en relief l'organisation structurelle des objets expéditeurs et destinataires de messages ; diagramme montrant l'organisation des interactions autour des instances et des liens qui les unissent.

événement Spécification d'une occurrence significative ayant une localisation temporelle et spatiale ; dans le contexte des machines à états, un événement est l'occurrence d'un stimulus pouvant déclencher une transition vers un autre état. exécutable expéditeur

Programme pouvant être exécuté sur un nœud. Objet transmettant une instance de message à un objet destinataire.

façade Paquetage stéréotypé ne contenant rien d'autre que des références à des éléments de modèle appartenant à un autre paquetage. Permet de fournir une vue « publique » d'une partie du contenu d'un paquetage.

diagramme de déploiement Diagramme montrant un ensemble de nœuds et leurs relations ; un diagramme de déploiement donne une vue statique du déploiement d'un système.

exportation Dans le contexte des paquetages, fait de rendre un élément visible en dehors de l'espace de noms dans lequel i l se trouve.

diagramme de composants Diagramme montrant un ensemble de composants et leurs relations ; les diagrammes de composants donnent une vue statique des composants d'un système.

diagramme d'états-transitions Diagramme montrant une machine à états ; les diagrammes d'états-transitions donnent une vue dynamique d'un système.

focalisation du contrôle Symbole figurant dans un diagramme de séquence et montranl la période au cours de laquelle un objet effectue une action, soit directement, soit par l'intermédiaire d'une opération subordonnée.

héritage Mécanisme par lequel des éléments plus spécifiques intègrent la structure et le comportement d'éléments plus généraux.

diagramme de séquence Diagramme d'interaction mettant l'accent sur l'ordonnancement temporel des messages.

généralisation Relation de spécialisation/généralisation telle que les objets de l'élément spécialisé (le sous-type) peuvent être remplacés par ceux de l'élément généralisé (le super-type).

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 système.

framework

diagramme d'interaction Diagramme montrant une interaction, comprenant un ensemble d'objets et leurs relations, ainsi que les messages pouvant être répartis entre eux ; les diagrammes d'interaction donnent une vue dynamique d'un système ; terme générique s'appliquant à plusieurs types de diagrammes illustrant les interactions entre objets, comme les diagrammes de collaboration, de séquence et d'activités.

élément

Constituant atomique d'un modèle.

emplacement

fournisseur Type, classe ou composant fournissant des services qui peuvent être Invoqués par d'autres. Voir infrastructure préfabriquée.

hiérarchie de contenance Hiérarchie d'espaces de noms composée d'éléments et des relations de contenance qui les unissent.

Localisation d'un composant sur un nœud.

importation Dans le contexte des paquetages, dépendance montrant le paquetage dont les classes peuvent être référencées à partir de paquetages donnés (y compris de paquetages imbriqués de façon récursive à l'intérieur de ce paquetage).

état d'action État représentant l'exécution d'une action atomique, par exemple l'invocation d'une opération.

héritage simple Variation sémantique de la généralisation, dans laquelle un type ne peut avoir qu'un seul super-type.

état Condition ou situation de la vie d'un objet pendant laquelle celui-ci remplit une condition, effectue une activité ou attend un événement particulier.

héritage multiple Variation sémantique de la généralisation, dans laquelle un type peut avoir plusieurs super-types.

espace de noms Partie du modèle dans laquelle peuvent être définis et utilisés les noms ; au sein d'un espace de noms, chaque nom a une signification unique.

héritage d'interface Héritage de l'interface d'un élément plus spécifique ; ne comprend pas l'héritage de l'implémentation.

envoyer

Transmission d'une instance de message d'un objet expéditeur à un objet destinataire.

Annexes

Présentation générale du langage UML mm ANNEXE

infrastructure préfabriquée Pattern architectural fournissant un cadre extensible pour des applications liées à un domaine spécifique. (Framework.)

note objet

A

Hi

Commentaire associé à un élément ou à une collection d'éléments, Voir instance.

objet transitoire l'a créé.

interface Collection d'opérations permettant de spécifier un service d'une classe ou d'un composant.

objet persistant d'exister.

interaction Comportement englobant un ensemble de messages échangés par un ensemble d'objets dans un contexte particulier et dans le but d'atteindre un objectif particulier.

objet actif Objet possédant un processus ou un thread et pouvant déclencher une activité de contrôle.

instance Manifestation concrète d'une abstraction ; entité à laquelle peut être appliqué un ensemble d'opérations et ayant un état stockant les effets des opérations ; synonyme d'objet.

Objet existant après que le processus ou le thread l'ayant créé a cessé

Objet n'existant que pendant l'exécution du thread ou du processus qui

Mécanisme généraliste permettant de regrouper les éléments.

paquetage

Spécification d'une variable pouvant être modifiée, passée ou renvoyée.

paramètre

liaison Création d'un élément à partir d'un template dont on fournit les arguments des paramètres.

opération Implémentation d'un service à laquelle un objet quelconque de la classe peut demander d'effectuer un certain comportement.

langage de contrainte sur les objets (OCL) contraintes sans effet secondaire.

lien

Langage formel permettant d'imposer des

Connexion sémantique entre objets ; instance d'une association.

ligne de vie Ligne d'un diagramme de séquence représentant l'existence d'un objet pendant une certaine période. machine à états Comportement spécifiant les séquences d'états que doit traverser un objet au cours de sa vie en réponse à des événements, ainsi que ses réponses à ces événements. mécanisme d'extensibilité Un des trois mécanismes (stéréotypes, valeurs marquées et contraintes) permettant d'enrichir le langage UML de façon contrôlée. message Spécification d'une communication entre objets véhiculant des informations, donnant lieu en principe à une activité ; la réception d'une instance de message est normalement considérée comme une instance d'un événement. métaclasse méthode modèle

Classe dont les instances sont des classes.

portée

Contexte conférant une signification particulière à un nom.

postcondition processus cessus.

Spécification de la gamme de cardinalités que peut assumer un ensemble.

Contrainte qui doit être vraie à l'issue de l'exécution d'une opération.

Flot de contrôle lourd pouvant s'exécuter concomitamment avec d'autres pro-

précondition propriété

Contrainte qui doit être vraie lors de l'invocation d'une opération.

Valeur nommée indiquant une caractéristique d'un élément.

réalisation Relation sémantique entre classificateurs, dans laquelle un classiflcateur spécifie un contrat dont un autre classiflcateur garantit l'application. recevoir

Prendre en charge une instance de message transmise par un objet expéditeur.

relation

Implémentation d'une opération. Abstraction sémantiquement fermée d'un système.

multiplicité

noeud Élément physique existant à l'exécution et représentant une ressource de calcul, doté en principe au moins de mémoire et souvent de capacités de traitement. nom Désignation d'un élément, d'une relation ou d'un diagramme ; chaîne permettant d'identifier un élément.

Connexion sémantique entre éléments.

responsabilité rôle

Contrat ou obligation d'un type ou d'une classe.

Comportement spécifique d'une entité participante dans un contexte particulier.

scénario signal

Séquence d'actions spécifique illustrant un comportement. Spécification d'un stimulus asynchrone communiqué entre instances.

signature

Nom et paramètres d'une propriété comportementale.

Annexes

Présentation générale du langage UML ANNEXE

sous-système Regroupement d'éléments, dont certains constituent une spécification du comportement fourni par les autres éléments contenus.

A

type de données Type dont les valeurs n'ont pas d'identité. Les types primitifs intrinsèques (comme les nombres et les chaînes) et les types d'énumération (comme les booléens) sont des types de données.

utilisation Dépendance dans laquelle un élément (le client) exige la présence d'un autre élément (le fournisseur) pour fonctionner ou s'implémenter correctement.

stéréotype Extension du vocabulaire d'UML permettant de créer de nouveaux types de briques de base dérivés de types existants, mais spécifiques à un problème particulier.

unité de distribution Ensemble d'objets ou de composants affectés en tant que groupe à une tâche ou à un processeur.

spécification Instruction textuelle de la syntaxe et de la sémantique d'une brique de base spécifique ; description déclarative de la nature ou du rôle d'un élément.

type primitif Type de base prédéfini, comme un entier ou une chaîne.

sous-type type.

stimulus

Dans une relation de généralisation, spécialisation d'un autre type, le super-

Opération ou signal.

valeur marquée Extension des propriétés d'un élément UML, permettant d'inclure de nouvelles informations dans la spécification de cet élément.

vue Projection d'un modèle, envisagé d'un point de vue donné ou avantageux, ometlant les entités non pertinentes pour ce point de vue.

système Collection de sous-systèmes agencés de façon à réaliser un objectif spécifique et décrits par un ensemble de modèles, éventuellement de différents points de vue.

visibilité

super-type type.

Dans une relation de généralisation, généralisation d'un autre type, le sous-

tâche Chemin unique d'exécution à travers un programme, un modèle dynamique ou une quelconque autre représentation d'un flot de contrôle ; thread ou processus. template

A.4

Point de terminaison d'une association, reliant cette asso-

2

3

Instance d'une terminaison d'association.

Façon dont un nom peut être vu et utilisé par d'autres.

Références 1

Élément paramétré.

terminaison d'association ciation à un classiflcateur. terminaison de lien

OMG Unified Modeling Language Spécification, Object Management Group, Framingham, MA, 1998. Internet : www.omg.org. James RUMBAUGH, Ivar JACOBSON et Grady BOOCH, The Unified Modeling Language Référence Manual, Reading, MA, Addison-Wesley, 1998. Grady BOOCH, James RUMBAUGH et Ivar JACOBSON, The Unified Modeling Language

User Guide, Reading, MA, Addison-Wesley, 1998.

thread Flot de contrôle léger pouvant s'exécuter concomitamment avec d'autres threads d'un même processus.

Hans-Erik ERIKSSON et Magnus PENKER, UML Toolkit, New York, John Wiley & Sons, 1998.

5

Martin FOWLER, UML Distilled, Reading, MA, Addison-Wesley, 1997.

4

traçabilité Dépendance indiquant une relation historique ou de processus entre deux éléments représentant le même concept sans règles spécifiques permettant de les dériver l'un de l'autre. transition Relation entre deux états indiquant qu'un objet étant dans le premier état va effectuer certaines actions spécifiées et entrer dans le second état lorsque se produira un événement particulier et que seront remplies des conditions spécifiées. travée Cloisonnement d'un diagramme d'activités permettant de répartir les responsabilités liées aux actions. type Stéréotype de classe permettant de spécifier un domaine d'objets ainsi que les opérations (et non les méthodes) applicables à ces objets.

B Extensions du langage UML spécifiques au Processus unifié B.1 Introduction Cette annexe présente les extensions du langage U M L qu'exige le Processus unifié. Ces extensions sont décrites en termes de stéréotypes et de valeurs marquées, c'est-à-dire en termes de mécanismes d'extension fournis par UML, ainsi qu'à l'aide de la notation graphique permettant de représenter certains de ces stéréotypes. Les stéréotypes ne faisant pas partie des extensions standard des ouvrages [1] et [2] sur le langage UML sont signalés par un astérisque (*). Pour une présentation générale du langage UML, consultez l'annexe A.

B.2 Stéréotypes

paquetage de plus haut niveau

système de cas d'utilisation

modèle

modèle des cas d'utilisation

S'applique à

Stéréotype

1

B r è v e description •MHHHnMHHHHMI^HMH^HHHIHHRHHHHI^HMIHHHHHH

Modèle contenant des acteurs et des cas d'utilisation, ainsi que leurs relations ; modèle décrivant ce que le système doit faire pour ses utilisateurs et sous quelles contraintes. Paquetage de plus haut niveau du modèle des cas d'utilisation (« système de cas d'utilisation » est un sous-type de « paquetageDePlusHautNiveau »).

l

I I

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

modèle

modèle d'analyse

S'applique à

Stéréotype

! système d'analyse

paquetage de plus haut niveau

paquetage

paquetage d'analyse*

collaboration

réalisation-analyse de cas

classe

classe frontière

classe

classe entité

classe

classe de contrôle

; paquetage de service* modèle de conception

système de conception classe de conception*

paquetage

modèle

sous-système de plus haut niveau classe

B r è v e description

Modèle objet dont les buts sont : (1) de décrire précisément les besoins ; (2) de les structurer de manière à en faciliter la compréhension, la préparation, la modification et, d'une manière générale, la maintenance ; et (3) de servir d'entrée principale au façonnage du système en conception et en implémentation - y compris avec son architecture.

:

Stéréotype

S'applique à

sous-système

sous-système de conception

collaboration

réalisation-conception de cas d'utilisation*

sous-système de service*

sous-système

modèle

modèle d'implémentation

modèle

modèle de déploiement*

sous-système

sous-système d'implémentation

B

Modèle objet décrivant la distribution physique du système par la répartition des fonctions sur les nœuds de calcul du réseau. Modèle objet décrivant la façon dont les éléments du modèle de conception, tels que les classes de conception, sont implémentés par des composants tels que des fichiers et des exécutables de code source.

sous-système de plus haut niveau

modèle

modèle des tests*

composant de test*


Collaboration du modèle de conception décrivant la façon dont est réalisé et effectué un cas d'utilisation particulier, en termes de soussystèmes de conception, de classes de conception et des objets qu'elles contiennent. Sous-système fournissant le moyen d'agencer les artefacts du modèle de conception en portions gérables. Un sous-système de conception peut se composer de classes de conception, de réalisations-conception de cas d'utilisation, d'interfaces et (de façon récursive) d'autres sous-systèmes de conception.

Paquetage de plus haut niveau du modèle d'analyse (« système d'analyse » est un sous-type de « paquetageDePlusHautNiveau »). Classe du modèle d'analyse représentant la coordination, le séquencement et le contrôle d'autre objets, souvent utilisée pour encapsuler le contrôle lié à un cas d'utilisation spécifique.

Variante d'un sous-système de conception utilisé à un niveau inférieur de la hiérarchie des sous-systèmes de conception (dans le modèle de conception) pour structurer le système en fonction des services qu'il fournit.

Classe du modèle d'analyse permettant de modéliser les informations de longue durée, souvent persistantes. Classe du modèle d'analyse permettant de modéliser l'interaction entre le système et ses acteurs, c'est-à-dire les utilisateurs et les systèmes externes. Collaboration dans le modèle d'analyse décrivant la façon dont est réalisé et effectué un cas d'utilisation particulier, en termes de classes d'analyse (c'est-à-dire de classes de contrôle, de classes entités et de classes frontières) et des objets en interaction qu'elles contiennent. j

système d'implémentation

Paquetage fournissant un moyen d'agencer les artefacts du modèle d'analyse en portions gérables. Un paquetage d'analyse peut se composer de classes d'analyse (c'est-à-dire de classes de contrôle, de classes entités et de classes frontières), de réalisations-analyse de cas d'utilisation et (de façon récursive) d'autres paquetages d'analyse. Variante d'un paquetage d'analyse utilisé à un niveau inférieur de la hiérarchie des paquetages d'analyse (dans le modèle d'analyse) pour structurer le système en fonction des services qu'il fournit.

système de test*

Modèle objet décrivant la réalisation physique des cas d'utilisation et s'intéressant à l'impact qu'exercent sur le système considéré les besoins fonctionnels et non fonctionnels ainsi que les autres contraintes liées à l'environnement d'implémentation.

Sous-système de plus haut niveau du modèle d'implémentation (« sous-système d'implémentation » est un sous-type de « paquetageDePlusHautNiveau »). Sous-système fournissant le moyen d'agencer les artefacts du modèle d'implémentation en portions gérables. Un sous-système d'implémentation peut se composer de composants, d'interfaces et (de façon récursive) d'autres sous-systèmes d'implémentation. Modèle décrivant principalement la façon dont les composants exé- • cutables (tels que des constructions) du modèle d'implémentation sont soumis à des tests d'intégration et à des tests système.

paquetage de haut niveau

Sous-système de plus haut niveau du modèle des tests (« sous-système de test » est un sous-type de « paquetageDePlusHautNiveau »).

composant

Composant automatisant une ou plusieurs procédures de test, en totalité ou en partie.

Sous-système de plus haut niveau du modèle de conception (« soussystème de conception » est un sous-type de « paquetageDePlusHautNiveau »). Une classe de conception représente une « abstraction directe » d'une classe ou d'une construction similaire de l'implémentation du système.

I

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

3

Valeurs marquées

réalisation-conception de cas d'utilisation

dgences Implémenta-

réalisation-conception de cas d'utilisation

il d'événeents-concep>n

classe de conception

agences implémentaon

réalisation-analyse de cas d'utilisation

xigences partiulières

Description textuelle expliquant et complétant les diagrammes (et leurs étiquettes) définissant la réalisation de cas d'utilisation.

réalisation-analyse de cas d'utilisation

«1 d'événelonts-analyse

Description textuelle recueillant les exigences non fonctionnelles pesant sur une classe d'analyse. Il s'agit d'exigences spécifiées en analyse, mais qui sont plus efficacement prises en charge par la conception et l'implémentation.

classe d'analyse (classe entité, frontière ou de contrôle)


cas d'utilisation


cas d'utilisation

nt d'événeîents

modèle des cas d'utilisation

escription énérale (ou 'ensemble)

S'applique à

Valeur narquée


Figure B.1 Les trois stéréotypes de classes standard utilisés en analyse.

B

Solution 1 :

û

Compte

O

Interface guichet

Ô

Solution 2:

Description textuelle destinée à donner une explication globale du modèle des cas d'utilisation.

«entité» Compte

s~\

Description textuelle de la séquence 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 formulées dans le flot d'événements correspondant.

«frontière» _^ Interface hÇ_) guichet

«contrôle» Retrait

/<\ w

B.5 Références James RiJMBAUGH, Ivar JACOBSON et Grady BOOCH, Unified Modeling Language Référence Manual, Reading, MA, Addison-Wesley, 1998.

2

OMG Unified Modeling Language Spécification, Object Management Group, Framingham, MA, 1998. Internet : www.omg.org.

1

Description textuelle recueillant toutes les exigences, telles que les exigences non fonctionnelles, pesant sur une réalisation de cas d'utilisation. Il s'agit d'exigences spécifiées en analyse, mais qui sont plus efficacement prises en charge par la conception et S l'implémentation. Description textuelle recueillant les exigences, telles que les exigences non fonctionnelles, pesant sur une classe de conception. ; Il s'agit d'exigences spécifiées en conception, mais qui sont plus efficacement prises en charge par l'implémentation. Description textuelle expliquant et complétant les diagrammes i (et leurs étiquettes) définissant la réalisation de cas d'utilisation. I Description textuelle recueillant toutes les exigences, telles que les exigences non fonctionnelles, pesant sur une réalisation de cas d'utilisation. Il s'agit d'exigences spécifiées en conception, mais qui sont plus efficacement prises en charge par l'implémentation.

i Notation graphique I .i plupart des stéréotypes présentés dans la section B.2 n'imposent aucun nouveau symbole p.i|iln<|iic spécifique et peuvent être désignés par le nom du stéréotype entre guillemets I < i > placé dans le symbole du stéréotype utilisé. toutefois les classes de contrôle et les classes entités et frontières exigent de nouveaux symi n 'i- d.. r ris dans la ligure B . l .

c

i I

C Glossaire général C.1 Introduction Cette annexe regroupe et définit les termes généraux employés pour décrire le Processus unifié, à l'exception des termes liés à UML et aux extensions d'UML spécifiques au Processus unifié, qui font respectivement l'objet des annexes A (« Présentation générale du langage UML ») et B (« Extensions du langage UML spécifiques au Processus unifié »).

C.2 Termes

I

1 p r

abstraction Caractéristiques essentielles d'une entité distinguant celle-ci de tous les autres types d'entités. Une abstraction définit une frontière par rapport au point de vue du spectateur. activité Unité de travail tangible réalisée par un travailleur dans un enchaînement d'activités. Une activité (1) implique une responsabilité définie pour le travailleur, (2) livre un résultat défini (un ensemble d'artefacts) à partir d'une entrée définie (un autre ensemble d'artefacts) et (3) représente une unité de travail aux frontières parfaitement définies. D sera sans doute fait référence à ce type d'activité dans un plan de projet lors de l'affectation de tâches à des individus. Peut également être vue comme l'exécution d'une opération par un travailleur. Voir artefact, travailleur. analyse (enchaînement d'activités) Enchaînement d'activités principal dont le premier objectif est d'analyser les besoins tels qu'ils ont été décrits dans la formulation des besoins, en les affinant et en les structurant. Le but est (1) de parvenir à une compréhension plus précise des besoins et (2) d'en livrer une description simple à entretenir et facilitant la structuration du système dans son ensemble, y compris de son architecture.

anomalie Défaut du système, tel que le symptôme d'une défaillance logicielle découverte au cours des tests ou un problème détecté lors d'une réunion de révision. Voir tests. approche en cascade approche du développement de systèmes dans laquelle le développement s'organise comme une séquence linéaire de travail, par exemple dans l'ordre suivant : formulation des besoins, analyse, conception, implémentation et tests. Voir besoins, analyse, conception, implémentation, tests. architecture Ensemble des décisions significatives concernant l'organisation d'un système logiciel, la sélection des éléments structurels dont est composé le système et de leurs interfaces, ainsi que leur comportement tel qu'il est spécifié dans les collaborations entre ces éléments, la composition de ces éléments structurels et comportementaux en sous-systèmes progressivement plus importants, et le style architectural guidant cette organisation : ces éléments 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é à réagir aux changements, de réutilisation, de clarté, de contraintes et de compromis économiques et technologiques, enfin de préoccupations esthétiques. architecture de référence Référence livrée à la fin de la phase d'élaboration, essentiellement centrée sur l'architecture du système. Voir élaboration, architecture, référence. artefact Information tangible ( 1 ) créée, modifiée et utilisée par les travailleurs dans la réalisation de leurs activités, (2) représentant un domaine de responsabilité et (3) susceptible d'être placée sous un contrôle de version à part. Un artefact peut être un modèle, un élément de modèle ou un document. Voir travailleur, activité. artefact de gestion Artefact autre qu'un artefact d'ingénierie, tel qu'un plan du projet créé par le chef de projet. Voir artefact d'ingénierie. artefact d'ingénierie Artefact créé dans l'un des enchaînements d'activités principaux. Voir enchaînement d'activités principal. besoin

Glossaire g é n é r a l ANNEXE

C

469

besoins (enchaînement d'activités) Un des enchaînements d'activités principaux dont le propos essentiel est d'orienter le développement vers le système approprié. I l faudra, pour cela, décrire les besoins du système avec suffisamment de justesse pour parvenir à un accord entre le client (et les utilisateurs) et les développeurs du système sur ce que devra et ne devra pas faire le système. Voir besoin, client, développeur. cas de test Spécification d'un cas permettant de tester le système, indiquant ce qui doit être testé à partir de quelles entrées, avec quel résultat et sous quelles conditions. centré sur l'architecture Dans le contexte du cycle de vie logiciel, signifie que l'architecture d'un système sert d'artefact principal à la conceptualisation, la construction, la gestion et l'évolution du système en cours de développement. client Personne, organisation ou groupe de personnes commandant la mise au point d'un système, soit construit ex nihilo, soit affiné par des versions successives. cohésion Capacité d'une entité (telle qu'un système, un sous-système ou un paquetage) à maintenir ses différentes parties en un ensemble. conception (enchaînement d'activités) Un des enchaînements d'activités principaux dont le premier objectif est de formuler des modèles centrés sur les exigences non fonctionnelles et le domaine de la solution, et préparant l'implémentation et les tests du système. concurrence Se produit lorsque plusieurs travaux plus ou moins indépendants (threads, processus) partagent simultanément une même unité matérielle (processeur). construction Version exécutable du système, concernant généralement une partie spécifique du système. Le développement se déroule à travers une succession de constructions. couche Partie clairement identifiée d'un système, définie par des paquetages ou des soussystèmes. Voir couche spécifique à l'application, couche générale aux applications, couche de middleware, couche de logiciel système.

Condition ou capacité à laquelle doit se conformer un système.

besoin fonctionnel Besoin spécifiant une action qu'un système doit être capable d'effectuer, sans considérer aucune contrainte physique ; besoin spécifiant un comportement d'entrée/sortie d'un système. Voir besoin. besoin non fonctionnel Besoin spécifiant des propriétés du système, telles que les contraintes liées à l'environnement et à l'implémentation, et les exigences en matière de performances, de dépendances de plate-forme, de facilité de maintenance, d'extensibilité et de fiabilité. Besoin spécifiant des contraintes physiques sur un besoin fonctionnel. Voir besoin, exigence de performances, fiabilité, besoin fonctionnel.

couche de logiciel système Couche contenant les logiciels de calcul et de mise en réseau de l'infrastructure, comme les systèmes d'exploitation, les systèmes de gestion de bases de données, les interfaces avec des matériels spécifiques, etc. C'est la couche située au bas de la hiérarchie des couches. Voir couche de middleware. couche de middleware Couche fournissant des briques de base réutilisables (paquetages ou sous-systèmes) pour des infrastructures préfabriquées d'utilitaires et des services indépendants de toute plate-forme, par exemple pour le calcul et l'interopérabilité des objets distribués dans des environnements hétérogènes. I l s'agit, entre autres, des ORB (Object Request Brokers), des infrastructures préfabriquées indépendantes de toute plate-forme permettant la création d'interfaces utilisateur graphiques ou, en général, des

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 spécifique à 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 )

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 de tels c o m p o s a n t s . développeur

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

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

enchaînement

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 .

domaine du p r o b l è m e

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

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. enchaînement d'activités

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 général 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

enchaînement

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

E n c h a î n e m e n t d'activités représentant 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

enchaî-

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 ,

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 r é s u l t a t s des travaux de test, notamment du n i v e a u de

é v a l u a t i o n des tests

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. Voir besoin.

exigence

exigence de performances

E x i g e n c e i m p o s a n t des conditions de comportement aux

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 .

exigence non fonctionnelle exigence s u p p l é m e n t a i r e

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

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 m é t i e r . Voir b e s o i n . fiabilité

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 .

gestion de configuration

T â c h e consistant à d é f i n i r et à assurer la maintenance des confi-

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 » .

Voir

implémentation (enchaînement d'activités)

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. incrément

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 é . 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

i n g é n i e r i e vers l'aval

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 . 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

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 ) . intégration incrémentale

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

Interface par l ' i n t e r m é d i a i r e de laquelle un utilisateur dialogue avec

le s y s t è m e . itératif

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

de versions e x é c u t a b l e s . itération

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 général 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 .

m a s s e des c a s d ' u t i l i s a t i o n

E n s e m b l e complet des actions de tous les c a s d'utilisation

d'un m o d è l e des c a s d'utilisation. mécanisme

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

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 .

Voir

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 architectural

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 ,

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

à égal

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

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

phase de c r é a t i o n

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 boration. 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

phase d ' é l a b o r a t i o n l'architecture.

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

phase de transition

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 général H?PW*3R| ANNExt.

p r o c e s s u s de d é v e l o p p e m e n t logiciel

c

M»J^|jl

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

prototype architectural

projet.

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.

référence

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. rétro-ingénierie

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. R i s q u e l i é à des artefacts de gestion et à des aspects tels que les res-

risque non technique

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. 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-

risque technique

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

S y s t è m e offrant un ensemble c o h é r e n t de c a s d'utilisation à un

final.

s y s t è m e existant

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

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. système hérité

Voir s y s t è m e existant.

s y s t è m e patrimoine

Voir s y s t è m e existant.

tests ( e n c h a î n e m e n t d ' a c t i v i t é s )

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

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 général ma ANNEXL C

lests de n o n - r é g r e s s i o n

In

Fait de lester de nouveau une partie ou la totalité d'une cons-

truction déjà lestée lors de constructions p r é c é d e n t e s . Les tests de non-régression servent essentiellement à vérifier qu'une « ancienne fonction » d ' « anciennes constructions » fonctionne toujours lorsqu'est ajoutée une « nouvelle fonction » dans une « nouvelle construction ». Voir lests, construction. travailleur

Fonction pouvant être attribuée à 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 réalisation de certaines activités 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 spécification, 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.

Voir

artefact, Processus unifié, développeur. utilisateur version

H u m a i n ayant une interaction avec le s y s t è m e .

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

Version e x p o s é e aux clients et utilisateurs, externe à l ' é q u i p e du projet.

Voir version. version interne Version non exposée aux clients et utilisateurs, mais uniquement destinée à 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 spécifique ou avantageux, omettant les entités non pertinentes pour ce point de vue.

vue architecturale

Projection dans la structure et le comportement d ' u n m o d è l e spécifique

d'un s y s t è m e , centrée 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 réalisations 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 conservée 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 réalisations 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 centrée sur les exigences non fonctionnelles, y compris les exigences de performances, de m o n t é e en charge et de débit, 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 système comprenant les n œ u d s formant la topologie matérielle du système sur laquelle s'exécute le s y s t è m e ; vue centrée 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 système

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 système comprenant les composants permettant d'assembler et de livrer le s y s t è m e ; vue centrée sur la gestion de configuration des versions du système, e l l e s - m ê m e s constituée de composants quelque peu i n d é p e n d a n t s pouvant être assemblés de diverses façons pour produire un système capable de s'exécuter.

Le processus unifié de developpement_logiciel

Recommend Documents