Recueil Et Specification Demarches Itera

Analyse
des besoins
pour le
développement
logiciel
Recueil et spécification,
démarches itératives et agiles
Jacques Lonchamp
Professeur des universités
Toutes les marques citées dans cet ouvrage
sont des marques déposées par leurs propriétaires respectifs.
Illustration de couverture :
Grey abstract communication © iStock.com/nnnnae
© Dunod, 2015
5 rue Laromiguière, 75005 Paris
www.dunod.com
ISBN 978-2-10-072994-4
Table des matières
AVANT-PROPOS VIII
CHAPITRE 1 • INTRODUCTION
1.1 Le logiciel 1
1.2 Le développement logiciel 3
1.3 La qualité du logiciel 4
1.4 La « crise du logiciel » 5
1.5 La maturité des organisations 8
PARTIE 1
LE DÉVELOPPEMENT LOGICIEL
CHAPITRE 2 • LES ACTIVITÉS DU DÉVELOPPEMENT

2.1 Le recueil des besoins 18
2.2 L’analyse et la spécification des besoins 22
2.3 La conception architecturale et détaillée 26
2.4 L’implantation 28
2.5 Le déploiement 28
2.6 La maintenance 29
2.7 La vérification et la validation (V&V) 30
2.8 La documentation 33
2.9 Les activités de gestion 33
2.10 La distribution efforts/erreurs/coûts 41
CHAPITRE 3 • LA MODÉLISATION – UML

3.1 La notion de modèle 45
3.2 La modélisation visuelle 47
3.3 Fonctions et objets 47
3.4 Le langage UML 49
3.5 Les principaux diagrammes UML 51
IV Table des matières
CHAPITRE 4 • LES MODÈLES DE DÉVELOPPEMENT

4.1 Les modèles linéaires 57
4.2 Les modèles centrés sur des prototypes 60
4.3 Les modèles itératifs et incrémentaux 61
4.4 Les modèles agiles 63
4.5 Les autres modèles de développement 67
CHAPITRE 5 • (R)UP, XP ET SCRUM

5.1 (Rational) Unified Process – (R)UP 73
5.2 EXtreme Programming (XP) 79
5.3 Scrum 84
5.4 Le développement dirigé par les tests 92
5.5 Les outils du développement agile 97
PARTIE 2
LA MODÉLISATION MÉTIER
CHAPITRE 6 • INTRODUCTION À LA MODÉLISATION MÉTIER

6.1 Définition 105
6.2 La modélisation métier avec UML 106
6.3 Une ébauche de démarche 109
CHAPITRE 7 • LA MODÉLISATION DES PROCESSUS MÉTIER

7.1 Les acteurs et intervenants métier 113
7.2 Les processus métier 114
7.3 Un exemple de processus métier 114
7.4 Les diagrammes UML associés 116
7.5 Vers les spécifications logicielles 121
CHAPITRE 8 • LA MODÉLISATION DU DOMAINE

8.2 Éléments du modèle du domaine 125
8.3 L’identification des classes du domaine 127
8.4 L’identification des associations du domaine 130
8.5 Un exemple 131
Table des matières V
CHAPITRE 9 • LES SPÉCIFICATIONS FORMELLES AVEC OCL

9.1 Présentation du langage OCL 137
9.2 Caractéristiques du langage OCL 139
9.3 Syntaxe de base des contraintes OCL 140
9.4 Écriture d’expressions OCL complexes 142
9.5 Des conseils d’utilisation 146
PARTIE 3
LA MODÉLISATION DES BESOINS
CHAPITRE 10 • LES USER STORIES

10.2 Des éléments de méthodologie 152
10.3 Un exemple 154
CHAPITRE 11 • LES CAS D’UTILISATION

11.2 La description textuelle du cas 160
11.3 Le diagramme de cas d’utilisation 161
11.5 User stories vs cas d’utilisation 164
11.6 Un exemple 165
CHAPITRE 12 • LES AUTRES MODÈLES UML

12.1 Les diagrammes de séquences « système » 169
12.2 Les diagrammes d’activités des cas 170
PARTIE 4
LA MODÉLISATION DE L’APPLICATION
CHAPITRE 13 • LE MODÈLE DES CLASSES D’ANALYSE

13.3 Un exemple 179
CHAPITRE 14 • LES MODÈLES UML COMPLÉMENTAIRES

14.1 Les diagrammes de séquences 183
14.2 Les diagrammes d’états 183
VI Table des matières
CHAPITRE 15 • LE MODÈLE DE NAVIGATION

15.2 Les composants du modèle de navigation 188
15.3 Un exemple 188
PARTIE 5
LES ÉTUDES DE CAS
CHAPITRE 16 • ÉTUDE DE CAS 1 – LA PHASE D’INITIALISATION

16.1 Les acteurs 195
16.2 Les cas d’utilisation 196
16.3 Les exigences non fonctionnelles 198
16.4 Une ébauche d’architecture fonctionnelle 198
16.5 La prioritisation des cas 200
16.6 Une première ébauche du modèle de classes 201
16.7 Les maquettes des principaux écrans 203
CHAPITRE 17 • ÉTUDE DE CAS 1 – LA PHASE D’ÉLABORATION

17.1 La spécification détaillée des cas 209
17.2 Les diagrammes de séquences système 212
17.3 Les diagrammes d’activités des cas 213
17.4 La structuration du diagramme des cas 213
17.5 Les modèles des classes d’analyse 214
17.6 La dynamique des classes d’analyse 215
17.7 Le prototypage 215
CHAPITRE 18 • ÉTUDE DE CAS 2 – LES USER STORIES

18.1 Le rappel des règles du jeu 217
18.2 L’analyse du jeu 220
18.3 Le dévelopement du jeu 224
CHAPITRE 19 • ÉTUDE DE CAS 2 – LES CAS D’UTILISATION

19.1 Les cas d’utilisation du jeu 233
19.2 Le diagramme des cas d’utilisation 243
CHAPITRE 20 • ÉTUDE DE CAS 2 – LES CLASSES DU DOMAINE

20.1 L’analyse textuelle 247
20.2 Le modèle des classes du domaine 248
Table des matières VII
20.3 L’analyse des entités complexes du domaine 251
CONCLUSION 253
CORRIGÉS DES EXERCICES 255
BIBLIOGRAPHIE 301
INDEX 305
Avant-propos
POURQUOI CET OUVRAGE ?

Le présent ouvrage est l’aboutissement d’une longue pratique de l’enseignement du
développement logiciel à divers publics universitaires et de formation continue. Plus
précisément, ce sont les insatisfactions éprouvées à la lecture des documents pédagogiques
existants, à l’occasion d’une réflexion nationale sur la formation des informaticiens, qui ont
constitué l’élément déclencheur de sa rédaction.
Sa première moitié est consacrée aux styles et processus de développement des applications
informatiques. Sa seconde moitié détaille les techniques utilisables lors de toutes les activités
en amont de la conception, qui vont du recueil des besoins à la spécification de l’application.
Dans la suite du volume, cet ensemble d’activités sera désigné par l’expression « analyse des
besoins » ou, encore plus simplement, par le terme « analyse ».
Cet ouvrage reprend les principes d’un premier volume paru dans la même collection
et consacré de manière complémentaire à la conception des applications (Conception
d’applications en Java/JEE. Principes, patterns et architectures. Jacques Lonchamp,
Dunod, 2014). Les principes communs qui sous-tendent ces deux volumes sont résumés au
paragraphe suivant.
Alors qu’il est possible de parler de la conception de manière assez indépendante des styles
et processus de développement logiciel, ce n’est pas du tout le cas pour l’analyse : on ne la
pratique pas de la même manière dans un développement « agile », fondé sur l’adaptation
continue aux évolutions des besoins grâce à un dialogue permanent avec le client et des
itérations courtes, et dans un développement « classique », fondé sur le recueil initial
exhaustif des besoins et la planification rigide de toutes les activités de production. C’est
ce qui justifie le regroupement au sein d’un même volume de la description des styles et
X Avant-propos
processus de développement avant la présentation des connaissances théoriques et pratiques

relatives à l’analyse.
LA CONCEPTION DE L’OUVRAGE
Le positionnement dans le cursus
Un cursus de formation à l’informatique ressemble à une fusée à trois étages.
L’étage disciplinaire vise l’acquisition des savoirs conceptuels et techniques de base, grâce à
des enseignements ciblés vers des domaines bien délimités.
L’étage intégratif doit permettre de tisser des liens entre les savoirs disciplinaires, de les
approfondir en conséquence, et de prendre conscience des enjeux réels dans le monde
professionnel.
L’étage professionnalisant, qui s’appuie sur la compréhension globale des grandes
thématiques que procure l’étage précédent, vise l’approfondissement de thèmes techniques
spécialisés permettant de passer de la compréhension à la maîtrise effective de certaines
facettes du métier.
Les deux ouvrages proposés, sur la conception d’une part et sur les processus et l’analyse
d’autre part, relèvent clairement de la phase « intégrative », pour laquelle le manque de
documents pédagogiques est criant.
Une progression logique des apprentissages

Dans le volume sur la conception, les savoirs en conception ont été ancrés dans les
connaissances préalables en programmation. En effet, tout programmeur Java utilise au sein
du JDK, sans en être nécessairement conscient, les patrons (patterns) de conception les plus
connus et les plus utiles. Leur compréhension et leur mémorisation se trouvent grandement
facilités quand cet ancrage est rendu explicite.
Dans ce second volume consacré aux concepts et méthodes de l’analyse, l’importance de
la connaissance préalable des styles et processus de développement a déjà été évoquée. Par
ailleurs, beaucoup de concepts de l’analyse prennent du sens à travers la compréhension
de ce que peut être une conception et une réalisation de qualité, comme la modélisation
de l’application en termes de classes frontières, de classes de contrôle et de classes entité.
Une progression logique des apprentissages en développement des applications peut donc se
schématiser par :
programmation −→ conception −→ styles et processus de développement −→ analyse.
Pour une « culture générale » de l’analyse

Le côté très parcellaire de beaucoup de documents existants est aux antipodes de ce qu’on
peut attendre pour la phase « intégrative » du cursus : l’analyse ne se réduit pas aux seuls
besoins fonctionnels, la modélisation au seul langage UML et les processus aux seules
approches agiles.
Avant-propos XI
Sans tomber dans le travers encyclopédique des énormes « bibles » du génie logiciel (comme
[Pre09] ou [Som04]), cet ouvrage cherche à donner une présentation synthétique large des
thèmes abordés, une forme de « culture générale » de l’analyse, tout en approfondissant les
points essentiels des pratiques les plus courantes.
L’importance de la mise en pratique

Beaucoup d’ouvrages de synthèse ne proposent ni exercices d’application ni études de cas,
au contraire de ceux centrés sur des thématiques spécialisées. Or toute faiblesse sur ce point
risque d’accréditer l’idée auprès des étudiants que ces documents se limitent à un discours
théorique, éloigné de la pratique de terrain, et qui peut donc être négligé.
Au contraire, cet ouvrage propose près de 70 exercices d’application tous corrigés, associés
à chacun des chapitres, et deux études de cas finales très détaillées. La majorité des exercices
ont été glanés sur le Web et retravaillés. Que leurs auteurs originaux, souvent impossibles à
déterminer, soient ici remerciés collectivement.
POUR QUELS LECTEURS ?

Cet ouvrage pédagogique s’adresse prioritairement aux étudiants de deuxième et troisième
année des cursus spécialisés en informatique, quelle que soit leur nature (DUT/LP, L2/L3,
deuxième et troisième années d’écoles d’ingénieurs).
Il peut bien entendu être également utile à tous les praticiens de l’informatique qui souhaitent
rafraîchir ou consolider leurs connaissances en processus de développement et analyse des
besoins.
LE PLAN DE L’OUVRAGE
La première partie s’attache à présenter de manière synthétique les différentes facettes du
développement logiciel en insistant plus particulièrement sur les activités de l’ingénierie des
besoins en amont de la conception des applications qui sont au cœur de l’ouvrage.
– Le chapitre 1 définit le logiciel et la problématique de son développement au sein des
organisations.
– Le chapitre 2 est une introduction à l’ensemble des activités du développement logiciel.
– Le chapitre 3 discute de la modélisation, qui est à la base de toute la démarche d’analyse
et de conception, et donne quelques rappels sur la notation UML.
– Le chapitre 4 présente les différentes organisations du développement logiciel, appelées
communément « modèles de cycle de vie ».
– Le chapitre 5 entre dans le détail des « méthodes » de développement objet les plus en
vogue actuellement : (Rational) Unified Process – (R)UP, eXtreme Programming – XP,
Scrum.
XII Avant-propos
Les trois parties suivantes du livre décrivent les principales techniques et notations utilisables
concrètement pendant l’analyse.
La deuxième partie est consacrée aux techniques de la modélisation métier.
– Le chapitre 6 introduit la problématique de la modélisation métier et de l’utilisation du
langage UML à cette fin.
– Le chapitre 7 détaille la modélisation des processus métier.
– Le chapitre 8 décrit la modélisation des entités métier ou modélisation du domaine.
– Le chapitre 9 introduit la spécification formelle d’expressions avec le langage OCL
(Object Constraint Language) qui sert souvent à préciser les modèles de classes du
domaine. Mais ce langage peut bien entendu être utilisé dans d’autres contextes et avec
d’autres modèles UML.
La troisième partie est dédiée aux techniques de la modélisation des besoins.

– Le chapitre 10 présente l’utilisation des user stories (scénarios client).
– Le chapitre 11 décrit l’utilisation des cas d’utilisation (use cases).
– Le chapitre 12 aborde l’utilisation d’autres modèles UML en complément des cas
d’utilisation : les diagrammes de séquences « système » et les diagrammes d’activités des
cas.
La quatrième partie est consacrée aux techniques de la modélisation des applications.

– Le chapitre 13 présente le modèle des classes d’analyse.
– Le chapitre 14 traite des modélisations UML complémentaires au modèle des classes
d’analyse sous la forme de diagrammes de séquences et de diagrammes d’états.
– Le chapitre 15 aborde les aspects liés aux interfaces homme-machine (IHM) à travers le
modèle de navigation.
La cinquième et dernière partie du livre présente en détail deux études de cas.

La première porte sur l’analyse d’un site de commerce électronique selon les préconisations
du processus unifié (R)UP.
– Le chapitre 16 décrit l’unique itération de la phase d’initialisation.
– Le chapitre 17 décrit la première itération de la phase d’élaboration.
La deuxième étude de cas porte sur l’analyse d’un jeu de plateau (type Monopoly).
– Le chapitre 18 décrit informellement les règles du jeu, puis donne une spécification de
l’application correspondante sous forme de user stories.
– Le chapitre 19 donne une spécification de l’application en termes de cas d’utilisation et
de diagramme de cas.
– Le chapitre 20 décrit le modèle des classes du domaine et illustre les diagrammes d’états
associés aux entités complexes du jeu.
Chapitre 1
Introduction
1.1 LE LOGICIEL
1.1.1. L’importance du logiciel
Beaucoup d’aspects de notre quotidien ne peuvent être imaginés aujourd’hui sans logiciel.
C’est le cas entre autres des domaines du transport, du commerce, des communications, de la
médecine, des finances ou des loisirs. Cette omniprésence du logiciel fait que nos vies et le
fonctionnement de nos sociétés dépendent fortement de sa qualité.
Les erreurs logicielles peuvent causer de vrais désastres, économiques ou sanitaires. Un
exemple emblématique est l’explosion de la première fusée Ariane 5 en 1996, qui a coûté
plus d’un demi-milliard de dollars, à cause du dépassement de capacité d’une variable lors
d’un calcul. Dans un registre différent, tout le monde se souvient de la grande peur du « bug
de l’an 2000 » et de son coût astronomique, estimé entre 300 et 5000 milliards de dollars !
1.1.2. La diversité du logiciel

Il existe une grande variété de logiciels et de nombreuses manières de les classer.
Une première différenciation oppose les logiciels « génériques », ou progiciels, qui sont
vendus en grand nombre comme des produits de consommation, aux logiciels « spécifiques »
qui sont développés pour un contexte et un client particulier.
Une seconde différenciation repose sur la nature de la dépendance entre les logiciels et leurs
environnements. Elle distingue trois classes :
2 1 • Introduction
– les logiciels « autonomes » (standalone), comme les traitements de texte, les logiciels de
calcul ou les jeux,
– les logiciels qui gèrent des processus (process support), aussi bien industriels que de
gestion,
– les logiciels « embarqués » dans des systèmes (embedded), comme dans les transports, la
téléphonie ou les satellites.
Dans cette dernière classe, on a coutume de parler plutôt de « développement système »

que de « développement logiciel », car les problématiques matérielles et logicielles y sont
indissociables.
Une troisième différenciation sépare les logiciels isolés des « lignes de produits logiciels ».
Celles-ci regroupent une famille de logiciels présentant de fortes similarités et un même
domaine d’application, comme des applications pour téléphones mobiles. Elles sont
développées à partir d’éléments réutilisables (assets) qui peuvent être des exigences,
des modèles, des codes (composants), des plans de tests, etc.
Dans les grandes organisations, on particularise souvent ce qu’on appelle les « logiciels du
patrimoine » (legacy software). Ce sont les applications les plus anciennes, complexes et peu
documentées, auxquelles on touche le moins possible tant qu’elles remplissent correctement
leurs fonctions en général vitales pour l’organisation.
Enfin les « logiciels web », ou « applications web », sont souvent considérés comme une
catégorie à part. Ce sont des logiciels hébergés sur un serveur web et manipulables via
les réseaux, Internet ou réseaux locaux, grâce à un navigateur web. On peut citer comme
particularités notables :
– les accès concurrents qu’ils subissent, avec une charge difficilement prédictible,
– leurs exigences élevées de performance, de disponibilité et de sécurité,
– la prédominance des données par rapport aux traitements,
– leurs besoins fréquents d’évolution,
– l’importance de l’ergonomie et de l’esthétique dans leur conception.
On comprend que la notion de qualité et les exigences qui s’y attachent peuvent varier
considérablement pour toute cette diversité de logiciels.
1.1.3. La complexité du logiciel

Techniquement, le terme « logiciel » désigne un riche ensemble d’artefacts incluant :
– des codes sources et des exécutables,
– des programmes et des données de test,
– des fichiers de configuration,
– des documentations « externes » à destination des utilisateurs,
– des documentations « internes » à destination de l’équipe de développement, etc.
1.2 Le développement logiciel 3
1.2 LE DÉVELOPPEMENT LOGICIEL

1.2.1. Les acteurs du développement
Le développement logiciel est une activité intellectuelle à forte composante humaine (human-
intensive). En 2013, le secteur du conseil, des études et des services informatiques en France
comptait 575 000 emplois, hors fonction publique d’État.
Pendant le développement d’un logiciel, outre les membres de l’équipe de développement
proprement dite, les autres acteurs à considérer sont le client (l’investisseur), les utilisateurs
finaux et d’éventuels sous-traitants.
1.2.2. Les contextes du développement

Le logiciel peut être développé dans plusieurs contextes assez différents.
– Chez des éditeurs de logiciels qui commercialisent les progiciels qu’ils développent.
– Dans des Sociétés de service en ingénierie informatique (SSII), également nommées
Entreprises de services du numérique (ESN), qui répondent aux besoins d’externalisation
des projets informatiques, en développant des logiciels pour le compte de leurs clients.
– En interne, dans des organisations de toutes natures, entreprises, administrations et
associations.
– Sur Internet, au moins en partie par des développeurs bénévoles, pour les logiciels libres.
1.2.3. Les activités du développement

Schématiquement, le développement logiciel consiste à transformer une idée ou un besoin
en un logiciel fonctionnel. L’idée est produite par un client ou maître d’ouvrage (MOA).
Le logiciel correspondant est développé par un fournisseur ou maître d’œuvre (MOE), puis
exploité par des utilisateurs finaux. Lorsqu’il s’agit d’entités on parle de Maîtrise d’ouvrage
(MOA) et de Maîtrise d’œuvre (MOE). La MOA peut être assistée en externe et en interne,
souvent par d’anciens informaticiens ayant une bonne pratique de la conduite des projets : on
parle de MOAD, pour maîtrise d’ouvrage déléguée.
F IGURE 1.1 Le développement logiciel
Comme cela sera détaillé dans la suite de l’ouvrage, le développement logiciel comprend
en amont une phase centrée sur les besoins (ou exigences). Il s’agit pour toutes les parties
prenantes d’un projet informatique de s’accorder sur l’ensemble des besoins auxquels devra
répondre le système ou logiciel à construire. Le terme d’« ingénierie des besoins » ou
« ingénierie des exigences » (requirements engineering) caractérise toutes les activités liées
à la gestion des besoins, y compris celles qui se poursuivent tout au long du développement,
comme la gestion des évolutions des besoins et de leur traçabilité.
Le présent ouvrage est plus précisément centré sur les phases en amont du développement, à
savoir le recueil, l’analyse, la spécification, la revue et le classement par priorités des besoins,
qui précèdent la conception du logiciel. Cet ensemble d’activités est désigné dans la suite de
l’ouvrage par l’expression « analyse des besoins » ou encore plus simplement par le terme
« analyse ».
Comme la manière de conduire une analyse dépend fortement du style de développement

suivi, l’ouvrage commence par une description en profondeur des différents styles et
processus de développement logiciel.
' () #
"#

$#
% &

!
F IGURE 1.2 Les thèmes principaux de l’ouvrage
1.3 LA QUALITÉ DU LOGICIEL

La notion de « qualité du logiciel » n’est pas simple à définir car elle est multiforme et dépend
du point de vue adopté, client ou fournisseur. Pour le client, le logiciel doit répondre à ses
besoins (adéquation), être efficace, facile d’apprentissage et d’utilisation (ergonomie), être
fiable, robuste et sûr, être peu coûteux et livré dans les délais. Pour le fournisseur, le coût et la
durée du développement sont généralement primordiaux, de même que la facilité d’extension,
de maintenance, d’adaptation et d’évolution, ainsi que la portabilité et l’interopérabilité.
Il est important de ne pas confondre les termes qui caractérisent les différentes formes de
qualité. La signification des plus courants d’entre eux est rappelée dans le tableau suivant.
Terme français Terme anglais Signification

Disponibilité Availability Capacité à délivrer le service attendu
Fiabilité Reliability Capacité à maintenir la continuité du service attendu
Sécurité Security Absence de conséquences catastrophiques
Sûreté Safety Protection contre les actions illicites
Intégrité Integrity Absence de d’altérations inapropriées
Confidentialité Confidentiality Absence de divulgations non autorisées
Maintenabilité Maintainability Aptitude aux réparations et aux évolutions
On résume parfois la variété de ce qui est attendu d’un logiciel par le sigle CQFD, pour
Coûts, Qualité, Fonctionnalités, Délais. Cette vision simplifiée est suffisante pour montrer les
tensions qui peuvent exister entre les principaux critères. Idéalement, il faudrait pouvoir faire
du logiciel « chic et pas cher » (F élevé et C faible), ce qui n’est pas simple, et de le faire
« vite et bien » (D faible et Q élevé), ce qui n’est également pas évident !
Comme cela a déjà été évoqué, tous ces critères sont bien entendu à pondérer en fonction du
type de logiciel à développer : du logiciel critique pour la sécurité (safety critical), dont les
défaillances peuvent avoir des conséquences désastreuses en termes humains, économiques
ou environnementaux, jusqu’au logiciel « jetable », beaucoup moins exigeant.
1.4 LA « CRISE DU LOGICIEL »

1.4.1. Le constat
L’expression « crise du logiciel » est employée depuis la fin des années 1960 pour rendre
compte de toutes les difficultés associées à sa production : délais de livraison et budgets
non respectés, non-satisfaction de certains besoins des clients ou utilisateurs, difficultés
d’utilisation et de maintenance, etc.
De nombreuses études rendent compte de ce phénomène en classant les développements en
trois grandes catégories :
– Succès : quand le logiciel est livré à temps, sans dépassement de budget et avec toutes les
fonctionnalités initialement prévues.
– Mitigé : quand le logiciel est livré et opérationnel, mais avec moins de fonctionnalités
qu’attendu ou un dépassement notable de budget ou des délais.
– Échec : quand le logiciel est abandonné en cours de développement ou livré et non utilisé.
Une des toutes premières études, réalisée par les militaires du Department of Defense (DoD)
américain dans les années 1980, donnait des résultats absolument catastrophiques : succès
5 % (dont utilisation « tel que » 2 % et avec de faibles modifications 3 %), mitigé 19 %,
échec 76 % (dont jamais utilisé 47 % et non livré 29 %). Depuis, si on se base sur les études
annuelles du Standish Group, connues sous le nom de Chaos Report et résumées dans le
tableau suivant, les progrès semblent à la fois réels et assez lents.
Année Succès Mitigé Échec

1995 16 % 53 % 31 %
2000 28 % 49 % 23 %
2006 35 % 46 % 19 %
2010 37 % 42 % 21 %
2013 39 % 43 % 19 %
Des exemples d’abandon de logiciels extrêmement coûteux continuent encore et toujours à

être dénoncés dans la presse, comme celui du Logiciel unique à vocation interarmées de la
solde (LOUVOIS) lancé en France en 1996 et dont l’abandon a été annoncé en novembre
2013. Son développement a été marqué par plusieurs crises, relances et réorientations entre
2001 et 2011, avant l’abandon final en raison de son incapacité à assurer son rôle de manière
fiable avec des dizaines de millions d’euros de moins-perçus et de trop-perçus dans les soldes
des militaires français. . .
1.4.2. L’influence de la complexité

Les progrès, bien qu’indéniables, sont atténués car la complexité des applications ne cesse de
s’accroître au fil des années ainsi que les exigences des utilisateurs.
Or plus la taille s’accroît plus les échecs sont fréquents. Dans l’étude du Standish Group de
2012 on trouve une comparaison entre « petits projets » de moins de 1 million de dollars et
« gros projets » de plus de 10 millions de dollars qui le démontre clairement.
F IGURE 1.3 Influence de la complexité sur la réussite des projets
Pour donner quelques ordres de grandeur à propos de la complexité des logiciels, on peut
indiquer qu’un compilateur simple correspond à 20 ou 30 KLS (milliers de lignes source), un
logiciel de modélisation 3D correspond à 200 KLS, le logiciel de contrôle d’un sous-marin
nucléaire exige 1 000 KLS et celui de la navette spatiale plus de 2 200 KLS. Soit un facteur
100 entre ces extrêmes.
1.4.3. Les causes

Parmi les multiples causes avancées, beaucoup sont liées à la nature même du logiciel et donc
très difficiles à combattre :
– Le logiciel est un objet immatériel, une structure d’information.
– Le logiciel est très malléable, au sens de facile à modifier, avec parfois des conséquences
majeures pour des modifications infimes.
– Les défaillances et erreurs ne proviennent ni de défauts dans les matériaux ni de
phénomènes d’usure dont on peut connaître les lois d’occurrence, mais d’erreurs
humaines, peu prévisibles. Beaucoup de ces erreurs sont difficiles à découvrir avant la
livraison du produit chez le client.
– Le logiciel ne s’use pas et ne se répare pas. Il n’y a pas de pièces de rechange ! Par contre,
le logiciel peu devenir assez rapidement obsolète par rapport aux concurrents, par rapport
au contexte technique, par rapport aux logiciels qui l’entourent. Il s’agit d’un domaine en
évolution extrêmement rapide.
D’autres causes sont plus spécifiquement liées à la difficulté de comprendre les besoins des
clients et des utilisateurs. Elles sont extrêmement importantes et au cœur de la problématique
abordée dans cet ouvrage :
– La trop faible implication des clients et des utilisateurs dans les projets de développement
logiciel.
– La difficulté pour les clients à décrire leurs besoins de façon claire et exhaustive pour ceux
qui développent les applications.
– L’inévitable évolutivité des besoins, résultant par exemple des évolutions fréquentes dans
l’environnement des applications.
Enfin, d’autres causes plus générales résultent de la difficulté à gérer des projets et des
équipes, en particulier quand ils sont de grande taille, comme par exemple :
– la différence de langage et de culture entre les personnels techniques et non techniques,
– le renouvellement rapide du personnel (turnover),
– la difficulté à motiver les personnes sur le long terme, etc.
1.4.4. Les « mythes » du développement logiciel

Beaucoup de croyances erronées, souvent qualifiées de « mythes », gênent la bonne
compréhension du développement logiciel et peuvent contribuer à aggraver les difficultés.
Les cinq mythes suivants sont parmi les plus connus [Pre09] :
– Un vague énoncé est suffisant pour commencer à coder. Il sera toujours temps de voir les
détails plus tard.
En réalité, la connaissance insuffisante des besoins est une source reconnue de retards et
de coûts élevés.
– Les besoins changent sans cesse, mais ce n’est pas grave car le logiciel est flexible.
En réalité, le coût d’une modification augmente considérablement avec l’avancement du
projet. Si on part d’un facteur 1 pour la phase de définition, on estime à un facteur 1,5 à
6 le coût d’une modification en cours de développement et à un facteur 60 à 100, le coût
d’une modification après installation du logiciel.
– Quand un programme est écrit et tourne, le travail du développeur est terminé.
En réalité, la maintenance des applications requiert de 50 à 70 % de l’effort total.
– Tant qu’un programme ne tourne pas, il n’y a aucun moyen d’en vérifier la qualité.
En réalité, on peut procéder à des revues ou inspections des produits du développement
(cf. paragraphe 2.9.4.) qui sont très efficaces pour en améliorer la qualité.
– Si un projet prend du retard, il suffit d’ajouter des programmeurs.
En réalité, le développement du logiciel n’est pas une activité industrielle classique.
Ajouter des programmeurs peut contribuer, au contraire, à aggraver la situation. Ce mythe,
énoncé dans le célèbre ouvrage The mythical Man-Month de Frederick Brooks [Bro75]
est analysé en exercice à la fin du chapitre.
1.4.5. Les solutions

L’étude des différents éléments de solution mis en œuvre aujourd’hui pour combattre la
« crise du logiciel » est au cœur du présent ouvrage.
Pour la phase en amont du développement logiciel, cela recouvre pour l’essentiel quatre
approches complémentaires qui seront étudiées en détail dans la suite de l’ouvrage.
(1) Le recueil des besoins avec les clients et utilisateurs et leur expression initiale à travers
des formes d’expression adaptées.
(2) L’analyse approfondie des besoins à l’aide de langages de modélisation, souvent visuels,
comme UML.
(3) La manière de gérer les développements. L’étude du Standish Group, déjà citée, montre
que la loi de Pareto du 20/80 est en gros respectée pour le logiciel, avec 20 % des
fonctionnalités implantées qui sont toujours (7 %) ou souvent (13 %) utilisées et 80 %
des fonctionnalités implantées qui sont parfois (16 %), rarement (19 %) ou jamais (45 %)
utilisées. Il est donc très important et rentable de cibler les développements en priorité
sur les fonctionnalités que l’on pense les plus utiles ou les plus critiques. D’où le fort
développement des méthodes itératives et agiles.
(4) Les bonnes pratiques pour la qualité, comme les revues et inspections ou le développement
dirigé par les tests.
1.5 LA MATURITÉ DES ORGANISATIONS

À côté des aspects techniques, les aspects organisationnels jouent également un grand rôle
pour le développement logiciel.
Le modèle CMMI (Capability Maturity Model + Integration 1), mis au point depuis 1987 par
le Software Engineering Institute (SEI) sur la base des travaux de Watts Humphrey, décrit
les stades de maturité que peuvent atteindre les organisations qui développent du logiciel, en
termes de qualité de leur processus. La norme distingue cinq niveaux de maturité croissants :
– Initial : L’organisation ne dispose pas de procédures standardisées ni de suivi de
performance. Le succès dépend essentiellement des efforts et des compétences des
individus.
– Piloté : Il y a un consensus dans l’organisation sur la manière dont les choses doivent être
gérées, mais cela n’est ni formalisé ni écrit. Le rôle des chefs de projets est essentiel pour
la capitalisation de l’expérience. Les coûts et les délais sont gérés.
– Standardisé : Le processus de développement est formalisé, documenté et appliqué. La
capitalisation de l’expérience est centralisée. Une structure chargée de la qualité et des
méthodes est en place.
1. La version la plus récente s’appelle CMMI-DEV et date de 2006.

1.5 La maturité des organisations 9
– Quantifié : Les projets sont pilotés sur la base d’indicateurs objectifs de qualité des produits
et des processus. Un processus formel de collecte des informations est en place.
– Optimisé : L’amélioration continue des processus devient une préoccupation centrale.
L’organisation se donne les moyens d’identifier et de mesurer les faiblesses de ses
processus. Une cellule de veille identifie puis met en œuvre les technologies innovantes et
les pratiques d’ingénierie logicielle les plus efficaces.
Ces niveaux constituent les étapes conduisant à des processus matures, c’est-à-dire conformes
aux meilleures pratiques observées à travers le monde dans les entreprises réputées bien gérer
leurs processus.
F IGURE 1.4 Les niveaux de maturité
Chaque niveau de maturité, sauf le niveau initial, définit une liste de thèmes majeurs à
considérer.
– Au niveau piloté, on trouve la planification de projet, le suivi et la supervision de projet, la
gestion de la sous-traitance, l’assurance qualité, la gestion de configuration. Au cœur de la
thématique de cet ouvrage, on trouve aussi la gestion des exigences qui implique :
• la compréhension et la prise en compte des exigences par les développeurs,
• la gestion des évolutions des exigences et leur traçabilité,
• la conformité des produits du projet aux exigences.
– Au niveau standardisé, on trouve la définition du processus organisationnel, la focalisation

sur le processus organisationnel, la formation à l’organisation, les revues par les pairs, la
coordination entre les groupes. Au cœur de la thématique de cet ouvrage, on trouve aussi
le développement des exigences qui implique :
• l’élucidation des souhaits et des besoins des clients et leur expression en exigences
client,
• la dérivation des exigences techniques sur l’application, ses composants et son interface,
• l’analyse et la validation des exigences.
– Au niveau quantifié, on trouve la gestion quantitative des processus et de la qualité

logicielle.
– Au niveau optimisé, on trouve la gestion des changements technologiques, l’innovation
organisationnelle et la prévention des défauts.
Chaque thème majeur est décrit par un ensemble de bonnes pratiques qu’il convient d’adopter
si l’on veut satisfaire à ses exigences.
Pour passer d’un niveau de maturité à l’autre, il faut obtenir une certification d’un organisme
habilité par le SEI.
Peu d’entreprises françaises se sont engagées dans ce type de démarche de certification
spécifique au développement logiciel. Ont été citées les sociétés de service Atos Origin,
Axlog, Capgemini, Silogic, Sogeti, Steria et SQLI, en général aux niveaux 2 et 3. Beaucoup
d’entreprises du secteur préfèrent s’engager dans des certifications qualité plus généralistes
et moins lourdes, comme celles de la famille ISO 9000.
Exercices 11
EXERCICES
Exercice 1.1. Les défaillances logicielles de systèmes complexes

Lire l’extrait suivant du communiqué officiel expliquant la désintégration de la première fusée
Ariane 5. Analyser la cascade d’erreurs commise et l’inefficacité des mesures de sécurité.
Communiqué de presse conjoint ESA-CNES

Paris, le 19 juillet 1996
Rapport de la Commission d’enquête Ariane 501

Echec du vol Ariane 5O1
Président de la Commission : Professeur J.-L. LIONS
Avant-propos
1. L’échec
1. Description générale
2. Informations disponibles
3. Récupération des débris
4. Autres anomalies observées sans rapport avec l’accident
2. Analyse de l’échec
1. Séquence des événements techniques
2. Commentaires du scénario de défaillance
3. Procédures d’essai et de qualification
4. Autres faiblesses éventuelles des systèmes incriminés
3. Conclusions
1. Résultats de l’enquête
2. Cause de l’accident
4. Recommandations
(...)
2. ANALYSE DE LÉCHEC
2.1. SEQUENCE DES EVENEMENTS TECHNIQUES
De manière générale la chaîne de pilotage d’Ariane 5 repose sur un concept
standard. L’attitude du lanceur et ses mouvements sont mesurés par un
système de référence inertielle (SRI) dont le calculateur interne calcule
les angles et les vitesses sur la base d’informations provenant d’une
plate-forme inertielle à composants liés, avec gyrolasers et accéléromètres.
Les données du SRI sont transmises via le bus de données, au calculateur
embarqué (OBC) qui exécute le programme de vol et qui commande les tuyères
des étages d’accélération à poudre et du moteur cryotechnique Vulcain, par
l’intermédiaire de servovalves et de vérins hydrauliques.
Pour améliorer la fiabilité, on a prévu une importante redondance au niveau

des équipements. On compte deux SRI travaillant en parallèle; ces systèmes
sont identiques tant sur le plan du matériel que sur celui du logiciel.
L’un est actif et l’autre est en mode "veille active"; si l’OBC détecte que
le SRI actif est en panne, il passe immédiatement sur l’autre SRI à

condition que ce dernier fonctionne correctement. De même on compte deux
OBC et un certain nombre d’autres unités de la chaîne de pilotage qui sont
également dupliquées.
La conception du SRI d’Ariane 5 est pratiquement la même que celle d’un

SRI qui est actuellement utilisé à bord d’Ariane 4, notamment pour ce qui
est du logiciel.
Sur la base de la documentation et des données exhaustives relatives à

l’échec d’Ariane 501 qui ont été mises à la disposition de la Commission,
on a pu établir la séquence suivante d’événements ainsi que leurs
interdépendances et leurs origines, depuis la destruction du lanceur
jusqu’à la cause principale en remontant dans le temps.
Le lanceur a commencé à se désintégrer à environ HO + 39 secondes sous

l’effet de charges aérodynamiques élevées dues à un angle d’attaque de
plus de 20 degrés qui a provoqué la séparation des étages d’accélération
à poudre de l’étage principal, événement qui a déclenché à son tour le
système d’auto destruction du lanceur.
Cet angle d’attaque avait pour origine le braquage en butée des tuyères
des moteurs à propergols solides et du moteur principal Vulcain; le
braquage des tuyères a été commandé par le logiciel du calculateur de
bord (OBC) agissant sur la base des données transmises par le système de
référence inertielle actif (SRI2). A cet instant, une partie de ces
données ne contenait pas des données du vol proprement dites mais
affichait un profil de bit spécifique de la panne du calculateur du
SRI2 qui a été interprété comme étant des données de vol.
La raison pour laquelle le SRI2 actif n’a pas transmis des données
d’attitude correctes tient au fait que l’unité avait déclaré une panne
due à une exception logicielle.
L’OBC n’a pas pu basculer sur le SRI1 de secours car cette unité avait
déjà cessé de fonctionner durant le précédent cycle de données (période
de 72 millisecondes) pour la même raison que le SRI2.
L’exception logicielle interne du SRI s’est produite pendant une

conversion de données de représentation flottante à 64 bits en valeurs
entières à 16 bits. Le nombre en représentation flottante qui a été
converti avait une valeur qui était supérieure à ce que pouvait exprimer
un nombre entier à 16 bits. Il en est résulté une erreur d’opérande.
Les instructions de conversion de données (en code Ada) n’étaient pas
protégées contre le déclenchement d’une erreur d’opérande bien que
d’autres conversions de variables comparables présentes à la même place
dans le code aient été protégées.
L’erreur s’est produite dans une partie du logiciel qui n’assure que
l’alignement de la plate-forme inertielle à composants liés. Ce module
Exercices 13
de logiciel calcule des résultats significatifs avant le décollage

seulement. Dès que le lanceur décolle, cette fonction n’est plus
d’aucune utilité.
La fonction d’alignement est active pendant 50 secondes après le

démarrage du mode vol des SRI qui se produit à HO - 3 secondes pour
Ariane 5. En conséquence, lorsque le décollage a eu lieu, cette
fonction se poursuit pendant environ 40 secondes de vol. Cette séquence
est une exigence Ariane 4 mais n’est pas demandé sur Ariane 5.
L’erreur d’opérande s’est produite sous l’effet d’une valeur élevée

non prévue d’un résultat de la fonction d’alignement interne appelé BH
(Biais Horizontal) et lié à la vitesse horizontale détectée par la
plate-forme. Le calcul de cette valeur sert d’indicateur pour la
précision de l’alignement en fonction du temps.
La valeur BH était nettement plus élevée que la valeur escomptée car

la première partie de la trajectoire d’Ariane 5 diffère de celle
d’Ariane 4, ce qui se traduit par des valeurs de vitesse horizontale
considérablement supérieures.
Les événements internes du SRI qui ont conduit à l’accident ont été
reproduits par simulation. En outre, les deux SRI ont été récupérés
pendant l’enquête de la Commission et le contexte de l’accident a été
déterminé avec précision à partir de la lecture des mémoires. De plus,
la Commission a examiné le code logiciel qui s’est avéré correspondre
au scénario de l’échec. Les résultats de ces examens sont exposés dans
le Rapport technique.
On peut donc raisonnablement affirmer que la séquence d’événements

ci-dessus traduit les causes techniques de l’échec d’Ariane 501.
Exercice 1.2. Les courbes de défaillance du matériel et du logiciel

Commenter les courbes suivantes, tirées de [Pre09], qui donnent l’évolution au cours du
temps du nombre de défaillances respectivement du matériel et du logiciel.
Matériel
Logiciel
Exercice 1.3. La diversité des applications

Donner les principales qualités attendues :
a) d’un site de commerce électronique,
b) d’un système temps réel (par exemple de guidage au sol d’une fusée),
c) d’un système embarqué (par exemple de contrôle du freinage d’une voiture).
Exercice 1.4. The mythical man-month

L’homme-mois est souvent utilisé comme unité de mesure de l’effort de développement.
Frederick Brooks a critiqué cette unité dans son ouvrage The mythical Man-Month [Bro75].
L’hypothèse qu’un homme pendant deux mois équivaut à deux hommes pendant un mois,
les deux valant deux hommes-mois, est le plus souvent fausse. Expliquer pourquoi en
commentant les figures suivantes.
PARTIE 1
Le développement logiciel
Chapitre 2
Les activités du développement
Quelle que soit la manière de développer du logiciel, un ensemble d’activités sont nécessaires
au cours du processus.
Les caractérisations et dénominations de ces activités ne sont pas normalisées, ou plus
exactement il existe une pléthore de normes produites par des organismes tels que
l’ISO (International Organization for Standardization), l’AFNOR (Association française
de normalisation), l’IEEE (Institute of Electrical and Electronics Engineers), le DoD
(Department of Defense) pour les applications militaires aux USA, ou l’ESA (European
Space Agency), chacune avec ses nuances propres.
Le statut de ces activités dans le processus de développement peut beaucoup varier. Dans
les processus classiques (en cascade ou en V, cf. paragraphe 4.1) certaines de ces activités
s’enchaînent logiquement et constituent des « stades du développement ». D’autres se
retrouvent incluses dans différents stades, comme la vérification, voire dans tous les stades,
comme la documentation. Dans les processus agiles (cf. paragraphe 4.4) certaines activités
sont entremêlées, comme le recueil des besoins et l’analyse et spécification des besoins,
car elles sont pratiquées par des équipes pluridisciplinaires mêlant clients et informaticiens.
Alors que dans les approches classiques, les client (MOA) et les informaticiens (MOE) les
réalisent séparément et successivement en s’échangeant des documents.
Ce chapitre décrit ces différentes activités en restant aussi indépendant que possible des
processus de développement. Celles qui relèvent de l’ingénierie des besoins en amont de
la conception, qui sont au cœur de l’ouvrage, sont présentées plus en détail que celles en aval
du développement.
18 Partie 1. Le développement logiciel
2.1 LE RECUEIL DES BESOINS

Synonymes : capture, élucidation, « élicitation », identification, expression des besoins (ou
exigences).
2.1.1. La notion de besoin

Au démarrage d’un projet, le client (qui demande et souvent paye le développement) et les
futurs utilisateurs finaux ont une idée brute de ce qu’ils souhaitent qui peut mêler des attentes
plus ou moins précises avec des idées de conception. On parle souvent de besoins bruts ou
besoins client. Les architectes décrivent le même phénomène avec leurs clients qui expriment
spontanément plutôt des détails de conception (ex. : une maison avec une tour, une véranda,
un toit végétalisé, etc.) que de véritables besoins liés à leur âge, au nombre et à l’âge de leurs
enfants, à leur style de vie et loisirs favoris, etc.
Pour établir et documenter les véritables besoins d’une application, il faut étudier son contexte
métier (processus, règles, standards, etc.), l’état actuel de son environnement (l’existant), son
rôle attendu, les ressources disponibles et requises, les performances espérées, les contraintes
d’utilisation, etc.
Dans un premier temps, l’application est vue « de l’extérieur », du point de vue de l’utilisateur
(MOA), comme une boîte noire dont seul le comportement externe importe. Dans un second
temps, l’analyse approfondie des besoins conduit la MOE à « ouvrir la boîte noire » pour
caractériser plus précisément les besoins de l’application (besoins produit). Ces deux temps
peuvent être soit distincts, soit entremêlés si les parties (MOA et MOE) sont réunies dans une
même équipe.
Les besoins analysés décrivent ce que l’application doit faire dans l’environnement qui est le
sien (ses buts), les principaux services qu’elle doit rendre (besoins fonctionnels), les exigences
qualitatives souhaitées (cf. paragraphe 1.3) et les contraintes sous lesquelles l’application
doit s’exécuter et être développée. Ces deux dernières catégories sont souvent regroupées
sous la dénomination de « besoins non fonctionnels ». Les exigences de qualité doivent être
mesurables et vérifiables contrairement aux autres besoins et contraintes.
F IGURE 2.1 Classification des besoins

2 • Les activités du développement 19
Remarque : Le terme « exigence » est parfois considéré comme un simple synonyme de

« besoin » et parfois réservé, comme ici, aux besoins non fonctionnels vérifiables.
2.1.2. Définition de l’activité

L’activité de recueil des besoins recouvre la réflexion conduite pour bien appréhender le
problème, construire et formuler les besoins bruts. La collecte des informations peut se faire
par des entretiens, des questionnaires, des groupes de travail, des brainstormings, la lecture
de documentations, l’observation in situ des utilisateurs, la collecte d’exemples (scénarios),
etc. Dans tous les cas, il faut se méfier des connaissances tacites, souvent non explicitées par
ceux qui y sont accoutumés, et des différences ou conflits entre points de vue différents.
Le terme « recueil » a été retenu ici parmi tous ceux proposés pour traduire le terme anglais
elicit car il a plusieurs sens tous pertinents qui incluent la cueillette, le rassemblement de
choses éparses et l’enregistrement par écrit de quelque chose.
Entrée : L’idée brute d’une nouvelle application.
Principales questions à se poser [BR05] :
– À qui l’application est-elle destinée ?
– Pourquoi est-elle attendue ?
– Quels problèmes doit-elle résoudre ? Quel est son périmètre ?
– Quelles seront ses conditions d’utilisation ?
– Quand est-elle attendue ?
– Comment fonctionnera-t-elle ?
Sortie : Il n’y a de sortie matérialisée par un document que si l’activité de recueil constitue
une phase isolée. C’est le cas dans les processus classiques en cascade ou en V (cf. paragraphe
4.1), où l’activité de recueil des besoins est sous le contrôle de la maîtrise d’ouvrage (MOA),
bien séparée de la maîtrise d’œuvre (MOE). Le document d’expression des besoins (ou cahier
des charges client) assure l’interface entre MOA et MOE. Il constitue le point de départ de la
phase ultérieure d’analyse et spécification des besoins par la MOE.
Dans les approches agiles (cf. paragraphe 4.4), toute la réflexion sur les besoins est effectuée
au sein d’une équipe mixte MOA+MOE. Il n’y a pas nécessité de sortie formalisée à l’activité
de recueil. La compréhension partagée des besoins bruts résultant des discussions entre toutes
les parties prenantes permet d’enchaîner immédiatement la suite du processus.
Difficultés : « The hardest single part of building a software system is deciding precisely
what to build » (« La partie la plus difficile de la construction d’un logiciel consiste à définir
précisément quoi construire ») [Bro87].
Cela résulte entre autres choses :
– De problèmes de compréhension : les développeurs et le client ne parlent pas le même
langage. Les utilisateurs ne connaissent pas vraiment leurs besoins. Les développeurs
connaissent mal le domaine de l’application.
– De problèmes humains : conflits, rétention d’information, etc.
– De problèmes de volatilité des besoins.
2.1.3. Le document d’expression des besoins

Quand il existe, ce document n’est pas contractuel. Il décrit succinctement les besoins
essentiels, sans donner d’indications sur la manière dont il vont être satisfaits.
Le document d’expression des besoins contient souvent les rubriques suivantes :
Positionnement stratégique de l’application~: importance, bénéfices

attendus, conséquences d’une non réalisation, etc.
Utilisateurs~: destinataires, nombre (total, en simultanéité),
localisation (locale, distante), compétences, etc.
Services attendus~: principaux services attendus, priorités
(avec 2 ou 3 niveaux).
Evolutions prévisibles~: du périmètre fonctionnel, du périmètre
d’utilisation, etc.
Contexte technique~: matériel et logiciel.
Contraintes d’exploitation~: plages horaires, tolérances
d’interruption, temps de réponse, etc.
Echéances~: démarrage possible, date de terminaison souhaitée,
disponibilité des personnes concernées, etc.
Les besoins bruts sont répertoriés de manière informelle (en langue naturelle) ou parfois
semi-formelle, sous une forme compréhensible par des non informaticiens. Dans la catégorie
semi-formelle, les arbres de buts décrits au paragraphe suivant, les textes structurés et les
scénarios sont souvent utilisés à ce stade. Le document d’expression des besoins peut inclure
également des ébauches ou maquettes des interfaces homme-machine (IHM) et un glossaire
pour fixer le vocabulaire du projet.
2.1.4. Les réflexions en amont des besoins

Il faut souligner que la réflexion sur un projet démarre souvent très en amont du recueil des
besoins. Un projet d’informatisation s’inscrit en général dans une stratégie de développement
technologique qui s’inscrit elle-même dans la stratégie générale de l’organisation.
Ces deux stratégies doivent être « alignées », c’est-à-dire mises en cohérence. Ce processus
d’alignement stratégique, conduit par la maîtrise d’ouvrage stratégique (MOAS), c’est-à-
dire les dirigeants et décideurs au plus haut niveau, peut fonctionner dans les deux sens.
Classiquement c’est la stratégie de développement technologique qui s’aligne sur la stratégie
globale de l’organisation. Mais les technologies Web et Web 2.0 par exemple peuvent
devenir le fondement de nouvelles stratégies et de nouveaux avantages concurrentiels pour
les organisations. À l’occasion d’un projet d’informatisation, la stratégie globale peut être
infléchie.
Cet ouvrage n’explore pas plus avant ces questions de stratégie globale des organisations.
À un niveau plus opérationnel, de plus en plus d’approches d’ingénierie des besoins, dites
« GORE » pour Goal-Oriented Requirements Engineering [DLF93], donnent la priorité à
la question du « pourquoi ? » (définir les buts ou objectifs) sur les questions du « quoi ? »
(définir les besoins fonctionnels) et du « comment ? » (définir les besoins non fonctionnels).
En explicitant le pourquoi on peut espérer développer des applications plus pertinentes
pour l’organisation, avec des fonctionnalités qui concrétisent réellement la satisfaction des
objectifs retenus.
Les buts aident à se focaliser sur l’essentiel et évitent de se perdre dans les détails. Ils
peuvent être exprimés à différents niveaux d’abstraction dans des arbres de décomposition
de buts (souvent des arbres ET/OU). Cette représentation permet de mettre en évidence des
alternatives et d’éventuelles contradictions entre buts.
F IGURE 2.2 Un arbre de décomposition de buts
Les besoins sont dérivés des buts. Contrairement aux buts qui sont des intentions générales,
les besoins sont soit des services qui doivent être offerts, soit des contraintes, soit des
exigences mesurables et testables.
Exemple
« L’application doit être facile à utiliser » est un but qui peut être raffiné en deux exigences
mesurables et vérifiables : « les utilisateurs doivent être capables d’utiliser les fonctions du
système après une formation de 3 heures » et « le nombre moyen d’erreurs faites par les
utilisateurs ne doit pas excéder 2 par jour ».
2.1.5. Le maquettage des interfaces homme-machine

Les maquettes permettent une première approche de l’interface homme-machine (IHM) de
l’application. Il s’agit de déterminer ce que souhaite l’utilisateur en termes d’organisation
générale des écrans, d’organisation visuelle des principaux contenus, de capacités d’action et
d’interaction, etc. Cette première approche doit être discutée, analysée et validée.
Ce genre de maquette peut être simplement ébauché à la main, produit avec des logiciels
généraux de dessin ou avec des outils spécialisés de maquettage d’IHM.
Les avantages de faire intervenir ce maquettage dès le début du processus de développement
sont multiples : aide au recueil des besoins, support de communication avec les clients et
utilisateurs, moyen de concrétiser la progression du travail d’analyse, etc.
2.2 L’ANALYSE ET LA SPÉCIFICATION DES BESOINS

Synonymes : analyse et spécification des exigences, analyse et spécification, analyse,
spécification.
2.2.1. Définition de l’activité

L’analyse et la spécification des besoins prolonge l’activité de recueil des besoins. Elle vise
à établir une compréhension en profondeur des besoins très souvent via la construction de
modèles plus ou moins formels. L’analyste (MOE) « entre à l’intérieur de la boîte noire ».
La réflexion concerne le détail des fonctionnalités offertes, le comportement observable de
l’application pour ses utilisateurs, les exigences de qualité, etc.
[BR05] insiste sur le caractère progressif du travail de recueil et d’analyse. Dans les
approches classiques, il est souvent nécessaire de réaliser plusieurs itérations pour parvenir à
une compréhension satisfaisante partagée entre toutes les parties prenantes (MOA et MOE).
Dans les approches agiles, cette progression se fait de manière plus naturelle et fluide au sein
des équipes mixtes MOA+MOE.
Entrée : Besoins bruts résultant du recueil des besoins.
Tâches à réaliser : Il faut raffiner, structurer, vérifier et valider les besoins. Pour atteindre ces
objectifs, il est souvent utile de modéliser le problème pour approfondir la compréhension de
ce qui est attendu et modéliser la solution pour vérifier qu’elle répond de manière adéquate
aux besoins. On distingue plus précisément trois activités de modélisation :
– La modélisation des processus métiers : il s’agit de spécifier le « contexte métier », pour
l’essentiel qui fait quoi, quand et où dans le métier.
– La modélisation du domaine : il s’agit de spécifier les concepts fondamentaux du domaine
cible de l’application, essentiellement dans un modèle des classes du domaine.
Remarque : La distinction entre « contexte métier » et « domaine » n’est pas très claire.
Certains préfèrent utiliser « modélisation conceptuelle » à la place de « modélisation du
domaine », mais cette dernière expression reste de loin la plus utilisée.
– La modélisation de l’application : il s’agit de spécifier les aspects informatiques de
l’application visibles pour les utilisateurs, essentiellement dans un modèle des classes de
l’application.
Une fois raffinés, les besoins doivent être vérifiés par relecture, revue ou inspection
(cf. paragraphe 2.9.4.) pour y détecter erreurs, incohérences et autres défauts, et validés par
la négociation, pour s’assurer que les parties prenantes les comprennent de la même façon et
les acceptent.
Sortie : Il n’y a de sortie matérialisée par un document que si l’activité d’analyse et de
spécification constitue une phase isolée. C’est le cas dans les processus classiques en cascade
ou en V (cf. paragraphe 4.1), où l’activité d’analyse et spécification est sous le contrôle de la
maîtrise d’œuvre (MOE), bien séparée de la maîtrise d’ouvrage (MOA). Dans les approches
objet, l’analyse se concrétise par des modèles de classes, d’états et d’interactions. L’ensemble
des modèles élaborés à ce stade s’intègre dans le dossier de spécification des besoins ou
cahier des charges (détaillé). Ce document permet à la MOA et à la MOE de s’accorder sur
les besoins ainsi documentés.
Dans les approches agiles (cf. paragraphe 4.4), toute la réflexion sur les besoins est effectuée
au sein d’une équipe mixte MOA+MOE. La formalisation est beaucoup plus légère car le
processus menant à une compréhension partagée ne passe pas prioritairement par l’écrit.
2.2.2. Le document de spécification des besoins

Dans les approches classiques, le document d’expression des besoins constitue souvent le
fondement du contrat entre maître d’ouvrage et maître d’œuvre. C’est la référence légale
pour déterminer quand le maître d’œuvre a terminé son travail. Un document précis limite
beaucoup le risque de contentieux.
Le détail du contenu peut varier notablement selon la nature et le contexte du projet. La norme
IEEE Std 830 propose le plan suivant :
1. Introduction
1.1. But du document
1.2. Portée de l’application : ce qu’elle fait et ne fait pas
1.3. Définitions, acronymes et abréviations (vocabulaire du projet)
1.4. Références (documents utilisés)
1.5. Vue d’ensemble du document
2. Description générale
2.1. Perspective de l’application
Environnement dans lequel s’inscrit le projet (stratégie, enjeux,
domaine, etc.)
Caractéristiques : autonome ou embarqué, avec quels composants,
interfaces matérielles, logicielles, utilisateur, etc.
2.2. Fonctions de l’application
Spécification détaillée des besoins fonctionnels (textuelle et
éventuellement semi formelle)
2.3. Caractéristiques de l’utilisateur
Expérience, expertise technique, niveau de formation, etc.
2.4. Contraintes
Tous les éléments qui risquent de limiter les options offertes
au concepteur (contraintes de développement, structurelles,
de performances, de sécurité, méthodologiques, etc.) .
2.5. Hypothèses et dépendances
Par exemple, système d’exploitation, matériel, etc.
3. Besoins spécifiques
Interfaces externes, modes de fonctionnement, gestion des données,
conformité à des standards, exigences qualitatives, etc.
4. Annexes (par exemple, les modèles construits pour la compréhension
du domaine, des processus et de l’application).
5. Table des matières
6. Index
On trouve également assez souvent un budget et un planning prévisionnel, des indications

sur le déploiement, l’exploitation et la maintenance de l’application, sur la formation des
utilisateurs, et une définition précise des responsabilités de la MOA et de la MOE.
Dans le document de spécification des besoins, ceux-ci sont souvent classés en catégories
d’importance. Par exemple la technique de hiérarchisation des besoins MoSCoW définit
quatre classes repérées par les lettres M,S,C,W :
– M comme Must : besoin essentiel et incontournable.
– S comme Should : besoin important, mais qui pourrait éventuellement être satisfait
autrement.
– C comme Could : besoin optionnel, à satisfaire seulement si on a le temps.
– W comme Won’t : besoin non nécessaire maintenant mais qui pourrait éventuellement être
considéré plus tard.
Les besoins peuvent aussi être classés selon leur stabilité prévisible dans le temps, comme
« immuable », « plutôt stable », « plutôt volatil ».
2.2.3. Différentes formes de spécification des besoins

a) Informelle
Les spécifications en langage naturel ont l’avantage d’être facilement accessibles à tous,
en particulier aux clients et utilisateurs finaux. Mais elles présentent également beaucoup
d’inconvénients. Elles peuvent souffrir de nombreuses ambiguïtés, avec plusieurs sens pour
un même mot selon les personnes et les contextes. Certains traitements, comme la recherche
des contradictions, des oublis et des redondances, sont très difficiles, voire impossibles, à
automatiser. La simple recherche d’une information n’est pas chose aisée et le risque de
mélanger spécification et conception est important.
b) Semi-formelle
Une première possibilité est le langage naturel structuré, comme les user stories et les cas
d’utilisation qui seront étudiés en détail aux chapitres 10 et 11. La rédaction est guidée par
un modèle de description avec des règles de rédaction précises et documentées.
On peut aussi recourir pour certains aspects à du pseudocode, c’est-à-dire à une description
algorithmique de l’exécution d’une tâche, ce qui donne une vision plus opérationnelle du
système.
Les langages visuels (graphiques) sont aussi très populaires. La spécification utilise différents
diagrammes, accompagnés de texte structuré ou non. C’est l’approche retenue par UML avec
les cas d’utilisation, les diagrammes de cas et les diagrammes complémentaires, structurels et
comportementaux, qui seront présentés dans la suite de cet ouvrage. Les notations visuelles
sont intuitives, faciles à apprendre et à utiliser. Par contre, elles conservent souvent une
certaine dose d’imprécision et se prêtent mal aux analyses automatiques.
c) Formelle
La spécification exploite un formalisme mathématique, comme des langages logiques ou
des modèles formels de comportement. Les descriptions sont analysables automatiquement
et peuvent être utilisées pour automatiser la vérification et le test du logiciel. Par contre,
l’apprentissage et la maîtrise de ces approches sont difficiles.
En pratique, l’utilisation des langages formels apparaît se limiter aux logiciels critiques (en
avionique, espace, santé, nucléaire, etc.) ou aux parties critiques de certains gros logiciels.
d) Qualités recherchées
Quelle que soit la forme retenue, on cherche toujours à éviter au maximum le bruit (éléments
inutiles qui empêchent de saisir l’essentiel), le silence (absence d’information sur une
caractéristique du problème), la sur-spécification (introduction d’éléments de la solution),
les contradictions, les ambiguïtés, les références avant (utilisation d’une information qui est
définie ultérieurement) et les vœux pieux (souhaits irréalisables) [Mey85].
2.2.4. Les besoins non fonctionnels

Il existe des check-lists pour recenser les besoins non fonctionnels. Par exemple, FURPS+
qui sont les initiales en anglais des principales catégories :
– Functionality : fonctions, capacités, sécurité, etc.
– Usability : facteurs humains, aide, documentation, etc.
– Reliability : fréquence des pannes, possibilité de récupération, etc.
– Performance : temps de réponse (un délai inférieur à un dixième de seconde est
imperceptible, alors qu’un délai d’une seconde commence à devenir problématique),
débit, exactitude, consommation de ressources, etc.
– Supportability : adaptabilité, maintenance, configurabilité, etc.
Le + de FURPS+ correspond à des facteurs complémentaires :

– langages, outils, aspects matériel, etc.,
– contraintes d’interfaçage avec des systèmes externes,
– aspects juridiques, licences, etc.
2.2.5. Modélisation du domaine vs modélisation de l’application

a) Modèle du domaine
La modélisation du domaine décrit à l’aide d’un diagramme de classes les objets (concepts)
essentiels qui existent dans l’environnement au sein duquel s’inscrit l’application. On parle
également d’« objets conceptuels » ou d’« objets métier ». Les classes correspondantes sont
caractérisées par des attributs et ne portent pas en général d’opérations.
Il est possible qu’un objet conceptuel devienne ultérieurement un « objet logiciel » mais
ce n’est pas systématique. Certains objets conceptuels sont décomposés en plusieurs objets
logiciels. D’autres concepts ne sont pas représentés, ou pas représentés comme des objets
mais par exemple comme des attributs. Et bien entendu des objets logiciels supplémentaires
peuvent apparaître, comme des structures de données ou des objets de l’interface homme-
machine.
Plusieurs approches ont été suggérées pour déterminer les classes du domaine :
– identifier les noms et groupes nominaux des descriptions textuelles du domaine,
– réutiliser et adapter des modèles existants ou « patrons d’analyse » (analysis patterns),
– utiliser des listes types de classes d’objets conceptuelles.
Ces approches seront présentées en détail au chapitre 8.
Il est souvent difficile de construire du premier jet un modèle de classes du domaine
« satisfaisant » et « complet ». Une tel modèle se construit le plus souvent en plusieurs
itérations, en approfondissant progressivement la connaissance du domaine en lien avec les
« experts » de ce domaine.
b) Modèle de l’application
Le modèle (conceptuel) d’une application décrit l’organisation générale de cette application
telle qu’elle est perçue par ses utilisateurs.
Il s’exprime par un diagramme de classes qui ajoute aux classes du domaine retenues pour
l’application, les principaux « artefacts » visibles par les utilisateurs et approuvés par eux (à
l’exclusion des artefacts d’implantation). On parle souvent de « classes frontière » (boundary
classes) et de « classes contrôleur ». Dans un tel modèle, les principales opérations de chaque
classe sont spécifiées.
2.3 LA CONCEPTION ARCHITECTURALE ET DÉTAILLÉE

2.3.1. Caractéristiques
À ce stade, qui correspond logiquement au troisième stade du développement, les concepteurs
doivent s’accorder sur la manière dont l’application doit être construite pour répondre au
problème défini lors de l’analyse des besoins.
En anglais, on résume souvent la différence entre analyse et conception par les formules
do the right thing (faire ce qu’il faut) pour l’analyse et do the thing right (le faire
correctement) pour la conception.
Cette solution qui satisfait la spécification des besoins s’exprime à deux niveaux.
– La description architecturale de l’application en termes de ses composants, des relations
entre ses composants et des relations avec son environnement.
Les composants d’une architecture peuvent être non seulement des composants logiciels,
mais aussi des bases de données, des flux de messages ou d’événements, ainsi que les
éléments physiques sur lesquels ces composants sont déployés, comme les serveurs, les
clients, les intergiciels (middleware), etc.
– La description détaillée de la conception de l’application qui peut comprendre :
• la réalisation des fonctionnalités par les composants,
• la structuration des données,
• l’organisation précise des interfaces, humaines (IHM) et logicielles, etc.
Un précédent ouvrage, complémentaire de celui-ci, détaille les principes et concepts

essentiels de la conception architecturale et détaillée, en termes de patrons de conception, de
principes de conception et d’architectures [Lon14].
2.3.2. Patron de conception vs patron d’analyse
a) Patron de conception
Un patron de conception (design pattern) est une solution générale à un problème de

conception logicielle courant, validé par l’expérience. En général, un patron de conception
décrit une structure de classes et d’interfaces, et s’applique donc au développement de
logiciels utilisant la programmation orientée objet (quel que soit le langage). Les patrons
peuvent être combinés au sein d’une conception.
La description d’un patron de conception comporte le plus souvent : son nom, le problème
à résoudre (le contexte), la solution sous la forme d’une certaine configuration de classes et
d’interfaces, les forces (avantages) de cette solution.
Les noms des patrons constituent une sorte de « langage commun » entre les concepteurs et
avec les programmeurs.
Exemple : Le patron « Observateur » [Gam+95] permet de définir une dépendance de un à

plusieurs, de l’observé aux observateurs.
F IGURE 2.3 Le schéma de classes du patron de conception Observateur
Quand l’observé change d’état, les observateurs qui se sont enregistrés auprès de lui via la
méthode ajoute sont notifiés par notifie. Ils se mettent à jour (méthode miseAJour)
en récupérant l’état de l’observé par getEtat.
b) Patron d’analyse
Un patron d’analyse est défini par Martin Fowler comme une « idée qui a été utile dans
un certain contexte d’application et qui sera probablement utile dans d’autres » [Fow97]. Il
précise que ces patrons reflètent des structures conceptuelles liées aux aspects fonctionnels
plutôt qu’aux implantations logicielles.
Les patrons d’analyse permettent de répondre à des questions telles que : Comment
représenter une quantité ? Une mesure ? Une organisation ? Une tâche à accomplir ? Une
période ? Etc.
Exemple : Le patron Event analysis montre comment capturer la mémoire de quelque chose
d’intéressant, appelé « événement », qui affecte le domaine considéré.
F IGURE 2.4 Le patron d’analyse Event analysis
2.4 L’IMPLANTATION
Le stade de l’implantation de l’application qui fait suite logiquement à sa conception,
comprend d’abord le codage dans le(s) langage(s) cible(s) de l’ensemble des fonctionnalités
qui doivent être incluses dans la livraison (release). La livraison peut correspondre à un
sous-ensemble du système ou au système complet selon le processus de développement
suivi. Le codage est le plus souvent manuel avec quelques éléments qui peuvent être générés
à partir des modèles de conception.
Les différents composants doivent ensuite être testés isolément (tests unitaires). Puis leur
assemblage doit être progressivement testé (tests d’intégration), jusqu’au test de la livraison
complète (tests de validation ou tests système). Enfin, l’application peut être fournie en « bêta
test » à quelques utilisateurs avant son déploiement effectif.
L’équipe de développement doit également produire toutes les informations et documents
utiles au déploiement et à l’exploitation de l’application, comme les manuels utilisateurs, le
« paquet d’installation », les guides d’installation, etc. Tous ces éléments doivent également
être soigneusement vérifiés.
2.5 LE DÉPLOIEMENT
Le stade du déploiement de l’application fait suite logiquement à son implantation. Chaque
déploiement recouvre un ensemble d’activités comme la livraison sur les sites concernés,
l’installation (manuelle ou automatisée), la configuration, la mise en pré-production puis en
production et la formation des utilisateurs.
Une organisation pour la remontée des questions, problèmes et suggestions doit également
être mise en place.
Il est important que les utilisateurs soient très précisément informés de ce qui est déployé
et des limitations existantes de la livraison, pour éviter des attentes inconsidérées et des
déceptions de leur part. Il est peu recommandé de déployer une livraison insuffisamment
testée qui risque de traumatiser durablement les utilisateurs.
2.6 LA MAINTENANCE
Le stade de la maintenance débute dès que l’application est déployée. Elle prend trois formes
principales :
– La maintenance corrective correspond à l’identification et la correction des erreurs
détectées pendant le fonctionnement de l’application.
– La maintenance perfective correspond à l’amélioration des performances ou de la
maintenabilité et à l’ajout de fonctionnalités.
– La maintenance adaptative correspond à l’adaptation du logiciel aux changements de son
environnement : modifications des règles métier, modifications des formats des données,
modifications de l’environnement d’exécution, etc.
Concrètement, il s’agit avant tout de gérer le flux des remontées d’information en provenance
des utilisateurs. Il peut s’agir :
– de rapports d’anomalie (bug reports),
– de demandes de modification (change requests),
– de demandes d’extension (feature requests).
Ces demandes doivent être analysées et triées, puis planifiées et traitées quand elles le
méritent. De nombreux outils existent pour faciliter cette gestion, comme Bugzilla, Jira,
Trac, etc.
En général, le flux des remontées s’accroît progressivement avec le temps. Finalement, devant
l’importance de l’effort et du budget de maintenance, qui représente couramment 60 à 70 %
du budget alloué au logiciel, la nécessité de refondre (reengineering) ou de renouveler les
applications finit par s’imposer.
Plus globalement, la gestion du parc applicatif peut impliquer l’utilisation de techniques :
– d’inventaire et de cartographie du parc (ou plus ambitieusement « d’urbanisation du
système d’information »),
– de restructuration automatique des codes et des données,
– d’ingénierie de rétro-conception (reverse engineering) qui consiste à analyser les
codes sources pour créer automatiquement des représentations à un plus haut niveau
d’abstraction facilitant leur compréhension,
– d’ingénierie de (re)construction (forward engineering) pour produire une nouvelle
application à partir d’une ancienne.
2.7 LA VÉRIFICATION ET LA VALIDATION (V&V)

2.7.1. La vérification
La vérification vise à montrer qu’un produit, quel qu’il soit, satisfait sa spécification, c’est-
à-dire un ensemble de propriétés qui ont été explicitées. C’est un processus « interne » à
l’équipe de développement et relativement « objectif ».
F IGURE 2.5 Vérification et validation
Elle peut se matérialiser pour les programmes par :

– des examens ou revues du code pour s’assurer de la conformité aux spécifications,
– des tests, établis à partir des spécifications : exécution d’un programme sur des données
choisies dans le but de détecter des non-conformités,
– des preuves de programmes basées sur des méthodes de déduction,
– des vérifications de modèle (model-checking), basées sur des méthodes d’exploration du
graphe d’états du système, etc.
La vérification a des limites pratiques sur lesquelles on reviendra et des limites théoriques,
liées à l’indécidabilité algorithmique. Par exemple, aucun algorithme ne peut prouver :
– qu’un programme est une implantation correcte de sa spécification,
– qu’un programme se termine,
– que deux programmes calculent la même chose.
2.7.2. La validation
La validation vise à montrer que l’application, et en particulier sa spécification, satisfait les
besoins du client. Au contraire de la vérification, c’est un processus « externe », conduit avec
les clients, et plutôt « subjectif » (cf. figure 2.5).
Elle peut se concrétiser par :

– de l’analyse des buts,
– de la modélisation,
– du prototypage rapide,
– des tests d’acceptation et d’utilisabilité,
– des examens ou revues des spécifications, etc.
2.7.3. Les tests
a) Définition
« Tester, c’est exécuter un programme dans l’intention d’y trouver des anomalies ou des
défauts » [Mye79].
En toute rigueur, les termes « erreur », « défaut » et « anomalie » devraient être distingués.
L’erreur est effectuée par le concepteur ou le programmeur. Elle se matérialise par un défaut
dans le code qui produit une anomalie lors de l’exécution, c’est-à-dire une différence entre le
comportement observé et le comportement attendu.
erreur → défaut → anomalie
Un test se définit avec quatre éléments (cf. figure 2.6) :

– l’objectif (spécification) du test,
– le cas de test, c’est-à-dire un ensemble de données à fournir en entrée,
– le scénario de test, c’est-à-dire la séquence d’actions à exécuter (programme de test),
– l’oracle, qui dit le résultat attendu.
F IGURE 2.6 Les éléments d’un test

b) Limites
Le test est une méthode de vérification partielle : « Tester permet seulement de révéler la
présence d’erreurs mais jamais leur absence » [Dij72]. En effet, le test est un processus fini
alors que le nombre d’exécutions possibles d’un programme est potentiellement infini. Il faut
faire face à l’explosion combinatoire des cas à tester. On y parvient grâce à des heuristiques de
choix des données de test, comme l’analyse partitionnelle en classes d’équivalence, les tests
aux limites des différentes classes, les approches combinatoires qui garantissent que chaque
couple de deux valeurs est testé au moins une fois (pairwise testing), les tests aléatoires, etc.
c) Classification
Il existe trois axes principaux de classification des tests, comme le montre la figure suivante.
F IGURE 2.7 Les axes de classification des tests
On peut tout d’abord classer les tests selon leur position dans le cycle de vie : tests
unitaires, tests d’intégration, tests système, tests d’acceptation et tests de non-régression
après modification (cf. paragraphe 4.1.2.).
On peut ensuite classer les tests selon l’objectif de qualité visé : tests de conformité aux
fonctionnalités attendues, tests de robustesse en cas d’utilisations imprévues, tests de sécurité
en cas d’attaques, tests de performance, etc.
On peut enfin distinguer les tests fonctionnels de type « boîte noire » et les tests structurels
de type « boîte blanche ». Les premiers ne nécessitent pas de connaître la structure interne
de l’application. Ils permettent d’assurer la cohérence entre spécification et code, mais
sont aveugles aux défauts fins de programmation. Les seconds se fondent sur la structure
interne de l’application, souvent représentée de manière abstraite sous la forme d’un graphe.
Ils sont adaptés à la recherche des défauts fins de programmation, mais sont aveugle aux
fonctionnalités absentes. Les deux types sont donc tout à fait complémentaires.
2.8 LA DOCUMENTATION
La documentation est une activité présente à tous les stades qui cible aussi bien les
développeurs que les clients et les utilisateurs.
La documentation technique à destination de l’équipe de développement est le moyen de
créer une base commune de référence qui évite par exemple la perte d’informations lors du
départ d’un développeur et facilite l’intégration de nouveaux développeurs. Elle comprend
les modèles d’analyse et de conception, la documentation du code – algorithmes, interfaces
de programmation (API), maquettes, prototypes –, les jeux de tests, etc.
Il a parfois été préconisé d’aller plus loin en répertoriant tous les choix faits à chaque stade
du développement, avec un objectif de traçabilité. Chaque choix est relié à ceux qui l’ont
précédé et dont il dérive. On parle de « logique de conception » ou design rationale. C’est
une approche ambitieuse et lourde à mettre en œuvre.
La qualité de la documentation technique dépend à sa création des revues qui en sont faites,
puis du système de mise à jour qui doit permettre de la garder en conformité avec les
évolutions du logiciel. À noter que dans les approches agiles, il est souvent affirmé que
le code lui-même, abondamment commenté, et les jeux de tests constituent la meilleure
documentation technique et la seule qui a une chance de rester toujours à jour.
Pour les clients, la documentation permet de donner une certaine compréhension de l’état
d’avancement du projet de développement.
Pour les utilisateurs, la documentation finale doit inclure les manuels d’utilisation et les
aides en ligne. Les utilisateurs, ou le plus souvent certains d’entre eux, peuvent fortement
contribuer à conserver la documentation à jour en remontant tous les problèmes qu’ils y
détectent.
2.9 LES ACTIVITÉS DE GESTION

Elles prennent place tout au long du développement et recouvrent la gestion de projet, la
gestion de configuration, la gestion des besoins et la gestion de la qualité.
2.9.1. La gestion de projet

a) Définition
Le concept de « projet » recouvre « un processus unique 1 qui consiste en un ensemble

d’activités coordonnées et maîtrisées comportant des dates de début et de fin, entrepris dans
le but d’atteindre un objectif conforme à des exigences spécifiques telles que des contraintes
de délais, de coûts et de ressources » (norme ISO 10006).
Gérer un projet signifie prendre toutes les mesures nécessaires pour faire en sorte qu’il
atteigne ses objectifs en termes de qualité des livrables (deliverables), de respect des délais,
de respect des coûts et de satisfaction du client.
1. Non répétitif.
La gestion de projet classique se décline selon trois dimensions complémentaires :

– Prévoir, c’est-à-dire structurer et planifier le projet.
La structuration d’un projet consiste à comprendre et expliciter les différents livrables à
produire puis à définir les activités qui seront nécessaires pour aboutir à ces productions.
La planification d’un projet consiste à prévoir l’ordonnancement des activités et
l’utilisation des ressources.
– Contrôler, afin de pouvoir piloter le projet.
Le pilotage d’un projet consiste à identifier au plus tôt tous les problèmes rencontrés, en
particulier les dérapages de planning et de coûts, afin de mettre en place des mesures
correctives.
– Animer, c’est-à-dire gérer l’équipe projet.
Le management d’une équipe consiste à créer les conditions de la réussite, en organisant
et accompagnant le travail au quotidien, en maintenant la cohérence des objectifs de
chacun avec l’objectif global, en évaluant les résultats et les performances et en maintenant
motivation et harmonie au sein de l’équipe.
b) Approche classique et approche agile

On distingue aujourd’hui deux grandes approches en gestion de projet, assez radicalement
opposées : l’approche « classique » (appelée aussi approche « prédictive ») et l’approche
« agile » (appelée aussi approche « adaptative »). Le tableau ci-après récapitule de manière
schématique les différences essentielles entre les deux approches en termes de structuration,
planification, pilotage du projet et management des équipes.
Domaine Approche classique Approche agile

Structuration Périmètre et exigences définis Définition au fil de l’eau d’une suite
au début et supposés stables. d’incréments fonctionnels.
Structuration rigide produit/processus. Incréments opérationnels.
Qualité évaluée sur le produit fini. Feedback rapide du client.
Planification Planification détaillée rigide. Planification au fil de l’eau.
Changements éventuellement admis, Changements attendus,
relèvent de procédures spécifiques. relèvent du processus normal.
Pilotage Conformité aux plans, analyse écarts. Un seul indicateur : fait/reste à faire.
Documentation systématique. Documentation légère : code, tests.
Management Chef de projet, contrôle hiérarchique. Auto-organisation, initiatives.
Spécialisation des participants. Partage et transparence.
Le paragraphe suivant résume les principaux outils de la gestion de projet classique. La

gestion de projet agile sera détaillée au chapitre 5, à l’occasion de la présentation des
démarches agiles XP et Scrum.
c) Les outils de la gestion de projet classique

® La structure de découpage de projet
La « structure de découpage de projet » ou Work Breakdown Structure (WBS) est une
décomposition sous forme arborescente des activités, purement statique, c’est-à-dire sans
notion d’ordonnancement.
F IGURE 2.8 Une structure de découpage de projet (WBS)
La racine de l’arbre est le projet tout entier et les feuilles sont les tâches considérées comme
élémentaires, c’est-à-dire bien définies et donc faciles à gérer : entrées et résultat (livrable)
clairement identifiés, responsabilité confiée à des acteurs précis, ressources nécessaires
connues, durée et coût évaluables.
La WBS facilite la préparation du graphe PERT pour l’ordonnancement des tâches ainsi que
la préparation du budget et la définition des missions confiées à chaque acteur.
® Le graphe PERT
Le graphe PERT (Program Evaluation and Review Technique) permet d’évaluer la durée
totale d’un projet et de détecter les tâches critiques ne supportant aucun retard.
Le point de départ de sa construction est la liste de toutes les tâches, avec pour chacune sa
durée et la liste des tâches antérieures.
Exemple
Le graphe PERT décrit les contraintes d’antériorité entre tâches. Les tâches constituent les
arcs du graphe et les états d’avancement du projet, les sommets 2 . Les arcs sont orientés de
l’état de début vers l’état de fin de la tâche et étiquetés par les durées des tâches. Les numéros
des sommets sont conformes à l’ordre de succession des états.
Pour concevoir le graphe PERT, on classe les tâches par niveaux :
2. Il existe d’autres méthodes, comme la méthode des potentiels, où les tâches sont les sommets et les arcs sont
les dépendances.
Tâche Tâche(s) antérieure(s) Durée

A – 6
B – 5
C A 4
D B 6
E C 5
F A, D 6
G E, F 4
– au niveau 0, les tâches commençantes qui n’ont pas de tâches antérieures,

– au niveau 1, les tâches dont les tâches antérieures sont de niveau 0,
– au niveau i (i 2), les tâches dont les tâches antérieures sont de niveau inférieur avec au
moins une tâche de niveau i − 1.
On construit le graphe en intégrant les tâches par niveaux croissants et en respectant toutes les
contraintes d’antériorité. Pour exprimer certaines contraintes d’antériorité, il faut introduire
des tâches fictives de durée nulle (figurées en pointillés sur le dessin du graphe ci-dessous).
Il faut essayer d’en limiter le nombre au maximum.
Exemple
Le tableau précédent définit quatre niveaux de tâches : A et B sont au niveau 0, C et D au
niveau 1, E et F au niveau 2 et G au niveau 3. À partir de ces niveaux, on peut construire le
graphe de la figure 2.9 qui respecte toutes les contraintes d’antériorité avec une seule tâche
fictive.
F IGURE 2.9 Le graphe PERT
La date au plus tôt de l’étape i (ti ) représente le temps minimum pour l’atteindre. Elle se
détermine de proche en proche, par ordre de sommet croissant, à partir de l’entrée du graphe,
par : t1 = 0 et tj = max(ti + dij ) pour tous les i précédant j, où dij est la durée de la tâche
ij.
Exemple
t1 = 0, t2 = 0 + 6 = 6, t3 = 0 + 5 = 5, t4 = 6 + 4 = 10, t5 = max(6 + 0, 5 + 6) = 11,
t6 = max(11 + 6, 10 + 5) = 17, t7 = 17 + 4 = 21.
La date au plus tard de l’étape i (Ti ) représente le temps maximum pour l’atteindre sans
augmenter la durée totale du projet. Elle se détermine de proche en proche, à partir de la
sortie (n) du graphe, par : Tn = tn et Ti = min(Tj − dij ) pour tous les j suivant i.
Exemple
T7 = 21, T6 = 21 − 4 = 17, T5 = 17 − 6 = 11, T4 = 17 − 5 = 12, T3 = 11 − 6 = 5,
T2 = min(11 − 0, 12 − 4) = 8, T1 = min(8 − 6, 5 − 5) = 0.
On a toujours t1 = T1 = 0 et t T pour tout sommet. La marge totale d’une tâche (M T )
représente le retard maximal qu’on peut prendre dans sa réalisation sans retarder l’ensemble
du projet. Elle vaut : M Tij = Tj − ti − dij .
Exemple
Calcul des marges totales du graphe précédent :
Tâche Marge totale

A M T12 = 8 − 0 − 6 = 2
B M T13 = 5 − 0 − 5 = 0
C M T24 = 12 − 6 − 4 = 2
D M T35 = 11 − 5 − 6 = 0
E M T46 = 17 − 10 − 5 = 2
F M T56 = 17 − 11 − 6 = 0
G M T67 = 21 − 17 − 4 = 0
Les tâches critiques sont celles dont la marge totale est nulle. Il existe toujours un chemin
critique allant de l’entrée à la sortie et composé uniquement de tâches critiques. Il est
représenté en traits épais dans le dessin de la figure 2.9.
® Le diagramme de Gantt
Le diagramme de Gantt est un outil de planification où chaque tâche est représentée par une
ligne. Les colonnes représentent les jours, semaines ou mois du calendrier selon la durée du
projet.
F IGURE 2.10 Un diagramme de Gantt

Le temps estimé pour une tâche se modélise par une barre horizontale dont l’extrémité gauche
est positionnée sur la date prévue de démarrage et l’extrémité droite sur la date prévue de fin
de réalisation. Les tâches peuvent s’enchaîner séquentiellement ou bien être exécutées en
parallèle. Il est possible de faire apparaître aussi sur le diagramme de Gantt les ressources,
humaines ou matérielles, afin de faciliter l’estimation des besoins et des coûts.
2.9.2. La gestion de configuration

La gestion de configuration consiste à gérer, d’une part, la description technique d’un
système en termes de composants et, d’autre part, l’ensemble des modifications opérées sur
les composants au cours de la vie du système.
En développement logiciel, la gestion de configuration sert principalement à tracer tous les
changements opérés par l’équipe de développeurs sur les codes sources de l’application
et les artefacts associés (tests unitaires, fichiers de configuration, etc.) sous forme de
versions-révisions-corrections successives. Elle peut servir également à gérer les évolutions
des documents associés, comme les dossiers d’analyse et de conception ou les manuels
utilisateurs. Elle s’appuie sur des logiciels de gestion de versions et de configurations, soit
centralisés comme CVS et Subversion (SVN), soit décentralisés (répartis) comme Git ou
Mercurial.
Plus précisément, la gestion de configuration couvre les domaines suivants.
F IGURE 2.11 La gestion de configuration
a) La définition et l’identification des composants du système

Exemple
F IGURE 2.12 Historique de l’évolution d’un composant

On note dans cet exemple une identification classique des composants par un numéro
de version (correspondant à une refonte ou extension majeure), un numéro de révision
(correspondant à une amélioration des performances, de la présentation ou un ajout de
fonctionnalité mineure) et un numéro de correction (correspondant à la correction d’une ou
plusieurs erreurs).
b) Le contrôle des changements

Il définit comment et quand les changements sont opérés et inclut les aspects suivants :
– contrôle d’accès,
– gestion des requêtes de changement (change request),
– définition et respect d’un processus de changement,
– suivi des erreurs et des corrections,
– propagation des changements,
– travail individuel en isolation (dans un espace de travail),
– résolution des conflits (fusion), etc.
c) La (re)construction du système
Une configuration cohérente du système complet est reconstruite à partir des composants
versionnés.
d) La traçabilité et l’information
La traçabilité implique l’historisation des composants et des processus de changement.
L’information inclut statistiques, rapports d’avancement, requêtes, etc.
2.9.3. La gestion des besoins

Le gestion des besoins recouvre principalement leur documentation dans un référentiel, leur
traçabilité sous différentes formes et leur versionnement.
a) La documentation des besoins

Chaque besoin est caractérisé par un ensemble d’attributs. Les principaux d’entre eux sont un
identifiant, un nom, une description, une source, une stabilité, une criticité et une priorité.
Dans les projets de grande taille, le référentiel des besoins doit pouvoir être interrogé et filtré
à volonté.
b) La traçabilité des besoins

Elle doit permettre de répondre à trois questions essentielles. D’où provient le besoin
(traçabilité amont) ? Quels autres besoins lui sont liés (traçabilité entre besoins) ? Comment
est-il relié aux autres informations comme les documents de conception, l’implantation, les
utilisateurs (traçabilité aval) ?
c) Le versionnement et la configuration des besoins

Les besoins évoluent tout au long du cycle de vie du logiciel. La maintenance adaptative
et la maintenance perfective résultent pour partie de ces évolutions continuelles (cf.
paragraphe 2.6). Il faut enregistrer l’état des besoins à tous les stades pour pouvoir les
retrouver si nécessaire. Chaque version des besoins est repérée par un numéro de version.
Une configuration regroupe un ensemble cohérent de versions des besoins, avec une seule
version par besoin. Elle peut par exemple correspondre aux besoins associés à une certaine
livraison du logiciel.
2.9.4. La gestion de la qualité

a) Contrôle qualité et assurance qualité
Ces deux aspects sont souvent distingués au sein de la gestion de la qualité.
® Contrôle qualité
Le contrôle qualité est l’ensemble de toutes les actions qui permettent d’assurer que les
artefacts du développement satisfont leurs critères de qualité. Ces actions se pratiquent tout
au long du développement. Pour les codes, on peut pratiquer des contrôles statiques, c’est-
à-dire sans exécution, comme les relectures (revues et inspections), les analyses de code,
les preuves formelles, etc., ainsi que des contrôles dynamiques, c’est-à-dire en exécutant les
codes, comme les tests ou le prototypage. Pour les autres artefacts, on peut pratiquer des
relectures, des vérifications de modèle (model checking), etc.
® Assurance qualité
L’assurance qualité recouvre la mise en place et la gestion de l’infrastructure qui englobe tous
les moyens permettant de produire du logiciel de qualité : méthodes, outils, gestion de projet,
contrôle qualité, etc. Ces moyens sont décrits dans le plan d’assurance qualité.
Les gestionnaires et les techniciens doivent recevoir toutes les informations nécessaires pour
établir leur confiance dans la qualité du logiciel produit.
b) Les relectures
On distingue toute une série de techniques apparentées :
– l’autocorrection ou relecture personnelle, considérée comme de faible efficacité, car il est
toujours difficile de trouver ses propres erreurs,
– la relecture croisée avec un collègue, déjà plus efficace, surtout quand elle est systématisée
comme dans la pratique du développement en binôme des approches agiles,
– la revue informelle (walkthrough) où un lecteur résume paragraphe par paragraphe le
document qui est discuté informellement par le groupe de revue, considérée comme
d’efficacité moyenne,
– la revue structurée autour d’une check-list de défauts et d’un secrétaire qui dirige les
débats, considérée comme plus efficace,
– l’inspection, plus lourde à mettre en œuvre mais qui présente la meilleure efficacité. Le
travail s’organise selon le processus suivant qui est planifié :
1. Préparation :
- recherche des défauts selon une check-list par des inspecteurs,
- rédaction d’un rapport de défauts basé sur un formulaire type.
2. Réunions avec un modérateur, les inspecteurs, un secrétaire pour noter
les décisions et l’auteur du document pour répondre aux questions :
- examen des défauts,
- prise de décision.
3. Suivi :
- vérification des corrections ou nouvelle inspection.
2.10 LA DISTRIBUTION EFFORTS/ERREURS/COÛTS

Il est intéressant en conclusion d’analyser la ventilation des efforts, des erreurs et du coût
selon les différentes activités du développement logiciel.
F IGURE 2.13 Distribution efforts/erreurs/coûts
En termes d’efforts, il faut remarquer que le codage ne représente qu’un pourcentage assez
faible de l’effort total (de l’ordre de 20 %).
En termes d’erreurs et de coûts, on peut souligner que plus de la moitié des erreurs peut être
attribué à des déficiences dans la spécification des besoins. Ces erreurs génèrent plus de 80 %
du coût de maintenance ! L’ingénierie des besoins constitue donc bien un enjeu majeur pour
le développement du logiciel.
42 Exercices
EXERCICES
Exercice 2.1. L’ingénierie des besoins

Le processus d’ingénierie des besoins est représenté comme suit par Petko Valtchev :
Que recouvre la négociation les besoins ?
Exercice 2.2. Besoins fonctionnels et non fonctionnels

On considère une application de contrôle d’ascenseurs.
Donner des exemples de besoins fonctionnels et non fonctionnels pour ce type d’application.
Exercice 2.3. La difficulté à spécifier rigoureusement un problème

La règle de notation d’un examen est la suivante : « L’examen comporte 20 questions à
réponses multiples. Chaque bonne réponse rapporte 1 point. Chaque mauvaise réponse fait
perdre 1/3 de point. Chaque question sans réponse donne 0 point. »
a) Cette spécification est-elle claire et non ambiguë ? Pour le vérifier, calculer la note des 3
étudiants suivants :
Noms Réponses Réponses Sans Doubles

correctes incorrectes réponse réponses
Dupont 10 5 5
Dutif 4 16
Duduche 10 3 4 3 (1 juste et 1 fausse chaque fois)
b) Proposer une spécification plus précise.

Exercice 2.4. La difficulté à tester rigoureusement un problème

Un programme reçoit en entrée trois entiers a, b et c qui représentent les longueurs des côtés
d’un triangle. Le programme détermine si le rectangle est équilatéral (trois côtés égaux),
isocèle (deux côtés égaux au moins) ou quelconque – scalène – (trois côtés différents).
Un expert du domaine rappelle que la somme des longueurs de deux côtés d’un triangle est
toujours strictement supérieure à la longueur du troisième côté (en tout cas en géométrie
euclidienne et si on considère qu’un triangle d’aire nulle n’est pas un triangle. . . ).
Donner le jeu de test le plus exhaustif possible. Glenford Myers [Mye79], l’auteur de cet
exercice, signale que les développeurs expérimentés ne trouvent en moyenne que la moitié
des cas des tests qu’il suggère.
Exercice 2.5. Arbre de buts

Soit l’arbre de buts ET/OU suivant, concernant une application de gestion d’une bibliothèque.
Commenter ce graphe et le conflit entre buts qu’il recèle.
Exercice 2.6. Relectures de code

a) Trouver et corriger quatre défauts dans le code Java suivant :
int factorielle(int n) {
int f;
while (n >= 0) {
n = n-1;
f = f*n;
}
return n;
}
b) Trouver et corriger cinq défauts dans le code Java suivant :

44 Exercices
int indicePremierElementNul(int[] tab) {

int i;
if (tab.length > 0)
for(i=1; i <= tab.length; i++)
if (tab[i] = 0)
return i;
else
System.out.println("tab est vide");
return -2;
return -1;
}
Exercice 2.7. PERT

Soit le projet comportant les tâches suivantes.
a) Construire le graphe PERT correspondant.
b) Calculer les dates au plus tôt, les dates au plus tard, les marges totales et le chemin critique.
Tâche Tâche(s) antérieure(s) Durée

A – 3
B A 1
C A 5
D B 6
E B 4
F C, D, I 2
G E, F 9
H – 5
I H 8
J H 2
K I 3
L J, K 7
Chapitre 3
La modélisation – UML
3.1 LA NOTION DE MODÈLE

3.1.1. Définition d’un modèle
Marvin Minsky donne la définition suivante d’un modèle : « pour un observateur B, un objet
A∗ est un modèle d’un objet A s’il permet à B de répondre à une question qu’il se pose sur
A » [Min65].
On peut prolonger cette définition en précisant qu’un modèle est une représentation
simplifiée, on dit souvent « abstraite », de la réalité – c’est l’objet de Minsky – qui met en
évidence certains aspects jugés comme étant significatifs dans le contexte considéré – ce sont
les réponses aux questions de Minsky.
C’est donc une vue « orientée » de la réalité, fonction des objectifs visés. Par exemple,
une carte est un modèle qui peut mettre en avant soit les villes et les routes pour faciliter
les déplacements des automobilistes, soit les caractéristiques géographiques (cours d’eau,
forêts, montagnes, etc.) pour informer les promeneurs, soit les limites administratives
(régions, départements, cantons, arrondissements, etc.) pour les personnes impactées par ces
découpages territoriaux.
Modéliser un objet peut servir à mieux le comprendre, comme en physique, ou à mieux le
construire, comme en ingénierie. Dans tous les cas, le modèle est avant tout un vecteur de
communication.
3.1.2. Caractéristiques d’un modèle

Un modèle peut être exprimé par des mathématiques, des mots ou des représentations
visuelles. En raison de son importance en informatique la catégorie visuelle est détaillée au
paragraphe 3.2.
Un modèle peut être exprimé à divers niveaux de précision (abstraction). C’est une erreur
classique de croire que plus un modèle est détaillé plus il est juste. En réalité, juste est le
contraire de faux, alors que détaillé est le contraire de général.
On utilise souvent plusieurs modèles pour décrire tous les aspects d’un système complexe,
plusieurs « vues ». On distingue le plus souvent trois vues principales pour un logiciel : la
vue fonctionnelle qui décrit les services rendus, la vue structurelle (statique) qui décrit les
composants et la vue comportementale (dynamique) qui décrit les évolutions.
F IGURE 3.1 Les trois vues essentielles d’un logiciel
3.1.3. Des conseils pour modéliser

Scott Ambler et Ron Jeffries [AJ02] proposent des conseils de modélisation de bon sens qui
dépassent le cadre des seules approches agiles dont ils parlent. Beaucoup d’entre eux peuvent
concerner toutes les formes de développement logiciel :
– Le but principal des développeurs est de produire du logiciel, pas des modèles.
– Il faut « voyager léger », c’est-à-dire éviter de créer des modèles non indispensables.
– Il faut s’efforcer de produire les modèles les plus simples possibles qui décrivent de
manière adéquate le problème ou le logiciel.
– Il faut construire des modèles « utiles » et oublier l’idée de modèles « parfaits ».
– Il ne faut pas se polariser sur la syntaxe du modèle. Ce qui est important c’est que le
modèle communique avec succès des idées.
– Il faut essayer d’obtenir du feedback aussitôt que possible, par des revues.
3 • La modélisation – UML 47
3.2 LA MODÉLISATION VISUELLE

Tout le monde connaît l’adage célèbre « un beau dessin vaut mieux qu’un long discours ».
Il s’explique par le fait que les langages visuels sont « naturels » et « faciles » pour le
cerveau humain. On estime en effet qu’au moins 50 % de notre cerveau est impliqué dans
les processus visuels.
Les modèles visuels et schématiques sont efficaces à condition toutefois qu’ils soient compris
par tous de la même manière. C’est-à-dire, si la sémantique de leurs éléments visuels est
suffisamment précise et partagée par tous les lecteurs.
La modélisation visuelle tient depuis toujours une rôle important en développement logiciel :
organigrammes, schéma entités/associations, SADT, réseaux de Petri, UML, etc.
3.3 FONCTIONS ET OBJETS

3.3.1. La décomposition fonctionnelle
Dans cette approche, la fonction donne la forme. Le système est décomposé selon les
fonctions qu’il assure. L’analyse se conduit souvent de manière descendante, par raffinements
successifs, jusqu’à l’obtention de fonctions élémentaires, facilement compréhensibles et
implantables. C’est la stratégie du « diviser pour régner ».
Cette approche a été beaucoup utilisée dans le passé pour les applications de gestion, dans le
cadre de processus de développement linéaires. Pour ces applications, l’état du système (ses
données) est centralisé et partagé par les fonctions.
F IGURE 3.2 Décomposition fonctionnelle
3.3.2. La décomposition objet

Dans cette approche, la fonction est réalisée par des objets inspirés du monde réel qui
interagissent.
Exemple
La figure 3.3 donne quelques objets inspirés de la réalité qui interagissent pour réaliser la
fonction d’appel d’un ascenseur.
F IGURE 3.3 Décomposition objet
Un objet regroupe données et fonctions. L’état du système est distribué entre tous les objets.
Cette approche présente des avantages dus à la modularité et la réutilisabilité des objets. Elle
est bien adaptée aux processus de développement itératifs et incrémentaux.
Le paragraphe suivant donne de courtes définitions des principaux concepts de l’orientation
objet. Le lecteur trouvera dans le volume dédié à la conception [Lon14] un chapitre beaucoup
plus étoffé sur ces concepts en lien avec la programmation Java.
3.3.3. Brefs rappels sur les concepts objet

Orientation objet : organisation d’un logiciel sous la forme d’une collection d’objets qui
incorporent structure de données et comportement.
Objet : regroupe identité, état (valeurs des attributs) et comportement (méthodes).
Identité : tout objet possède une identité unique et invariable, qui permet de le distinguer des
autres objets. Cette identité est indépendante des valeurs des attributs.
Attributs : variables stockant des informations d’état de l’objet.
Méthodes : opérations que l’objet est à même de réaliser et qui caractérisent son
comportement. Ces opérations permettent de faire réagir l’objet aux sollicitations
extérieures et d’agir sur les autres objets.
Les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre des
valeurs des attributs et/ou les modifier.
Classification : regroupement dans des classes des objets ayant même structure de données
(attributs) et même comportement (opérations).
Classe : abstraction décrivant un ensemble d’objets potentiellement infini partageant la
même structure et le même comportement. Génératrice d’instances conformes au modèle
qu’elle définit.
Instance d’une classe : objet appartenant à la classe.
Héritage ou généralisation/spécialisation : on peut définir une classe (la sous-classe ou
classe fille) à partir d’une autre classe (la superclasse ou classe mère). Les objets de
la sous-classe héritent de tous les attributs et de toutes les méthodes de la superclasse et
peuvent en ajouter d’autres.
La sous-classe est une spécialisation de la superclasse. La superclasse est une

généralisation de la sous-classe.
Polymorphisme : possibilité de comportements différents d’une même opération selon les
situations (vient du grec ancien polús qui signifie nombreux et morphê qui signifie forme).
Le polymorphisme s’appuie sur le fait que les méthodes sont appelées en fonction du type
réel (dynamique) de l’objet, c’est-à-dire la classe dont il est instance, et non pas du type
de la variable dans laquelle il est stocké (type statique).
Le polymorphisme permet que certaines parties du code, écrites de manière « générique »
avec les types statiques, soient exécutées de manières différentes en fonction des types
réels des objets.
Délégation : on parle de délégation quand une classe (cliente) délègue à une autre classe
(serveuse) une partie de son activité. Il y a donc réutilisation de code. Une raison peut
être le souhait de séparer du reste ce qui est susceptible d’évoluer souvent.
La délégation s’implante grâce à un attribut de la classe cliente contenant une référence
vers la classe serveuse. En changeant la référence on peut changer le comportement, y
compris pendant l’exécution.
Interface : une interface est la définition abstraite d’un type, indépendamment de la façon
dont il est implanté (type abstrait). Concrètement, c’est un ensemble de méthodes
publiques abstraites.
Il est très conseillé de typer aux maximum les variables par des interfaces (qui évoluent
peu) plutôt que par des implantations (qui sont susceptibles d’évoluer plus souvent).
Association : une association représente une relation sémantique particulière entre des
classes, qui porte un nom.
La relation d’héritage ci-dessus et d’agrégation/composition ci-après sont des formes
particulières d’association qui ne portent pas de nom.
Agrégation et composition : une agrégation est une association avec une sémantique du
type « un tout (un agrégat) vers les parties de ce tout ».
Une composition est une agrégation particulière dans laquelle la durée de vie des parties
est liée à celle du tout : les parties ne peuvent exister que si l’agrégat existe. Si l’agrégat
est supprimé les parties le sont aussi.
3.4 LE LANGAGE UML

3.4.1. Présentation d’UML
UML (Unified Modeling Language) est un langage visuel normalisé qui aide à découvrir,
spécifier et documenter les artefacts d’une application orientée objets tout au long de son
développement. Ses 4+1 vues couvrent les aspects fonctionnels, structurels (statiques),
comportementaux (dynamiques), d’implantation et de déploiement (cf. figure 3.4).
UML est un langage qui n’est pas lié à un processus de développement objet particulier.
En UML, les mêmes concepts et la même notation sont utilisables tout au long du processus
de développement, mais avec des changements d’objectifs et des changements de niveaux
de détail (d’abstraction). Concrètement, une classe de conception comporte plus de détails
F IGURE 3.4 Les 4+1 vues d’UML
qu’une classe conceptuelle (« métier ») et moins de détails qu’une classe qui documente
un code. Par exemple, les classes conceptuelles ne portent pas d’opérations, les classes de
conception précisent les noms des principales opérations, les classes qui documentent le code
donnent les profils détaillés des opérations avec les types de leurs paramètres.
3.4.2. Modes d’utilisation d’UML

La richesse et la flexibilité de la notation UML autorisent plusieurs modes d’utilisation.
Martin Fowler en distingue trois [Fow03].
a) « UML as sketch »
Dans les approches agiles qui seront détaillées dans les deux chapitres suivants, c’est
l’aspect découverte qui est mis en avant, avec une utilisation d’UML en mode « esquisse »
(sketch), c’est-à-dire sans trop de détails, centrée sur les seuls aspects difficiles et conduite
en collaboration autour d’un tableau blanc, plutôt qu’avec un environnement de modélisation
sophistiqué.
b) « UML as blueprint »
Dans les approches classiques (prescriptives) qui seront également évoquées au chapitre
suivant, c’est l’aspect modélisation systématique qui est mis en avant. L’analyse produit des
modèles pour mieux comprendre le problème et la conception produit des modèles pour
mieux implanter le système. Ces derniers modèles sont progressivement détaillés jusqu’à
ce que les codeurs n’aient plus que des décisions de détail à prendre. Des squelettes de
programmes peuvent être générés. Les modèles peuvent aussi pour partie être reconstruits
à partir du code (reverse engineering).
Dans ce mode, les environnements de modélisation (CASE tools) sont préconisés.
c) « UML as programming language »

Enfin, dans la mouvance des approches dirigées par les modèles (Model Driven Architecture
ou MDA), l’objectif est de parvenir à une extension d’UML suffisamment précise en termes
de sémantique pour permettre la génération complète ou presque de l’application à partir des
modèles.
3.5 LES PRINCIPAUX DIAGRAMMES UML

Cinq diagrammes UML jouent un rôle prépondérant dans le cadre des phases en amont de la
conception. Ils sont brièvement présentés ci-après 1.
Cet ouvrage fait l’hypothèse que les notations UML de base sont connues et que la pratique
de la modélisation élémentaire est acquise. Les exercices en fin de chapitre mettent en œuvre
quelque-unes de ces compétences supposées acquises.
3.5.1. Le diagramme de cas d’utilisation

Il est fondamental en ingénierie des besoins. Il synthétise les interactions entre les acteurs
et l’application. Les cas d’utilisation et les diagrammes de cas d’utilisation sont étudiés en
détail au chapitre 11.
F IGURE 3.5 Diagramme de cas d’utilisation
3.5.2. Le diagramme de classes

Il est essentiel dans toute analyse et conception orientées objets.
F IGURE 3.6 Diagramme de classes
1. Les diagrammes de l’ouvrage ont été générés avec le logiciel libre PlantUML (plantuml.sourceforge.net).
Au stade de l’analyse, il sert essentiellement à décrire la nature des concepts du domaine

applicatif (modèle des classes du domaine). Au stade de la conception, il représente, à
différents niveaux de détail, l’organisation du code orienté objet.
3.5.3. Le diagramme de séquences

Il précise les échanges de messages entre objets, dans le cadre d’un fonctionnement particulier
du système. Au stade de l’analyse, il sert à exprimer les scénarios d’utilisation du système.
Au stade de la conception, il sert à montrer les enchaînements d’appels de méthodes entre les
objets qui contribuent à implanter une certaine fonctionnalité complexe.
F IGURE 3.7 Diagramme de séquences
3.5.4. Le diagramme d’états

Il détaille le cycle de vie des objets d’une certaine classe. Il permet de préciser la description
des classes complexes en montrant leurs différents états et les transitions possibles entre eux.
Il peut également être utilisé pour décrire la navigation dans une application web ou dans
l’IHM interactif d’une application classique.
F IGURE 3.8 Diagramme d’états

3.5.5. Le diagramme d’activités

Il représente les enchaînements d’actions et de décisions au sein d’une activité. Il peut
également être utilisé comme alternative au diagramme d’états pour décrire la navigation
dans une application web ou dans l’IHM interactif d’une application classique.
F IGURE 3.9 Diagramme d’activités

54 Exercices
EXERCICES
Exercice 3.1. Modélisation des relations

Classer les relations suivantes en généralisation/spécialisation, agrégation ou association.
(1) Un pays possède une capitale.
(2) Un philosophe qui dîne utilise une fourchette.
(3) Un fichier est un fichier ordinaire ou un répertoire.
(4) Les fichiers contiennent des enregistrements.
(5) Un polygone se compose d’un ensemble ordonné de points.
(6) Un développeur emploie un langage informatique pour un projet.
(7) Les modems et les claviers sont des périphériques d’entrée/sortie.
(8) Les classes d’objets peuvent avoir plusieurs attributs.
(9) Un joueur joue dans une équipe pendant une année donnée.
(10) Une route relie deux villes.
Exercice 3.2. Diagramme de classes

Donner les schémas de classes d’un graphe non orienté et d’un graphe orienté (sans sommets
isolés), conformes aux figures ci-après.
Exercice 3.3. Diagramme d’états

Donner un diagramme d’états qui décrit la dynamique d’un thread (processus léger) définie
de la manière suivante.
Le thread est :
– non_démarré, initialement,
– en_cours, lorsqu’il possède toutes ses ressources applicatives plus le processeur,
– en_attente, lorsqu’il lui manque une ressource applicative,
– prêt, lorsqu’il a toutes ses ressources applicatives et pas le processeur,
– terminé, lorsqu’il a fini son exécution.
Le thread reçoit des événements qui le font changer d’état :

– début, au démarrage du thread (start en Java, execlv en Unix, etc.). Avant la réception
de début, le thread est non_démarré.
– ressource_attendue, correspond à l’indication qu’une ressource applicative requise
n’est pas disponible.
– ressource_OK, correspond à la libération d’une ressource applicative par un autre
thread et à sa réservation.
– processeur_OK, correspond à la libération du processeur par un autre thread et à son
utilisation.
– fin correspond soit à l’exécution de la dernière instruction du programme exécuté par le
thread soit à la réception d’un événement pour tuer définitivement le thread. Sur réception
de fin, le thread devient terminé.
Exercice 3.4. Diagramme d’activités

Donner un diagramme d’activités qui rende compte du processus suivant.
Dans un garage, le chef d’atelier ouvre une « fiche réparation » pour chaque véhicule traité.
Le magasinier ajoute à la fiche les pièces utilisées. En parallèle, le chef d’atelier ajoute à
la fiche les temps passés par les mécaniciens. Quand la réparation est validée par le chef
d’atelier, la fiche sert de base à la facturation, effectuée à la comptabilité.
Exercice 3.5. Diagramme de séquences

On considère une application de type carnet d’adresses avec laquelle l’utilisateur peut ouvrir
et fermer le carnet, chercher, ajouter, supprimer et modifier des adresses.
Donner un diagramme de séquences montrant les interactions entre l’utilisateur et
l’application (considérée comme un objet unique) pour un scénario où l’utilisateur ajoute
une adresse puis en modifie une autre.
On modélisera la possibilité de succès et la possibilité d’échec des opérations.
Chapitre 4
Les modèles de développement
Comme pour toutes les fabrications, il est important d’avoir un processus bien défini et
documenté. Dans le cas du logiciel, il s’agit d’un type de fabrication un peu particulier, en un
seul exemplaire, car la production en série est triviale par simple recopie.
Ce processus de fabrication du logiciel, dont les principales déclinaisons vont être détaillées
dans les paragraphes qui suivent, est toujours accompagné d’un processus de gestion de projet
(estimation, planification, suivi, etc.) et d’un processus qualité (mesure, contrôle qualité,
documentation, etc.).
Les modèles de développement ou modèles de cycle de vie décrivent à un niveau très abstrait
et idéalisé les différentes manières d’organiser la production du logiciel. Les étapes, leur
ordonnancement, et parfois les critères pour passer d’une étape à une autre sont explicités :
critères de terminaison d’une étape, critères de choix de l’étape suivante, critères de
démarrage d’une étape.
4.1 LES MODÈLES LINÉAIRES

On peut considérer le « développement sauvage » (cow boy programming) ou « coder et
corriger » (code and fix) comme la situation qui prévalait au début de l’informatique, quand
la codification commençait sans aucun travail d’analyse et de conception préalable. Cela
peut encore se concevoir pour de très petits programmes mais certainement pas pour des
développements sérieux. Les modèles linéaires sont apparus ensuite.
4.1.1. La cascade (waterfall)
Dans cette approche proposée en 1970 par Winston Royce [Roy70] et héritée des méthodes
classiques d’ingénierie, chaque étape doit être terminée avant que ne commence la suivante.
À chaque étape, il y a production d’un « livrable » (deliverable) qui sert de base pour l’étape
suivante. La découverte d’une erreur entraîne le retour à la phase à l’origine de l’erreur et une
nouvelle cascade avec de nouveaux livrables. Les coûts de correction des erreurs sont donc
importants. Il faut si possible « tout bien faire » dès le début.
La résolution de beaucoup de facteurs de risque, comme le démarrage du codage ou

l’intégration des éléments de l’application (en un unique big bang), sont repoussés à la fin du
processus. Cette approche peut donc donner une fausse impression de progression. Les choix
en amont sont cruciaux, ce qui est typique d’une production industrielle. Les utilisateurs
interviennent en début de processus, pour définir les besoins, et en toute fin du processus
pour valider le système au regard des besoins exprimés au début.
F IGURE 4.1 Le modèle de la cascade
Par contre, l’approche est simple à comprendre et à utiliser. Elle facilite l’organisation du
travail et des équipes dans les grands projets, en proposant des moments clés où des revues
peuvent prendre place. Elle simplifie la gestion du projet et l’assurance qualité.
Cette approche est peu adaptée si les besoins du client sont changeants ou difficiles à
déterminer au départ. Elle reste utilisée pour de gros projets, dans des domaines et avec
des technologies bien connus et maîtrisés par les équipes de développement. Elle convient
également pour la construction d’une nouvelle version d’un logiciel existant ou son portage
vers une nouvelle plateforme.
4 • Les modèles de développement 59
4.1.2. Le modèle en V
Il s’agit d’une variante du modèle de la cascade qui met en évidence la complémentarité des
phases menant à la réalisation et des phases de test permettant de la valider. Les tests sont
préparés tout au long des phases menant à la réalisation et exécutés en fin de processus.
Le modèle en V, calqué sur la production industrielle classique, met clairement en évidence
les différents niveaux de test :
– test unitaire : test de chaque composant de l’application pris isolément,
– test d’intégration : test des interactions entre les composants de l’application,
– test de validation (test système) : validation par les développeurs du système complet par
rapport à son cahier des charges,
– test d’acceptation (recette) : validation par le client du système complet par rapport aux
besoins des utilisateurs.
F IGURE 4.2 Le modèle en V
Les inconvénients sont similaires à ceux évoqués pour la cascade. Les avantages reconnus
sont de placer la vérification et la validation au centre des préoccupations dès les premiers
stades du développement et d’imposer l’idée de livrable évaluable. L’approche convient bien
aux projets classiques qui mettent la fiabilité au cœur de leurs préoccupations.
4.1.3. Le modèle en Y
Il s’agit d’une autre variante du modèle de la cascade qui distingue initialement une branche
fonctionnelle et une branche technique afin de paralléliser la résolution des questions
correspondantes [RV04].
Le modèle en Y est adapté aux projets technologiquement innovants car il permet de lever au
plus tôt les incertitudes liées aux technologies à mettre en œuvre.
F IGURE 4.3 Le modèle en Y
4.1.4. Discussion
Toutes les approches linéaires supposent qu’il est possible de spécifier correctement et
exhaustivement les besoins en début de processus et que ces besoins restent stables tout au
long du processus de développement.
Les erreurs d’analyse, de conception ou de codage sont découvertes tardivement au terme
d’un long processus (« effet tunnel »).
Il existe en outre des risques de « paralysie par l’analyse », car potentiellement une analyse
n’est jamais finie, de démotivation à cause de la durée et d’effet « big bang », c’est-à-dire de
résolution en une fois et très tardivement des principaux risques.
4.2 LES MODÈLES CENTRÉS SUR DES PROTOTYPES

L’approche habituelle, qualifiée de « prototypage rapide », s’appuie sur le développement
rapide d’un prototype avec le client pour analyser ses besoins. Le client donne son feedback
qui conduit à des adaptations successives du prototype. Le développement du logiciel final se
fait ensuite de manière classique, à partir du cahier des charges qui reprend les besoins mis
en évidence via le prototype (cf. figure 4.5).
L’idée est de permettre la validation des spécifications par expérimentation : « Je saurai ce que
je veux lorsque je le verrai ! ». Cette approche permet une validation beaucoup plus concrète
des besoins, ce qui minimise les risques d’erreurs à ce niveau. Par contre, la planification
initiale du projet est délicate à faire.
F IGURE 4.4 Le prototypage rapide
On peut également utiliser des prototypes ultérieurement dans le processus de développement.

Par exemple, au niveau de la conception, pour s’assurer de la faisabilité de parties critiques
ou valider des options de conception. On parle alors de « prototypage expérimental ».
Enfin, on peut construire un prototype comme embryon du futur système. Contrairement
aux cas précédents le prototype n’est plus jeté mais réutilisé. Ce genre de démarche est à
rapprocher du développement itératif et incrémental.
4.3 LES MODÈLES ITÉRATIFS ET INCRÉMENTAUX
4.3.1. Définition
Dans ces approches le logiciel est développé en plusieurs itérations. Cela revient à répéter des
mini-processus de développement, plus ou moins complets. Chaque itération correspond au
raffinement d’un développement précédent ou à l’ajout d’un incrément supplémentaire (d’où
l’expression « itératif et incrémental »). C’est intéressant pour les projets de grande taille, car
on peut obtenir rapidement un logiciel fonctionnel offrant les fonctionnalités de base.
Dans l’approche la plus classique, le logiciel est spécifié et conçu dans son ensemble. C’est
la conception détaillée et la réalisation (codage, tests unitaires, intégration à ce qui a déjà été
développé, livraison) qui se font par itérations successives (cf. figure 4.5).
Les avantages sont de permettre de développer en premier les fonctions primordiales ou les
plus risquées. Les clients peuvent réagir après chaque itération. On peut aussi obtenir une
meilleure motivation de l’équipe de développement qui voit se concrétiser plus rapidement
ses efforts. Les autres difficultés, comme la nécessité de recueillir dès le départ et de figer les
besoins, demeurent.
Dans d’autres approches, les itérations incluent l’analyse et la spécification des besoins, ce
qui exclut la possibilité d’une conception globale a priori (cf. figure 4.6).
Les avantages principaux sont d’avoir un recueil des besoins continu et évolutif, une détection
précoce des erreurs, une implication continue des clients/utilisateurs. Les inconvénients
majeurs sont liés à la difficulté de gérer les besoins (« explosion des besoins ») et à la
difficulté de définir les incréments. Une direction rigoureuse est nécessaire pour ne pas
retomber dans les errements du code and fix.
F IGURE 4.5 Une approche itérative à partir d’une conception préalable
F IGURE 4.6 Une approche complètement itérative
4.3.2. Le modèle en spirale

Le modèle en spirale de Barry Boehm (1988) et le processus unifié de James Rumbaugh,
Ivar Jacobson et Grady Booch (1999) sont des cas particuliers d’approches itératives.
Le chapitre suivant revient en détail sur le processus unifié qui correspond à l’état de l’art en
développement objet utilisant UML.
Le modèle en spirale est parfois qualifié de « méta procédé » car il peut inclure une activité
de choix du procédé de développement. Il met l’accent sur l’identification et la résolution des
risques :
– humains, comme le manque de compétences, d’expérience, de communication, de

motivation, etc.,
– organisationnels, comme le manque de temps, de budget, la non-disponibilité de
composants externes, etc.,
– technologiques, comme des exigences démesurées par rapport à la technologie, une
technologie non maîtrisée, des problèmes de performance, etc.
Chaque itération (ou cycle de la spirale) correspond à une séquence de quatre phases :
(1) La détermination des objectifs et des alternatives possibles pour les atteindre (comme
développer, réutiliser, acheter, sous-traiter, etc.) et des contraintes (temps, coûts). Ces
analyses se fondent sur les résultats des itérations précédentes ou initialement sur
l’analyse préliminaire des besoins.
(2) L’identification des risques et l’évaluation des alternatives pour les résoudre, par
exemple par du prototypage.
(3) Le développement et la vérification de la solution retenue, par un modèle de procédé à
définir (cascade, en V, etc.).
(4) La revue des résultats et la planification du cycle suivant.
Ce type d’approche convient pour de grands projets complexes, plutôt innovants et risqués.
F IGURE 4.7 Le modèle en spirale
4.4 LES MODÈLES AGILES

4.4.1. Définition
Les approches qui précèdent sont fréquemment qualifiées de « prescriptives » [Pre09]
ou « normatives » car elles imposent, avec des injonctions très précises, une manière de
développer le logiciel : quelles activités, dans quel ordre, avec quels moyens, avec quelle
organisation, selon quelle planification, avec quels contrôles, etc. Dans un tel cadre, où tout
est rationalisé, contractualisé et en conséquence rigidifié, une part importante de l’effort n’est
pas directement dirigée vers le produit logiciel lui-même.
Au contraire, les approches agiles cherchent à alléger le cadre (« trop de méthode tue la
méthode ») et à rester le plus possible focalisées sur le code. Un objectif central est de
répondre rapidement et de manière souple à tous les changements qui peuvent apparaître à
tout instant. Les approches agiles visent la simplicité, la légèreté, l’auto-adaptation et l’auto-
organisation. Contrairement aux approches prescriptives qui définissent des ensembles de
règles, les approches agiles sont plutôt à base de principes.
Plus concrètement, les approches agiles sont des approches itératives à planification
souple et itérations très courtes. Certains les caractérisent également comme une réaction
à la spécification ou à la documentation « à outrance ». En effet, maintenir à jour une
documentation pléthorique consomme énormément de ressources et ne pas la maintenir à
jour la rend inutile, voire dangereuse. Dans les approches agiles, peu de documents sont
élaborés, le code et les tests constituant les sources de documentation primordiales.
Ces approches se sont développées en même temps que les applications web, pour lesquelles
elles sont très bien adaptées. Elles conviennent bien aussi aux applications de gestion de
taille raisonnable. Elles sont moins adaptées pour les systèmes qui nécessitent des analyses
de pré-développement poussées, comme les systèmes critiques, ou les systèmes développés
par plusieurs équipes géographiquement distribuées. Enfin, elles rendent beaucoup plus
difficiles les négociations commerciales client-fournisseur traditionnellement assises sur une
planification globale du processus de développement.
4.4.2. Le manifeste agile

Le manifeste agile, texte rédigé en 2000 par 17 experts du développement d’applications
informatiques (http://agilemanifesto.org/iso/fr), propose de valoriser :
(1) les individus et leurs interactions plus que les processus et les outils,
(2) des logiciels opérationnels plus qu’une documentation exhaustive,
(3) la collaboration avec les clients plus que la négociation contractuelle,
(4) l’adaptation au changement plus que le suivi d’un plan.
Les auteurs reconnaissent la valeur des seconds éléments de ces phrases, mais privilégient les
premiers éléments.
De ce positionnement dérivent les douze principes suivants :
(1) satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande
valeur ajoutée,
(2) accueillir positivement les changements de besoins, même tardivement dans le projet,
(3) livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à
quelques mois, avec une préférence pour les plus courts,
(4) faire travailler ensemble utilisateurs (ou leurs représentants) et développeurs chaque jour
tout au long du projet,
(5) construire les projets autour de personnes motivées, en leur donnant l’environnement et
les moyens nécessaires et en leur faisant confiance,
(6) privilégier le dialogue en face-à-face,

(7) considérer le logiciel opérationnel comme la principale mesure d’avancement du projet,
(8) encourager un rythme de développement soutenable,
(9) s’attacher à l’excellence technique et à la qualité de la conception,
(10) considérer que la simplicité, l’art de minimiser la quantité de travail inutile, est
essentielle,
(11) comprendre que les meilleures architectures, spécifications et conceptions émergent
d’équipes auto-organisées,
(12) faire en sorte qu’à intervalles réguliers, l’équipe réfléchisse aux moyens de devenir plus
efficace, puis règle et modifie son comportement en conséquence.
La traduction concrète de ces principes est étudiée au chapitre suivant.
4.4.3. Les tendances software craftsmanship et clean code

Un autre manifeste, celui des « artisans du logiciel » (software craftsmanship), rédigé en 2009
(http://manifesto.softwarecraftsmanship.org/ ), prolonge le manifeste agile en soulignant
qu’au-delà des aspects d’ingénierie, la compétence et le savoir-faire des développeurs sont
primordiaux. Dans les quatre principes suivants, la recherche des éléments de droite, qui font
partie du manifeste agile, a conduit aux éléments de gauche qui sont mis en avant par les
auteurs :
(1) pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus (proche
des idées connues sous la dénomination de « clean code »),
(2) pas seulement l’adaptation aux changements, mais aussi l’ajout constant de valeur au
produit,
(3) pas seulement les individus et leurs interactions, mais aussi une communauté de
professionnels,
(4) pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.
Les tenants de cette approche s’opposent à la banalisation du métier et aux externalisations
du développement dans les pays à bas coûts. Les artisans du logiciel se veulent fiers de leur
excellence technique, fruit de la pratique et de l’entraide communautaire.
4.4.4. Développement lean, kanban et agilité

a) Le développement lean
La théorie lean a été et reste une source d’inspiration essentielle pour les approches agiles
[PP03]. Lean signifie en anglais « sans gras », ou « au plus juste ». C’est une méthode de
gestion de la production développée chez Toyota dans les années 1980 qui est centrée sur la
lutte contre les gaspillages.
Ses sept principes fondamentaux sont les suivants.
(1) Éliminer les gaspillages, c’est-à-dire tout ce qui n’apporte pas de valeur au produit.
– Le travail partiellement fait : c’est du stock qui ne rapporte rien, qui rend moins réactif
et qui doit donc absolument être réduit.
– Les processus inutiles : chaque processus ou action engagée doit être source de valeur
pour le client.
– L’excès de fonctionnalités : le développement de fonctions non attendues, non utilisées
est le plus gros gaspillage.
– Le passage d’une tâche à une autre : crée une surcharge cognitive et du temps gaspillé.
– Les attentes, comme celles des réponses aux demandes ou les temps d’accès aux
clients.
– Les défauts, qui constituent aussi, dans l’esprit lean, des stocks à éliminer.
(2) Améliorer l’apprentissage : devenir une entreprise apprenante, qui apprend de ses erreurs.
Le feedback est essentiel et doit se pratiquer à tous les niveaux.
(3) Décider aussi tard que possible, pour être toujours en mesure de répondre efficacement
au changement, et pour préserver sa capacité à agir.
(4) Livrer aussi vite que possible : il est préférable de mettre tout de suite sur le marché, une
bonne solution perfectible (une version beta) plutôt que la meilleure solution, un an plus
tard.
(5) Donner le pouvoir à l’équipe : les personnes savent travailler, il faut chercher avant
tout à changer l’environnement qui les contraint. Il faut faire confiance à l’intelligence
collective.
(6) Intégrer la qualité dès la conception : la qualité est le fil rouge, construite et améliorée sans
cesse. Elle pousse à se soucier des utilisateurs et des usages et à rechercher un feedback
permanent.
(7) Optimiser le système dans sa globalité (system thinking).
Il est très difficile de différencier développement lean et développement agile : « You can’t
really talk about them being alternatives, if you are doing agile you are doing lean and vice-
versa » (« On ne peut pas les considérer comme des alternatives, si on fait du lean on fait de
l’agile et réciproquement ») [Fow08]).
Le développement lean n’est pas un processus établi, comme Scrum ou XP, les deux
approches agiles les plus connues, qui seront détaillées au chapitre suivant. C’est un
ensemble de principes compatibles avec toutes les approches agiles.
b) Le concept de kanban
Un kanban est une petite fiche cartonnée qui accompagne les produits dans le système de
production de Toyota.
Ces fiches permettent un contrôle de production décentralisé de type « tirer » (pull). Cela
signifie que le processus de production amont est piloté par le processus de production aval
via les fiches kanban : il n’y a production en amont que s’il y a consommation en aval avec
échange de la fiche kanban quand le produit est consommé. C’est l’aval qui tire l’amont
et l’ensemble découle de la demande des clients. On obtient ainsi des flux tendus avec un
minimum de stocks intermédiaires.
En développement agile les « fiches kanban » (des Post-it associés aux tâches) sont affichées
sur les murs de la salle de projet (war room). Le statut des tâches s’exprime par la colonne
dans laquelle la fiche est placée, le plus souvent trois colonnes « à faire », « en cours » et
« terminé ». Ce « tableau kanban » permet à toute l’équipe de développement de partager
visuellement la situation et de limiter au mieux le stock des tâches en cours de production.
On peut dire que le processus est de type « tirer », car tout part des clients et de leurs besoins
déclinés en tâches.
4.5 LES AUTRES MODÈLES DE DÉVELOPPEMENT

Il existe beaucoup d’autres approches de développement logiciel qui correspondent à
des contextes particuliers. C’est le cas en particulier du développement par assemblage
de composants génériques ou « composants logiciels pris sur étagère » pour traduire
l’expression commercial off-the-shelf software component (COTS), des approches formelles
et des approches de développement des logiciels libres.
4.5.1. Le développement par assemblage de composants génériques

L’approche suivie est en général itérative, chaque itération comportant les étapes suivantes :
(1) Recherche et évaluation des composants disponibles pour le domaine d’application
considéré.
(2) Résolution des questions d’intégration des composants.
(3) Mise en place d’une architecture d’accueil.
(4) Intégration des composants dans cette architecture d’accueil.
(5) Test et validation.
Par exemple, une application web peut être construite par la combinaison de services web
disponibles sur Internet, qui joue tout à la fois le rôle de « méga-étagère » et d’architecture
d’accueil.
4.5.2. Les approches formelles

Dans ces approches, le processus commence par l’élaboration d’une spécification formelle.
Si cette spécification est dotée d’une sémantique opérationnelle (spécification exécutable ou
simulable) le comportement observé du système peut être comparé avec le comportement
de la spécification. De plus, la spécification peut parfois faire l’objet d’une traduction
automatique du langage de spécification vers un langage d’implantation cible.
Si la spécification est dotée d’une sémantique axiomatique, les pré et postconditions de la
spécification peuvent devenir des assertions dans le code exécutable. Ces assertions peuvent
être utilisées pour vérifier le fonctionnement correct du système pendant son exécution (ou sa
simulation), ou plus ambitieusement encore, des méthodes statiques (preuves de théorèmes,
model-checking) peuvent être utilisées pour prouver que ces assertions seront satisfaites par
toute exécution du système.
L’intérêt des approches formelles est :
– d’apporter une sémantique claire et surtout non ambiguë,
– de produire des descriptions concises et précises,
– de proposer des abstractions de haut niveau,
– de permettre des manipulations automatiques.
L’impact des approches formelles reste cependant encore très limité malgré quelques
réalisations notables, comme le développement du logiciel de contrôle de la ligne de métro
14 de la RATP, la seule exploitée de manière complètement automatique, spécifiée avec la
méthode B [Abr96].
Les principales raisons qui expliquent cet état de fait, sont :
– la difficulté d’utilisation,
– la difficulté de compréhension par les non-spécialistes,
– la très grande diversité et spécialisation des formalismes disponibles (Z, B, VDM,
automates, réseaux de Petri, SDL, CSP, CCS, TLA, pi-calcul, spécifications algébriques,
lambda-calcul, LOTOS, COLD, RSL, etc.),
– la rusticité de la plupart des outils de spécification et de preuve.
La seule approche formelle qui sera détaillée dans cet ouvrage est OCL (Object Constraint
Language), au chapitre 9, car elle est complémentaire d’UML et peut être utilisée
ponctuellement pour améliorer la précision de spécifications semi-formelles. C’est une
approche qui privilégie la simplicité d’utilisation et de compréhension sur la puissance
d’expression.
4.5.3. Le développement des logiciels libres

a) Définition du logiciel libre
Un logiciel libre garantit quatre libertés fondamentales :

– La liberté d’exécuter le programme, pour tous les usages, même commerciaux.
– La liberté d’étudier le fonctionnement du programme, et de l’adapter à des besoins
particuliers. Pour ceci l’accès au code source est une condition requise.
– La liberté de redistribuer des copies, donc d’aider le voisin.
– La liberté d’améliorer le programme et de publier les améliorations pour en faire profiter
toute la communauté.
Libre n’équivaut pas à gratuit, même si le mot anglais free possède les deux sens. On trouve
des logiciels non libres gratuits, comme Internet Explorer ou Acrobat Reader et des logiciels
libres non gratuits, comme certaines distributions commerciales de Linux.
Il existe différentes licences libres, qui précisent les conditions de modification et de

distribution. La plus populaire, la GNU GPL (GNU General Public License), permet de
diffuser les modifications apportées au logiciel à la condition que les dérivés soient toujours
distribués sous une licence GNU GPL. Il existe beaucoup d’autre licences, plus ou moins
restrictives, comme la GNU LGPL, BSD, MPL (Mozilla), ASL (Apache), etc.
b) Techniques de développement
L’analyse d’Eric Raymond dans le texte The cathedral and the Bazaar [Ray99] oppose les
processus logiciels classiques, lourds et hiérarchiques (de type cathedral), au développement
des logiciels libres (de type bazaar) avec les caractéristiques suivantes.
– La coexistence d’un petit cœur de développeurs de haut niveau avec une large communauté
d’utilisateurs/contributeurs bénévoles.
– La communauté des utilisateurs/contributeurs réalise du débogage et du développement
parallèle à grande échelle : « given enough eyeballs, all bugs are shallow » [Ray99] (avec
assez d’yeux, les bugs deviennent insignifiants).
– Les revues par des pairs sont essentielles.
– Les livraisons sont rapides et fréquentes.
– L’organisation est une méritocratie, où chacun progresse selon ses mérites, avec un
« dictateur bienveillant » (benevolent dictator) qui a le dernier mot sur tout.
– La conception du produit doit absolument rester modulaire et la plus simple possible.
Des analyses plus récentes [SM04], retiennent un modèle de développement « mixte » en

cinq phases.
(1) Une phase préliminaire avec la sélection d’un problème important aux yeux de l’initiateur
du projet, l’étude de ce qui est réutilisable dans l’existant, et une analyse minimum du
projet en termes de besoins et de risques.
(2) Une phase de prototypage, avec le développement de type cathedral par un individu ou
un petit groupe fermé d’un prototype prometteur (promising prototype).
(3) Une phase de transition qui correspond à l’ouverture vers la communauté des
développeurs libres par la mise en place d’une infrastructure sur le Web et d’une
organisation compatible avec les habitudes de cette communauté.
(4) Une phase de type bazaar, avec le développement, le débogage, et l’extension du
prototype avec la communauté.
(5) Une phase de transfert de la responsabilité du projet à un successeur compétent en cas de
perte d’intérêt du porteur initial.
c) Spécificités en recueil et analyse de besoins
Dans les phases de type bazaar, les besoins pour les logiciels libres proviennent plus des
développeurs que des utilisateurs, au contraire des contextes traditionnels. Ces besoins
résultent de l’expérience personnelle des développeurs, qui sont très souvent eux-mêmes des
utilisateurs, de leur désir d’explorer des idées nouvelles, ou de leur connaissance de ce que
les utilisateurs peuvent désirer [NWM10].
Les utilisateurs non développeurs peuvent aussi contribuer directement en postant sur le site
du projet des rapports d’anomalies ou des demandes de fonctionnalité (feature requests).
Enfin, les besoins répondent souvent à l’apparition ou à l’évolution d’un standard publié ou
du succès d’une nouveauté dans un produit concurrent, vu comme un standard de fait.
Les communautés décrivent et gèrent ces besoins à travers des artefacts web, que Scacchi
qualifie d’informalisms [Sca02]. Cela inclut les outils de communication comme le mail, les
forums, les blogs, les wikis, les news, la messagerie instantanée, ainsi que les pages web,
les how-to, les to do lists, les FAQ (Frequently Asked Questions) et des documentations plus
traditionnelles.
EXERCICES
Exercice 4.1. Choix d’un modèle de cycle de vie

a) Si les utilisateurs d’un logiciel à développer sont hésitants sur ce qu’ils veulent, quel(s)
modèle(s) de cycle de vie est (sont) à privilégier ?
(1) prototypage, (2) cascade, (3) modèle en V.
b) Si on dispose d’une équipe de développeurs expérimentée dans le domaine d’application
concerné et qu’on doit développer un grand logiciel assez similaire à ce que cette équipe a
déjà développé dans le passé, quel(s) modèle(s) de cycle de vie est (sont) à privilégier ?
(1) prototypage, (2) cascade, (3) modèle en V.
Exercice 4.2. Caractéristiques des modèles de cycle de vie

Associer les modèles de cycle de vie à gauche aux caractéristiques qui leur conviennent à
droite.
cascade projet classique
V projet innovant
spirale projet critique
incrémental projet mal défini
prototypage projet de grande taille
agile projet de petite ou moyenne taille
Exercice 4.3. Activités génériques du développement

Pour Pressman [Pre09], tout processus de développement, quelles que soient la nature et la
complexité de l’application, inclut cinq activités génériques qu’il nomme : communication,
planification, modélisation, construction et déploiement.
Comment peut-on les rattacher aux activités classiques du chapitre 2 dont une seule se
retrouve avec la même dénomination : recueil des besoins, analyse et spécification des
besoins, conception architecturale et détaillée, implantation et déploiement ?
Chapitre 5
(R)UP, XP et Scrum
Ce chapitre détaille trois « méthodes » de développement objet qui jouent un rôle majeur
aujourd’hui : (Rational) Unified Process – (R)UP –, eXtreme Programming – XP – et Scrum.
Le mot méthode est placé entre guillemets car ces approches n’ont pas tous les attributs d’une
méthode complète. XP est plutôt un « cadre technique » et Scrum un « cadre organisationnel »
pour le développement agile des applications.
5.1 (RATIONAL) UNIFIED PROCESS – (R)UP

James Rumbaugh, Ivar Jacobson et Grady Booch, ont proposé un cadre général de processus
itératif pour le développement orienté objet, Unified Process (UP) [JBR99], étroitement
associé au langage UML dont ils sont également les principaux auteurs. La version de
la société Rational, Rational Unified Process (RUP) en est la déclinaison la plus connue
[Kru04]. Il en existe plusieurs autres, comme eXtreme UP (XUP), qui intègre XP et UP,
Agile UP qui simplifie UP dans une optique d’agilité ou 2TUP (Two Tracks UP) et son
modèle en Y déjà discuté au paragraphe 4.1.3., qui peuvent satisfaire différents types de
projet.
(R)UP met en avant sept « bonnes pratiques » qui sont explicitées dans les paragraphes
suivants :
(1) le développement itératif et incrémental,
(2) le développement guidé par les cas d’utilisation et centré sur l’architecture,
(3) le pilotage par les risques,
(4) la gestion des exigences,
(5) la maîtrise des modifications,

(6) l’évaluation continue de la qualité,
(7) la modélisation visuelle avec UML.
5.1.1. Le développement itératif et incrémental

(R)UP définit un processus de développement relativement « générique », qui peut être adapté
à des contextes particuliers. Dans l’approche (R)UP, le développement d’un logiciel passe par
quatre phases, chacune pouvant donner lieu à une série d’itérations : lancement (inception),
élaboration, construction et transition. Chaque phase se termine par un jalon d’évaluation et
de prise de décision quant au passage à la phase suivante.
Toute phase est concernée en proportions diverses par différentes « disciplines » du
développement (activités) : modélisation métier, recueil et expression des besoins, analyse
et conception de l’application, implantation, tests, déploiement et les activités transversales
de gestion de configuration et du changement, gestion de projet (personnes, budgets,
contrats, planning), gestion de l’environnement de développement (outils, administration
système/réseau/bases de données). Par exemple, lors de la phase de lancement, ce sont les
disciplines de modélisation métier et de recueil et expression des besoins qui dominent en
proportion. Lors de la phase de construction, ce sont les disciplines d’implantation, de test et
de déploiement qui dominent (cf. figure 5.1).
F IGURE 5.1 Phases, itérations et disciplines
Les phases sont composées d’itérations. Une itération est une séquence d’activités qui
répond à un plan et possède des critères d’évaluation. Une itération se termine par un jalon
d’évaluation et de prise de décision. Toute itération peut être considérée comme un mini
projet (qui parcourt une ou plusieurs fois le cycle recueil et expression des besoins, analyse,
conception, implantation, tests) et qui produit un livrable (cf. figure 5.2).
Le développement se concrétise donc par une série de livrables, par exemple des maquettes
ou des prototypes dans les premières itérations et des versions exécutables du logiciel final
(releases) ultérieurement, comme dans l’exemple de la figure 5.3.
5 • (R)UP, XP et Scrum 75
F IGURE 5.2 Structure d’une itération
F IGURE 5.3 Un exemple de suite de livrables
® Le lancement
Objectifs : C’est une phase très courte, avec souvent une seule itération. Elle explicite la
« vision » associée au projet en termes de faisabilité, de risques et de périmètre du projet.
Livrables : (tout ou partie de la liste suivante)
– Un document de vision présentant les besoins de base, les contraintes et fonctionnalités
principales.
– Une description courte des principaux cas d’utilisation et une analyse plus poussée des
10 % de cas les plus critiques.
– Un glossaire de projet.
– Un document de justification économique incluant le contexte général de réalisation, les
facteurs de succès et la prévision financière.
– Une évaluation des risques.
– Une première planification du projet (phases et itérations).
– Une maquette.
® L’élaboration
Objectifs : Cette phase comporte quelques itérations courtes et de durée fixe, pilotées par
les risques et centrée sur l’architecture. Elle comprend l’identification et la stabilisation de
la plupart des besoins, la spécification de la plupart des cas d’utilisation, la conception de
l’architecture de référence, du squelette du système à réaliser, la programmation et le test
des éléments d’architecture les plus importants, la réalisation et le test des cas d’utilisation
critiques (< 10 % des besoins) et une estimation fiable du calendrier et des coûts de
construction de l’application.
Livrables :
– Au moins 80 % des cas d’utilisation sont élaborés à la fin des itérations.
– Les exigences et contraintes non fonctionnelles sont identifiées.
– L’architecture est définie.
– Une version du produit permettant de valider l’architecture du logiciel à travers les
fonctionnalités les plus importantes.
– Un planning de réalisation réaliste (phases, itérations, critères d’évaluation).
® La construction
Objectifs : C’est la phase la plus longue (plus de 50 % du cycle de développement). La
construction se fait par incréments, avec une architecture stable malgré des changements
mineurs. À chaque incrément, le produit doit contenir tout ce qui avait été planifié. Par contre,
il peut éventuellement rester quelques erreurs non encore traitées.
Livrables :
– Les versions exécutables du logiciel correspondant à l’enrichissement itération par
itération des fonctionnalités.
– Les manuels d’utilisation réalisés simultanément à la livraison incrémentale des
exécutables.
– Une description des versions produites.
® La transition
Objectifs : Le produit est livré (en version béta). Il y a correction du reliquat d’erreurs. Le
produit est essayé et amélioré, les utilisateurs sont formés, l’assistance en ligne est élaborée.
Livrables :
– La version finale du logiciel.
– Les manuels d’utilisation.
– L’assistance en ligne.
Une telle approche est très flexible. Lors des premières itérations la gestion des risques est
fondamentale. Il faut également construire et stabiliser le noyau architectural rapidement.
Le feedback régulier des utilisateurs doit permettre une adaptation permanente du système
aux besoins réels. Le feedback des développeurs et des testeurs doit permettre d’affiner la
conception et les modèles et de mieux gérer la complexité. Des étapes courtes et pas trop
complexes permettent d’éviter la « paralysie par l’analyse ».
5.1.2. Le guidage par les cas et le centrage sur l’architecture

Les cas d’utilisation (use cases) décrivent les interactions entre les acteurs et le système.
Ils permettent de réfléchir en termes d’acteurs et de buts plutôt que directement en termes
de fonctionnalités. Il s’agit d’un bon véhicule, compréhensible par tous, pour recueillir et
communiquer les besoins métier. C’est également un bon outil pour guider et garantir la
cohérence de tout le processus de développement.
F IGURE 5.4 Guidage par les cas
Dans le cadre d’un développement itératif, chaque itération est centrée sur un sous-ensemble
de cas. Il faut traiter en premier les cas d’utilisation « pertinents », c’est-à-dire les plus risqués
(critiques), les plus importants pour le client ou les plus représentatifs du système.
L’architecture décrit les aspects les plus significatifs du système en termes de modèles,
selon les 4+1 vues définies par UML [Kru95] : modèle fonctionnel (cas d’utilisation),
modèles statiques (classes, objets, paquets), modèles dynamiques (processus, concurrence,
performance), modèle d’implantation (composants logiciels), modèle de déploiement
(composants logiciels et matériels). Elle est conçue et stabilisée lors des premières itérations
en parallèle avec l’approfondissement des cas d’utilisation.
5.1.3. Les autres bonnes pratiques

a) Le pilotage par les risques
Un risque est un événement prévisible redouté, car il peut produire des dommages au projet.
Ces risques peuvent être techniques, mais aussi liés au client, au domaine applicatif ou à
l’organisation du projet.
Le pilotage par les risques implique une analyse des risques potentiels le plus tôt possible,
dès les premières itérations, et leur hiérarchisation. Cela conduit à travailler prioritairement
sur les éléments les plus exposés, comme l’architecture de l’application ou la gestion des
ressources humaines.
b) La gestion des exigences

(R)UP recommande de se servir des cas d’utilisation UML pour exprimer les exigences
fonctionnelles. (R)UP indique que les exigences doivent être organisées, enregistrées et
tracées, si possible avec un outil. On retrouve ce qui est demandé au niveau de maturité 2
du CMMI en matière de gestion des exigences (cf. paragraphe 1.5). Par contre, on ne voit
pas d’apport conséquent de (R)UP pour ce qui est demandé au niveau de maturité 3 dans le
domaine du développement des exigences.
c) La maîtrise des modifications

La multiplication du nombre de versions, liée au nombre d’itérations et à l’évolution des
besoins dans le temps, ainsi que la parallélisation des développements impliquent de gérer
les modifications.
Les demandes doivent être formalisées sous la forme d’une demande de changement (change
request), d’une demande d’extension (feature request) ou d’un rapport d’anomalie (bug
report), enregistrées, négociées, validées et tracées.
Il faut en parallèle gérer les configurations du logiciel et les versions de ses composants, mais
aussi les artefacts associés (documentations, scripts de configuration, etc.).
d) L’évaluation continue de la qualité

Tester en fin de développement n’est pas suffisant. Il faut des tests systématiques tout au long
du développement, susceptibles de déclencher des actions qualité.
L’évaluation continue de la qualité doit permettre une identification précoce des problèmes,
une bonne réactivité aux déviations et la maîtrise des risques de dérapage.
e) La modélisation visuelle avec UML

La bonne quantité de modélisation visuelle se situe entre le trop et le pas assez. Des schémas
dessinés sur un tableau blanc, sont plus efficaces pour exprimer des idées et les communiquer,
que d’écrire ou changer du code directement.
5.1.4. Conclusion
En tant que cadre général (R)UP doit être instancié et adapté en fonction des spécificités du
projet, de sa complexité et d’éventuelles règles propres à l’organisation qui l’héberge.
Cette adaptation concerne non seulement la forme des documents utilisés ou la nature des
outils déployés, mais aussi de manière plus fondamentale la manière de mettre en œuvre
le cycle de vie, incluant par exemple l’existence d’itérations parallèles au sein des grandes
équipes de développement ou la manière de coder. Certaines préconisations de XP, présentées
au paragraphe suivant, peuvent parfaitement trouver leur place dans le cadre de (R)UP.
5.2 EXTREME PROGRAMMING (XP)

Ce cadre technique pour le développement agile des applications a été conçu à l’origine par
Kent Beck [Bec99].
Son nom ne doit pas être mal interprété. Il ne s’agit pas d’une « méthode pour extrémistes de
la programmation » qui méconnaîtraient l’importance de la conception ou des tests !
L’idée directrice consiste au contraire à pousser « à l’extrême » les meilleures pratiques du
développement logiciel.
– Puisque la revue de code est une bonne pratique, elle doit être pratiquée par un binôme de
développeurs où chacun contrôle en permanence la production de l’autre.
– Puisque les tests sont utiles, ils doivent être systématiquement créés avant chaque écriture
de code et tous vérifiés après chaque modification de l’application.
– Puisque la conception est importante, elle doit être pratiquée tout au long du projet, en
remaniant à chaque fois que nécessaire les codes (refactoring).
– Puisque l’intégration des modifications est cruciale, elle doit être effectuée plusieurs fois
par jour.
– Puisque les besoins évoluent vite, les cycles de développement doivent être extrêmement
courts.
5.2.1. Les valeurs

XP met en avant quatre valeurs, qui sont des normes de conduite individuelle ou sociale.
La communication : Le développement logiciel est un effort collectif de création qui
exige une vision commune et une bonne synchronisation des acteurs. Dans ce cadre, la
communication est fondamentale.
Au sein de l’équipe de développement, XP privilégie la communication orale directe
par rapport à l’échange de documents, car cette forme de communication permet une
meilleure réactivité. Sa faible structuration et traçabilité est compensée par l’existence de
contreparties écrites, principalement au sein du code (commenté) et des jeux de tests.
Par ailleurs, les développeurs communiquent en direct avec le client.
Le retour d’information (feedback) : Les boucles de feedback sont essentielles pour
réduire les risques. Elles permettent de connaître l’état réel du projet et de rectifier
sa trajectoire si nécessaire. Les boucles de feedback facilitent aussi l’acquisition
d’expérience et l’amélioration continue des pratiques.
Le courage : Il consiste d’une part à accepter de se lancer dans un projet non entièrement
spécifié et de changer fréquemment de rôle et de vision.
Il consiste d’autre part, à travers le feedback et une communication franche et ouverte, à
accepter de montrer ses propres limites et insuffisances.
La simplicité : Il faut viser « la chose la plus simple qui puisse marcher », sans confondre
toutefois simple et simpliste. Cela peut concerner autant le processus que le code. Par
exemple, éviter toute complexité inutile ou duplication à l’intérieur des codes.
5.2.2. Les pratiques
De ces quatre valeurs dérivent douze pratiques. Les quatre premières sont liées à la gestion
de projet, les quatre suivantes à la communication et les quatre dernières à la programmation.
(1) Client sur site : Le client doit être intégré physiquement à l’équipe de développement
pour répondre aux questions des développeurs et définir les tests fonctionnels.
Une telle implication continue du client n’est évidemment pas toujours facile à mettre en
pratique.
(2) Rythme soutenable : Il faut savoir travailler mais aussi savoir se reposer. L’équipe doit
adopter un rythme de travail raisonnable qui lui permette de fournir un travail de qualité
tout au long du projet.
Par exemple, éviter de dépasser les horaires hebdomadaires prévus. Si les heures
supplémentaires sont nécessaires deux semaines de suite, c’est le symptôme d’un
problème qu’il faut résoudre plutôt que de le masquer par un surplus de travail.
(3) Livraisons fréquentes : La première livraison, minimale, doit arriver le plus tôt possible,
afin de dissiper d’éventuels malentendus et de donner une matérialité au projet.
Les livraisons suivantes doivent être aussi proches que possible (1 à 6 mois), pour
permettre un pilotage précis du projet et montrer son avancement. Chaque livraison
permet un feedback vers le client et vers les développeurs.
(4) Planification itérative : La planification s’effectue à deux niveaux de granularité : les
livraisons, associées à des fonctionnalités, et les itérations, associées à des tâches à
réaliser par les développeurs.
On compte de 4 à 6 itérations en moyenne par livraison, d’une durée de 1 à 4 semaines
chacune.
La réunion de planification des livraisons (release planning meeting) définit un plan des
livraisons (release plan) pour l’ensemble du projet. Ce plan est utilisé pour définir des
plans d’itération (iteration plan) au début de chaque itération.
Ces plans peuvent être revus et remaniés à tout moment pour tenir compte de l’expérience
acquise par le client et l’équipe de développement.
(5) Programmation en binôme : Cette organisation correspond à une forme de revue de code
permanente. Le pilote écrit le code et le co-pilote le relit et fait des propositions.
Les binômes changent fréquemment (plusieurs fois par jour). Les affectations sont libres.
Chaque développeur est responsable de ses tâches. À tout instant, soit il travaille sur une
de ses tâches, soit il aide quelqu’un d’autre à réaliser les siennes.
Cette organisation fonctionne mieux dans un espace de travail ouvert (salle de projet ou
war room).
(6) Appropriation collective du code : Chaque binôme peut intervenir sur n’importe quelle
partie du code et chacun est responsable de l’ensemble. Les spécialistes doivent devenir
polyvalents et agissent comme des consultants internes.
(7) Intégration continue : On peut avoir plusieurs intégrations par jour. Cette pratique permet
de profiter immédiatement des efforts de chacun, sans avoir à attendre une période
d’intégration lointaine.
Les modalités techniques de l’intégration continue sont présentées au paragraphe 5.5.2.
(8) Développement dirigé par les tests : Les tests unitaires sont automatisés pour être rejoués
à chaque évolution du code (non-régression). Ils sont écrits en premier, avant le code
qu’ils testent. Ils servent à documenter le code (notion de contrat).
Les modalités techniques du développement dirigé par les tests sont présentées au
paragraphe 5.4.
(9) Règles de codage et de nommage : Une homogénéisation est nécessaire pour permettre
l’appropriation collective. Elle permet une prise en main plus rapide du code écrit par
d’autres.
Les règles doivent être définies avant le démarrage du projet. Elles peuvent concerner
la présentation du code (indentation, espaces, etc.), l’organisation des commentaires, les
règles de nommage (classes, méthodes, constantes, etc.), le vocabulaire commun, des
pratiques de codage ou idiomes (parcours de liste, singletons, etc.).
(10) Conception simple : On peut résumer cette philosophie de la façon suivante « il vaut
mieux faire simple aujourd’hui, quitte à changer demain, plutôt que de faire tout de suite
compliqué sans être absolument certain de l’utilité de ce que l’on développe ».
Plutôt que de tenter de trouver dès le début une architecture idéale assez générique pour
accueillir toutes les fonctionnalités et survivre aux évolutions, l’idée est de considérer
chaque fonctionnalité tour à tour et de rechercher une solution simple et fonctionnelle
sans essayer d’aller au-delà, quitte à devoir remanier régulièrement le code déjà
développé.
Cette philosophie correspond aux préceptes « Do the simplest thing that could possibly
work » (« Faire la chose la plus simple qui puisse fonctionner ») et « You Aren’t Gonna
Need It » ou YAGNI (« Tu n’en auras pas besoin »).
La simplicité recherchée n’est pas la facilité. Elle se caractérise entre autres choses par :
– des idées exprimées clairement et ponctuellement,
– un nombre minimal de classes, de méthodes et de lignes de code,
– pas de duplications de code,
– des tests, tous exécutés avec succès à tout moment.
(11) Utilisation de métaphores : La documentation est limitée au maximum. En effet, les tests
fonctionnels documentent les spécifications, les tests unitaires et le code documentent la
conception détaillée.
Il reste essentiellement à définir la vision d’ensemble de l’application. Elle doit éviter
le jargon technique et utiliser plutôt des analogies avec la vie réelle (métaphores) et des
expressions imagées qui parlent à tout le monde.
(12) Remaniement (refactoring) du code : Remanier signifie modifier un logiciel de façon à
améliorer sa structure interne sans changer son comportement externe.
Martin Fowler a répertorié des dizaines de symptômes de problèmes (code smells), décrits
avec précision un peu à la manière des patrons de conception : code dupliqué, code mort,
trop de paramètres, trop grosse méthode, trop grosse classe (God object), etc.
À noter que certaines corrections peuvent être appliquées automatiquement par des
environnements de développement comme Eclipse.
5.2.3. Les rôles

Le programmeur (développeur) est au cœur de tout. Il est à la fois codeur, concepteur et
analyste. Il doit viser l’excellence. Il reçoit des responsabilisés qui vont bien au-delà de la
seule technique, comme l’estimation des charges et des délais, qui doivent l’inciter à donner
le meilleur de lui-même.
Le client est intégré à l’équipe et il explique ce qu’il souhaite via les user stories et les tests
d’acceptation qui doivent être passés avec succès par les livraisons.
Le testeur travaille avec le client pour définir et automatiser les tests d’acceptation. Il doit
communiquer sur la progression de nombre de tests passés (graphiques de progression) pour
motiver l’équipe.
Le tracker suit l’avancement des tâches en cours d’itération. Ce n’est pas un supérieur
hiérarchique mais quelqu’un qui cherche à détecter les problèmes au plus tôt en discutant
avec les programmeurs. Il « fait en sorte que la tâche de 3 jours en prenne 4 et non 6 » !
Le manager est le supérieur hiérarchique des programmeurs, qui s’occupe matériellement de
l’équipe, demande des comptes sur les engagements pris, et réalise l’interface avec l’extérieur.
Le coach est le garant du processus. C’est un expert de la méthode XP, un expert technique,
programmeur chevronné, architecte, pédagogue et doté de sang-froid pour faire face aux
difficultés.
5.2.4. Le processus
Un projet XP présente la structure que décrit la figure 5.5.
F IGURE 5.5 Processus XP au niveau macroscopique
(1) Une phase d’exploration pendant laquelle les user stories initiales et les éléments
architecturaux initiaux du projet (concepts et composants) sont déterminés avec les
clients.
(2) Une phase de planification pendant laquelle sont sélectionnées avec les clients les stories
à implanter dans la première livraison et les livraisons suivantes (release plan). Les
stories choisies pour la première livraison sont décomposées en tâches à réaliser dont
les durées sont estimées par les développeurs.
(3) Une phase de construction incrémentale de la livraison. Les itérations d’une durée d’une
à quatre semaines sont planifiées de manière souple (cf. figure 5.6).
Chaque itération permet de recalculer la vélocité. Elle peut éventuellement créer de
nouvelles stories. Quand l’ensemble des tests fonctionnels (d’acceptation) passent, on
entame la mise en production de la livraison.
(4) Une phase de mise en production de la livraison impliquant l’accord du client.
(5) Une phase de maintenance qui répète les phases de planification, construction et mise
en production pour les livraisons suivantes (2 à n). Ce cycle se répète tant que le client
peut sélectionner des stories à livrer.
Généralement, la première livraison est celle qui inclut le volume le plus important de
fonctionnalités et ébauche le squelette du système (the whole system in a skeletal form).
Au niveau microscopique, chaque itération de la phase de construction s’organise autour du
développement dirigé par les tests.
F IGURE 5.6 Processus XP au niveau microscopique
5.2.5. Conclusion
a) Forces et faiblesses
La production de logiciels de bonne qualité bien adaptés aux besoins des clients et l’efficacité
pour les petits projets sont les points le plus souvent portés à l’actif de XP.
A contrario, la limitation des équipes à 20 personnes au maximum, l’investissement très
important demandé au client, et la programmation en binôme pas toujours bien ressentie,
sont fréquemment mis au passif de XP.
Enfin XP est plus facile à appliquer en interne qu’avec un prestataire externe. Les contrats
au « forfait » classiques, où le fournisseur s’engage à un résultat donné, dans un délai donné,
pour un prix fixé, sont délicats à mettre en place. Il faut forfaitiser chaque itération ou chaque
livraison avec la possibilité pour le client d’interrompre le contrat. Il faut accepter aussi
le « troc d’exigence », c’est-à-dire l’ajout d’une nouvelle exigence en échange du retrait
d’une autre moins importante et de même coût. Même les « régies », où le fournisseur met à
disposition du personnel, ne sont envisageables qu’avec des personnes très expérimentées et
motivées.
b) XP et (R)UP
Certaines pratiques de XP peuvent être utilisées dans tout projet (R)UP, alors que c’est
beaucoup moins évident pour d’autres.
Parmi les pratiques compatibles on peut citer par exemple le développement dirigé par les
tests et l’intégration continue.
Par contre l’appropriation collective du code est peu crédible dès que la taille du projet devient
importante. Le remaniement permanent du code, acceptable pour les petits projets, s’oppose
à l’idée d’une architecture clairement définie, souvent considérée comme essentielle dans les
gros projets et les projets critiques. De même, des livraisons très rapides peuvent ne pas être
souhaitables pour des gros systèmes où la logistique du déploiement est lourde et coûteuse.
5.3 SCRUM
Scrum est un cadre de gestion d’un projet agile [SB01]. Scrum signifie « mêlée de rugby ».
L’image est qu’on fait progresser le ballon en travaillant ensemble, comme on fait progresser
un projet en travaillant ensemble. Scrum reprend les principes de base des méthodes agiles :
– itérations courtes (appelées sprints), produisant une version potentiellement livrable,
– travail en collaboration étroite entre tous les intervenants, sans « spécialistes » et sans
primes individuelles selon les performances,
– avec un rythme de développement soutenable,
– avec une équipe qui s’auto-organise.
5.3.1. Les rôles

Scrum sépare les « cochons » (pigs), c’est-à-dire les membres de l’équipe de développement,
et les « poulets » (chickens), c’est-à-dire les personnes extérieures à l’équipe, intéressées par
le développement (stakeholders) incluant :
– le Client, extérieur ou interne, qui commande et paye le développement et peut donner du
feedback,
– l’Utilisateur final, qui connaît les besoins, contribue à définir le produit et donne du
feedback,
– le Manager, qui met en place un environnement optimal pour le déroulement du projet.
Parmi les « cochons » on distingue :

– Le Product Owner, qui représente les « poulets » au sein de l’équipe, est chargé de :
• communiquer une vision claire du produit et définir ses caractéristiques,
• piloter le projet d’un point de vue métier,
• s’assurer que l’équipe de développement se concentre sur les aspects à plus forte valeur
ajoutée.
– Le Scrum Master est chargé principalement de :

• vérifier la mise en œuvre de Scrum,
• assurer la bonne collaboration au sein de l’équipe de développement et avec le Product
Owner,
• protéger l’équipe de développement des turbulences et lever les obstacles qui pourraient
apparaître.
– L’équipe de développement (Team), pluridisciplinaire et autogérée, comporte de cinq à
neuf personnes qui sont chargées de :
• travailler avec les utilisateurs finaux, les clients, le Product Owner pour comprendre les
exigences métier,
• collaborer pour spécifier, coder, valider et documenter le produit,
• délivrer un produit de qualité.
On parle parfois de Scrum team pour l’équipe de développement complétée par le Scrum
Master et le Product Owner.
5.3.2. Les artefacts

a) Le product backlog
Le travail de l’équipe de développement s’organise autour d’un artefact particulier, le product

backlog (« carnet de produit »). Backlog signifie quelque chose comme le « restant dû ».
Il s’agit d’une liste d’items (user stories ou epics) qui restent à développer par priorités
décroissantes. Chaque item inclut une définition, un effort estimé et une priorité. Les plus
prioritaires sont aussi les plus détaillés (cf. figure 5.7).
Le Product Owner génère la liste initiale des items. L’équipe associe à chaque item un effort
estimé. Il s’agit d’une estimation relative entre items exprimée en points (story points) plutôt
que d’une estimation absolue en durée. La technique du Planning Poker est préconisée pour
obtenir cette estimation en points :
(1) Les membres de l’équipe disposent chacun d’un jeu de cartes dont les valeurs suivent la
suite de Fibonacci, 1, 2, 3, 5, 8, 13, 21, 34, 55. . . plus éventuellement une carte « infini »
qui signifie que l’item est trop gros et doit être scindé en au moins deux parties.
(2) Chacun joue une carte face cachée représentant son estimation en points de l’effort.
(3) Si tout le monde est d’accord, ou presque, l’estimation est adoptée.
F IGURE 5.7 Le product backlog
(4) Sinon, le plus pessimiste et le plus optimiste expliquent leur vote, des discussions rapides
ont lieu, puis on recommence en (2).
La figure 5.8 résume toutes les opérations courantes sur le backlog.
F IGURE 5.8 Les opérations courantes sur le product backlog
Le Product Owner, éventuellement avec le Scrum Master, donne une priorité à chaque item,
en fonction d’un objectif, comme par exemple la maximisation du retour sur investissement.
Une user story est supprimée du backlog quand elle est « finie » (done). Cette notion de
« fini » doit être définie avec précision et être partagée par tous au sein du projet, car elle
garantit la qualité du logiciel. Elle dépasse la seule notion de test réussi et peut concerner
bien d’autres aspects comme l’ergonomie, la documentation, les performances, etc. Elle doit
être appliquée rigoureusement : « À moitié fini n’est pas fini » (half done is not done) !
Le backlog peut être complété par de nouvelles stories à chaque itération si des besoins
nouveaux apparaissent.
b) Le sprint backlog
Un sprint est une itération courte de deux à quatre semaines, débouchant sur une version
potentiellement livrable, c’est-à-dire testée et documentée.
Elle s’appuie sur un sprint backlog (ou « carnet de sprint ») qui est l’extrait du product
backlog concerné par le sprint. Une fois qu’un sprint est initialisé, il doit se dérouler comme
prévu jusqu’au bout.
F IGURE 5.9 Structure d’un sprint
Le sprint backlog prend la forme d’un tableau avec un ensemble de Post-it, un par tâche
assignée au sprint, répartis en trois colonnes : « à faire », « en cours », « fait ». Le passage de
« à faire » à « en cours » est fait individuellement par chaque intervenant le matin. Le passage
de « en cours » à « fait » se fait en fin de journée, si tout ce qui a été spécifié comme indiquant
qu’une tâche peut être considérée comme faite, a été réalisé. Si une tâche n’est pas finie, il y
a mise à jour de l’effort restant.
Pendant un sprint :
– le but ne peut être modifié,
– la composition de l’équipe reste a priori inchangée,
– la qualité n’est pas négociable,
– la liste d’items est négociée entre le Product Owner et l’équipe de développement.
c) Le sprint burndown chart

Ce graphique représente en abscisses, l’écoulement du temps en jours ouvrables du début à
la fin du sprint, et en ordonnées, le montant de travail restant à faire estimé en points.
F IGURE 5.10 Le sprint backlog
L’avancement idéal est représenté par une droite. L’avancement réel est souvent moins
linéaire en fonction des avances ou des retards pris par l’équipe.
F IGURE 5.11 Le sprint burndown chart
d) Le product burndown chart

Ce graphique représente en abscisses, les sprints successifs, et en ordonnées, le montant de
travail restant à faire estimé en points.
Connaissant la vélocité de l’équipe, il permet d’estimer le nombre de sprints qui restent à
réaliser pour terminer le produit.
5.3.3. Les réunions

Plusieurs réunions rythment le développement de l’application (cf. figure 5.12).
a) Le sprint planning meeting

La planification d’un sprint se réalise au cours d’une réunion de planification (sprint planning
meeting), d’une journée au maximum. Dans un premier temps le Product Owner choisit les
items qu’il aimerait voir implantés dans le sprint (le QUOI).
F IGURE 5.12 Les réunions
Le nombre d’items possibles dépend de la vélocité de l’équipe. Elle se calcule par la somme
des points des stories qui ont été terminées lors du précédent sprint. Elle ne doit pas être
gonflée artificiellement en rognant sur les exigences de qualité.
Dans un deuxième temps, l’équipe et le Product Owner discutent pour mieux appréhender
ce qui est attendu pour chaque item (le COMMENT), c’est-à-dire la conception en termes
d’architecture, de composants, d’interfaces, de données, etc. Les items sont découpés en
tâches, qui sont ajoutées au sprint backlog. Un effort estimé (en heures) est associé à chaque
tâche. Il n’y a pas d’attribution des tâches à un participant, sauf si une compétence unique est
requise.
Remarque : Il est possible également de planifier les livraisons qui seront fournies aux
utilisateurs. Entre deux livraisons effectives, plusieurs sprints sont en général nécessaires.
Pour éviter une dérive vers une approche trop prédictive et rigide, ce type de planification
doit rester souple et modifiable après chaque sprint.
b) Le daily scrum
Chaque jour, le daily scrum ou « mêlée quotidienne » est une réunion de type stand-up
(debout) et de durée très réduite (environ un quart d’heure) où chacun expose :
– ce qu’il a fait la veille,
– ce qu’il compte faire ce jour,
– les embûches éventuelles.
Il n’y a pas de discussion pendant le daily scrum. Si cela semble nécessaire, les discussions
se tiennent après, lors d’un follow-up meeting.
Après ces réunions, le travail de développement est effectué. En fin de journée, le sprint
backlog est mis à jour de même que le sprint burndown chart.
Le sprint se termine à la date prévue, que la totalité du sprint soit réalisée ou non, sans
multiplier les heures supplémentaires. Cette terminaison comprend une revue et une
rétrospective de sprint.
c) La revue de sprint
La revue de sprint (quatre heures maximum) consiste à inspecter le produit. Il est présenté par
l’équipe au Product Owner. Les « poulets » participent en général à cette réunion. « Poulets »
et « cochons » sont libres de poser des questions et d’y répondre. Il s’agit de vérifier si les
items sont « bien faits ». Cela passe par une démonstration du produit, mais ne doit pas se
limiter à cela. Le backlog et les plannings sont revus en fonction des tâches ou items non
réalisés.
d) La rétrospective de sprint
La rétrospective de sprint (trois heures maximum) consiste à inspecter le processus. L’équipe
et le Scrum Master y participent. Le Scrum Master doit limiter ses interventions pour garder
au maximum une position neutre. La présence du Product Owner n’est pas indispensable.
Un tableau à trois colonnes sur ce qui « marche bien», ce qui « marche mal » et ce qui pourrait
être fait pour améliorer la situation est élaboré. Chaque intervenant dispose un ou plusieurs
items dans chaque colonne. Les items répétés sont marqués par des barres pour chaque
occurrence supplémentaire. L’équipe discute des modifications à essayer dans le prochain
sprint pour corriger les défauts.
F IGURE 5.13 La rétrospective de sprint
5.3.4. Réflexions sur Scrum

a) La gestion et le développement des besoins
La gestion des exigences au sens du niveau 2 du CMMI (cf. paragraphe 1.5) est assurée par le
Product Owner. Les besoins sont exprimés sous forme de user stories qui sont stockées dans
le product backlog et le sprint backlog sous son contrôle.
Scrum apporte aussi des réponses pour le développement des exigences au sens du niveau 3
du CMMI, incluant par exemple l’intégration continue du client à l’équipe de développement
ou la systématisation des démonstrations du produit pour valider les exigences.
b) La possibilité de changer d’échelle
La limitation des équipes à moins d’une dizaine de personnes est un facteur limitant
important. Selon Jeff Sutherland, co-fondateur de la méthode, il est possible d’utiliser Scrum
dans des projets de plus de 500 personnes. L’idée, appelée « Scrum de Scrums » ou « Méta-
Scrum », consiste à diviser le projet entre n équipes. Un Scrum of Scrums meeting réunit
une personne de chaque équipe pour coordonner le travail. Ces réunions sont similaires à la
mêlée quotidienne mais avec une fréquence moindre (deux par semaine suffisent souvent).
Pour les très gros projets, on peut avoir des Scrum of Scrums meetings à plusieurs niveaux.
c) La complémentarité de Scrum et XP
La complémentarité de Scrum et XP est communément admise. Scrum se positionne au

niveau de la gestion et de l’organisation de projet alors que XP se positionne au niveau des
activités de développement. C’est la raison pour laquelle ces deux approches se marient
si bien ensemble : elles s’attachent à des problématiques différentes et se complètent
mutuellement. La figure 5.14 montre un mélange habituel des concepts des deux approches.
F IGURE 5.14 Les pratiques combinées de Scrum/XP
Si on raisonne en termes de feedback, la complémentarité et la puissance de l’approche

combinée sont aussi évidentes. Le feedback est partout, avec toutes les fréquences de
rétroaction possibles, comme l’illustre la figure 5.15.
F IGURE 5.15 Les rétroactions multiples de Scrum/XP
5.4 LE DÉVELOPPEMENT DIRIGÉ PAR LES TESTS

5.4.1. Présentation
Le développement dirigé par les tests (Test-driven development ou TDD) est une technique
popularisée par XP qui a rencontré un écho dépassant largement le cadre de cette seule
méthode. La technique est fondée sur deux idées principales.
La première est l’importance de la conception des tests pour améliorer la qualité du logiciel :
« More than the act of testing, the act of designing tests is one of the best bug preventers
known. The thinking that must be done to create a useful test can discover and eliminate
bugs before they are coded » [Bei90] (« Plus que l’acte de tester, l’acte de concevoir des tests
est une des meilleures manière de prévenir les bugs. La réflexion qui doit être conduite pour
créer un test utile aide à découvrir et éliminer les bugs avant même qu’ils soient codés »).
C’est une idée déjà présente dans le modèle en V qui prône la conception des tests dans la
phase descendante et leur exécution dans la phase ascendante. Cela peut concerner les tests
d’acceptation comme les tests unitaires.
La seconde idée est de concevoir les tests unitaires utiles juste avant de coder chaque morceau
de code : « Test a little, code a little » (« Tester un peu, coder un peu »). Dans cette optique, les
tests unitaires deviennent la spécification du code (non ambigüe a priori). Le pseudocode et
le schéma qui suivent résument cette manière de travailler qui combine les tests d’acceptation
au niveau du système et les tests unitaires au niveau de chaque morceau de code.
répéter
choisir une fonctionnalité à implanter
créer et/ou modifier les tests d’acceptation
répéter
le développeur choisit une unité à écrire et/ou modifier
le développeur crée et/ou modifie les tests unitaires
répéter
le développeur écrit et/ou modifie le code de l’unité
jusqu’à ce que tous les tests unitaires passent
jusqu’à ce que tous les tests d’acceptation passent
jusqu’à qu’il ne reste plus de fonctionnalité à implanter
F IGURE 5.16 Le processus du TDD
À noter qu’initialement un test doit toujours échouer car le code correspondant n’est pas
encore écrit ! À noter également que chaque itération de test et codage s’accompagne d’une
activité de remaniement (refactoring) du code :
1. Écrire un petit nombre des tests unitaires automatisés.
2. Vérifier qu’ils échouent (car le code testé n’existe pas encore)
ce qui montre qu’ils sont valides.
3. Écrire le code suffisant pour passer les tests.
4. Lancer les tests jusqu’à ce qu’ils passent tous,
sinon corriger le code.
5. Remanier le code, pour améliorer sa conception ou ses performances
tout en gardant les mêmes fonctionnalités.
Le développement dirigé par les tests présente de nombreux avantages :

– Une suite complète de tests est construite progressivement.
– Cette suite peut être exécutée à chaque évolution du code (chaque compilation).
– Tous les tests qui passaient auparavant doivent continuer à passer (non-régression).
– Le code peut être remanié avec confiance car il ne régressera jamais.
L’essentiel des tests peut être exécuté automatiquement. Il existe de nombreux frameworks
pour automatiser le test unitaire, comme JUnit pour Java, où les tests sont écrits dans le même
langage que le code.
5.4.2. Un exemple en Java avec le framework JUnit

On veut coder une méthode qui compte le nombre de chiffres dans un entier non négatif et
qui ne commence pas par des zéros inutiles :
public static int compterChiffres(long n)
Un premier test porte sur la plus petite valeur, 0L. Pour éviter d’avoir à dupliquer plusieurs
fois le code de test, on l’écrit pour qu’il puisse tester n’importe quelle valeur passée en
paramètre.
private void testValeur(long n, int resultatOK) {
System.out.println("compte les chiffres de "+n);
int resultat = compterChiffres(n);
assertEquals("resultat", resultatOK, resultat);
}
@Test
public void test0() {
testValeur(0L, 1);
}
Ce code ne compile pas car le code de la méthode compterChiffres n’est pas écrit. Pour
le faire compiler on peut se contenter dans un premier temps d’écrire :
public static int compterChiffres(long n) {
return 1;
}
Le test passe. On ajoute un deuxième test pour le plus grand nombre qui donne 1, soit 9L.
@Test
testValeur(9L, 1);
}
Les deux tests passent. On ajoute un troisième test pour le plus petit nombre qui donne 2, soit
10L.
@Test
testValeur(10L, 2);
}
Bien entendu le test ne passe plus. Il faut coder la méthode compterChiffres de manière
plus réaliste. On la réécrit avec une itération qui compare n aux puissances successives de
10 :
int res = 1;
long p10 = 10L;
while (!(n < p10)) {
p10 *= 10;
res++;
}
return res;
}
Les trois tests passent maintenant. On généralise à une longueur quelconque (par exemple 5),
avec un quatrième test pour la plus grande valeur qui donne 5, soit 99999L.
@Test
testValeur(99999L, 5);
}
Les quatre tests passent. On ajoute un cinquième test pour la plus petite valeur qui donne 6,
soit 100000L.
@Test
}
Les cinq tests passent. On teste maintenant la plus grande valeur possible sur 64 bits,
Long.MAX_VALUE soit 263 − 1 ou 9223372036854775807, de longueur 19.
@Test
public void testmax() {
testValeur(Long.MAX_VALUE, 19);
}
Le test ne passe pas, il boucle indéfiniment.

Remarque : On peut borner le temps avec l’annotation @Test(timeout=1000) qui ar-
rête l’exécution après une seconde.
L’explication est que p10 *= 10; déborde et passe donc dans les valeurs négatives, ce
qui permet au programme de continuer. Il faut écrire la méthode compterChiffres de
manière plus robuste.
L’idée et de faire décroître n au lieu de faire croître p. Soit :
int res = 1;
while (10 <= n) {
n /= 10;
res++;
}
return res;
}
Cette fois-ci tous les tests passent. On est en droit d’avoir une certaine confiance en cette
dernière implantation.
La classe à tester :
public class ClasseATester{
int res = 1;
while (10 <= n) {
n /= 10;
res++;
}
return res;
}
}
La classe de test :
import static org.junit.Assert.*;
import org.junit.*;
public class ClasseTest {
private void testValeur(long n, int resultatOK) {
System.out.println("compte les chiffres de "+n);
int resultat = ClasseATester.compterChiffres(n);
assertEquals("resultat", resultatOK, resultat);
}
@Test
public void test0(){
testValeur(0L, 1);
}
@Test
testValeur(9L, 1);
}
@Test
testValeur(10L, 2);
}
@Test
}
@Test
}
@Test
public void essaiMax(){
testValeur(Long.MAX_VALUE, 19);
}
}
Le compilation en ligne de commandes sous Windows dans un répertoire qui contient tous
les fichiers et les librairies s’écrit :
javac -cp .;junit-4.11.jar ClasseTest.java
L’exécution en ligne de commande s’écrit :

java -cp .;junit-4.11.jar;hamcrest-all-1.3.jar org.junit.runner.JUnitCore
ClasseTest
Le résultat obtenu est le suivant :

Il existe des cas de figure beaucoup plus complexes, en particulier quand on doit recourir
à des objets factices (mock objects ou mocks) car l’objet réel n’existe pas encore ou car il
est trop coûteux à utiliser dans un test, comme une base de données complexe. Ce mock a la
même interface que l’objet qu’il simule. Il existe des frameworks spécialisés dans la définition
et la manipulation des différentes catégories d’objets factices (mock, stub, spy, etc.), comme
Mockito pour Java. Ces frameworks permettent au minimum de spécifier quelles méthodes
vont être appelées, dans quel ordre, ainsi que les valeurs retournées.
5.5 LES OUTILS DU DÉVELOPPEMENT AGILE

Le développement agile s’appuie souvent sur une combinaison d’outils low tech pour la
communication et la collaboration et d’outils high tech pour la gestion des artefacts.
5.5.1. Les outils low tech

Les outils de communication et de collaboration usuels font partie de cette catégorie. Ils
jouent un rôle essentiel pour l’analyse, la conception et la gestion de projet. On y retrouve
les Post-it, les posters affichés aux murs, les tableaux blancs, les grilles Excel, etc. La
communication active passe par la programmation en binôme et les multiples réunions en
face-à-face. La communication passive passe par les « radiateurs d’informations » ou autres
« kanban des tâches » affichés aux murs de la salle de projet.
5.5.2. Les outils high tech pour l’intégration continue

La gestion des artefacts du développement (codes sources, binaires, tests unitaires, scripts de
construction, de déploiement, etc.) et l’assurance qualité font au contraire appel à des outils
logiciels parfois sophistiqués.
L’intégration continue est prônée par les méthodes agiles. Elle consiste à reconstruire
l’application, on dit « produire un build », très fréquemment et en tout cas plusieurs fois
par jour. Il existe différents types de builds, plus ou moins complets. Builds privés par le
développeur sur sa machine, build d’intégration pendant la journée pour tester toutes les
modifications ensemble, build de nuit plus poussé avec la production de rapports détaillés à
consulter le matin. Tout ou partie des opérations suivantes sont exécutées lors d’un build :
– chargement de la dernière version depuis le gestionnaire de sources,
– compilation des sources,
– exécution des tests unitaires,
– contrôle de la qualité du code,
– construction de l’artefact de déploiement (packaging),
– déploiement de l’application sur l’environnement de test,
– exécution des tests d’intégration, de performance, etc.,
– génération de la documentation,
– génération de rapports.
L’intégration continue peut être mise en œuvre à l’aide d’un gestionnaire de versions (comme
CVS, Subversion, Git, etc.), d’un logiciel d’intégration continue (comme Jenkins/Hudson,
Apache Continuum, etc.) et éventuellement d’outils de mesure de la qualité (comme Sonar,
PMD, etc.). La figure 5.17 montre un scénario possible.
F IGURE 5.17 Un scénario d’intégration continue
(1) Le développeur code une fonctionnalité.

(2) Il la teste en local en faisant des builds privés sur sa machine avec des outils tels que Ant
ou Maven et en corrigeant les éventuelles erreurs.
(3) Il récupère la dernière version du code sur le gestionnaire de sources pour mettre à jour
son propre code (update).
(4) Il fusionne son code avec le code qu’il a récupéré, résout les conflits et refait des builds
privés pour corriger les éventuelles erreurs.
(5) Il publie sa nouvelle version (commit).
(6) Soit parce qu’il détecte un changement, soit à heure fixe, le logiciel d’intégration exécute
un build d’intégration en utilisant les différents scripts à sa disposition.
(7) L’application est déployée sur le serveur de test et testée.
(8) Le logiciel d’intégration génère les différents types de feedback qui ont été configurés,
comme RSS, mail, blog, etc. Les développeurs peuvent prendre connaissance de ces
feedbacks et réagir en conséquence, par exemple si le build a échoué.
EXERCICES
Exercice 5.1. Caractéristiques des méthodes

Remplir le tableau suivant avec un + ou un ++ par case selon que la méthode satisfait (+) ou
satisfait préférentiellement (++) la caractéristique de la ligne.
Caractéristique (R)UP XP Scrum

Itérative et incrémentale
Centrée sur l’architecture
Centrée sur les tests
Centrée sur l’interaction client-développeur
Centrée sur la qualité du code
Convient aux grosses équipes
Convient aux petites équipes
Centrée sur les cas d’utilisation
Convient aux gros projets
Considère la gestion du risque
Exercice 5.2. QCM Scrum (une seule réponse possible par question)
Q1. Quel rôle est responsable de la définition des priorités au sein du product backlog ?
a) Product Owner b) Project Manager c) Lead Developer d) Scrum Master
Q2. Quel rôle n’est pas défini dans Scrum ?
a) Product Owner b) Scrum Master c) Product Manager d) Team
Q3. Quel document n’est pas un artefact Scrum ?
a) Product backlog b) User story c) Sprint backlog d) Burndown Chart
Q4. Quel type de réunion ne fait pas partie de Scrum ?
a) Product review meeting b) Sprint review meeting c) Sprint planning meeting
d) Sprint retrospective meeting
Q5. Quel est le nom de la réunion dans laquelle l’équipe démontre au Product owner et aux
autres personnes intéressées ce qui a été accompli durant le sprint ?
a) Sprint retrospective meeting b) Product review meeting c) Sprint review meeting
d) Stakeholder review meeting
Q6. Quand l’exécution d’un sprint est-elle finie ?
a) Cela dépend des événements b) Quand tous les items du product backlog sont « faits »
(done) c) Quand toutes les tâches planifiées sont finies d) À la fin de la durée prévue
(timebox)
Q7. Quelle est la durée normale du Daily Scrum meeting ?
a) 15 minutes b) Aussi longtemps que nécessaire c) 60 minutes d) 5 minutes
Q8. Quelle est la taille recommandée pour une équipe Scrum ?
a) 9 ± 3 b) 10 ± 3 c) 7 ± 2 d) Peu importe
100 Exercices
Q9. Comment le product backlog est organisé ?

a) Items par importance décroissante b) Items par taille décroissante c) Au hasard
d) Par catégories
Q10. Qui estime l’effort nécessaire pour réaliser un item du product backlog ?
a) Product owner b) Scrum master c) Team d) Le développeur le plus expérimenté
Exercice 5.3. Tests de validation

Soit le cas d’utilisation suivant. Comment construire un ensemble de tests d’acceptation
(positifs, c’est-à-dire conformes au cas, et négatifs, c’est-à-dire qui violent le cas) permettant
de valider ce cas ?
Nom : Réserver un vol

Description : Ce cas d’utilisation décrit la réservation d’un vol constitué d’une ou
plusieurs étapes par un voyageur.
Acteur principal : Voyageur
Acteurs secondaires : Agent de voyage, Commercial de la compagnie
aérienne
Préconditions :
– Chaque étape du vol existe.
– Il y a une place disponible dans la classe souhaitée pour chaque étape du vol.
– Toutes les exigences de réservation et de séjour sont satisfaites.
Postconditions :
– Les réservations pour chaque étape du vol sont faites.
– Le voyageur a reçu la confirmation.
– Les places disponibles ont été mises à jour.
Déroulement normal :
1. La demande de réservation est faite.
2. La demande de réservation est traitée.
Variantes :
1. Le voyageur règle sa réservation immédiatement.
2. Le voyageur demande une prestation optionnelle.
3. Le voyageur est sur la liste noire des passagers.
Autres cas liés : Annuler une réservation, Payer une réservation
Autres remarques :
– La transaction ne doit pas nécessiter plus de deux minutes.
– Le cas concerne uniquement une réservation pour un seul voyageur.
Exercice 5.4. Tests unitaires

On veut développer une méthode qui trie un tableau d’entiers en enlevant les répétitions de
valeurs identiques : int[] tri_sans_rep(int[] tab)
Donner une liste d’une dizaine de cas de tests significatifs en explicitant les situations
considérées.
Exercice 5.5. Test driven development (TDD)

Développer en Java avec JUnit une classe Premier avec une unique méthode estPremier
qui indique si son paramètre entier est premier ou non :
public static boolean estPremier(int n)
On rappelle que 0 et 1 ne sont pas premiers.

Les premiers nombres premiers sont 2, 3, 5, 7, 11, 13. . .
PARTIE 2
La modélisation métier
Chapitre 6
Introduction à la modélisation métier
6.1 DÉFINITION
La modélisation métier (business modeling) est une des neuf disciplines fondamentales du
développement logiciel définie par (R)UP, au même titre que l’analyse/conception, les tests
ou la gestion de projet. Elle y joue un rôle prépondérant durant la phase d’étude préliminaire
(inception) mais peut continuer à vivre tout au long du développement car les participants
vont approfondir et actualiser leurs connaissances métier tout au long du processus.
La modélisation métier consiste à représenter le contexte, la structure et la dynamique d’un
« système métier » (business system), avec ses composants, ses processus et ses informations.
Elle peut viser différents objectifs dont celui d’aider à préciser les besoins d’une application
par une bonne compréhension du milieu dans laquelle elle doit s’insérer, ce qui est pour cet
ouvrage l’aspect essentiel. Mais elle peut viser aussi la réorganisation et l’optimisation du
fonctionnement global de l’organisation (business reengineering). Dans ce dernier cas, il est
important de distinguer clairement la modélisation du système existant (As-is system) et celle
du système envisagé après réorganisation (To-be system).
Une bonne connaissance du contexte métier est importante pour bien cerner les besoins d’une
application. Il est par exemple difficile d’imaginer créer une application bancaire complexe
sans une bonne connaissance du milieu bancaire. Cette connaissance permet d’avoir :
– une compréhension globale de « l’écosystème » dans lequel se situe l’application, des
problèmes et des potentialités d’amélioration de cet écosystème,
– une meilleure chance de comprendre les besoins réels auxquels doit répondre l’application,
pas toujours parfaitement en accord avec les besoins exprimés,
– un langage commun aux clients, utilisateurs et développeurs,
106 Partie 2. La modélisation métier
La modélisation métier n’est pas indispensable à tous les projets. Elle peut avoir un coût
de réalisation élevé. Elle se justifie principalement dans les organisations complexes, les
organisations en plein développement ou les métiers mal connus.
Les méthodes agiles parlent assez peu de modélisation métier et préfèrent plutôt insister sur la
participation active et continue des clients et utilisateurs à l’équipe de développement tout au
long du projet, ce qui permet d’éclaircir la problématique métier à chaque fois que nécessaire
par la discussion directe entre les parties prenantes.
6.2 LA MODÉLISATION MÉTIER AVEC UML

Il existe de nombreuses notations dédiées à la modélisation métier et la modélisation des
processus métier, comme BPMN (Business Process Modeling Notation), les Réseaux de Petri,
EPC (Event-driven Process Chain), etc. UML constitue une autre approche de modélisation
possible. Son intérêt principal est de partager le même cadre conceptuel entre modélisation
métier et modélisation de l’application.
Pour faciliter l’utilisation d’UML, des profils UML dédiés à la modélisation métier ont été
proposés [OMG97 ; Joh04]. Ces profils définissent un petit nombre de concepts spécialisés,
dotés d’une représentation graphique. Ces concepts dédiés peuvent apparaître dans les
diagrammes habituels d’UML, comme les diagrammes de cas, de classes, d’activités, de
séquences, etc.
6.2.1. Acteur métier (Business Actor)

Un acteur métier représente un ensemble de personnes jouant un même rôle en dehors du
système métier et en interaction avec lui. En d’autres termes, il s’agit d’un rôle externe
impliqué dans le métier.
Exemples
Client, Grossiste en pièces détachées, Banque sont des acteurs métier
potentiels d’un garage automobile.
6.2.2. Intervenant métier (Business Worker)

Un intervenant métier représente un ensemble de personnes jouant un même rôle à l’intérieur
du système métier et en interaction avec d’autres intervenants et des entités métier. En
d’autres termes, il s’agit d’un rôle interne au métier.
Exemples
Mécanicien, Chargé d’accueil client, Comptable, Vendeur sont des
intervenants métier potentiels d’un garage.
6 • Introduction à la modélisation métier 107
La notion d’intervenant peut être raffinée en :

– « intervenant à l’interface » (Case Worker) qui interagit directement avec au moins un
acteur métier externe. Cela peut être le cas de Chargé d’accueil client et de
Vendeur dans un garage.
– « intervenant interne » (Internal Worker) qui interagit uniquement avec d’autres

intervenants métier internes. Cela peut être le cas de Mécanicien et de Comptable
dans un garage. La représentation graphique suivante sert aussi dans le cas d’un Worker
indéterminé.
Remarque
Cet ouvrage utilise le terme « participant métier » quand la différenciation externe/interne au
métier n’est pas importante.
6.2.3. Entité métier (Business Entity)

Une entité métier représente un ensemble d’instances d’objets informationnels persistants
que les participants métier créent, modifient, lisent, etc.
Ces objets peuvent être partagés par les participants métier de processus différents.
Exemples
Bon de travail, Voiture, Client, Facture sont des entités métier potentielles
d’un garage.
6.2.4. Cas métier (Business Use Case)

Un cas métier représente un processus métier qui produit un service significatif pour un
ensemble de participants métier.
On a coutume de distinguer les processus « cœur de métier » (core processes) qui satisfont des
acteurs métier et créent directement de la valeur et les processus « de support » (supporting
processes) qui satisfont des intervenants métier et contribuent seulement indirectement à créer
de la valeur.
Exemples
Réparer voiture, Laver voiture, Vendre voiture sont des processus
cœur de métier potentiels d’un garage, associés à l’acteur métier Client. Tenir la
comptabilité est un processus de support potentiel d’un garage, associé à l’intervenant
métier Comptable.
6.2.5. Unité organisationnelle (Organizational Unit)

Une unité organisationnelle représente une collection d’intervenants métier, d’entités métier,
de cas métier et de sous-unités organisationnelles avec leurs interrelations.
Ce concept permet de structurer un modèle métier complexe en le divisant en plusieurs parties
(c’est une spécialisation du concept de paquetage).
Exemples
Gestion comptable, Atelier, Réception, etc., sont des unités organisationnelles
potentielles d’un garage.
6.2.6. Autres concepts

On trouve également de manière optionnelle :
– l’événement métier (business event) qui décrit l’occurrence de quelque chose de
significatif dans l’espace et dans le temps pour le système métier.
Les événements métier sont utiles comme signaux entre les processus et sont souvent
associés aux entités métier.
– le but métier (business goal) qui est une propriété que le système métier doit satisfaire.
Les buts métier peuvent être associés à des processus particuliers ou au métier en général
sous la forme d’un arbre de buts.
– la règle métier (business rule) qui est une condition qui doit être vérifiée.
Les règles peuvent être exprimées en langage naturel (ex. : « une commande doit toujours
être associée à un client ») ou dans un langage formel comme OCL (cf. chapitre 9).
6.3 UNE ÉBAUCHE DE DÉMARCHE

La figure 6.1 définit les grandes lignes de la démarche d’analyse métier.
F IGURE 6.1 Une ébauche de démarche d’analyse métier

La démarche commence par l’identification des participants métier et des cas (processus)
métier. Ces éléments et leurs relations peuvent être synthétisés visuellement dans un
diagramme des cas métier.
La description des cas métier, principalement via des diagrammes d’activités, et l’identification
et la description des entités métier, principalement via un diagramme de classes appelé
« modèle des classes du domaine », peuvent se conduire en parallèle.
La démarche se termine par une phase de consolidation réciproque des modèles.
En cas de besoin, il peut être fait appel également aux diagrammes d’états et aux diagrammes
de séquences pour détailler la dynamique de certains aspects complexes du système métier.
D’autres artefacts, comme un glossaire, peuvent être adjoints aux modèles UML.
EXERCICES
Exercice 6.1. Le Rational UML Profile for Business Modeling

Dans ce profil on trouve l’extrait de méta-modèle suivant :
On rappelle qu’un méta-modèle est un modèle des concepts qui peuvent apparaître dans un
certain type de modèle. Il précise les concepts utilisables, leurs relations, leurs attributs, etc.
Commenter cet extrait de méta-modèle.
Exercice 6.2. Les buts en modélisation métier

a) Comment structurer un ensemble de buts en modélisation métier (buts de l’entreprise, buts
du processus, etc.) ?
b) À quel autre type d’élément le concept de but est-il relié par une association stéréotypée
par <<support>> dans l’extrait de méta-modèle de l’exercice précédent ?
Exercice 6.3. Cas métier et cas d’utilisation

Pour [Ng02], le nombre de cas métier devrait en général être nettement inférieur au nombre
de cas d’utilisation d’un système qui implanterait ce métier (rapport de 1 à 5 jusqu’à 1 à 10).
Comment expliquer cette différence ?
Chapitre 7
La modélisation des processus métier
7.1 LES ACTEURS ET INTERVENANTS MÉTIER

7.1.1. Définition
Un acteur métier est une personne, un groupe de personnes ou une organisation qui interagit
de l’extérieur avec le système métier considéré. En général, on ne rentre pas dans le détail
des intervenants ou systèmes au sein des organisations externes.
Exemples
Clients, fournisseurs, partenaires, banques, administrations et autorités, sous-traitants, etc.
Si le système métier considéré fait partie d’une grande organisation, les acteurs métier
externes peuvent représenter d’autres parties de la même organisation ou des individus dans
ces autres parties.
Un intervenant métier est une personne ou un groupe de personnes jouant un rôle donné à
l’intérieur du système métier.
7.1.2. Recherche
La recherche des acteurs métier constitue habituellement la première étape du processus
d’analyse métier.
Il est conseillé de dresser la liste des acteurs potentiels avec une brève description de la nature
de leur interaction avec le système métier considéré. Les noms des acteurs doivent être choisis
avec soin pour refléter précisément leurs rôles dans le métier.
7.2 LES PROCESSUS MÉTIER

7.2.1. Définition
Les processus métier sont aussi appelés « cas métier » ou même « cas d’utilisation métier ».
Il n’y a pas de plan type pour décrire textuellement un cas métier. Les quatre premiers points
sont considérés comme le minimum à fournir :
(1) un titre,
(2) une brève description,
(3) un ou des buts (la valeur métier),
(4) le flot de tâches normal du processus métier (ou « scénario nominal »).
On peut leur adjoindre d’autres points complémentaires :
(5) les variantes possibles au scénario nominal,
(6) les propriétés requises, par exemple sous forme de préconditions, postconditions et
invariants,
(7) des diagrammes UML pour formaliser plus précisément certains aspects statiques ou
dynamiques. Ce point sera détaillé au paragraphe 7.4.
Si le scénario nominal et ses variantes sont très complexes, il faut essayer de scinder le cas
en plusieurs cas de portée plus restreinte.
7.2.2. La recherche des processus métier

Pour trouver les processus « cœur de métier » on peut commencer par les acteurs métier les
plus importants (souvent les clients) et se demander quels services ils reçoivent du système
métier. Une bonne manière de procéder est de suivre le « cycle de vie » de ces acteurs pour
bénéficier de ce service : leur premier contact avec le système métier, les étapes successives
par lesquelles ils passent, les alternatives possibles à ce processus, les intervenants métier
impliqués, etc.
Pour trouver les processus de support on peut considérer successivement les activités
classiques de cette nature, comme la gestion du personnel, la gestion des infrastructures, la
sécurité, les questions juridiques, etc.
Tous les processus n’ont pas la même importance en fonction du contexte dans lequel
l’analyse du métier est conduite et tous ne nécessitent pas nécessairement une modélisation
détaillée. Pour les processus qui le méritent, il faut produire une description textuelle du
processus, au moins sous la forme d’une première ébauche qui pourra être raffinée par la
suite.
7.3 UN EXEMPLE DE PROCESSUS MÉTIER

Dans l’exemple du garage automobile, la spécification du cas métier Réparer une
voiture peut prendre la forme suivante.
7 • La modélisation des processus métier 115
Titre : Réparer une voiture

Description :
Service rendu à un client qui demande à faire réparer sa voiture.
Buts :
– Rendre le service dans la journée.
– Optimiser l’utilisation des mécaniciens.
Scénario nominal :
1. Accueil du client par le chargé d’accueil client :
– Vérification du rendez-vous. En cas d’erreur, prise d’un nouveau rendez-vous.
– Établissement d’un devis de réparation.
2. Si le devis est accepté par le client, planification du travail par le chef d’atelier.
3. Réparation du véhicule par le mécanicien prévu au planning.
4. Vérification du véhicule par le chef d’atelier. Établissement d’un bon de reprise en
réparation s’il reste des problèmes ou d’un bon de sortie si tout est correct.
5. Préparation de la facture par le chargé d’accueil client au vu du bon de sortie.
6. Au retour du client, règlement de la facture par celui-ci.
Variantes :
1. Refus du devis par le client : aménagement du devis quand c’est possible ou annulation
du rendez-vous.
2. Pièce manquante ou problème lors de la réparation : le chef d’atelier se fournit
auprès d’un confrère ou passe une commande en urgence (le client est prévenu du délai
supplémentaire et un remplacement gratuit du véhicule est proposé).
3. Défaut de paiement par le client : le véhicule est conservé au garage jusqu’au paiement
effectif.
Propriétés :
1. Préconditions :
– L’atelier fonctionne normalement.
– Tous les rôles sont assurés.
2. Postconditions :
– La facture est réglée.
– Le véhicule est rendu propre et en état de fonctionnement.
Autres informations :
Cf. diagrammes UML ci-après.
7.4 LES DIAGRAMMES UML ASSOCIÉS
7.4.1. Le diagramme de cas métier

C’est le diagramme qui correspond au diagramme de cas d’utilisation UML. Il représente
l’ensemble des cas métier correspondant au système métier ou à un sous-système de celui-ci,
comme par exemple une unité organisationnelle.
Chaque cas métier est lié aux acteurs et intervenants métier impliqués par un trait simple qui
modélise leur implication.
Exemple
On reprend l’exemple du garage automobile. Quatre cas métier ont été retenus dans cette
ébauche de diagramme de cas métier. Ces cas métier sont décorés par le stéréotype facultatif
« cœur de métier » ou « support ». Les icônes utilisées ont été explicitées au chapitre
précédent.
F IGURE 7.1 Une ébauche de diagramme de cas métier d’un garage

Remarque
On peut également dessiner un diagramme de contexte qui lie les acteurs métier externes au
système métier vu comme un cas métier unique. Ce diagramme donne une vue synthétique
du système métier au sein de son environnement.
7.4.2. Les diagrammes métier complémentaires

Il faut recourir à ces diagrammes complémentaires lorsque certains aspects du cas métier
méritent d’être approfondis. On en distingue quatre types, les deux premiers étant les plus
fréquemment utilisés :
– Les diagrammes d’activités métier permettent de formaliser plus en détail les flots de
tâches.
– Les diagrammes de classes métier permettent de donner une vision interne des cas métier,
en tant que collaboration entre participants métier via les entités métier.
– Les diagrammes de séquences permettent de formaliser les échanges entre participants
métier.
– Les diagrammes d’états sont utiles pour détailler le cycle de vie de certaines entités métier
particulièrement complexes.
a) Le diagramme d’activités métier

Dans le contexte de la modélisation métier, certaines notations sont plus particulièrement
utilisées :
– Les fork et join pour spécifier des flots d’activités parallèles, fréquents dans le mode de
fonctionnement des organisations.
– Les « couloirs » ou partitions (swimlanes) qui permettent de lier les activités aux
participants métier qui les effectuent.
– Les flots d’entités métier entre activités. Sur chaque entité peut figurer optionnellement un
état, noté entre crochets. Ceci permet de relier diagrammes d’activités métier, diagrammes
de classes et diagrammes d’états.
La figure 7.2 de la page suivante donne le diagramme d’activités métier associé au cas
métier Réparer une voiture, décrit au paragraphe 7.3. On peut y noter l’utilisation
des partitions et des flots d’entités.
b) Le diagramme de classes métier

Si les cas métier reflètent la vue que peuvent avoir du système ou du sous-système les acteurs
métier externes, le diagramme de classes métier correspond à la vue que peuvent en avoir les
intervenants métier internes.
Le diagramme de classes métier est aussi appelé Business Object Model (BOM). Il montre
comment les intervenants métier et les entités métier sont reliés et contribuent à la réalisation
du processus. Le plus souvent, les entités sont seulement caractérisées par un nom et les
Partie 2. La modélisation métier
F IGURE 7.2 Le diagramme d’activités métier de la réparation d’une voiture

118
associations qui les relient restent anonymes, précisées seulement par leurs cardinalités
(multiplicités), comme on peut le voir sur la figure 7.3.
On trouve parfois des diagrammes de classes métier sans les intervenants, avec uniquement
les associations entre entités métier.
Ce modèle ne doit pas être confondu avec le modèle des classes du domaine qui est un
diagramme de classes plus détaillé représentant les entités conceptuelles significatives du
domaine avec leurs relations. Il est présenté en détail au chapitre suivant.
Exemple
Dans le diagramme des classes métier du garage de la figure 7.3, on peut noter l’apparition de
l’entité Voiture, jamais évoquée jusqu’ici. Ce n’est pas surprenant, puisque le but de ces
diagrammes complémentaires est précisément d’enrichir différents aspects de la modélisation
métier.
F IGURE 7.3 Le diagramme de classes métier de la réparation d’une voiture

c) Le diagramme de séquences
Classiquement les diagrammes de séquences détaillent la chronologie des échanges de
messages entre les éléments qui interviennent durant un scénario. En modélisation métier, ils
servent surtout à détailler les échanges entre acteurs externes et intervenants internes.
Exemple
La figure 7.4 donne le diagramme de séquences du scénario nominal de la réparation.
F IGURE 7.4 Le diagramme de séquences du scénario nominal de la réparation

On peut remarquer sur la figure 7.4 que certains échanges sont de nature matérielle, comme
le transfert de la voiture, et non informationnelle. Ce n’est pas un problème dans ce contexte.
d) Le diagramme d’états
Il permet la spécification du cycle de vie des entités métier les plus complexes.
Exemple
La modélisation des états d’une voiture lors d’une réparation.
F IGURE 7.5 Le diagramme d’états de la voiture en réparation
On note sur la figure 7.5 les actions associées aux états qui peuvent être rapprochées des
activités du diagramme d’activités métier.
7.5 VERS LES SPÉCIFICATIONS LOGICIELLES

La modélisation des cas métier constitue une base solide pour l’analyse des besoins d’une
future application informatique. Les activités que l’on souhaite informatiser ont vocation à
devenir des cas d’utilisation du logiciel. De même, les acteurs et participants métier impliqués
dans ces activités ont vocation à devenir des acteurs des cas d’utilisation du logiciel.
Exemple
Si l’application de gestion du garage prévoit d’informatiser le poste du chargé d’accueil
client, les activités suivantes peuvent devenir des cas d’utilisation :
– gérer les rendez-vous (pour les activités métier Vérifier rendez-vous et Prendre
rendez-vous),
– gérer les devis (pour l’activité métier Établir devis et la saisie de la décision du
client),
– gérer les factures (pour l’activité métier Établir facture et pour la saisie du
règlement du client).
Soit l’ébauche de diagramme des cas d’utilisation suivante.
F IGURE 7.6 Cas d’utilisation associés au Chargé d’accueil client

EXERCICES
Exercice 7.1. Analyse métier – location de véhicules

La société LocAuto loue des voitures et des camionnettes. Le prix de la location est composé
d’un forfait journalier et d’un supplément kilométrique au-delà de 200 km parcourus par
jour de location. La location se fait par journée sur une ou plusieurs journées consécutives
avec départ et retour à l’agence. Le forfait journalier tient compte de la catégorie du véhicule
(véhicule léger économique ou véhicule léger luxe ou camionnette) et de la période (semaine,
week-end, vacances été). Le supplément kilométrique est fonction de la catégorie du véhicule.
L’âge du conducteur et le nombre d’années depuis l’obtention du permis influent aussi sur le
calcul du prix de la location. Ce prix inclut l’assurance du véhicule et du conducteur, tous
deux fonction de la catégorie du véhicule. C’est en fonction de son type (marque et modèle)
qu’un véhicule est affecté à une catégorie.
Lors de la réservation (par téléphone, mail ou visite à l’agence), le client précise à l’employé
d’agence les caractéristiques de sa demande : son nom, adresse et âge, la date d’obtention
de son permis, la date et la durée de la location, la catégorie de véhicule demandée. Il reçoit
une réponse positive ou négative selon les disponibilités à la date indiquée. Un véhicule est
immédiatement réservé. L’employé prépare le contrat de location avant la date prévue pour
l’emprunt du véhicule.
Lors de l’emprunt du véhicule à l’agence le client doit montrer son permis de conduire à
l’employé, signer le contrat de location et déposer une caution qui dépend de la catégorie du
véhicule. Une fiche indiquant l’état du véhicule lui est soumise. Le client indique les défauts
supplémentaires qu’il constate (ou leur absence) afin de mettre à jour la fiche d’état qui reste
stockée à l’agence. Le kilométrage au départ est relevé.
Lorsque le client ramène le véhicule à l’agence, l’employé compare son état en sa présence
avec la fiche d’état. Les éventuels défauts supplémentaires sont ajoutés sur la fiche d’état
et des frais de remise en état sont évalués. Le kilométrage à l’arrivée est relevé par
l’employé d’agence. La facture incluant la location et les frais de remise en état est rédigée.
Normalement, le client la règle immédiatement et la caution lui est rendue. En cas de
non-règlement dans un délai maximum de 8 jours la caution est conservée et le dossier est
transmis au contentieux.
Si le client provient d’une autre agence, la réception se fait avec une copie de la fiche d’état
qui est faxée par l’agence concernée.
Périodiquement, le mécanicien de l’agence prend la fiche d’état de chaque véhicule et répare
un maximum de défauts. Il rédige une nouvelle fiche d’état du véhicule.
a) Construire le diagramme de cas métier.
b) Donner la description textuelle du ou des cas métier correspondant au retour d’un véhicule
avec la possibilité de règlement immédiat.
Exercice 7.2. Diagramme d’activité métier (suite de l’exercice 7.1.)

Décrire le diagramme d’activités métier du retour d’un véhicule.
124 Exercices
Exercice 7.3. Diagramme de classes métier (suite de l’exercice 7.1.)

Décrire le diagramme de classes métier du retour d’un véhicule.
Exercice 7.4. Diagramme de séquences d’un cas métier (suite de l’exercice 7.1.)
Décrire le diagramme de séquences du cas nominal du retour d’un véhicule.
Exercice 7.5. Diagramme d’états d’une entité métier (suite de l’exercice 7.1.)
Décrire le diagramme d’états de l’entité métier véhicule.
Chapitre 8
La modélisation du domaine
8.1 DÉFINITION
La modélisation du domaine consiste à représenter visuellement, par un schéma de
classes UML, les concepts remarquables du domaine étudié. On obtient ainsi une sorte de
« dictionnaire visuel » des concepts de la portion du monde réel considérée. Cette description
ne doit pas être confondue avec celle des classes logicielles de la future application ayant
pour but de répondre à certains besoins au sein de ce domaine d’application.
La construction d’un tel modèle permet de se focaliser sur la signification des choses dans
l’espace problème, c’est-à-dire sur le niveau sémantique. C’est une description très stable,
aussi stable que le métier lui-même. Les sources d’information sont les cas métier (s’ils ont
déjà été élaborés), les autres descriptions du métier, les connaissances des experts du domaine
et toutes les connaissances générales que les analystes possèdent.
La modélisation du domaine permet de fixer un langage commun à tous les intervenants d’un
projet et peut servir de point de départ pour la définition des modèles de classes des futures
applications opérant dans ce domaine.
8.2 ÉLÉMENTS DU MODÈLE DU DOMAINE

Un modèle des classes du domaine comprend des classes conceptuelles et des associations
qui les lient avec leurs cardinalités (multiplicités). Les classes conceptuelles sont décrites par
leurs noms et les noms de leurs attributs. Les notations sont celles des modèles de classes
habituels.
En comparaison, les classes logicielles contiendront beaucoup plus de détails liés aux
traitements et à l’implantation des données, comme des types de données associés aux
attributs et aux méthodes (paramètres et résultat).
Si nécessaire, des règles métier importantes peuvent être spécifiées textuellement ou
formellement (cf. chapitre 9) dans des notes associées aux éléments du modèle.
Exemple : Modélisation du domaine de la location d’outils de bricolage.
F IGURE 8.1 Un exemple de modèle des classes du domaine

8 • La modélisation du domaine 127
Les boutiques de ce genre offrent à leurs clients la location d’outils décrits dans un catalogue,
avec pour chaque type d’outil un tarif par jour de location prévu et un tarif par jour de retard.
Le règlement de la location se fait au retrait de l’outil pour une durée donnée et le règlement
des éventuels frais de retard se fait quand l’outil est rendu.
8.3 L’IDENTIFICATION DES CLASSES DU DOMAINE

Il existe trois techniques qui peuvent aider à l’identification des classes du domaine :
(1) l’utilisation de listes de catégories de classes conceptuelles,
(2) l’analyse linguistique de documents (cas métiers ou autres),
(3) la réutilisation de modèles sous la forme de patrons d’analyse (analysis pattern).
8.3.1. Les listes de catégories de classes conceptuelles

Ces listes servent de guide pour une recherche systématique par catégories de concepts. Par
exemple, la liste suivante qui s’inspire largement d’une liste proposée par Craig Larman
[Lar95], propose les catégories suivantes :
– objets physiques tangibles (ex. : une voiture, une machine, un bureau, un dé, etc.),
– abstractions (ex. : un but, une condition, une idée, etc.),
– conteneurs d’autres objets (ex. : un stock, un répertoire, un plateau de jeu, etc.),
– objets dans les conteneurs (ex. : une pièce détachée, un passager, un pion, etc.),
– descriptions d’objet (ex. : une description de produit, une description de voyage, etc.),
Remarque : Il est conseillé de séparer la description d’un type d’items des items eux-
mêmes car la description n’est pas propre à chaque item et doit subsister même aux instants
où aucun item de ce type ne subsiste.
– endroits (ex. : un magasin, un aéroport, une agence, etc.),
– rôles (ex. : un caissier, un pilote, un joueur, etc.),
– transactions (ex. : une commande, un règlement, une réservation, un tour de jeu, etc.),
– éléments de transactions (ex. : une ligne de commande, un produit livré, etc.),
– systèmes externes (ex. : un système d’autorisation de crédit, un système de contrôle de
trafic, etc.),
– règles (ex. : une règle de tarification, une politique d’annulation, etc.),
– organisations (ex. : une banque, un service de comptabilité, etc.),
– catalogues (ex. : un catalogue de produits, une nomenclature de pièces, etc.)
– enregistrements (ex. : un historique, des logs, etc.),
– documents écrits (ex. : une copie, un livre, un contrat, etc.),
– événements (ex. : un atterrissage, une réunion, etc.),
– processus (ex. : une vérification, une réparation, une mise à jour, etc.).
8.3.2. L’analyse linguistique de documents

Dans les textes qui décrivent le domaine, en particulier les cas métier mais aussi les glossaires
et d’autres documents de présentation, les noms et groupes nominaux désignent souvent les
concepts du domaine et donc des classes conceptuelles candidates.
Ce genre d’analyse donne seulement des indications. Un certain « bruit » entoure toujours la
description des concepts : il faut tenir compte de l’utilisation fréquente dans tous les textes
de termes très généraux, de l’ambiguïté de certains termes et des possibilités de synonymie.
Un nom peut également correspondre à un attribut s’il représente une valeur élémentaire,
comme un nombre ou une chaîne de caractères, et pas un concept plus élaboré.
8.3.3. Les patrons d’analyse

Les patrons d’analyse ont été introduits par Martin Fowler en 1997 [Fow97]. Il les définit
comme « un groupe de concepts qui représente une construction fréquente en modélisation
métier ». Un patron d’analyse peut être utile dans un seul domaine d’activité ou il peut
se retrouver dans beaucoup de domaines d’activités. Dans son ouvrage de référence,
Martin Fowler classe ses propositions en catégories qui correspondent soit à des domaines
d’activité particuliers (comptabilité, commerce, etc.) soit à des problématiques générales.
Les paragraphes suivants donnent à titre d’exemple un patron caractéristique dans chacune
de ces catégories d’intérêt général.
a) Mesures et observations
Les patrons de cette catégorie s’intéressent à l’enregistrement de différents types de faits.
Exemple
Un grand nombre de mesures peuvent concerner une même personne, dont certaines
peuvent ne pas être numériques. La solution consiste à créer des objets Phénomène et
Observation. De plus, une Observation est soit une Mesure soit une Catégorie
Observée prise parmi un ensemble de Catégories.
F IGURE 8.2 Patron de la catégorie « Mesures et Observations »

Remarque : L’unité de la mesure peut se représenter comme un attribut ou constituer une

classe supplémentaire liée à Mesure.
b) Responsabilités
Ces patrons décrivent les responsabilités des personnes et des organisations.
Exemple
De nombreuses personnes et unités organisationnelles peuvent être décrites par des propriétés
similaires (adresse, mail, téléphone, etc.). La solution consiste à créer un type Partie en
tant que supertype des types Personne et Unité.
F IGURE 8.3 Patron de la catégorie « Responsabilités »
Remarque : Adresse, téléphone et mail peuvent aussi être représentés comme des attributs.
c) Planification
Ces patrons traitent des plans et des ressources.
Exemple
Il faut parfois gérer à la fois des activités prévues et des activités réalisées. La solution
consiste à utiliser des objets distincts pour ces deux types d’activités.
F IGURE 8.4 Patron de la catégorie « Planification »

Les patrons d’analyse n’ont pas connu le même succès que les patrons de conception. Il
en existe potentiellement un nombre quasi infini et la probabilité de pouvoir les mettre en
œuvre est assez faible. L’effort à faire pour se les approprier peut sembler disproportionné
par rapport aux avantages que l’on peut espérer en tirer.
8.4 L’IDENTIFICATION DES ASSOCIATIONS DU DOMAINE

On dispose des mêmes techniques que pour l’identification des classes du domaine. On ne
revient pas dans la suite sur les patrons d’analyse qui permettent d’identifier à la fois classes
et associations.
8.4.1. Les listes de catégories d’associations conceptuelles

On peut citer les catégories suivantes qui sont parmi les plus fréquentes :
– A est une partie physique de B (ex. : roue et voiture),
– A est une partie logique de B (ex. : tronçon et itinéraire),
– A est physiquement contenu dans B (ex. : pièce et stock),
– A est logiquement contenu dans B (ex. : étudiant et classe),
– A est une description de B (ex. : description de voyage et voyage),
– A est un item d’une transaction B (ex. : ligne de commande et commande),
– A est connu/tracé/enregistré/capturé dans B (ex. : vente et registre des ventes),
– A est un membre de B (ex. : mécanicien et garage),
– A est une sous-unité de B (ex. : service comptable et entreprise),
– A utilise/gère B (ex. : pilote et avion),
– A communique avec B (ex. : client et caissier),
– A est lié à une transaction B (ex. : client et règlement),
– A est une transaction liée à une autre transaction B (ex. : vente et règlement),
– A suit B (ex. : phase et phase suivante),
– A est possédé par B (ex. : avion et compagnie aérienne),
– A est un événement lié à B (ex. : défaut de stock et réapprovisionnement).
Il faut se focaliser sur les associations indispensables pour la compréhension du domaine

et éviter celles qui sont redondantes ou dérivables d’autres associations. Certains auteurs
soulignent que l’identification des concepts est plus fondamentale que celle des associations.
En UML, certaines catégories ci-dessus peuvent se représenter comme des agrégations (« un
tout vers une partie du tout » avec des durées de vie indépendantes) ou des compositions
(avec des durées de vie liées).
Les relations de généralisation/spécialisation (« héritage ») sont intéressantes dans les
modèles des classes du domaine car elles soulignent les points communs entre concepts.
Elles peuvent aider à comprendre les concepts de manière plus abstraite.
8.4.2. L’analyse linguistique de documents

Les associations sont repérables à travers de nombreuses constructions :
– les verbes (ex. : la compagnie aérienne gère des vols),
– les pronoms possessifs (ex. : l’élève rend sa copie),
– les formes exprimant la possession ou l’appartenance (ex. : du, de, de la, des. . . ), etc.
8.5 UN EXEMPLE
Il s’agit de décrire la caisse d’un magasin. On analyse tout d’abord le cas métier Passage
en caisse qui propose le scénario nominal suivant. Les noms et groupes nominaux à
analyser sont soulignés.
(1) Le client arrive à la caisse avec les produits qu’il a choisis.
(2) Le caissier commence une nouvelle vente.
(3) Le caissier saisit l’identification du produit et éventuellement une quantité.
(4) La caisse affiche la description du produit, son prix et le montant courant.
(5) Le caissier répète les deux points précédents pour chaque item de la vente.
(6) La caisse affiche le montant total.
(7) Le caissier demande le règlement.
(8) Le client paye le montant demandé et le caissier enregistre le règlement.
(9) La caisse transmet les informations au système comptable et au système de gestion des
stocks.
(10) La caisse imprime le ticket de caisse.
(11) Le client quitte la caisse avec le ticket de caisse et les produits.
Les noms retenus comme reflétant a priori des concepts importants du domaine sont : Client,
Caisse, Produit, Caissier, Vente, Item et Règlement.
Les noms dénotant des valeurs élémentaires, donc des attributs, sont : Identification (du
produit), Quantité (d’un élément de la vente), Description (du produit), Prix (du produit),
Montant (de l’item, de la vente, du règlement).
Les noms écartés car considérés comme moins importants ou liés à l’implantation sont :
Système comptable, Système de gestion des stocks et Ticket de caisse.
Le concept de Vente apparaît au cœur du modèle. Le Client et le Caissier sont liés à la Vente
(association « A est lié à une transaction B »). La Vente utilise la Caisse (association « A
utilise B »). Le Règlement résulte de la Vente (association « A est une transaction liée à une
autre transaction B »). L’Item est un élément de la Vente (association « A est un item d’une
transaction B »). L’Item est décrit par le Produit (association « A est une description de B »).
La figure 8.5 donne la première esquisse du modèle du domaine résultant de cette analyse
linguistique.
F IGURE 8.5 La première esquisse du modèle des classes du domaine
Pour beaucoup de spécialistes, il vaut mieux trop d’éléments que de passer à côté d’un
concept important. On peut chercher à enrichir le modèle en s’aidant de la liste des catégories
de classes conceptuelles. Par exemple :
– la catégorie « description d’objet » peut inciter l’analyste à distinguer la Description
Produit (le type) et les instances (pour lesquelles on conserve le nom Produit) ; ce n’est
envisageable que pour des produits dont les instances sont bien identifiables par une
référence,
– la catégorie « conteneur d’objets » peut inciter l’analyste à introduire le concept de Stock
qui contient toutes les instances de produit (vendues et disponibles),
– la catégorie « enregistrement » peut inciter l’analyste à introduire un Enregistrement des
ventes (par caisse et par caissier).
Il n’existe pas de modèle « complet » ou « idéal ». La description obtenue doit satisfaire
les experts du domaine et répondre aux besoins de compréhension du métier des divers
intervenants à cet instant. La version enrichie de l’exemple est la suivante (cf. figure 8.6).
F IGURE 8.6 La version enrichie du modèle des classes du domaine

134 Exercices
EXERCICES
Exercice 8.1. Domaine de la location de véhicules

Définir par une analyse textuelle de l’énoncé de l’exercice 7.1., le modèle des classes du
domaine du loueur de véhicules LocAuto.
Exercice 8.2. Domaine de la gestion des eaux

On veut modéliser les concepts liés à la gestion du réseau de production d’eau potable d’un
syndicat de communes en vue d’une future informatisation.
L’eau provient de captages par forage dans les nappes souterraines. Chaque captage est
caractérisé par un nom, un débit maximum exprimé en m3 d’eau par heure, une profondeur et
un diamètre du forage. Pour chaque captage, on conserve le débit moyen calculé pour chaque
mois de l’année, ce qui permet de prévoir les éventuels problèmes d’alimentation en eau.
Chaque captage alimente grâce à des pompes automatiques un ou des réservoirs (châteaux
d’eau) dont la fonction est le stockage de l’eau à distribuer.
Chaque réservoir a un nom et une capacité maximale. Pour garantir la continuité du service
de distribution d’eau potable, chaque réservoir est relié, en plus de son captage principal, à
un ou plusieurs captages de secours pour le cas où le captage principal soit interrompu. La
mise en service de la connexion d’un réservoir à l’un de ses captages de secours est sous
la responsabilité d’un technicien, dont il faut connaître le nom et le numéro de téléphone
portable.
La production d’eau est soumise à des normes de qualité exigeantes. Le syndicat de
communes effectue fréquemment des analyses de l’eau en collaboration avec un laboratoire
indépendant. Ces analyses sont réalisées soit au niveau des captages, soit au niveau des
réservoirs. Deux critères de qualité biologiques sont impératifs : on ne tolère la présence
d’aucune bactérie de type Escherichia Coli ni d’aucun entérocoque dans l’eau. En ce qui
concerne les substances chimiques et les métaux (arsenic, cadmium, cyanure, mercure,
plomb, etc.), la réglementation fixe pour chacun d’entre eux une concentration maximale à
ne pas dépasser exprimée en microgramme par litre. Il est imposé de conserver les résultats
obtenus à chaque analyse.
Donner une ébauche du diagramme des classes du domaine à partir d’une analyse de cette
description textuelle.
Exercice 8.3. Domaine de la gestion d’un cirque

On veut modéliser les concepts du domaine relatifs à la gestion d’un cirque qui songe à une
informatisation de sa gestion.
Les membres du personnel du cirque sont caractérisés par leur état civil (nom, prénom), leur
date de naissance et leur salaire. On souhaite de surcroît stocker les pseudonymes des artistes
et le numéro du permis de conduire des chauffeurs de poids lourds.
Les artistes sont susceptibles d’assurer plusieurs numéros de cirque, chaque numéro étant
caractérisé par un nom, le nombre d’artistes présents sur la scène et une durée. De plus, on
souhaite savoir l’instrument utilisé pour les numéros musicaux, l’animal concerné par les
numéros de dressage et le type des acrobaties (contorsionnisme, équilibrisme, trapèze volant,

etc.). Par ailleurs, chaque numéro peut nécessiter un certain nombre d’accessoires caractérisés
par une désignation, une couleur et un volume.
On souhaite également savoir, individuellement, quels artistes utilisent quels accessoires.
Enfin, les accessoires sont rangés après chaque spectacle dans des camions caractérisés par
leur numéro d’immatriculation, leur marque, leur modèle et leur capacité (en volume). Selon
la taille du camion, une équipe plus ou moins nombreuse de chauffeurs lui est assignée (de
un à trois chauffeurs).
Chapitre 9
Les spécifications formelles avec OCL
9.1 PRÉSENTATION DU LANGAGE OCL

OCL (Object Constraint language) [OMG14] est le langage de spécification de contraintes,
ou plus largement d’expressions, associé à UML. Son objectif est l’enrichissement de la
plupart des diagrammes UML pour les rendre plus précis. Son utilisation principale concerne
les schémas de classes où il permet d’établir formellement les caractéristiques des classes et
de leurs méthodes (leurs contrats).
La figure 9.1 montre un diagramme de classes classique suivi du même diagramme « décoré »
par quelques expressions OCL dans des commentaires liés aux éléments concernés. Ce type
de représentation graphique devient rapidement illisible quand il y a beaucoup d’expressions.
Il est alors préférable de regrouper les expressions OCL dans un fichier texte séparé du dia-
gramme, comme montré ci-après.
-- invariant : le nombre de siège est positif
context Avion
inv : self.nombreDeSièges > 0
-- initialisation : initialement, il n’y a aucun passager

context Vol :: passagers : Set(Personne)
init : Set{}
-- dérivation : l’attribut nombreDePassagers est le nombre de liens de Vol à

Personne
context Vol :: nombreDePassagers : Integer
derive : passagers -> size()
-- requête : la méthode siègesDisponibles() rend la différence entre

-- la capacité de l’avion et le nombre de passagers
context Vol :: siègesDisponibles() : Integer
body : capacité - nombreDePassagers
F IGURE 9.1 Un diagramme de classes et sa « décoration » OCL

9 • Les spécifications formelles avec OCL 139
9.2 CARACTÉRISTIQUES DU LANGAGE OCL

9.2.1. Propriétés générales
OCL est un langage formel basé sur la théorie des ensembles et la logique des prédicats.
Il se veut simple à utiliser, grâce à une notation dite « intuitive » proche des langages de
programmation et moins rebutante qu’une notation truffée de symboles mathématiques. Il est
standardisé par l’OMG (http://www.omg.org/spec/OCL/ ).
OCL est un langage déclaratif, qui décrit de manière abstraite ce que réalise l’application à
travers un ensemble d’expressions qu’elle vérifie. Il est sans effet de bord, c’est-à-dire que les
instances ne sont jamais modifiées par les expressions. Il est donc assimilable à un langage de
requêtes et non à un langage de programmation. C’est un langage typé. Toutes les expressions
possèdent un type qui permet de vérifier leur cohérence.
9.2.2. Utilisations possibles

Les expressions OCL servent le plus souvent à décrire :
– des invariants de classe, c’est-à-dire des contraintes qui doivent être respectées à tout
instant par toutes les instances de la classe,
– des préconditions d’opération, c’est-à-dire des contraintes qui doivent être vraies avant
l’exécution de l’opération,
– des postconditions d’opération, c’est-à-dire des conditions vraies après l’exécution de
l’opération (effets),
– des valeurs retournées par les méthodes sans effet de bord (requêtes),
– des initialisations d’attribut,
– des valeurs d’attribut dérivé,
– des gardes, c’est-à-dire des conditions d’évolution dans les diagrammes représentant la
dynamique (diagrammes de séquences, d’activités, d’états).
À noter qu’OCL a aussi été utilisé pour rendre plus précis le méta modèle UML. On
rappelle qu’un méta modèle est un modèle de modèle, c’est-à-dire un modèle qui décrit
la structure d’un modèle : Quels composants ? Quelles associations entre composants ?
Quelles propriétés des composants et associations ? Par exemple, un diagramme d’états
UML contient des composants État et Transition d’état. Une transition d’état
définit un état suivant. Il existe un état initial, etc. Ce méta modèle peut être ébauché
en UML comme montré par la figure 9.2.
OCL permet d’être beaucoup plus précis sur ce qui est possible ou non dans un diagramme
d’états.
Exemple
Deux états distincts portent nécessairement des noms différents :
context Etat
inv: Etat.allInstances() -> forAll(e1, e2 | e1<>e2 implies e1.nom<>e2.nom)
F IGURE 9.2 Ébauche du méta modèle des diagrammes d’états UML
9.3 SYNTAXE DE BASE DES CONTRAINTES OCL

9.3.1. Notion de contexte
Une expression OCL est toujours définie dans un contexte (context). Ce contexte est une
instance d’une classe. L’expression OCL s’applique à la classe définie par le contexte, c’est-
à-dire à toutes les instances de cette classe.
9.3.2. Invariant
Un invariant (inv) exprime une contrainte sur un objet ou un groupe d’objets qui doit être
respectée en permanence.
Exemples
context p : Personne
inv : p.nom <> ’’ -- toute personne a un nom non vide (commentaire)
context Personne
inv : nom <> ’’ -- autre syntaxe possible
context Personne
inv : self.nom <> ’’ -- autre syntaxe possible
-- la notation . permet d’accéder à une caractéristique d’un objet,
-- attribut, méthode, extrémité d’association (navigation)
-- self représente l’objet désigné par le contexte
context Personne
inv : (age <= 100) and (age >= 0) -- age est compris entre 0 et 100
context p : Personne
inv borneAge : (p.age <= 100) and (p.age >= 0) -- invariant nommé
9.3.3. Pré et postconditions

Une précondition contraint généralement les paramètres d’entrée d’une opération (pre). Une
postcondition spécifie la sémantique d’une opération. C’est-à-dire ce qu’elle fait, ce qu’elle
modifie, et non comment elle le fait.
Exemple
context Personne :: setAge(a : entier)
-- la notation :: désigne attribut, méthode ou extrémité d’association
pre : (a <= 100) and (a >= 0) and (a >= age)
post : age = a
Dans les postconditions uniquement, on peut utiliser les opérateurs spéciaux :

– @pre, pour accéder à la valeur d’une propriété avant l’exécution de l’opération,
– result, pour accéder au résultat de l’opération.
Exemples
context Compte :: debiter(somme : Real)
pre : somme > 0
post : solde = solde@pre - somme
context Compte :: getSolde() : Real

post : result = somme
9.3.4. Retour d’une méthode sans effet de bord (requête)

Ce que réalise le corps de l’opération (body) est spécifié en définissant le résultat retourné.
Exemple
context Compte :: getSolde() : Real
body : self.solde
9.3.5. Valeurs d’attributs

On peut spécifier la valeur initiale d’un attribut (init) ou la valeur d’un attribut dérivé (derive).
Exemples
context Compte :: solde : Real
init : 0.0
context Vol :: nombreDePassagers : Integer

derive : passagers -> size()
-- passagers est le nom de rôle de l’association
9.4 ÉCRITURE D’EXPRESSIONS OCL COMPLEXES

9.4.1. Expressions composées
Outre les opérateurs logiques (and, or, xor, not . . . ) on peut utiliser if et implies :
– if expr1 then expr2 else expr3 endif si l’expression expr1 est vraie alors expr2 doit être
vraie sinon expr3 doit être vraie,
– expr1 implies expr2 si l’expression expr1 est vraie, alors expr2 doit être vraie.
Exemple
On suppose l’existence dans Personne d’un attribut booléen dérivé majeur et d’un attribut
booléen marié.
context Personne
inv :
if age>=18 then
majeur=vrai
else
majeur=faux
endif
context Personne
inv : marié implies majeur
9.4.2. Variables
On peut définir des variables pour simplifier l’écriture d’une expression avec la syntaxe :
let variable : type = expression1 in expression2
Exemple
Mise en facteur du calcul du montantImposable dans une expression qui le calcule selon
différentes formules correspondants à des tranches d’imposition différentes.
context Personne
inv :
let montantImposable : Real = salaire*0.8 -- 80% du salaire
in
if (montantImposable >= 100000) -- tranche à 45%
then impot = montantImposable*45/100
else if (montantImposable >= 50000)
then impot = montantImposable*30/100 -- tranche à 30%
else impot = montantImposable*10/100 -- tranche à 10%
endif
endif
On peut aussi définir une variable ou opération utilisable dans plusieurs expressions avec la
syntaxe :
def variable : type = expression1
Exemples
context Personne
def : montantImposable : Real = salaire*0.8
context Personne
def : ageCorrect(a : Real) : Boolean = (a >= 0) and (a <= 100)
Avec cette opération, on peut réécrire l’invariant sur l’âge :
context Personne
inv : ageCorrect(age) -- l’age est entre 0 et 100 ans
9.4.3. Types et opérateurs

Les types et les principaux opérateurs OCL sont récapitulés dans le tableau suivant.
Type Exemples de valeurs Opérateurs

Boolean true false and or xor not implies if-then-else-endif . . .
Integer 1 -5 2 34 26524 * / + - abs() . . .
Real 1,5 3,14 * / + - abs() floor() . . .
String "To be or not to be" concat() size() substring() . . .
On peut utiliser une valeur d’un type énuméré par la notation :

NomEnum::valeur.
Exemples
context Personne
inv :
if age <=12 then cat = Categorie::enfant
else if age <=18 then cat = Categorie::ado
else cat = Categorie::adulte
endif
endif
context Personne
inv: genre = Genre::femme
9.4.4. Exploitation de la relation de spécialisation

Les spécialisations entre classes peuvent être prises en compte avec les opérations :
– oclIsKindOf(type) : vrai si l’objet est du type type ou un de ses sous-types,
– oclIsTypeOf(type) : vrai si l’objet est du type type.
Exemple
Soit la classe Pilote qui dérive de la classe Personne. Dans le contexte de la classe
Pilote self.oclIsKindOf(Pilote) et self.oclIsKindOf(Personne) sont
vraies.
9.4.5. Types collection

Il existe plusieurs sous-types du type abstrait Collection :
– Set : ensemble non ordonné d’éléments uniques.
– OrderedSet : ensemble ordonné d’éléments uniques (ordered).
– Bag : collection non ordonnée d’éléments avec possibilité de doublons.
– Sequence : collection ordonnée d’éléments avec possibilité de doublons.
9.4.6. Accès aux objets et navigation

Dans une expression OCL associée à un objet, on peut :
– accéder à l’état interne de cet objet (ses attributs) : self.attribut,
– accéder aux opérations de cet objet : self.operation,
– naviguer le long des associations, c’est-à-dire accéder de manière transitive à tous les
objets ou groupe d’objets avec qui cet objet est en association : via un nom de rôle ou
à défaut via le nom de la classe associée avec sa première lettre en minuscule. Il y a
ambiguïté si de multiples associations existent entre cet objet et la classe associée ou si
l’association est réflexive. Dans ce cas le nom de rôle est indispensable.
Exemple
context Vol
inv: self.personne.age <= 60 -- ambigu car deux associations
inv: self.pilote.age <= 60 -- non ambigu
Si l’objet référencé est une instance de la classe X et la multiplicité de l’association du côté

de cette classe X est :
– 1, le type du résultat est un objet X,
– *, le type du résultat est un Set(X) ;
– * avec contrainte ordered, le type du résultat est un OrderedSet(X).
Si on compose plusieurs accès, le type du résultat peut être un Bag ou une Sequence.
Exemples
Dans le contexte de la classe Vol :
appareil est de type Avion ;
passagers est de type Set(Personne)
escales est de type OrderedSet(Aeroport)
escales.localisation est de type Sequence(Pays)
passagers.nationalite est de type Bag(Pays)
9.4.7. Opérations sur les collections

Les opérations sur les Collections sont nombreuses et leur utilisation est notée :
collection -> operation().
On remarque l’utilisation de la flèche à la place de la notation pointée.

Parmi les opérations les plus souvent utilisées, on peut mentionner :
– size() retourne le nombre d’éléments de la collection,
– count(obj) retourne le nombre d’occurrences de l’objet obj dans la collection,
– sum() retourne la somme de tous les éléments (entiers ou réels) de la collection,
– exists(elem : T | uneExpression) ou exists(uneExpression)
retourne vrai si et seulement si au moins un élément de la collection satisfait l’expression
uneExpression,
– isEmpty()/notEmpty() retourne vrai si la collection est/n’est pas vide,
– includes(obj)/excludes(obj) retourne vrai si la collection inclut/n’inclut pas
l’objet obj,
– includesAll(coll)/excludesAll(coll) retourne vrai si la collection contient
tous/ne contient aucun des éléments de la collection coll,
– AllInstances() retourne toutes les instances de la classe référencée,
– forAll(elem : T | uneExpression) ou forAll(uneExpression)
retourne vrai si et seulement si l’expression uneExpression est vraie pour tous les
éléments de la collection,
– union retourne l’union de deux collections,
– intersection retourne l’intersection de deux collections,
– select(elem : T | uneExpression) ou select(uneExpression)
retourne les éléments de la collection qui vérifient l’expression uneExpression,
– reject(elem : T | uneExpression) ou reject(uneExpression)
retourne tous les éléments de la collection exceptés ceux qui vérifient l’expression
uneExpression,
– collect(elem : T | uneExpression) ou collect(uneExpression)
retourne la collection des valeurs (Bag) résultant de l’évaluation de l’expression
uneExpression appliquée à tous les éléments de la collection.
Exemples
context Vol
inv : not(self.pilote -> exists(age<18))
-- pas de pilote de moins de 18 ans
context Personne
inv: Personne.allInstances() -> forAll(p1, p2 | p1 <> p2 implies p1.nom <>
p2.nom)
-- deux personnes distinctes ont des noms différents
context Personne
inv: self.comptes.solde->sum() > 0
-- la somme des comptes d’une personne est positive
9.5 DES CONSEILS D’UTILISATION

On peut donner quelques conseils pour une bonne utilisation du langage OCL.
En premier lieu, le conseil de la simplicité. Les expressions formelles doivent servir à lever
des ambiguïtés ponctuelles et non à rendre les spécifications inutilement compliquées.
Ensuite, le conseil d’associer toujours un commentaire en langage naturel à une expression
OCL, pour joindre compréhension aisée et non-ambiguïté.
Enfin, le conseil d’utiliser des outils pour au moins vérifier la syntaxe des expressions lors de
leur saisie dans un outil de modélisation et éventuellement pour :
– vérifier que des diagrammes d’objets sont conformes aux expressions sur les classes,
– générer un squelette d’application à partir du modèle de classes décoré afin que les
contraintes soient surveillées à l’exécution et que certaines expressions (initialisations,
règles de dérivation, etc.) soient correctement implantées.
EXERCICES
Exercice 9.1. Gestion immobilière

Le schéma de classes ci-dessous décrit la gestion d’emprunts immobiliers. Écrire les
expressions OCL correspondant aux propriétés suivantes :
a) Une personne n’a pu contracter un emprunt que sur un bien qu’elle possède.
b) La date de début d’un emprunt doit précéder sa date de fin.
c) Les id des personnes doivent être uniques.
d) Un emprunt ne peut être accordé que si le salaire de la personne est au moins le triple du
total des mensualités qu’elle doit déjà payer plus la mensualité qu’elle devra payer pour ce
nouvel emprunt (précondition de la méthode emprunter).
Quelle méthode doit être ajoutée ?
Exercice 9.2. Gestion de projets

Le schéma de classes ci-après décrit la gestion de projets. Écrire les expressions OCL
correspondant aux propriétés suivantes :
a) Le chef d’un employé doit être plus âgé que lui.
148 Exercices
b) Le salaire d’un employé ne peut pas être plus élevé que celui de son chef.
c) La date d’embauche d’un employé doit être plus récente que sa date de naissance.
d) La date de début comme gestionnaire d’un département d’un employé doit être plus récente
que sa date d’embauche.
Remarque : Le nom d’une classe association (avec sa première lettre en minuscule) peut être
utilisé pour la navigation comme tout nom d’association.
e) Le gestionnaire d’un département doit être membre de ce département.
f) Un employé ne peut travailler que dans des projets hébergés par son département.
g) Un employé travaille au moins 30 heures par semaine et au plus 50 heures par semaine
dans tous ses projets.
h) Un employé ne peut pas être son propre chef.
PARTIE 3
La modélisation des besoins
DÉFINITION
Comme cela a été montré dans les chapitres qui précèdent, la modélisation métier qui initie
souvent la démarche de développement d’une application est centrée sur le domaine d’activité
considéré, en termes de processus (cas métier) et d’entités (classes du domaine).
La démarche se recentre ensuite sur les besoins de l’application qui doit être développée
au sein de ce domaine d’activité. Dans un premier temps, l’application est considérée de
l’extérieur, comme une boîte noire. Dans un second temps, la boîte noire est ouverte pour
spécifier les artefacts essentiels de l’application visibles par les utilisateurs et approuvés par
eux.
PRINCIPAUX FORMALISMES ET MODÈLES

Les premières formes d’expression sont celles qui permettent de caractériser les besoins de
l’extérieur. Les scénarios client (user stories) et les cas d’utilisation (use cases) sont les deux
formalismes les plus utilisés à ce stade.
Les cas d’utilisation sont souvent accompagnés par des modélisations complémentaires,
comme les diagrammes de séquences « système » et les diagrammes d’activités des
principaux scénarios de l’application. Ces formalismes sont détaillés dans les trois chapitres
qui suivent.
Chapitre 10
Les user stories
10.1 DÉFINITION
Le formalisme des user stories a été introduit dans la méthode XP et joue un rôle important
dans beaucoup d’approches agiles. Certains traduisent user stories par « scénarios client »,
« histoires utilisateur » ou encore « récits utilisateur ». Dans cet ouvrage, le terme anglais,
très majoritairement utilisé, est conservé. Philosophiquement, les user stories tentent de
combiner les forces de la communication écrite (édition et révision facile, persistance,
partage aisé, termes qui peuvent être soigneusement choisis) et de la communication orale
(feedback immédiat, clarification facile, compréhension plus aisée).
Une user story est une phrase formatée, écrite en langage naturel, qui vise à décrire avec clarté
un besoin, c’est-à-dire une fonctionnalité à développer, une qualité espérée ou une contrainte
à respecter par l’application. Cette phrase peut être considérée comme un élément d’une
conversation (a token for a conversation) qui pourra se tenir ultérieurement (a mechanism for
deferring conversation).
Dans son format le plus courant (matrice « rôle-fonctionnalité-bénéfice »), la phrase doit
contenir trois éléments : le <qui> (rôle), le <quoi> (fonctionnalité) et le <pourquoi>
(bénéfice).
En tant que <qui> je veux <quoi> afin de <pourquoi>
Dans certains cas le <pourquoi> peut être omis.
Exemples
– En tant qu’utilisateur je veux pouvoir rechercher un client par son prénom et nom de
famille afin de le retrouver rapidement lorsque je reçois un appel de sa part.
152 Partie 3. La modélisation des besoins
– En tant qu’utilisateur fermant l’application je veux être incité (prompted) à sauvegarder ce

qui a changé depuis la dernière sauvegarde afin de préserver tout travail utile ou d’effacer
tout travail sans intérêt.
– En tant que client de la banque je veux pouvoir retirer de l’argent à un guichet automatique
afin de ne me soucier ni des horaires d’ouverture ni de l’affluence à l’agence.
10.2 DES ÉLÉMENTS DE MÉTHODOLOGIE

10.2.1. La formule des trois C
La « formule des trois C » caractérise plus en détail les user stories [Jef01]. Les trois C font
référence à « carte », « conversation » et « confirmation ».
Une carte, souvent un Post-it, est utilisée pour donner une forme tangible et durable au
scénario utilisateur.
Des conversations peuvent prendre place à plusieurs moments du projet entre les différentes
parties prenantes (stakeholders) concernées par la story : clients, utilisateurs, développeurs,
testeurs, etc. En particulier, quand la story est estimée puis quand elle est associée à une
itération.
Une confirmation, la plus formelle possible, précise comment l’objectif exprimé par la user
story peut être atteint. Ces critères d’acceptation (de validation) sont souvent écrits au dos de
la carte.
Exemple
En tant qu’utilisateur du site de réservation je veux pouvoir annuler à moindre coût une
réservation d’hôtel afin de bénéficier d’une certaine souplesse.
Critères de validation :
– Vérifier qu’un utilisateur premium peut annuler sans frais.
– Vérifier qu’un utilisateur non premium paye 10 % du montant de la réservation en frais
d’annulation.
– Vérifier que l’hôtel est bien notifié par mail de l’annulation.
10.2.2. La grille INVEST

L’acronyme INVEST est formé des initiales de six critères qui caractérisent une bonne user
story [Wak03].
– Independent : Une bonne user story devrait être indépendante des autres. Les dépendances
rendent l’estimation, l’affectation de priorités et la planification plus difficiles. Souvent,
les dépendances peuvent être réduites par des décompositions ou des fusions de stories.
– Negotiable : Une user story est négociable. Sa formulation doit être courte et ne doit pas
inclure trop de détails. Les détails seront considérés lors des conversations évoquées dans
la formule des trois C. Une formulation initiale avec trop de détails risque de décourager
les échanges.
10 • Les user stories 153
– Valuable : Une user story doit avoir une valeur pour le client ou l’utilisateur, ce qui
implique au moins qu’elle soit parfaitement compréhensible par lui.
– Estimable : Les développeurs doivent être capables d’estimer une user story pour permettre
de lui affecter une priorité et la planifier. Elle ne doit pas être trop grosse ou trop floue.
– Small : Une bonne user story doit correspondre à un effort limité (pas plus de deux ou trois
semaines/homme). Sinon, sa définition et son estimation deviennent difficiles.
– Testable : Cela correspond au dernier C (confirmation) de la formule des trois C. On ne
développe rien que l’on ne peut pas précisément tester. Sinon, on ne peut pas savoir quand
le développement est terminé. « Le logiciel doit être facile à utiliser » est l’exemple type
de story non testable.
10.2.3. Autres conseils d’écriture

a) L’utilisation des story maps
Une autre question récurrente est celle de la granularité des stories. Une tendance naturelle
lors de l’analyse d’une situation est d’ajouter toujours plus de détails et donc de multiplier
les stories sur des aspects mineurs du problème. Il faut se souvenir qu’une user story doit
proposer une vision orientée client ou utilisateur et être source de valeur pour eux.
Une technique parfois suggérée pour rester dans cette vision utilisateur au bon niveau de
détail consiste à partir d’un scénario (un story board) éventuellement avec des personnages
(personas) et d’en déduire des stories candidates. Celles-ci sont disposées dans une story
map pour discussion (par exemple durant le sprint 0 de Scrum avec le Product Owner,
les utilisateurs et clients, l’équipe de développement). L’axe horizontal représente le
temps afin de refléter les processus métier. L’axe vertical correspond au raffinement de
grosses fonctionnalités non testables (epics) en stories classées par intérêt (business value)
décroissant.
F IGURE 10.1 Story map et user stories

b) Le raffinement des descriptions

On peut ajouter des détails soit en décomposant les stories soit en détaillant les conditions
d’acceptation. Les deux techniques sont utilisables selon les circonstances.
Exemple
En tant qu’utilisateur du site de réservation je veux pouvoir annuler à moindre coût une
réservation d’hôtel afin de bénéficier d’une certaine souplesse,
peut être raffinée en trois stories plus ciblées :
– En tant qu’utilisateur premium je veux pouvoir annuler ma réservation d’hôtel sans
supplément.
– En tant que non utilisateur premium je veux pouvoir annuler ma réservation d’hôtel en
payant 10 % du montant en frais.
– En tant qu’hôtel concerné par une annulation je veux être notifié par mail.
Ces mêmes informations peuvent prendre la forme de critères d’acceptation de la story

initiale :
– Vérifier qu’un utilisateur premium peut annuler une réservation d’hôtel sans frais.
– Vérifier qu’un utilisateur non-premium paye 10 % du montant de la réservation d’hôtel en
frais d’annulation.
– Vérifier que l’hôtel est bien notifié par mail de l’annulation.
c) La structuration des conditions d’acceptation

L’approche Behavior-Driven Development (BDD, [Nor06]) suggère d’écrire les conditions
d’acceptation selon un format standard qui prépare l’écriture, manuelle ou automatisée par
un framework spécialisé, des codes de test correspondants :
Étant donné que <condition initiale> et que je <action> alors <résultat>
Il peut y avoir plusieurs conditions initiales et plusieurs résultats combinés par des et.
Exemple
Étant donné que je suis un utilisateur premium et que je demande une annulation de
réservation d’hôtel alors je suis remboursé intégralement du montant de la réservation.
10.3 UN EXEMPLE
Il s’agit d’analyser un site web destiné à la vente de livres de recettes de cuisine.
L’approche qui a été retenue s’inspire du story mapping. Quatre rôles ont été retenus :
utilisateur novice, utilisateur expert, acheteur de cadeau et administrateur. Ils ont guidé
la définition d’une collection de stories qui couvre bien les différents types d’utilisation
envisagés. Leur recherche s’est faite en considérant les processus d’interaction des différents
types de client.
Des user stories générales

Les premières stories sont assez générales et concernent tous les types de client engagés dans
un processus d’achat.
La première story porte sur la fonctionnalité initiale de recherche d’un livre :
– En tant qu’utilisateur je veux pouvoir rechercher un livre par son titre, son auteur ou son
numéro ISBN afin d’augmenter les chances de trouver ce que je cherche.
La seconde story indique la nécessité d’accéder à une description détaillée de l’ouvrage ainsi
trouvé :
– En tant qu’utilisateur je veux pouvoir lire une description détaillée des livres que j’ai
trouvé (par exemple, description, nombre de pages, date de publication, etc.) afin de
conforter mon choix.
Les deux stories suivantes portent sur la gestion du panier d’achat du site :
– En tant qu’utilisateur je veux pouvoir ajouter un livre dans mon panier d’achat afin de
préparer ma commande.
– En tant qu’utilisateur je veux pouvoir retirer un livre de mon panier d’achat afin de
permettre une sélection avant achat.
La story suivante caractérise l’acte d’achat proprement dit :

– En tant qu’utilisateur je veux pouvoir acheter le contenu de mon panier d’achat afin de
finaliser ma visite sur le site.
Des user stories spécifiques aux rôles

Pour les acheteurs novices des stories spécifiques sont proposées, comme :
– En tant qu’utilisateur novice je veux pouvoir accéder à des conseils par catégories de
livres de recettes afin de faciliter mon choix.
De même, pour les utilisateurs experts :

– En tant qu’utilisateur expert je veux pouvoir noter et commenter les livres de recettes afin
de partager mon expertise.
De même, pour les acheteurs de cadeaux :

– En tant qu’acheteur de cadeau je veux pouvoir accéder à la liste de souhaits (wish list)
d’une autre personne afin de choisir un cadeau qui lui plaise,
qui fait écho à la story générale :

– En tant qu’utilisateur je veux pouvoir déposer une liste de souhaits afin d’aider mes amis
à choisir des livres qui m’intéressent.
Pour l’administrateur du site, on trouve la série de stories suivante :

– En tant qu’administrateur je veux pouvoir ajouter un livre.
– En tant qu’administrateur je veux pouvoir supprimer un livre.

– En tant qu’administrateur je veux pouvoir modifier un livre.
On retrouve dans ce dernier cas un découpage selon les opérations CRUD (Create-Read-
Update-Delete), classiques dans le domaine des bases de données.
On trouve aussi des stories pour l’administrateur en liaison avec les utilisateurs :
– En tant qu’administrateur je veux pouvoir approuver ou rejeter les commentaires des
utilisateurs avant publication afin d’éviter les dérives.
Des contraintes
Enfin, certaines stories expriment des exigences qualitatives (d’efficacité, de sécurité, de
sûreté, etc.), comme :
– En tant qu’acheteur expérimenté je veux pouvoir trouver et commander un livre en moins
de 90 secondes afin de répondre à ce type de commande urgente.
– En tant qu’administrateur je veux pouvoir offrir un système qui accepte jusqu’à 50
connexions simultanées afin de pouvoir répondre aux pics de charge.
EXERCICES
Exercice 10.1. Qualité des user stories

Quelles stories ne sont pas satisfaisantes et pourquoi ?
a) En tant qu’utilisateur je veux pouvoir maîtriser rapidement l’application.
b) En tant qu’utilisateur je veux pouvoir éditer mon adresse sur mon CV.
c) En tant qu’administrateur je veux pouvoir accéder au log de toutes les erreurs à l’exécution
afin de pouvoir déboguer l’application.
d) En tant qu’utilisateur je veux pouvoir annuler jusqu’à 50 actions.
e) En tant que développeur je veux utiliser Log4J pour gérer les logs.
f) En tant qu’utilisateur je veux pouvoir exporter mes données en XML.
Exercice 10.2. Techniques de décomposition des user stories

a) En tant que client je veux pouvoir acheter des produits dans mon panier afin de les recevoir
chez moi.
Décomposer cette story selon les étapes successives du processus d’achat.
b) En tant que client je veux pouvoir me loguer avec mon compte afin de pouvoir accéder à
des pages sécurisées.
Décomposer cette story en considérant les cas exceptionnels qui peuvent se produire.
c) En tant que gérant de boutique en ligne je veux pouvoir gérer les produits de mon catalogue
afin de pouvoir mettre à jour les prix et les descriptions.
Décomposer cette story selon les opérations CRUD (Create-Read-Update-Delete).
Exercice 10.3. Behavior-Driven Development (BDD)

Soit la story :
En tant que client de la banque je veux pouvoir transférer de l’argent entre mes comptes
(courant et épargne) afin de gérer au mieux mon argent.
Écrire un certain nombre de tests d’acceptation en respectant le format prôné par l’approche
BDD :
Étant donné que <conditions initiales> et que je <action> alors <résultat>.
Exercice 10.4. Epics et stories

On rappelle qu’une epic est un besoin général qui doit être décomposé en plusieurs stories
plus précises, qui soient en particulier testables.
Soit l’epic suivante :
L’application doit permettre à un demandeur d’emploi de bénéficier d’agents automatiques
qui recherchent les offres d’emploi.
Esquisser sa décomposition.
Chapitre 11
Les cas d’utilisation
11.1 DÉFINITION
Les cas d’utilisation (use cases) ont été formalisés par Ivar Jacobson [Jac+92], par la suite
contributeur important du langage UML et du processus unifié, dont ils constituent un des
éléments essentiels.
Un cas d’utilisation décrit une interaction avec l’application par un utilisateur dans
une certaine intention. Autrement dit, un service de bout en bout ou une fonctionnalité
significative vu de l’extérieur.
L’ensemble des cas, récapitulés dans le diagramme des cas UML, permet la délimitation de
l’application à travers l’ensemble des services qu’elle offre et la visualisation de ses relations
avec son environnement constitué d’acteurs.
Un acteur est une personne ou un système qui interagit directement avec l’application en
échangeant de l’information. Par exemple les utilisateurs finaux de l’application, bénéficiaires
directs des services qu’elle offre, ou les responsables de son fonctionnement, comme ses
administrateurs. Plus précisément, un acteur représente un rôle. La même personne physique
peut jouer le rôle de plusieurs acteurs et plusieurs personnes physiques peuvent jouer le même
rôle et donc agir comme un même acteur.
Dans le chapitre sur la modélisation des processus métier, on a déjà rencontré la notion de
« cas », sous la dénomination de « cas métier ». Certains cas d’utilisation correspondent à des
cas métier que l’application implante. Les acteurs et les intervenants métier des cas métier
implantés deviennent les acteurs de ces cas d’utilisation. La modélisation des processus
métier peut donc aider à la détermination des cas d’utilisation des applications qui opèrent au
sein du métier considéré.
11.2 LA DESCRIPTION TEXTUELLE DU CAS

Un cas d’utilisation est décrit par un texte en langue naturelle, structuré en plusieurs sections.
UML n’impose aucune structuration ni format type. Un cas d’utilisation peut se décrire à
différents niveaux de détail au fil de l’analyse. La forme abrégée est réduite au scénario
principal d’interaction, résumé en une phrase ou un court paragraphe. La forme intermédiaire
résume en plus les différents scenarios alternatifs. La forme détaillée, produite juste avant la
conception, comprend classiquement les sections suivantes :
– nom (de préférence un verbe ou groupe verbal à l’infinitif),
– date, auteur, numéro de version,
– description résumée (objectif du cas),
– acteur principal et acteurs secondaires,
– conditions au démarrage (préconditions),
– conditions à la terminaison (postconditions),
– étapes du déroulement normal (« scénario nominal »),
– autres déroulements possibles et cas d’erreurs,
– contraintes non fonctionnelles : performance, sécurité, disponibilité, confidentialité, etc.
– autres cas liés.
– autres remarques.
Exemple
Nom : Prendre un rendez-vous

Description : Prise automatique de rendez-vous auprès d’un cabinet médical.
Acteur principal : Patient
Acteurs secondaires : Secrétariat du cabinet
Préconditions : L’application est en fonctionnement.
Postconditions : Un rendez-vous est enregistré ou la demande est transmise au secrétariat
ou abandonnée.
1. le patient s’identifie (nom, prénom, adresse) et sélectionne le nom du médecin voulu,
2. l’application vérifie que le patient est enregistré dans la base des clients et qu’il s’agit
de son médecin traitant,
3. l’application demande la plage horaire souhaitée (jour et heure),
4. l’application recherche un ou des créneaux de 20 minutes dans la plage ou à défaut
juste avant ou après la plage demandée, selon le planning du médecin traitant,
5. l’application demande l’accord du patient pour un des créneaux proposés,
6. en cas d’accord, le rendez-vous du patient avec le médecin traitant est enregistré.
11 • Les cas d’utilisation 161
Variantes :
1. Patient inconnu : la demande est transmise au secrétariat avec un numéro de téléphone
pour la réponse.
2. Médecin incorrect : avec l’accord du patient l’application retient le nom du médecin
traitant du patient conservé dans la base des clients. Si le patient n’est pas d’accord, la
demande est transmise au secrétariat.
3. Refus du ou des créneaux proposés : si c’est possible, l’application propose un médecin
de remplacement dans la plage horaire demandée.
4. Refus du remplacement : la demande est transmise au secrétariat.
Contraintes non fonctionnelles :
1. Performance : la recherche dans la base des clients doit démarrer dès la saisie du nom.
2. Sécurité : l’accès au formulaire doit être protégé contre les robots (CAPTCHA).
3. . . .
11.3 LE DIAGRAMME DE CAS D’UTILISATION

Ce diagramme UML décrit les interactions entre les acteurs et l’application représentée
comme un ensemble de cas. En général les interactions ne sont pas orientées (une flèche
pouvant avoir de multiples interprétations). Elles peuvent porter un stéréotype indiquant si
l’acteur est le destinataire principal du service (<<principal>> ou <<primary>>) ou un
contributeur secondaire (<<secondaire>> ou <<secondary>>).
F IGURE 11.1 Les éléments de base d’un diagramme de cas d’utilisation

À noter que le diagramme de cas réduit à un seul cas qui correspond à l’application toute
entière est souvent appelé « diagramme de contexte ». Il explicite simplement l’ensemble des
acteurs en lien avec l’application, c’est-à-dire les éléments notables de son contexte.
F IGURE 11.2 Un diagramme de contexte
Dans un diagramme de cas, les cas peuvent éventuellement être liés par des relations
stéréotypées :
– La relation d’inclusion, notée A <<include>> B (ou A <<inclut>> B), signifie que
le cas A inclut obligatoirement le cas B. Cela permet de décomposer les cas et de factoriser
les parties communes entre cas.
– La relation d’extension, notée A <<extend>> B (ou A <<étend>> B), signifie que
le cas A est une extension optionnelle du cas B à un certain point de son exécution.
Exemple
F IGURE 11.3 Un exemple de relations d’inclusion et d’extension entre cas

Remarque : <<xxx>> dénote un stéréotype UML, c’est-à-dire une annotation permettant

de caractériser et classer des éléments de modèles UML. Certains, comme <<include>> et
<<extend>> sont prédéfinis, d’autres peuvent être définis par les utilisateurs d’UML.
On peut également avoir de l’héritage entre acteurs et entre cas (relation de généralisation/
spécialisation) :
– Un acteur A2 qui hérite d’un acteur A1 peut faire tout ce que fait A1 plus ses interactions
propres. Cela simplifie seulement le dessin, puisqu’il n’est plus nécessaire de répéter
certaines interactions.
– Un cas C2 qui hérite d’un cas C1 représente une manière spécifique de réaliser l’interaction
définie par C1. On peut substituer C2 à C1 dans un cas précis.
Exemple
F IGURE 11.4 Des exemples de relations de généralisation/spécialisation

Une des principales difficultés avec les cas d’utilisation est de se positionner « au bon niveau »
d’abstraction et de granularité. La définition qui précise qu’un cas représente un tout cohérent
associé à une intention de l’acteur principal laisse en effet une grande marge d’appréciation.
Une première erreur fréquente consiste à abuser de la décomposition, concrétisée par la
relation <<include>> du diagramme des cas. L’approche ne prône pas du tout l’idée de
décomposition fonctionnelle hiérarchique avec des grosses fonctions décomposées en plus
petites, jusqu’à des actions élémentaires.
Il n’y a par ailleurs aucune idée de temporalité dans le modèle : les « sous-cas » ne doivent
pas servir à modéliser des processus. D’autres diagrammes UML sont prévus pour cela.
Une troisième erreur fréquente consiste à se polariser sur le diagramme des cas et ses
relations assez subtiles. « Une caractéristique habituelle d’un modélisateur novice (ou
scolaire) est sa focalisation sur les diagrammes de cas et ses relations, plutôt que d’écrire du
texte. (. . . ) Les diagrammes et leurs relations sont des aspects secondaires du travail. Les
cas d’utilisation sont des documents textuels. Le travail avec les cas d’utilisation consiste à
écrire du texte » [Lar95]. Un diagramme de cas qui récapitule simplement la liste des cas
inclus dans l’application avec les acteurs concernés par chaque cas suffit le plus souvent.
Il ne faut pas non plus confondre cas d’utilisation et scénario. Un cas d’utilisation est plutôt
une classe de scénarios. Chaque scénario est un chemin particulier, une instance de la
description abstraite et générale fournie par le cas d’utilisation. Les scénarios correspondent
aux jeux de test fonctionnels de l’application (tests d’acceptation).
Exemple
Un scénario associé au cas de prise de rendez-vous.
1. Pierre saisit ses coordonnées et demande un rendez-vous avec le Docteur Jules.
2. L’application trouve Pierre dans la base.
3. Pierre propose la plage 10h-11h du lendemain.
4. L’application propose les créneaux de 9h20 et de 12h00.
5. Pierre accepte le créneau de 12h00.
6. L’application enregistre le rendez-vous dans le planning du Docteur Jules.
Enfin, il est important que les cas d’utilisation soient compréhensibles par tous. D’après
(R)UP, les cas d’utilisation sont le fil conducteur du projet et sont utilisés aussi bien par
les analystes, les architectes, les gestionnaires, les utilisateurs, les clients, les développeurs et
les testeurs. De multiples conseils ont été formulés pour leur écriture.
Exemples
– Rester concis et pertinent. Éviter les longs documents.
– Pour chaque étape du cas, le sujet doit être clairement localisable, en début de phrase
généralement : « le client fait ceci . . . », « l’application fait cela . . . ».
– Pour chaque étape du cas, éviter les si et placer les comportements alternatifs dans la
section des variantes.
11.5 USER STORIES VS CAS D’UTILISATION

User stories et cas d’utilisation sont deux approches en concurrence pour le recueil des
besoins utilisateurs, promues respectivement par les méthodes agiles et par (R)UP. Le tableau
de la page suivante (inspiré de [Gro09]) explicite quelques différences notables entre ces deux
approches.
Certains considèrent la story comme un préalable au cas d’utilisation. Alors que le cas
d’utilisation raconte en détail un processus complexe d’interaction, chaque story prépare le
terrain en explicitant un des besoins fonctionnels auquel répond le cas d’utilisation.
On peut noter au passage qu’une story ne raconte pas vraiment une « histoire », contrairement
au cas d’utilisation ! Le terme user story n’est pas a priori très heureux.
User Story Use Case

Format écrit très synthétique. Format écrit très détaillé.
Ouvert aux discussions orales. Volonté d’exhaustivité.
Outil de spécification mais aussi Outil de spécification uniquement.
d’estimation et de planification.
Émergence lors de séances de travail Long travail d’analyse et de formalisation.
collectives.
Pas de vision globale. Vision globale par les diagrammes de cas.
Client ou utilisateur impliqué dans la Travail d’un analyste reflétant les indications
rédaction. données par les clients et utilisateurs.
Implanté et testé en une seule itération. Pas de contrainte d’implantation.
Contient systématiquement des tests Peut éventuellement donner lieu à
d’acceptation (au dos de la carte). des scénarios (jeux de tests fonctionnels).
11.6 UN EXEMPLE
Il s’agit du module d’administration d’une application intranet d’entreprise avec des
fonctionnalités de gestion des utilisateurs, des groupes et des modules. Le diagramme de cas
de la figure 11.5 explicite les cas du sous-système de gestion des utilisateurs.
F IGURE 11.5 Diagramme de cas du module d’administration

La spécification du cas Ajouter compte utilisateur est la suivante :
Nom : Ajouter compte utilisateur

Description : Ajout d’un nouveau compte utilisateur à l’application intranet.
Remarques :
– Il n’y a pas de limite au nombre de comptes utilisateur enregistrés dans l’application.
– Seul l’administrateur peut ajouter un nouveau compte utilisateur.
Acteur principal : Administrateur
Préconditions :
– L’administrateur est connecté dans l’application.
– La sécurité peut ou non être activée.
Postconditions :
– Un nouveau compte utilisateur est créé avec au minimum un login, un mot de passe, un
nom et un groupe d’affectation.
1. L’administrateur choisit l’option d’ajout d’un nouveau compte utilisateur.
2. Le système demande à l’administrateur les informations suivantes : login, mot de passe
initial (deux fois), groupe de rattachement, nom de famille, prénom (facultatif).
L’administrateur saisit ces informations et soumet le formulaire.
3. L’application crée le nouveau compte utilisateur.
Variantes :
1. Si un des champs obligatoire n’est pas rempli, l’administrateur est notifié. Le focus est
placé sur le premier champ manquant.
2. Si le login est déjà utilisé, le système réclame un autre nom.
3. Si le login est invalide, l’administrateur est notifié et les critères de validité sont
affichés.
4. Si le mot de passe est invalide, l’administrateur est notifié et les critères de validité
sont affichés.
Autres cas liés :
– Lister les utilisateurs.
– Lister les groupes.
Autres remarques :
– Le login et le mot de passe sont sensibles à la casse (majuscules/minuscules).
EXERCICES
Exercice 11.1. Application web Cyber-cartes

Cette application doit permettre :
– à un internaute de s’inscrire pour créer un compte ; il choisit alors un login et un mot
de passe ; il devient, après validation du compte par l’administrateur, un client de Cyber-
cartes ;
– à un administrateur de se connecter ; après quoi il peut valider un ou plusieurs comptes
correspondant chacun à une demande d’un internaute et se déconnecter ;
– à un client de se connecter à l’application ; après quoi il peut :
• créer une (ou plusieurs) carte(s) électronique(s) avec obligatoirement un texte
personnalisé et dans la ou lesquelles il peut en plus :
* ajouter une ou plusieurs images animées,
* ajouter une mélodie,
• expédier une ou plusieurs cartes par mail à un destinataire dont il fournit l’adresse mail,
• se déconnecter.
a) Décrire brièvement chaque cas.

b) Construire le diagramme de cas en utilisant ses possibilités de structuration des cas.
Exercice 11.2. Application documentaire

Une société met à la disposition de son personnel une base documentaire où sont stockés tous
les documents utiles à la conduite de projets.
Tout le personnel de l’entreprise peut consulter l’application, soit pour une recherche soit pour
accéder en lecture et optionnellement imprimer un document particulier. Toute consultation
doit être précédée par une authentification (identification) légère dans laquelle la personne
précise son nom et son service à des fins statistiques (pas de vérification).
Les maîtres d’œuvre des projets peuvent effectuer différentes opérations de mise à jour
pour les documents dont ils sont propriétaires : ajout, retrait et modification. Ces opérations
doivent être précédées d’une authentification plus approfondie où l’ingénieur précise son
nom, son service et introduit un mot de passe qui est vérifié en contactant l’annuaire LDAP
de l’entreprise. Toutes les opérations (consultations et mises à jour) donnent lieu à un
enregistrement dans un journal des accès.
a) Lister les acteurs et les cas.
b) Construire le diagramme de cas en utilisant ses possibilités de structuration des cas.
Exercice 11.3. Authentification

Un site de commerce électronique permet aux internautes de s’enregistrer comme client. Leur
enregistrement doit être validé en cliquant un lien sur un mail qu’ils reçoivent.
168 Exercices
Un client enregistré peut se loguer. Il peut aussi faire appel à une fonctionnalité de
changement de son mot de passe s’il l’a oublié.
Donner le diagramme de cas d’utilisation avec les cas Se loguer, S’enregistrer,
Confirmer son enregistrement, J’ai oublié mon mot de passe.
Exploiter les relations entre cas.
Remarque : On serait tout à fait en droit de se demander si ces (micro-)fonctionnalités
doivent vraiment être représentées comme des cas d’utilisation.
Chapitre 12
Les autres modèles UML
12.1 LES DIAGRAMMES DE SÉQUENCES « SYSTÈME »

Le diagramme de séquences « système » (DSS) est un diagramme de séquences UML dans
lequel l’application (le système) apparaît comme une entité unique, une boîte noire, qui reçoit
des messages en provenance de certains acteurs et en émet vers d’autres (cf. figure 12.1).
Un tel diagramme peut être ébauché très tôt afin d’aider à découvrir les principaux cas
d’utilisation. En effet, les cas d’utilisation sont le plus souvent démarrés par un événement
externe initial (une saisie, une décision, une interruption, etc.) qui est modélisé par l’arrivée
d’un certain message depuis un acteur. Symétriquement, les cas sont terminés par un ou
plusieurs événements externes finaux qui sont modélisés par la production de messages
vers des acteurs. Déterminer les cas d’utilisation revient donc à rechercher les groupes de
messages logiquement liés. Une partie du « vocabulaire de l’application », à travers les noms
de message et les éventuels noms de paramètres (qui pourront devenir des noms de méthodes
et d’attributs des futures classes de l’application), est ainsi capturé.
Le plus souvent toutefois, ce type de diagramme sert à documenter a posteriori les cas
d’utilisation en explicitant la chronologie de tous les événements externes (messages) de
ces cas. Même si les parties optionnelles, les alternatives et les répétitions peuvent être
représentées dans les diagrammes de séquences sous forme de boîtes imbriquables, il est
conseillé de ne pas trop charger leur représentation et de se limiter donc à un processus
unique, nominal ou variante, par diagramme.
Exemple
Diagramme de séquences « système » du scénario nominal de la prise automatique de rendez-
vous auprès d’un cabinet médical.
F IGURE 12.1 Un exemple de diagramme de séquences « système »
12.2 LES DIAGRAMMES D’ACTIVITÉS DES CAS

Un diagramme d’activités UML peut être utile pour les cas d’utilisation complexes. Il
permet de spécifier clairement la dimension temporelle du processus nominal ainsi que
la structuration des cas alternatifs au cas nominal quand ces derniers sont nombreux et
compliqués, ce que ne permet pas aisément le diagramme de séquences « système ».
Exemple
L’articulation de l’ensemble des scénarios, nominal et variantes, de la prise de rendez-vous
est décrite par la figure 12.2, page suivante.
12 • Les autres modèles UML 171
F IGURE 12.2 Diagramme d’activités d’un cas d’utilisation

172 Exercices
EXERCICES
Exercice 12.1. DSS du jeu du démineur

Le champ de mines est représenté par une grille de forme quelconque. Chaque case de la
grille peut cacher une mine ou être vide. Le but du jeu est de découvrir toutes les cases vides
en cliquant dessus, sans cliquer sur une case qui cache une mine ce qui la fait exploser et fait
perdre le joueur.
Quand le joueur clique sur une case vide comportant au moins une mine dans l’une de ses
cases avoisinantes, un chiffre apparaît qui indique ce nombre de mines. Sinon, quand toutes
les cases adjacentes sont vides, une case vide est affichée. La même opération est répétée
sur les cases vides jusqu’à ce que la zone vide soit entièrement entourée par des chiffres. En
s’aidant de ces informations le joueur peut progresser dans le déminage du terrain.
S’il le souhaite, le joueur peut signaler les cases qu’il pense contenir des mines par un drapeau
en cliquant sur le bouton droit de la souris.
Donner un diagramme de séquences « système » du jeu du démineur. Il est indispensable
ici d’utiliser les boîtes imbriquables loop, alt et opt pour indiquer respectivement des
répétitions, des choix ou des parties optionnelles.
Exercice 12.2. DSS d’une commande web

Soit le cas d’utilisation suivant :
Nom : Effectuer une commande

Description : À tout moment, le client peut accéder à la page de commande dans lequel
il peut saisir les informations nécessaires à la livraison et au paiement.
Acteur principal : Client
12 • Les autres modèles UML 173
Préconditions :
– le panier du client n’est pas vide,
– le client est authentifié.
Postconditions :
– une commande est enregistrée et transmise au service Commandes,
– une transaction cryptée a été passée avec le système externe de paiement sécurisé et
sauvegardée.
1. Le client saisit l’ensemble des informations nécessaires à la livraison, (adresse de
facturation et adresse de livraison si elle est différente de l’adresse de facturation).
2. L’application affiche un récapitulatif des adresses et du panier.
3. Le client valide sa commande.
4. Le client sélectionne le paiement par carte bancaire.
5. Le client fournit son numéro de carte de crédit, sa date de validité et son numéro de
contrôle.
6. L’application envoie les informations cryptées au système externe de paiement
sécurisé.
7. Le système de paiement sécurisé autorise la transaction.
8. L’application confirme la prise de commande au client.
9. L’application envoie la commande validée au Service commercial.
10. L’application enregistre la commande.
Variantes :
3.1. 1 Le client annule sa commande.
3.2. L’application revient sur l’affichage du panier et le cas d’utilisation se termine en
échec.
4.1. Le client choisit un paiement différé (chèque, virement, etc.).
4.2. L’application confirme la commande au client et lui rappelle la démarche à suivre
pour la terminer.
4.3. L’application enregistre la commande dans l’état « en attente de règlement ».
6.1. L’application détecte que les informations sur la carte sont incomplètes ou erronées.
6.2. L’application demande au client de modifier ou compléter les informations sur la
carte.
6.3. Retour à l’étape 5 du déroulement normal.
7.1. Le système de paiement sécurisé n’autorise pas la transaction ou ne répond pas.
7.2. L’application indique au client que le paiement par carte bancaire a échoué.
7.3. Retour à l’étape 4 du déroulement normal.
1. Le premier chiffre fait référence à celui du déroulement normal.

174 Exercices
Contraintes :
– L’envoi des données est crypté (protocole SSL).
– Sont acceptées les seules cartes Visa, Eurocard-Mastercard et American Express.
Donner le diagramme de séquences système du déroulement normal de ce cas.
Exercice 12.3. Diagramme d’activités d’une commande web

Reprendre le cas de l’exercice précédent et donner le diagramme d’activités qui spécifie
l’ensemble des déroulements possibles.
PARTIE 4
La modélisation de l’application
DÉFINITION
Après avoir analysé l’application du point de vue externe, comme une boîte noire, il est
temps de commencer à « ouvrir la boîte », sans toutefois empiéter trop sur la conception de la
solution. On se limite donc aux principaux « artefacts » qui ont un intérêt pour les utilisateurs
de l’application et qui doivent être compris et approuvés par eux. C’est le cas en particulier
des principaux composants de l’interface homme–machine (IHM) et des principales entités
logicielles qui sont manipulées par l’application.
LES PRINCIPAUX MODÈLES

Le modèle des classes d’analyse
Le modèle des classes d’analyse, ou modèle des classes participantes, est élaboré à partir des
cas d’utilisation, du modèle des classes du domaine et de la maquette de l’interface utilisateur.
Il esquisse une description interne qui « concrétise » la vision externe dans le langage des
clients véhiculée par les cas d’utilisation, sous une forme qui en facilite la compréhension par
les développeurs. Il explicite une vision de l’application en termes de classes stéréotypées,
dialogues, contrôleurs et entités logicielles, plus éventuellement un regroupement en paquets
(packages), qui ébauche l’architecture de l’application.
Ce découpage en classes de dialogue, classes contrôleur et classes entités dérive directement
du modèle de conception MVC (Modèle-Vue-Contrôleur). Il convient pour une large
majorité d’applications, en particulier les applications web et les applications « classiques »
de gestion, interactives et exploitant des bases de données. C’est cette quasi-universalité qui
justifie de mettre en œuvre ce découpage dès la phase d’analyse. À noter cependant que cette
176 Partie 4. La modélisation de l’application
approche convient mal pour quelques types particuliers d’application, comme celles relevant
par exemple du modèle de conception « tubes et filtres », tels les compilateurs. Pour plus de
détails, le lecteur pourra se référer au volume compagnon sur la conception des applications
[Lon14].
Le modèle de navigation
Le modèle de navigation représente de manière formelle, à l’aide des diagrammes UML
qui permettent de modéliser les aspects dynamiques (transitions d’états ou flots d’activités),
l’ensemble des cheminements possibles entre les principaux composants (écrans, panneaux,
menus, etc.) proposés aux utilisateurs par l’interface utilisateur de l’application. En général,
cette modélisation fait suite à l’élaboration d’une maquette de l’interface homme-machine.
Chapitre 13
Le modèle des classes d’analyse
13.1 DÉFINITION
Le modèle des classes d’analyse distingue trois types de classes : les classes de dialogue (ou
classes « frontière »), les classes de contrôle et les classes entité.
13.1.1. Les classes de dialogue

Ce sont les classes qui permettent aux acteurs d’interagir avec l’application. On parle aussi
de « vues » dans le cadre de l’architecture Modèle-Vue-Contrôleur (MVC).
Ce sont en général des abstractions des fenêtres de l’application et de leurs principaux
composants (panneaux, menus, etc.), directement issues de l’analyse de la maquette de
l’interface utilisateur. Mais elles peuvent aussi correspondre à d’autres formes d’interfaces
de communication, moins fréquentes, comme des API (Application Programming Interface
ou interface de programmation), des interfaces de transfert de données, etc.
F IGURE 13.1 Le stéréotype des classes de dialogue

13.1.2. Les classes entité

Elles correspondent aux classes métier, qui proviennent en général du modèle du domaine.
On parle aussi de « modèles » dans le cadre de l’architecture Modèle-Vue-Contrôleur (MVC).
Ces classes sont généralement persistantes, c’est-à-dire que leurs objets survivent à
l’exécution d’un cas d’utilisation particulier et que ces objets sont porteurs d’informations
stockées dans des fichiers ou des bases de données.
F IGURE 13.2 Le stéréotype des classes entité
13.1.3. Les classes de contrôle

Ce sont les classes qui modélisent les traitements effectués par l’application. Elles font la
jonction entre les classes de dialogue et les classes entité, en permettant aux différentes vues
de l’application de manipuler les informations détenues par une ou plusieurs classes entité.
On parle aussi de « contrôleurs » dans le cadre de l’architecture Modèle-Vue-Contrôleur
(MVC).
Ces classes contiennent les règles applicatives (règles métier) et les isolent à la fois des classes
de dialogue et des classes entité.
F IGURE 13.3 Le stéréotype des classes de contrôle

Le travail d’analyse se fait le plus souvent cas d’utilisation par cas d’utilisation. Une vision
globale peut ensuite être élaborée en termes de paquets (packages) d’analyse regroupant des
ensembles de classes, ce qui esquisse une première architecture de l’application.
13.2.1. Détermination des classes entité

Les classes entité correspondent aux classes métier. Elles apparaissent couramment dans la
concrétisation de plusieurs cas d’utilisation. Elles sont caractérisées essentiellement par leurs
attributs. Elles peuvent être associées à d’autres classes entité et peuvent être accédées par
des classes de contrôle, via des méthodes d’accès.
13 • Le modèle des classes d’analyse 179
13.2.2. Détermination des classes de contrôle

Le plus souvent une classe de contrôle est associée à un et un seul cas d’utilisation. Par
contre, il est assez fréquent d’associer à un cas d’utilisation complexe plusieurs classes de
contrôle. Les objets instances des classes de contrôle ont une durée de vie limitée à celle
du cas d’utilisation auquel ils sont liés. Les classes de contrôle sont définies essentiellement
par leurs opérations (méthodes). Elles peuvent être associées à tous les types de classes :
des classes de dialogue, d’autres classes de contrôle et des classes entités auxquelles elles
accèdent.
13.2.3. Détermination des classes de dialogue

Le plus souvent, on définit une classe de dialogue pour chaque association entre un acteur
et un cas d’utilisation. Les acteurs associés aux dialogues peuvent figurer dans le modèle
des classes d’analyse. Les classes de dialogue comportent des attributs et des opérations.
Les attributs représentent des informations saisies par les utilisateurs ou des résultats à
destination des utilisateurs (on peut les représenter comme des attributs calculés selon la
notation UML /nom_attribut). Les opérations réalisent, en général par délégation aux
classes de contrôle, les actions que l’utilisateur demande par l’intermédiaire de l’interface
utilisateur. Les classes de dialogue peuvent être associées à des classes de contrôle et à
d’autres classes de dialogue, mais pas directement à des classes entité.
La figure 13.4 de la page suivante résume la structure caractéristique d’un modèle des classes
d’analyse.
13.3 UN EXEMPLE
On reprend le cas d’utilisation de l’ajout d’un compte utilisateur par l’administrateur d’une
application.
Nom : Ajouter compte utilisateur

Description : Ajout d’un nouveau compte utilisateur à l’application intranet.
Remarques :
– Il n’y a pas de limite au nombre de comptes utilisateur enregistrés dans l’application.
– Seul l’administrateur peut ajouter un nouveau compte utilisateur.
Préconditions :
– L’administrateur est connecté dans l’application.
– La sécurité peut ou non être activée.
Postconditions :
– Un nouveau compte utilisateur est créé avec au minimum un login, un mot de passe, un
nom et un groupe d’affectation.
1. L’administrateur choisit l’option d’ajout d’un nouveau compte utilisateur.
Partie 4. La modélisation de l’application
F IGURE 13.4 La structure caractéristique d’un modèle des classes d’analyse

180
13 • Le modèle des classes d’analyse 181
2. Le système demande à l’administrateur les informations suivantes : login, mot de passe

initial (deux fois), groupe de rattachement, nom de famille, prénom (facultatif).
L’administrateur saisit ces informations et soumet le formulaire.
3. L’application crée le nouveau compte utilisateur.
Variantes :
1. Si un des champs obligatoire n’est pas rempli, l’administrateur est notifié. Le focus est
placé sur le premier champ manquant.
2. Si le login est déjà utilisé, le système réclame un autre nom.
3. Si le login est invalide, l’administrateur est notifié et les critères de validité sont
affichés.
4. Si le mot de passe est invalide, l’administrateur est notifié et les critères de validité
sont affichés.
Autres cas liés :
– Lister les utilisateurs.
– Lister les groupes.
Autres remarques :
– Le login et le mot de passe sont sensibles à la casse (majuscules/minuscules).
Dans ce cas très simple, il y a un seul écran de saisie (EcranAjoutCompte) et un

seul contrôleur (AjouterCompte) qui accède aux entités métier Compte et Groupe.
Toutefois, en présence d’erreur(s), l’application affiche un dialogue supplémentaire pour
demander des corrections (EcranNotifErreurs). La figure 13.5 décrit ce modèle
d’analyse.
F IGURE 13.5 Le modèle des classes d’analyse de l’ajout de compte utilisateur

182 Exercices
EXERCICES
Exercice 13.1. Modèle des classes d’analyse d’une commande web

Donner le modèle des classes d’analyse du cas Effectuer une commande de l’exercice
12.2. Dans cette première ébauche on se limitera à l’analyse du déroulement normal du cas.
Exercice 13.2. Suite de l’exercice précédent

Lister les modifications à apporter au modèle des classes d’analyse pour prendre en compte
les variantes du déroulement normal du cas.
Exercice 13.3. Recherche d’ouvrages

Expliquer les différents composants du modèle des classes d’analyse ci-dessous.
Chapitre 14
Les modèles UML complémentaires
14.1 LES DIAGRAMMES DE SÉQUENCES

On peut construire un diagramme de séquences à partir du diagramme des classes d’analyse
de chaque cas pour expliciter la dynamique des échanges entre dialogues, contrôleurs et
entités et s’assurer de la cohérence et complétude de l’analyse.
La réflexion doit rester centrée sur les artefacts ayant une réelle importance pour les
utilisateurs : principales classes de dialogue et principales entités métier. Les contrôleurs sont
seulement esquissés, avec le plus souvent un contrôleur par cas. Ils pourront être reconsidérés
lors de la phase de conception.
Exemple
La figure 14.1 donne le diagramme de séquences de l’ajout de compte utilisateur associé au
modèle des classes d’analyse de la figure 13.5.
14.2 LES DIAGRAMMES D’ÉTATS

Les entités dotées de comportements complexes, souvent partagées entre plusieurs cas,
peuvent être analysées de manière plus approfondie grâce à des diagrammes d’états.
Un diagramme d’états décrit comment un objet réagit à des événements en fonction de son
état courant et vers quel état suivant il évolue. On peut parler de comportement complexe
quand :
– l’objet réagit différemment à un même événement selon son état courant,
– une certaine chronologie des événements est imposée.
F IGURE 14.1 Le modèle de séquences associé à l’ajout de compte utilisateur
Exemple
On suppose qu’un compte client peut non seulement être créé et supprimé mais aussi être
désactivé puis réactivé, soit par une intervention de l’administrateur, soit au bout d’un délai
d’inactivation prévu lors de la désactivation. À sa création le compte est activé. Il peut être
supprimé à tout instant.
Le diagramme d’états correspondant est donné par la figure 14.2. On rappelle qu’un
événement en UML peut comprendre des paramètres, une condition (garde) et un effet (autre
que le changement d’état, comme un affichage par exemple) :
événement(paramètres) [condition] / effet
F IGURE 14.2 Le modèle d’états associé au compte utilisateur

14 • Les modèles UML complémentaires 185
EXERCICES
Exercice 14.1. Diagramme de séquences de la recherche de livres

Dessiner le diagramme de séquences associé au diagramme des classes d’analyse de
l’exercice 13.3 dans le cas de la recherche rapide.
Exercice 14.2. Diagramme d’états du panier d’achat d’un site de commerce électronique
Dessiner le diagramme d’états du panier d’achat d’un site de commerce électronique. On peut
ajouter ou supprimer des articles, incrémenter ou décrémenter les quantités des articles, vider
le panier et passer commande de tout ce qui se trouve dans le panier.
Exercice 14.3. Diagramme de séquences d’une commande web

Dessiner le diagramme de séquences associé au diagramme des classes d’analyse de
l’exercice 13.1.
Chapitre 15
Le modèle de navigation
15.1 DÉFINITION
Très tôt dans le processus de développement, l’analyste a déjà pu créer des maquettes
statiques des principaux écrans de l’interface homme-machine (IHM) de l’application (cf.
paragraphe 2.1.5.) Par le biais du modèle des classes d’analyse il a pu également spécifier des
classes de dialogue qui sont les classes « en périphérie de l’application », en lien d’un côté
avec les acteurs et de l’autre côté avec les contrôleurs qui implantent la logique métier. Ces
classes de dialogue sont des abstractions des écrans de l’application et des objets logiques
essentiels que ces écrans hébergent, comme les cadres ou panneaux (frame), les menus, etc.
(cf. paragraphe 13.1.1.)
Le modèle de navigation complète ces représentations en systématisant la description de la
navigation au sein des composants de l’interface utilisateur. Il ne s’agit pas d’entrer dans tous
les détails de conception, et encore moins d’implantation de l’interface. Il s’agit seulement
de définir la stratégie générale d’utilisation de l’application.
C’est une pratique bien établie pour les applications web, pour lesquelles différentes
extensions d’UML ont été proposées. À noter que certaines propositions s’appuient sur
les diagrammes d’états UML [Roq06], ce qui est assez logique en raison du caractère
« événementiel » de l’évolution des interfaces utilisateur, alors que d’autres s’appuient sur
les diagrammes d’activités UML, s’inscrivant dans la tradition de l’analyse des flots de
tâches que peuvent effectuer les utilisateurs.
La suite de ce chapitre décrit une extension minimum du diagramme d’activités UML pour
modéliser la navigation.
15.2 LES COMPOSANTS DU MODÈLE DE NAVIGATION

On retrouve les notations classiques du diagramme d’activités : début, fin, activité, transition
entre activités, choix avec gardes et barres de synchronisation.
Les activités sont simplement porteuses de stéréotypes permettant de différencier par
exemple :
– « écran » (ou « page »),
– « panneau » (ou « cadre » ou « frame »),
– « action » de l’utilisateur ou de l’application,
– « exception » pour une erreur,
– « connecteur » pour un renvoi vers un autre diagramme.
On peut en ajouter d’autres au besoin, comme « dialogue » pour modéliser à un niveau abstrait
une interaction entre acteur et application [Lie04].
À noter que plusieurs transitions qui partent d’une même activité modélisent un choix indéfini
qui est à la discrétion de l’utilisateur. Un choix conditionnel est modélisé avec le symbole
de choix en forme de losange et des gardes précisant les conditions. Enfin, une barre de
synchronisation modélise le lancement simultané de plusieurs activités parallèles.
F IGURE 15.1 Différentes formes de relation 1 vers n entre activités
À noter également que seules les transitions ayant une signification au regard du processus
métier sont explicitées dans le modèle. D’autres transitions, comme des annulations ou
des retours arrière, pourront parfaitement être établies à la conception et ajoutées dans
l’implantation.
15.3 UN EXEMPLE
On reprend le processus de recherche d’ouvrages correspondant au modèle des classes
d’analyse de la page 182.
Depuis l’écran d’Accueil, l’utilisateur peut soit passer à l’écran Recherche avancée,
soit utiliser le panneau Recherche rapide. Dans les deux cas une action de Recherche
est lancée. Si des ouvrages sont trouvés ils sont affichés sur l’écran Résultat de
recherche sinon une exception Pas d’ouvrage apparaît.
15 • Le modèle de navigation 189
Depuis l’écran d’accueil il est possible également de poursuivre vers d’autres écrans non
détaillés dans ce modèle mais désignés par des connecteurs (Meilleures ventes et
Nouveautés).
F IGURE 15.2 Navigation pour la recherche d’ouvrages

190 Exercices
EXERCICES
Exercice 15.1. Navigation dans une application de gestion de contacts

On veut modéliser la navigation au sein d’une application de gestion de contacts qui permet
d’accéder au niveau de l’écran d’accueil à la liste des contacts, avec des possibilités de
changement de page en avant et en arrière dans la liste, des possibilités d’édition et de
suppression dans la liste. Il est également possible d’accéder à des écrans pour ajouter un
contact et pour rechercher un contact selon des critères.
Donner le diagramme de navigation correspondant à cette description avec les principales
exceptions envisageables.
Exercice 15.2. Modèle de navigation sous la forme d’un diagramme d’états

Reprendre l’exemple de la navigation pour la recherche d’ouvrages du paragraphe 15.3, sous
la forme d’un diagramme d’états. On pourra associer aux états les mêmes stéréotypes que
ceux associés aux activités. On pourra tirer bénéfice de la notion UML d’« état composite »
qui regroupe plusieurs états sémantiquement liés et permet de factoriser certaines transitions
communes. La figure de la page suivante montre un exemple d’état composite dans un modèle
d’appel téléphonique.
On rappelle qu’on peut associer des activités aux états (do <activité>) ainsi que des actions
atomiques à l’entrée de l’état (entry <action>) et à la sortie de l’état (exit <action>).
15 • Le modèle de navigation 191
On rappelle également qu’on peut associer à une transition entre états, par l’intermédiaire de
la notation événement[garde]/action :
– un événement (signal, opération, condition when ou condition after)
– une garde (condition),
– une action.
Quand l’événement se produit si la condition est vérifiée alors l’action est effectuée et la
transition d’état s’opère.
PARTIE 5
Les études de cas
CAS 1 : UN SITE DE COMMERCE ÉLECTRONIQUE

La première étude de cas décrit l’analyse des besoins effectuée lors du développement d’un
site de commerce électronique de vente de livres de cuisine, appelé livresgourmands.net.
Ce site se propose de vendre des livres de cuisine couvrant tous les niveaux d’expertise et
tous les types de cuisine. Pour se démarquer des sites similaires, livresgourmands.net prévoit
de recueillir les avis et commentaires de ses clients et d’offrir une fonctionnalité de gestion
de listes de cadeaux.
Ses développeurs ont décidé que le développement serait conduit selon les préceptes généraux
du processus unifié (R)UP qu’ils maîtrisent bien.
Le chapitre 16 décrit l’étude préliminaire ou phase d’initialisation (inception). Celle-ci,
comme c’est souvent le cas, ne comprend qu’une seule itération.
Le chapitre 17 décrit la première itération de la phase d’élaboration, pour ce qui concerne les
disciplines relevant de la thématique de cet ouvrage.
CAS 2 : UN PROGRAMME DE JEU DE PLATEAU

La seconde étude de cas décrit l’analyse des besoins pour un programme de jeu de plateau du
type « Monopoly ». 1
Dans sa première partie, le chapitre 18 commence par décrire informellement les règles du
jeu qui sont utilisées pour la suite de l’analyse. Dans la seconde partie, une spécification de
ce jeu en termes de user stories est ébauchée.
1. Le Monopoly est un jeu de société édité par la société Hasbro.

194 Partie 5. Les études de cas
Le chapitre 19 reprend la même analyse, avec cette fois une spécification en termes de cas
d’utilisation.
Enfin, le chapitre 20 donne une description du modèle du domaine et illustre les diagrammes
d’états associés aux entités les plus complexes du jeu.
Chapitre 16
Étude de cas 1 – La phase d’initialisation
La phase d’initialisation (inception) est centrée sur l’identification des besoins fonctionnels
et non fonctionnels. La description des acteurs et des cas d’utilisation, sous une forme
synthétique, constitue l’outil essentiel d’expression initiale des besoins fonctionnels. Les
principales exigences non fonctionnelles sont également listées. Une première ébauche
d’analyse en termes d’architecture fonctionnelle et de classes importantes pour le domaine
visé est aussi conduite. Enfin, des maquettes des principaux écrans sont élaborées.
16.1 LES ACTEURS

Les six rôles suivants ont été retenus :
– Internaute : une personne qui peut visiter les pages de présentation et faire des
recherches.
– Client : une personne s’étant enregistrée et connectée, qui peut passer des commandes
et les suivre, créer et gérer des listes de cadeaux, évaluer et commenter des ouvrages.
– Ami : une personne ayant reçu un code personnalisé permettant d’accéder à une liste de
cadeaux et de passer commande dans cette liste.
– Éditeur : un employé chargé des descriptions d’ouvrage, de la classification des
ouvrages (niveau d’expertise et catégories d’appartenance) et de la validation des
commentaires des clients.
– Gestionnaire : un employé chargé de gérer le catalogue et le stock d’ouvrages.
– Administrateur : un employé chargé du bon fonctionnement du site et de sa

maintenance.
Les trois premiers rôles relèvent du front office, les trois derniers du back office. Il existe aussi
un acteur logiciel, le Système de paiement sécurisé d’un prestataire externe.
16.2 LES CAS D’UTILISATION

Après discussion entre les porteurs du projet et les développeurs experts en sites marchands,
la première liste de cas d’utilisation suivante a été établie en considérant successivement les
interactions essentielles initiées par chaque type d’acteur.
a) Cas d’utilisation de l’Internaute

– Rechercher des ouvrages : l’application offre aux internautes plusieurs méthodes
de recherche.
• Une recherche textuelle dans les descriptions.
• Une recherche avancée par catégories : niveau d’expertise, catégorie d’ouvrage, tranche
de prix.
• Une recherche par les caractéristiques de l’ouvrage : titre, auteur, numéro ISBN.
• Une recherche selon la popularité : avis des clients et ventes réalisées.
Seuls les ouvrages disponibles en stock doivent apparaître dans les listes de résultat.
– Consulter un ouvrage : l’ouvrage trouvé par l’internaute est présenté en détail
avec la photo de sa couverture, ses caractéristiques, sa description, l’avis des clients, un
accès aux commentaires.
b) Cas d’utilisation du Client

– S’enregistrer : le futur client doit fournir des informations obligatoires (nom,
prénom, adresse, mail, login, mot de passe) et peut fournir des informations facultatives
supplémentaires (âge, téléphone, etc.).
– Se connecter : le client enregistré se connecte par saisie de son login et de son mot de
passe.
– Rechercher des ouvrages et Consulter un ouvrage (cf. ci-dessus).
– Sélectionner des ouvrages dans son panier : le client peut en ajouter,
simplement en les désignant, en supprimer, en changer la quantité. Il est informé à chaque
instant du nombre d’articles et du montant courant du panier.
– Passer une commande : ce processus de passation de commande par le client
comporte le choix des modalités de livraison (adresse de livraison, type de livraison),
le choix du mode de règlement, la saisie des coordonnées bancaires sur un serveur de
paiement sécurisé externe et la confirmation d’achat en cas de succès de la transaction
financière.
16 • Étude de cas 1 – La phase d’initialisation 197
– Consulter ses commandes : le client peut consulter ses commandes en cours et

l’historique de ses commandes déjà livrées.
– Créer une liste de cadeaux : le client peut transformer le contenu de son panier
en une liste de cadeaux. Il doit ensuite saisir la nature et de la date de l’événement fêté, les
prénoms et adresses mail des amis concernés par la liste. Un mail est généré pour chaque
ami avec un code personnalisé lui permettant ultérieurement l’accès à la liste.
– Proposer un avis : le client effectue un simple choix parmi un ensemble prédéfini
d’appréciations.
– Proposer un commentaire : le client saisit un texte libre de 500 caractères au
maximum qui est enregistré en attente de validation par un Éditeur.
c) Cas d’utilisation de l’Ami

– Consulter une liste de cadeaux : après identification de l’ami avec le code
reçu par mail, la liste des ouvrages sélectionnés non encore choisis est affichée avec leurs
caractéristiques, dont le prix.
– Acheter des cadeaux dans une liste : l’ami désigne un ou plusieurs
ouvrages dans la liste des cadeaux restants, saisit ses coordonnées personnelles (celles
d’un client) et règle son achat, selon un processus identique au règlement des commandes
normales.
d) Cas d’utilisation de l’Éditeur

– Éditer une description d’ouvrage : l’éditeur saisit la description textuelle et
le niveau d’expertise (débutant, amateur, chef) de l’ouvrage.
– Gérer les catégories d’ouvrages : l’éditeur peut ajouter, modifier et
supprimer des catégories.
– Examiner les commentaires en attente de validation : l’éditeur
peut afficher la liste des commentaires en attente et les valider ou non par un simple choix.
e) Cas d’utilisation du Gestionnaire (à détailler ultérieurement)

– Gérer le catalogue : le gestionnaire peut ajouter un ouvrage avec ses données
factuelles (éditeur, nombre de pages, date de parution, etc.), modifier un ouvrage,
supprimer un ouvrage et afficher le catalogue.
– Gérer le stock : le gestionnaire peut enregistrer une entrée en stock, enregistrer une
sortie exceptionnelle du stock, afficher le stock, rechercher selon le niveau de stock.
– Suivre les ventes : le gestionnaire peut déterminer les ventes selon différents
critères (période, niveau de détail, etc.).
f) Cas d’utilisation de l’Administrateur (à détailler ultérieurement)

– Maintenir le site : l’administrateur peut gérer les utilisateurs du back office
(éditeurs, gestionnaires, administrateurs), gérer les clients, etc.
16.3 LES EXIGENCES NON FONCTIONNELLES

Elles sont classées en trois catégories : facilité d’utilisation, efficacité et sécurité.
16.3.1. Facilité d’utilisation

– Présentation des pages du site simple et agréable à l’œil.
– Seules les fonctionnalités utilisables selon le rôle joué (internaute, client enregistré, ami,
etc.) doivent apparaître.
– Aide en ligne systématique et uniforme sur tout le site.
– Formulaire de contact disponible et réactivité des réponses.
16.3.2. Efficacité
– Pas de durée de recherche supérieure à 5 secondes avant l’affichage des premiers résultats.
– Pic de charge absorbable jusqu’à 100 connexions simultanées.
16.3.3. Sécurité
– Paiement sécurisé.
– Pas de conservation des coordonnées bancaires après achat.
– Durée de vie du panier limitée à la session.
16.4 UNE ÉBAUCHE D’ARCHITECTURE FONCTIONNELLE

Le front office et le back office sont séparés. Cela correspond à une première ébauche
d’architecture fonctionnelle en deux paquets.
F IGURE 16.1 Ébauche d’architecture fonctionnelle
Cette architecture est explicitée par les deux diagrammes de cas d’utilisation suivants (cf.
figures 16.2 et 16.3).
Chaque diagramme est simplement esquissé dans un premier temps comme une liste de cas
par acteur.
F IGURE 16.2 Les cas du front office

F IGURE 16.3 Les cas du back office
16.5 LA PRIORITISATION DES CAS

Les priorités sont déterminées en combinant une évaluation de l’importance des cas par les
porteurs du projet et du risque associé aux cas par les développeurs, selon une échelle à trois
niveaux : élevé (+++), moyen (++), faible (+). Le tableau récapitulatif est donné à la page
suivante.
Les quatre niveaux de priorité ainsi établis donneront lieu à des développements :
– au plus tôt en cas de conjonction d’une importance élevée et d’un risque élevé
(version 1 du logiciel),
– prioritaire pour la version 2,
– standard pour la version 3,
– complémentaire pour les versions 4 et plus.
La première version, à réaliser au plus tôt, comprendra donc la recherche et la consultation

des ouvrages, leur sélection et le processus de commande. La deuxième version ajoutera
Cas Importance Risque Priorité

Rechercher des ouvrages +++ ++ 1
Consulter un ouvrage +++ ++ 1
S’enregistrer ++ ++ 2
Se connecter ++ ++ 2
Sélectionner des ouvrages dans son panier +++ ++ 1
Passer une commande +++ +++ 1
Consulter ses commandes ++ + 3
Créer une liste de cadeaux + + 4
Proposer un avis + + 4
Proposer un commentaire + + 4
Consulter une liste de cadeaux + + 4
Acheter des cadeaux dans une liste + + 4
Éditer une description/classification d’ouvrage ++ + 3
Gérer les catégories d’ouvrages ++ + 3
Examiner les commentaires en attente de validation + + 4
Gérer le catalogue ++ ++ 2
Gérer le stock ++ ++ 2
Suivre les ventes ++ ++ 2
Maintenir le site ++ + 3
l’enregistrement des clients et leur connexion ainsi que la gestion du catalogue, des stocks et
le suivi des ventes. La troisième version incluera la gestion des catégories et des descriptions,
la consultation des commandes et les fonctions d’administration. Viendront ensuite dans les
versions ultérieures, les avis, les commentaires et les listes de cadeaux.
16.6 UNE PREMIÈRE ÉBAUCHE DU MODÈLE DE CLASSES
Les classes et attributs sont obtenus en reprenant chaque cas d’utilisation et en listant les
concepts qui y apparaissent. Le schéma de classes est donné tel que, avec juste l’introduction
d’une classe Personne dont héritent les différents types d’intervenants (cf. figure 16.4).
– Rechercher des ouvrages : Ouvrage (classe), titre (attribut d’Ouvrage),
auteur (attribut d’Ouvrage), ISBN (attribut d’Ouvrage), description (attribut
d’Ouvrage), niveauExpertise (attribut d’Ouvrage), prix (attribut d’Ouvrage),
ventes (attribut d’Ouvrage), avisMoyen (attribut d’Ouvrage), qtéStock (attribut
d’Ouvrage), Catégorie (classe), nom (attribut de Catégorie).
– Consulter un ouvrage.
– S’enregistrer : Client (classe), nom (attribut de Client), prénom (attribut de
Client), adresse (attribut de Client), mail (attribut de Client), login (attribut de
Client), motPasse (attribut crypté de Client), âge (attribut de Client), téléphone
(attribut de Client).
– Se connecter : état (attribut de Client – ex. : déconnecté, connecté).
F IGURE 16.4 Première ébauche du modèle de classes

– Sélectionner des ouvrages dans son panier : LigneCommande

(classe), quantité (attribut de LigneCommande).
– Passer une commande : Commande (classe), adresseLivraison (attribut de
Commande), typeEnvoi (attribut de Commande), prixTTC (attribut de Commande).
– Consulter ses commandes : date (attribut de Commande), état (attribut de
Commande – ex. : prêt à livrer, livré).
– Créer une liste de cadeaux : ListeCadeaux (classe), dateEchéance
(attribut de ListeCadeau), Ami (classe), nom (attribut d’Ami), prénom (attribut d’Ami),
mail (attribut d’Ami).
– Proposer un avis.
– Proposer un commentaire : Commentaire (classe), texte (attribut de
Commentaire), validé (attribut de Commentaire).
– Consulter une liste de cadeaux : codePersonnalisé (attribut d’Ami).
– Acheter des cadeaux dans une liste : Cadeau (classe), dateVente
(attribut de Cadeau).
– Éditer une description d’ouvrage.
– Gérer les catégories d’ouvrages.
– Examiner les commentaires en attente de validation.
– Gérer le catalogue : Catalogue (classe), éditeur (attribut d’Ouvrage),
dateParution (attribut d’Ouvrage), nombrePages (attribut d’Ouvrage).
– Gérer le stock.
– Suivre les ventes.
– Maintenir le site : Utilisateur (classe), nom (attribut d’Utilisateur),
prénom (attribut d’Utilisateur), mail (attribut d’Utilisateur), login (attribut
d’Utilisateur), motPasse (attribut crypté d’Utilisateur).
16.7 LES MAQUETTES DES PRINCIPAUX ÉCRANS

Les maquettes ont été dessinées avec le logiciel libre Pencil (http://pencil.evolus.vn).
L’écran d’accueil est esquissé à la figure 16.5. Il permet :
– la connexion des internautes déjà enregistrés,
– la création d’un compte pour les internautes non encore enregistrés,
– la recherche des ouvrages par tous les internautes selon les différents modes prévus,
– l’accès à une liste de cadeaux, également disponible à tous mais protégé par le code
personnel reçu par mail,
– la création d’une liste de cadeaux et l’accès au panier, réservés et donc visibles aux seuls
clients connectés.
Les maquettes de six autres pages sont données ci-après.

F IGURE 16.5 Maquette de la page d’accueil
– Page de recherche avancée : avec saisie des informations et lancement de la recherche (cf.
figure 16.6).
F IGURE 16.6 Maquette de la page de recherche avancée

– Page de résultat d’une recherche : liste d’images avec titres et prix (cf. figure 16.7).
F IGURE 16.7 Maquette de la page d’accueil
– Page de description d’un ouvrage : image, caractéristiques, description, catégories, mise

au panier avec quantité, avis et commentaires (cf. figure 16.8).
F IGURE 16.8 Maquette de la page de description d’un ouvrage

– Page d’enregistrement sur le site : saisie des données personnelles, du login et du mot de
passe (cf. figure 16.9).
F IGURE 16.9 Maquette de la page d’enregistrement
– Page de visualisation du panier : avec possibilité de suppression et de changement de

quantité commandée (cf. figure 16.10).
F IGURE 16.10 Maquette de la page de visualisation du panier

– Page de choix des modes de livraison et de règlement (cf. figure 16.11).
F IGURE 16.11 Maquette de la page du choix des modes de livraison et de règlement
Les maquettes des autres pages, dont les principales sont listées ici, seront élaborées
ultérieurement dans le processus :
– page de mot de passe oublié,
– page de visualisation des commentaires,
– page externe de saisie des données bancaires,
– page de confirmation d’achat,
– page de création d’une liste de cadeaux, par vidage du panier et saisie des amis,
– page d’accès à une liste de cadeaux, avec saisie du code personnel,
– page de visualisation de la liste de cadeaux disponibles, avec possibilité de mise au panier.
208 Exercices
EXERCICES
Exercice 16.1. Détermination des risques

Pourquoi la passation des commandes est le cas qui présente le risque le plus élevé ?
Exercice 16.2. Maquettage d’une page de l’application

Proposer une maquette pour la page de création d’une liste de cadeaux, par vidage du panier
et saisie des amis.
Chapitre 17
Étude de cas 1 – La phase d’élaboration
La phase d’élaboration est centrée sur l’analyse approfondie des besoins. Les cas d’utilisation
sont détaillés et leur réalisation est analysée en exploitant toutes les formes de diagrammes
UML, selon les besoins.
La phase d’élaboration est réalisée en plusieurs itérations. Ce chapitre décrit en détail la
première itération qui analyse les cas les plus prioritaires : recherche et consultation des
ouvrages, sélection des ouvrages à commander et passation de la commande.
17.1 LA SPÉCIFICATION DÉTAILLÉE DES CAS
Nom : Rechercher des ouvrages

Description : Le visiteur sélectionne une des méthodes de recherche et récupère une page
de réponse contenant les ouvrages qui répondent à sa requête.
Acteur principal : Internaute ou Client
Acteurs secondaires :
Préconditions :
– Être positionné sur la page d’accueil.
– Être connecté ou non.
Postconditions :
– L’application construit une page de résultats.
1. Le visiteur choisit une méthode de recherche :

(a) textuelle, (b) par critères, (c) par catégories, (d) par popularité (des avis et des ventes).
2. Le visiteur saisit les paramètres de recherche s’il y en a et lance la recherche :
(a) saisie du mot-clé dans le champ de saisie et bouton « chercher »,
(b) bouton « recherche avancée », remplissage des critères de la page de recherche
avancée et bouton « chercher »,
(c) sélection d’une catégorie avec la liste déroulante et bouton « chercher »,
(d) positionnement sur l’ouvrage choisi dans une des deux listes et clic sur l’image.
3. L’application affiche la page de résultats.
Variantes :
– Une recherche combinée par mot-clé et catégorie est possible. Il suffit de saisir le
texte et de choisir une catégorie sur la page d’accueil avant d’appuyer sur le bouton
« chercher ».
Autres cas liés :
Autres remarques :
– Les premiers résultats doivent apparaître en moins de 5 secondes.
– En l’absence de résultat la page de résultat indique un message d’échec de la recherche.
– L’avis moyen et le nombre de ventes de chaque ouvrage doit être disponible pour
permettre les recherches par popularité.
Nom : Consulter un ouvrage

Description : Un visiteur peut accéder à la description détaillée d’un ouvrage.
Préconditions :
– Être positionné sur la page d’accueil ou sur la page de résultats d’une requête.
Postconditions :
– La page de description détaillée de l’ouvrage est affichée.
1. Le visiteur clique sur l’image d’un ouvrage.
2. L’application affiche la page de description détaillée de cet ouvrage.
Variantes :
Autres cas liés :
Autres remarques :
Nom : Sélectionner des ouvrages dans son panier

Description : Ajout d’un ouvrage au panier en un ou plusieurs exemplaires.
17 • Étude de cas 1 – La phase d’élaboration 211
Préconditions :
– Être connecté comme Client.
– Se trouver sur la page de description détaillée d’un ouvrage.
Postconditions :
– L’ouvrage est ajouté au panier du client.
– Le nombre d’articles et le montant courant en euros du panier sont affichés.
1. Le client peut ajuster la quantité voulue (par défaut à 1).
2. Le client clique sur le bouton « Ajouter au panier ».
3. L’application affiche le nouveau nombre d’articles et le prix total courant.
Variantes :
Autres cas liés :
Autres remarques :
Nom : Passer une commande

Description : Après validation du panier le processus de passage de commande débute.
Il inclut le choix des modalités de livraison, le règlement et la confirmation de l’achat.
Acteur principal : Client ou Ami
Acteurs secondaires : Système de paiement sécurisé.
Préconditions :
– Être connecté comme Client ou Ami.
– Avoir au moins un article dans son panier.
– Se trouver sur la page de visualisation du panier et appuyer sur le bouton « Passer la
commande ».
Postconditions :
– La commande est enregistrée comme prête à livrer.
– Le règlement est effectué via le prestataire externe.
1. Le client appuie sur le bouton « Passer la commande » de la page d’affichage du panier.
2. L’application affiche un formulaire de livraison.
3. Le client remplit le formulaire de livraison (adresse de livraison, type d’envoi) et
l’enregistre.
4. L’application crée la commande.
5. Le client demande le paiement par carte bancaire en cliquant sur une des icônes
proposées.
6. Le client saisit sur la page sécurisée fournie par le prestataire externe les coordonnées
bancaires (numéro de carte, date de validité, cryptogramme) et valide la transaction.
7. Le système de paiement externe affiche la facturette si la transaction est acceptée.

8. L’application affiche une page de confirmation d’achat du site où le client peut
télécharger la facture.
Variantes :
– Panier vide.
– Non-validation du règlement.
Autres cas liés : Acheter des cadeaux dans une liste
Autres remarques :
– La transaction sur le site externe est sécurisée.
17.2 LES DIAGRAMMES DE SÉQUENCES SYSTÈME

Ils servent à approfondir l’analyse des processus complexes des cas. Le processus de passage
de commande, par exemple, est analysé de la sorte. La figure 17.1 donne le diagramme de
séquences système du processus nominal du cas Passer une commande.
F IGURE 17.1 Diagramme de séquences système du processus nominal

de Passer une commande
17.3 LES DIAGRAMMES D’ACTIVITÉS DES CAS

Ils servent à expliciter comment s’articulent les différents processus, en particulier les
variantes et les processus exceptionnels. La figure 17.2 donne le diagramme d’activités du
cas Passer une commande.
F IGURE 17.2 Diagramme d’activités de Passer une commande
17.4 LA STRUCTURATION DU DIAGRAMME DES CAS

Les relations d’héritage entre acteurs et d’héritage entre cas permettent de rendre compte de
certaines similarités qui peuvent apparaître à l’analyse : des acteurs qui ont en commun des
interactions (c’est le cas d’Internaute et de Client) et des cas similaires qui sont des
spécialisations d’un cas plus général. C’est le cas des différentes formes de recherche qui
devraient être séparées.
La figure 17.3 donne le diagramme des cas d’utilisation tel qu’il est structuré au terme de la
première itération. Le cas Rechercher des ouvrages devra être repris et scindé.
F IGURE 17.3 Diagramme de cas structuré
17.5 LES MODÈLES DES CLASSES D’ANALYSE

Les modèles des classes d’analyse sont établis cas d’utilisation par cas d’utilisation, voire
même scénario par scénario. Le modèle correspondant au scénario de la recherche textuelle
par mot-clé du cas Rechercher des ouvrages est le suivant.
F IGURE 17.4 Classes d’analyse de la recherche textuelle par mot-clé

17.6 LA DYNAMIQUE DES CLASSES D’ANALYSE

Cette dynamique est décrite pour chaque cas d’utilisation par un diagramme de séquences.
On reprend comme illustration le cas de la recherche textuelle par mot-clé.
F IGURE 17.5 Dynamique de la recherche textuelle par mot-clé
17.7 LE PROTOTYPAGE
On peut imaginer que cette première itération se termine et se concrétise par le développement
d’un prototype exploratoire de l’aspect le plus critique de l’application.
Il s’agit certainement du processus de règlement faisant appel aux services d’un prestataire
externe. Un prototype programmé en utilisant l’API de ce service peut permettre de lever au
plus tôt les risques que font peser cet aspect sur l’application.
216 Exercices
EXERCICES
Exercice 17.1. Spécification des autres cas du front office

Donner la spécification détaillée de tous les cas non encore décrits du front office.
Exercice 17.2. Diagramme de cas

Donner le diagramme de cas structuré complet du front office.
Exercice 17.3. Modèle de classes

Sur la base de la spécification détaillée des cas du front office, quels compléments faut-il
apporter au schéma de classes initial (cf. figure 16.4) ?
Exercice 17.4. Diagramme des classes d’analyse

Donner le diagramme des classes d’analyse du cas Consulter un ouvrage.
Exercice 17.5. Dynamique des classes d’analyse

Donner le diagramme de séquences décrivant la dynamique du cas précédent.
Chapitre 18
Étude de cas 2 – Les user stories
18.1 LE RAPPEL DES RÈGLES DU JEU

18.1.1. Les éléments du jeu
Le jeu utilise le plateau de jeu visible à la figure 18.1, 8 pions indiquant la position des
joueurs, 16 cartes « Caisse de communauté », 16 cartes « Chance », 28 cartes de propriété,
de l’argent, 32 maisons, 12 hôtels et 2 dés.
18.1.2. Les propriétés
Il existe trois types de propriété : les terrains nus (par groupes de couleur), les gares (4) et les
compagnies de service public (compagnie d’eau et d’électricité).
Quand un joueur s’arrête sur une case n’appartenant à personne il peut l’acheter en payant le
prix indiqué. Si le joueur n’achète pas le terrain, celui-ci est mis aux enchères. L’objectif est
d’acheter tous les terrains d’une même couleur car les revenus augmentent dans ce cas. En
outre, il devient possible de construire des maisons et hôtels qui accroissent encore plus les
revenus.
Quand un joueur s’arrête sur une propriété qui appartient à quelqu’un d’autre, il doit payer un
loyer. Le loyer pour un terrain nu, c’est-à-dire non construit, est doublé quand on possède tous
les terrains (non hypothéqués) d’un même groupe de couleur (monopole). Le loyer augmente
aussi selon le nombre de bâtiments construits sur le terrain : terrain nu, une maison, deux
maisons, un hôtel, etc. Si la propriété est hypothéquée il n’y a aucun loyer à payer.
Quand un joueur s’arrête sur une propriété qui lui appartient il ne se passe rien.
Le loyer des gares dépend du nombre de gares possédées. Le loyer est doublé à chaque gare
en plus.
F IGURE 18.1 Le plateau de jeu
Le loyer des compagnies de service public dépend du jet de dés : il faut lancer les dés et
multiplier le résultat par 4 ou 10 si on possède les deux compagnies.
18.1.3. Les cases spéciales

Quand un joueur arrive sur une case « Chance » ou « Caisse de communauté » il doit prendre
la carte au sommet du tas de cartes correspondant. Il doit ensuite suivre les instructions de la
carte. Il peut recevoir de l’argent ou au contraire payer une taxe. La carte est remise sous le
tas de carte.
Si le joueur pioche une carte « Vous êtes libéré de prison » il peut la garder jusqu’à ce qu’elle
lui serve. Il est aussi possible de la vendre à un autre joueur.
18 • Étude de cas 2 – Les user stories 219
Quand un joueur arrive sur une case « Impôts sur le revenu » ou « Taxe de luxe », il doit payer
le montant indiqué : 10 % de sa trésorerie plafonné à 200 e pour « Impôts sur le revenu » et
75 e pour « Taxe de luxe ».
Quand un joueur arrive sur la case « Allez en prison » il doit aller en prison sans passer par
la case départ. Les dés passent au joueur suivant. On peut être envoyé en prison également
quand on tire une carte qui indique d’aller en prison ou quand on fait trois doubles d’affilée
aux dés.
Il y a trois moyens pour sortir de prison :
– payer une amende de 50 e au début du tour suivant.
– utiliser une carte « Vous êtes libéré de prison » si le joueur en possède une ou s’il l’achète à
un autre joueur. Après utilisation, la carte est remise en dessous du paquet correspondant.
– attendre la fin des trois tours en essayant de se libérer à chaque tour en faisant un double.
Avec un double le joueur est libéré et il repart en relançant les dés. Si à la fin des trois tours
le joueur n’a pas fait de double il doit payer l’amende de 50 e avant de pouvoir repartir.
Quand un joueur arrive sur la case « Prison » lors d’un déplacement normal il est en « simple
visite ». Il n’y a aucune pénalité.
Quand un joueur arrive sur la case « Parc gratuit » il ne se passe rien.
18.1.4. Le déroulement du jeu

Chaque joueur reçoit une même somme d’argent au départ (1 500 e). La partie commence
par un lancer des dés. L’objectif est de déterminer le joueur qui joue en premier. Celui qui fait
le meilleur score à l’aide des deux dés commence la partie. Les autres joueurs jouent selon
l’ordre de leur saisie. Le jeu démarre sur la case départ.
Le joueur avance son pion d’autant de cases que la somme des deux dés. Les achats de terrains
peuvent commencer immédiatement. On gagne 200 e à chaque passage par la case départ ou
arrêt sur celle-ci. Le fait de faire un double aux dés donne la possibilité de rejouer. Trois
doubles d’affilée conduisent en prison.
À tout instant il est possible de procéder aux opérations suivantes, même en prison :
– Demander un loyer : si un joueur s’arrête sur une propriété non hypothéquée que l’on
possède.
– Participer à des enchères :
• quand un joueur s’arrête sur une propriété qui n’appartient à personne et qu’il décide
de ne pas l’acheter,
• quand un joueur fait faillite. Ses propriétés sont vendues non hypothéquées,
• quand il y a une crise du bâtiment, c’est-à-dire plus de maisons et d’hôtels à vendre, et
que des joueurs souhaitent acheter les mêmes bâtiments qui se libèrent.
Le paiement d’une enchère se fait en argent. L’enchère commence à n’importe quel prix
offert avec un minimum de 1 e. Tout le monde peut y participer. Le plus offrant emporte
l’enchère.
– Construire un bâtiment : pour acheter des maisons il faut obligatoirement posséder tous les
terrains d’un même groupe de couleur (monopole). Le prix est plus ou moins élevé selon
la rue sur laquelle la maison est construite. Il faut construire uniformément. C’est-à-dire
qu’on ne peut pas construire une deuxième maison sur un terrain si on n’a pas construit
une maison sur chaque terrain d’une même couleur auparavant. On peut construire quatre
maisons au maximum par terrain. On peut échanger quatre maisons contre un hôtel en
payant le prix indiqué. Un seul hôtel par terrain est possible. Il est impossible de construire
quand un terrain du même groupe de couleur est hypothéqué.
– Vendre un bâtiment : ils sont vendus à la moitié de leur valeur d’achat. Ils doivent être
vendus uniformément comme ils ont été achetés.
– Hypothéquer une propriété : quand un joueur n’a plus d’argent pour régler une dette il est
obligé d’hypothéquer une de ses propriétés. Il faut d’abord vendre tous les bâtiments situés
dessus. Le joueur reçoit le montant indiqué de l’hypothèque.
– Lever une hypothèque : il faut payer le montant de l’hypothèque plus 10% d’intérêts.
Le gagnant est le seul joueur qui n’a pas fait faillite. Un joueur qui fait faillite est éliminé du
jeu :
– Il doit rembourser ce qu’il peut avec l’argent restant.
– S’il est mis en faillite par un autre joueur, il doit lui donner toutes les propriétés et les
cartes « Vous êtes libéré de prison ». Le bénéficiaire doit immédiatement payer 10 % des
hypothèques.
– S’il est mis en faillite par la banque, tous les titres de propriété sont mis aux enchères
non hypothéqués. Les cartes « Vous êtes libéré de prison » sont remises dans la pile
correspondante.
18.2 L’ANALYSE DU JEU

18.2.1. Le logiciel à développer
L’objectif est de développer selon les préceptes agiles un logiciel interactif de jeu. Les règles
de la version « plateau » sont très légèrement modifiées :
– on ne gère pas des billets de banque mais directement des sommes d’argent,
– le rôle du banquier est tenu par le logiciel,
– les pions matériels deviennent des positions sur le plateau,
– les joueurs ne peuvent pas librement passer des accords entre eux.
Initialement, le logiciel permet d’inscrire les joueurs en leur demandant un nom et une couleur
(parmi celles encore disponibles). Le logiciel propose ensuite de commencer le jeu. Lorsque
cette option est validée, l’argent est distribué, le plateau est créé, les pions de couleurs sont
placés sur la case de départ. On passe ensuite à la détermination du joueur qui commence.
À chaque tour de jeu le logiciel propose au joueur qui a la main de lancer les dés. Il déplace
la position de ce joueur en conséquence et gère les actions obligatoires en fonction de la
case d’arrivée. Le logiciel affiche aussi les options facultatives qui sont possibles selon l’état
courant : achat de propriété, achat/vente de maison ou d’hôtel, hypothèque, etc.
18.2.2. Les user stories du jeu

Les deux rôles à considérer sont joueur et jeu. Ce dernier participe activement au
déroulement de la partie.
L’équipe de développement recherche les principales stories pour ces rôles et leur associe une
désignation, une brève description, une priorité et un nombre de points. Cette liste initiale est
susceptible d’être complétée et raffinée tout au long du processus de développement.
– Les joueurs
En tant que jeu je veux avoir une liste ordonnée de deux à huit joueurs, caractérisés par
un nom et une couleur.
Priorité : 1 Nombre de points : 1
– Le plateau
En tant que jeu je veux avoir un plateau de jeu basé sur le plateau standard du Monopoly
et tous les éléments complémentaires (états des joueurs, états des cases, etc.).
– L’ordre des joueurs
En tant que joueur je veux pouvoir lancer les deux dés pour savoir qui commencera. Le
meilleur score commence et les autres jouent dans l’ordre de la liste des joueurs.
– Les tours de jeu
En tant que jeu je veux pouvoir exécuter autant de tours de jeu qu’il est nécessaire pour
que le jeu soit terminé.
– Donner la main
En tant que jeu je veux pouvoir donner la main pendant chaque tour de jeu à chaque joueur
dans l’ordre défini ci-dessus.
– Le déplacement des pions
En tant que joueur je veux pouvoir lancer les dés et voir le logiciel déplacer mon pion
autour du plateau dans le sens des aiguilles d’une montre en fonction du résultat.
– Obtenir un double
En tant que joueur je veux continuer mon tour de jeu si j’obtiens un double (pas plus de
deux fois de suite).
– Arriver sur la case départ
En tant que joueur je veux gagner 200 e quand j’arrive sur la case départ.
– Passer sur la case départ

En tant que joueur je veux gagner 200 e quand je termine un tour en passant sur la case
départ.
– Arriver sur la case prison
En tant que joueur je veux passer sur la case prison en « simple visite ».
– Arriver sur la case « Impôts sur le revenu »
En tant que joueur je veux payer la somme demandée quand je tombe sur la case « Impôts
sur le revenu ».
– Arriver sur la case « Taxe de luxe »
En tant que joueur je veux payer la somme demandée quand je tombe sur la case « Taxe
de luxe ».
– Arriver sur la case « Parc gratuit »
En tant que joueur je veux pouvoir séjourner sans conséquences sur la case « Parc
gratuit ».
– Arriver sur une case « Caisse de communauté » ou « Chance »
En tant que joueur je veux pouvoir tirer la prochaine carte de ce type.
– Implanter les effets d’une carte
En tant que jeu je veux pouvoir implanter les effets d’une carte tirée par un joueur : perte
d’argent, gain d’argent ou déplacement.
– Acheter une « propriété »
En tant que joueur je veux pouvoir acheter une propriété libre quand je tombe sur elle
pendant un tour. Le prix dépend de sa situation. Si je ne l’achète pas une enchère est
organisée.
– Organiser une vente aux enchères
En tant que jeu je veux pouvoir organiser une enchère pour la vente d’une propriété qui n’a
pas été acquise. La mise à prix est 1e. Sans nouvel enchérissement pendant 30 secondes,
l’enchère est close et emportée par le mieux disant.
– Enchérir
En tant que joueur je veux pouvoir enchérir (par une valeur supérieure) lors d’une enchère.
– Demander un loyer
En tant que joueur je veux pouvoir demander un loyer quand un joueur tombe sur une
propriété que je possède. Il faut le faire avant qu’un autre joueur joue.
– Payer un loyer
En tant que joueur je veux payer un loyer quand je tombe sur une propriété possédée par
un autre joueur qui le demande. Le prix dépend de la propriété, de la situation de monopole
ou non et de ses constructions.
– Hypothéquer une propriété
En tant que joueur je veux pouvoir hypothéquer une propriété pendant mon tour. C’est la
seule manière d’obtenir des fonds, les prêts entre joueurs étant interdits.
– Rembourser une hypothèque
En tant que joueur je veux pouvoir rembourser une hypothèque d’une propriété.
– Construire un bâtiment
En tant que joueur je veux pouvoir construire un bâtiment sur une propriété s’il en reste
de disponible et si les conditions sont remplies.
– Organiser une enchère en cas de crise du bâtiment
En tant que jeu je veux pouvoir organiser une enchère si un bâtiment devient disponible en
période de crise du bâtiment. La mise à prix est 1 e. Sans nouvel enchérissement pendant
30 secondes, l’enchère est close et emportée par le mieux disant.
– Vendre un bâtiment
En tant que joueur je veux pouvoir vendre un bâtiment si les conditions sont remplies.
– Offrir les options
En tant que jeu je veux offrir toutes les options admissibles selon la situation aux joueurs
au début et à la fin de leur tour de jeu.
– Arriver sur la case « Allez en prison »
En tant que joueur je veux aller directement en prison sans passer par la case départ quand
je tombe sur la case « Allez en prison ».
– Obtenir un double trois fois de suite
En tant que joueur je veux aller directement en prison sans passer par la case départ quand
j’obtiens trois doubles de suite dans le même tour de jeu.
– Sortir de prison
En tant que joueur je veux pouvoir sortir de prison : en obtenant un double dans un des
trois tours de jeu suivants, ou en utilisant la carte « Vous êtes libéré de prison » si je la
possède, ou en achetant la carte « Vous êtes libéré de prison » à un joueur qui la possède,
ou en payant 50 e lors d’un des trois tours suivants.
– Faillite
En tant que joueur je veux être mis en faillite si je dois plus que je ne peux payer. Je
dois suivre les règles de faillite avec la banque ou le joueur concerné par mon défaut de
paiement.
– Organiser une enchère après une faillite
En tant que jeu je veux pouvoir organiser une enchère pour la vente d’une propriété après
une faillite. La mise à prix est 1 e. Sans nouvel enchérissement pendant 30 secondes,
l’enchère est close et emportée par le mieux disant.
– Fin du jeu
En tant que jeu je veux terminer quand il ne reste plus qu’un joueur qui n’est pas en
faillite.
18.3 LE DÉVELOPEMENT DU JEU

Sur la base de ces priorités, le regroupement des user stories délimite cinq itérations qui
débouchent sur cinq livraisons successives de l’application, correspondant respectivement
à 10, 9, 10, 9 et 12 points. Les deux premières itérations sont décrites en détail dans les
paragraphes qui suivent. Les tests d’acceptation (tests unitaires) sont précisés pour chaque
story ce qui permet de mettre en œuvre l’approche de développement piloté par les tests. La
description n’entre pas dans les détails de la conception et du codage de chaque livraison.
Seules les informations liées à l’analyse, comme les maquettes d’écrans et les diagrammes
de classes d’analyse, sont présentées dans ce qui suit.
18.3.1. Itération 1
La première livraison produite par cette itération implante la mise en place des joueurs et du
jeu ainsi que le déplacement des pions autour du plateau de jeu.
a) Tests d’acceptation
Les tests d’acceptation des stories de l’itération sont les suivants.
– Les joueurs
En tant que jeu je veux avoir une liste ordonnée de deux à huit joueurs, caractérisés par
un nom et une couleur.
• Créer un jeu avec deux joueurs Toto (rouge) et Tata (bleu).

• Créer un jeu avec un seul ou plus de 8 joueurs.
– Le plateau
En tant que jeu je veux avoir un plateau de jeu basé sur le plateau standard du Monopoly
et tous les éléments complémentaires (états des joueurs, états des cases, etc.).
• Créer un jeu avec 3 joueurs (rouge, bleu, vert). Les 3 pions doivent être sur la case
départ, les 3 joueurs doivent être dotés de 1 500 e et les propriétés doivent toutes être
disponibles.
– L’ordre des joueurs

En tant que joueur je veux pouvoir lancer les deux dés pour savoir qui commencera. Le
meilleur score commence et les autres jouent dans l’ordre de la liste des joueurs.
• Faire un lancer de dés de tous les joueurs créés.
• Vérifier que le meilleur score joue en premier.
– Les tours de jeu

En tant que jeu je veux pouvoir exécuter autant de tours de jeu qu’il est nécessaire pour
que le jeu soit terminé.
• Pour le moment on fixe un nombre de tours maximum (n) comme condition d’arrêt.
Vérifier que n tours s’enchaînent.
• Vérifier que chaque joueur joue n fois.
– Donner la main
En tant que jeu je veux pouvoir donner la main pendant chaque tour de jeu à chaque joueur
dans l’ordre défini ci-dessus.
• Vérifier que l’ordre des joueurs reste le même pour tous les tours de jeu.
– Le déplacement des pions

En tant que joueur je veux pouvoir lancer les dés et voir le logiciel déplacer mon pion
autour du plateau dans le sens des aiguilles d’une montre en fonction du résultat.
• Un joueur sur la case départ (case 0) lance 2 et 4 et se retrouve sur la case 6 (chance).
• Un joueur sur la case 39 (Rue Lafayette, la dernière avant le départ) lance 3 et 4 et se
retrouve sur la case 6 (chance).
– Obtenir un double
En tant que joueur je veux continuer mon tour de jeu si j’obtiens un double (pas plus de
deux fois de suite).
• Un joueur tire un double et joue. Il garde la main, ne tire pas un double, joue et passe la
main.
• Un joueur tire un double et joue. Il garde la main, tire un autre double et joue. Il garde
la main, ne tire pas un double, joue et passe la main.
b) Maquettes des principaux écrans du jeu

La figure 18.2 ébauche ce que pourrait être l’écran de mise en place du jeu par la création des
joueurs.
F IGURE 18.2 La création des joueurs
La figure 18.3 esquisse l’organisation de l’écran principal du jeu.
F IGURE 18.3 L’écran principal du jeu
Les cases du plateau sont disposées en bordure d’écran. Dans les livraisons ultérieures
chaque case indiquera en outre l’éventuel propriétaire, les éventuels bâtiments construits,
une éventuelle hypothèque et le loyer tenant compte de tous ces éléments.
Les pions de couleur indiquent la position des joueurs sur les cases (au maximum 8). Au
centre du plateau on trouve les caractéristiques des joueurs (nom, couleur) et leur état courant
(trésorerie, patrimoine, etc.) avec une indication du joueur qui a la main actuellement.
Au bas du plateau se situe la zone contextuelle des actions disponibles pour cet utilisateur
ainsi que les affichages correspondants. Dans la première livraison on trouve uniquement
l’action de lancer les dés et l’animation correspondante.
c) Modèle des classes d’analyse
L’analyse des règles du jeu conduit à retenir pour le moment comme classes d’entités :
– Case avec de nombreuses sous-classes (Départ, Prison, AllezEnPrison,
ParcGratuit, Taxe, Impôts, Chance, CaisseDeCommunauté, Propriété,
Gare, CompagnieServicePublic),
– Carte avec deux sous-classes (CarteChance et CarteCaisseDeCommunauté),
– Joueur,
– Dés qui pourra accueillir les deux valeurs tirées et des méthodes comme lancer() et
estDouble().
La première version du schéma comprend aussi une classe de dialogue Plateau et une
classe contrôleur Jeu.
La figure 18.4 décrit cette première version du modèle des classes d’analyse qui inclut aussi
une association situant chaque joueur sur une case.
F IGURE 18.4 Première version du modèle des classes d’analyse

18.3.2. Itération 2
La deuxième livraison produite par cette itération implante les conséquences du passage par
les cases spéciales du plateau : gain d’argent, perte d’argent ou déplacement du pion.
a) Tests d’acceptation
Les tests d’acceptation des stories de l’itération sont les suivants.
– Arriver sur la case départ
En tant que joueur je veux gagner 200 e quand j’arrive sur la case départ.
• Un joueur arrive sur la case départ. Sa trésorerie augmente de 200 e.
• Un joueur arrive sur une case normale. Sa trésorerie reste inchangée.
– Passer sur la case départ

En tant que joueur je veux gagner 200 e quand je termine un tour en passant sur la case
départ.
• Un joueur passe au-dessus de la case départ. Sa trésorerie augmente de 200 e.
• Un joueur passe deux fois au-dessus de la case départ au cours du même tour de jeu. Sa
trésorerie augmente de 400 e.
• Un joueur démarre de la case départ sans repasser dessus dans le même tour de jeu. Sa
trésorerie reste inchangée.
– Arriver sur la case prison

En tant que joueur je veux passer sur la case prison en « simple visite ».
• Un joueur arrive sur la case prison. Il n’y a aucune conséquence ni sur sa trésorerie ni
sur son prochain tour de jeu.
• Un joueur passe au-dessus de la case prison sans atteindre la case départ. Il n’y a aucune
conséquence ni sur sa trésorerie ni sur son déplacement.
– Arriver sur la case « Impôts sur le revenu »
En tant que joueur je veux payer la somme demandée quand je tombe sur la case « Impôts
sur le revenu ».
• Un joueur arrive sur la case « Impôts sur le revenu » avec une trésorerie de 1 800 e. Sa
trésorerie diminue de 180 e.
• Un joueur arrive sur la case « Impôts sur le revenu » avec une trésorerie de 0 e. Sa
trésorerie est inchangée.
• Un joueur passe au dessus de la case « Impôts sur le revenu » sans atteindre la case
départ. Il n’y a aucune conséquence ni sur sa trésorerie ni sur son déplacement.
– Arriver sur la case « Taxe de luxe »

En tant que joueur je veux payer la somme demandée quand je tombe sur la case « Taxe
de luxe ».
• Un joueur arrive sur la case « Taxe de luxe ». Sa trésorerie diminue de 75 e.
• Un joueur passe au-dessus de la case « Taxe de luxe » sans atteindre la case départ. Il
n’y a aucune conséquence ni sur sa trésorerie ni sur son déplacement.
– Arriver sur la case « Parc gratuit »
En tant que joueur je veux pouvoir séjourner sans conséquences sur la case « Parc
gratuit ».
• Un joueur arrive sur la case « Parc gratuit ». Sa trésorerie est inchangée.
• Un joueur passe au-dessus de la case « Parc gratuit » sans atteindre la case départ. Il
n’y a aucune conséquence ni sur sa trésorerie ni sur son déplacement.
– Arriver sur une case « Caisse de communauté » ou « Chance »
En tant que joueur je veux pouvoir tirer la prochaine carte de ce type.
• Un joueur arrive sur une case « Caisse de communauté » ou « Chance ». Il tire une
carte. Le jeu implante son effet (cf. story suivante). La carte est en général replacée en
bas de la pile.
• Un joueur passe au-dessus d’une case « Caisse de communauté » ou « Chance » sans
atteindre la case départ. Il n’y a aucune conséquence ni sur sa trésorerie ni sur son
déplacement.
– Implanter les effets d’une carte

En tant que jeu je veux pouvoir implanter les effets d’une carte tirée par un joueur : perte
d’argent, gain d’argent ou déplacement.
• L’effet peut porter sur la trésorerie (gain ou perte) et sur la position du joueur. La carte
« Vous êtes libéré de prison » peut être gardée jusqu’à ce qu’elle serve ou être vendue à
un autre joueur.
b) Modèle des classes d’analyse

Le modèle des classes est complété par l’introduction des sous-classes de Case et de Carte.
Les cases Chance et CaisseDeCommunauté sont reliées à leurs cartes respectives
CarteChance et CarteCaisseDeCommunauté par des agrégations.
L’association possède indique les cartes possédées par un Joueur.
La figure 18.5 donne cette version complétée.
Les études de cas
Partie 5.
F IGURE 18.5 Deuxième version du modèle des classes d’analyse

230
18.3.3. Les itérations suivantes

La troisième livraison réalise la gestion des propriétés (achat direct ou enchères, vente, prise
et levée d’hypothèque, loyers, etc.). Un écran de suivi d’une enchère doit être proposé.
La quatrième livraison implante la gestion des bâtiments (maisons et hôtels) avec le cas
particulier de la crise du bâtiment.
Enfin, la cinquième livraison gère les autres situations, comme le passage en prison ou la
mise en faillite.
232 Exercices
EXERCICES
Exercice 18.1. Tests d’acceptation

Donner les tests d’acceptation des trois user stories de l’itération 3 : Acheter une
propriété, Organiser une vente aux enchères, Enchérir.
Exercice 18.2. Maquette d’écran

Proposer la maquette de l’écran permettant aux joueurs de participer à une enchère.
Chapitre 19
Étude de cas 2 – Les cas d’utilisation
Dans ce chapitre, le jeu tel qu’il est défini au chapitre précédent est repris et le résultat de
l’analyse des besoins est exprimé en termes de cas d’utilisation et de diagramme de cas.
19.1 LES CAS D’UTILISATION DU JEU

19.1.1. S’enregistrer
Nom : S’enregistrer
Description : Dès son lancement, le jeu affiche une grille de saisie du nom et de la couleur
que chaque joueur doit remplir.
Acteur principal : Joueur
Acteurs secondaires : Jeu
Préconditions : Moins de 8 joueurs déjà inscrits
Postconditions : Le joueur est enregistré.
1. Saisie du nom.
2. Choix d’une couleur parmi celles qui restent.
3. Ajout du joueur.
4. Passage au joueur suivant ou terminaison de la saisie.
Variantes :
1. Message d’erreur si plus de 8 joueurs.
2. Message d’erreur si le nom est vide.
Autres cas liés :
Autres remarques : Prévoir un bouton d’annulation.
19.1.2. Tirer celui qui commence
Nom : Tirer celui qui commence

Description : Après la saisie des joueurs, tous les joueurs lancent les dés pour savoir qui
va commencer le jeu.
Préconditions : La saisie des joueurs a été faite.
Postconditions : Le joueur qui va commencer le jeu est connu. Les autres joueront ensuite
dans l’ordre de leur saisie.
1. Tous les joueurs lancent les dés dans l’ordre de leur inscription.
2. En cas d’égalité, les joueurs concernés recommencent jusqu’à ce qu’un vainqueur
unique soit désigné.
Variantes :
Autres cas liés : Lancer les dés
Autres remarques :
19.1.3. Afficher le plateau
Nom : Afficher le plateau

Description : Dès que l’initialisation du jeu est terminée et après chaque action, le jeu
affiche un plateau mis à jour.
Acteur principal : Jeu
Préconditions : Le jeu a été initialisé.
Postconditions : L’affichage du plateau est à jour.
1. Affichage du plateau mis à jour. Les joueurs peuvent voir leur nom, couleur, trésorerie
ainsi que les cartes et propriétés qu’ils possèdent. Les cases montrent leur nom et prix
19 • Étude de cas 2 – Les cas d’utilisation 235
et éventuellement leur propriétaire, bâtiments, loyer, le fait d’être hypothéqué. Le joueur

qui a la main est mis en évidence.
Variantes :
Autres cas liés :
Autres remarques :
19.1.4. Lancer les dés
Nom : Lancer les dés

Description : Chaque fois qu’un joueur a la main il doit lancer les dés. Chaque joueur
doit aussi le faire en début de jeu, pour définir qui commence en premier.
Préconditions : Le joueur a la main.
Postconditions : Les valeurs des deux dés sont établies.
1. Lancer l’action « Jeter les dés ».
2. Les valeurs des deux dés, tirées au hasard, apparaissent.
Variantes :
1. Le joueur est en prison et obtient un double. Il peut sortir de prison en relançant les
dés.
2. Le joueur obtient un troisième double de suite. Il se retrouve en prison sans passer par
la case départ.
Autres cas liés :
Autres remarques : Le bouton pourrait lancer une animation.
19.1.5. Déplacer un pion
Nom : Déplacer un pion

Description : Après que le joueur a lancé les dés, le jeu déplace son pion en fonction de
la valeur obtenue.
Préconditions : Un joueur vient de lancer les dés et il ne s’est pas retrouvé en prison pour
un troisième double.
Postconditions : Le pion est déplacé du nombre de cases indiqué par les dés.
1. Le déplacement est visible sur le plateau.

2. Les cas impliqués par ce déplacement démarrent (ex. : passage sur la case départ,
action liée à la case d’arrivée).
Variantes :
Autres cas liés : Passer sur ou arriver à la case départ, Arriver à
la case prison, Arriver à la case parc gratuit, Rejouer après
un double, Afficher le plateau
Autres remarques : Il serait agréable de voir l’avancement du pion case par case jusqu’à
sa position finale.
19.1.6. Passer sur ou arriver à la case départ
Nom : Passer sur ou arriver à la case départ

Description : Traitement d’un passage au-dessus de la case départ ou d’une arrivée sur
celle-ci suite à un jet de dés.
Préconditions :
– Le pion vient d’être déplacé suite à un jet de dés.
– Le déplacement l’amène à passer sur ou arriver à la case départ.
Postconditions : La trésorerie du joueur augmente de 200 e.
1. La trésorerie du joueur est mise à jour.
Variantes :
1. Le joueur passe sur la case départ pour se rendre en prison. Il ne gagne pas d’argent.
Autres cas liés : Déplacer un pion
Autres remarques :
19.1.7. Arriver à la case prison
Nom : Arriver à la case prison

Description : Traitement d’une arrivée sur la case prison suite à un jet de dés.
Préconditions :
– Le déplacement l’amène à la case prison.

Postconditions :
1. Rien ne se passe (c’est une « simple visite »).
Variantes :
Autres remarques :
19.1.8. Arriver à la case parc gratuit
Nom : Arriver à la case parc gratuit

Description : Traitement d’une arrivée sur la case parc gratuit suite à un jet de dés.
Préconditions :
– Le déplacement l’amène à la case parc gratuit.
Postconditions :
1. Rien ne se passe.
Variantes :
Autres remarques :
19.1.9. Arriver à la case allez en prison
Nom : Arriver à la case allez en prison

Description : Traitement d’une arrivée sur la case allez en prison suite à un jet de dés.
Préconditions :
– Le déplacement l’amène à la case allez en prison.
Postconditions : Le joueur est en prison.
1. Le pion est déplacé vers la case prison sans passer sur la case départ.
Variantes :
Autres remarques :
19.1.10. Sortir de prison
Nom : Sortir de prison

Description : Sortie de la prison en payant une amende ou en jouant une carte « Vous
êtes libéré de prison ».
Préconditions : Un joueur est en prison.
Postconditions : Une carte « Vous êtes libéré de prison » que ce joueur possède est remise
en bas du tas dont elle est issue ou bien la trésorerie de ce joueur diminue de 50 e. Le
joueur peut continuer normalement en jetant les dés.
1. Demander à sortir de prison.
Variantes :
1. En vue de sortir de prison, le joueur achète à un autre joueur une carte « Vous êtes
libéré de prison ».
2. Impossibilité de payer l’amende. Il faut hypothéquer une propriété ou être mis en
faillite.
Autres cas liés : Lancer les dés
Autres remarques :
19.1.11. Acheter une carte « Vous êtes libéré de prison »
Nom : Acheter une carte « Vous êtes libéré de prison »

Description : En vue de sortir de prison un joueur peut acheter cette carte à un autre
joueur.
Préconditions :
– Un joueur possède une carte « Vous êtes libéré de prison ».
– Un autre joueur lui fait une offre d’achat.
Postconditions :
– L’acheteur récupère la carte « Vous êtes libéré de prison ».

– La trésorerie de l’acheteur est débitée du prix convenu, celle du vendeur est créditée du
même prix.
1. Le prix est négocié entre acheteur et vendeur. Le prix proposé par l’acheteur est saisi.
Il peut être accepté ou non par le vendeur. Il peut être augmenté par l’acheteur qui peut
aussi abandonner.
Variantes :
Autres cas liés :
Autres remarques :
19.1.12. Rejouer après un double
Nom : Rejouer après un double

Description : Un joueur qui a joué une fois après avoir obtenu un double doit rejouer.
Préconditions :
– Un joueur a joué une fois après avoir obtenu un double.
– Il a demandé la fin du tour.
Postconditions : Ce joueur conserve la main.
1. Le jeu demande au joueur de rejouer.
Variantes :
Autres cas liés : Demander la fin du tour
Autres remarques :
19.1.13. Acheter une propriété
Nom : Acheter une propriété

Description : Un joueur arrive sur une propriété libre. Il peut l’acheter. S’il ne le fait pas
elle est mise aux enchères.
Préconditions : Le joueur arrive sur une propriété libre.
Postconditions : La propriété est achetée.
1. Le joueur demande à acheter.
2. Sa trésorerie diminue du montant de l’achat.
Variante :
1. Le joueur renonce à acheter. Une enchère est démarrée.
Autres cas liés : Afficher le plateau
Autres remarques :
19.1.14. Hypothéquer une propriété – Lever une hypothèque

Ces deux cas sont traités en exercice.
19.1.15. Participer à une enchère
Nom : Participer à une enchère

Description : Un joueur enchérit lors d’une enchère.
Préconditions : L’enchère est lancée.
Postconditions : L’enchère est gagnée et close ou une autre offre est arrivée.
1. Proposer un prix initial ou supérieur au prix maximum déjà proposé.
2. L’enchère est gagnée et close si aucune autre offre n’arrive dans les 30 secondes qui
suivent.
Variantes :
Autres cas liés : Acheter une propriété
Autres remarques :
19.1.16. Construire un bâtiment
Nom : Construire un bâtiment

Description : Un joueur construit une maison ou un hôtel sur une de ses propriétés.
Préconditions :
– Le joueur a la main.
– Le joueur possède toutes les propriétés de la couleur et aucune n’est hypothéquée.
– Les règles de construction (uniformité, 4 maisons au maximum, un hôtel après 4

maisons, un seul hôtel, etc.) sont satisfaites.
– Il reste un bâtiment disponible.
Postconditions :
– Le bâtiment est construit.
– La trésorerie du joueur diminue du prix du bâtiment.
1. Demander la construction en précisant le type de bâtiment et la localisation.
Variantes :
1. Une des règles de construction n’est pas satisfaite. La construction est refusée.
2. Il n’y a plus de bâtiment disponible (« crise du bâtiment »). Une enchère sera lancée
par le jeu dès qu’un bâtiment deviendra disponible.
Autres cas liés : Afficher le plateau.
Autres remarques :
19.1.17. Demander un loyer
Nom : Demander un loyer

Description : Un propriétaire demande un loyer à un autre joueur.
Préconditions : Un joueur (l’arrivant) vient d’arriver sur une propriété non hypothéquée
d’un autre joueur (le propriétaire).
Postconditions : La trésorerie de l’arrivant est débitée du loyer au profit de la trésorerie
du propriétaire.
1. Le propriétaire actionne la demande de loyer.
2. Le paiement du loyer s’effectue.
Variantes
1. Si la case est une compagnie de service public l’arrivant doit lancer les dés pour
déterminer le montant du loyer.
2. Si l’arrivant ne peut pas payer il est mis en faillite.
3. Si le tour de l’arrivant est terminé la demande de loyer par le propriétaire n’est plus
possible.
Autres cas liés : Mettre en faillite, lancer les dés
Autres remarques :
19.1.18. Tirer une carte
Nom : Tirer une carte

Description : Traitement d’une arrivée sur une case « Caisse de communauté » ou
« Chance ».
Préconditions :
– Le déplacement l’amène sur une case « Caisse de communauté » ou « Chance ».
Postconditions :
– La carte en sommet de paquet est rendue visible.
– Le jeu implante son effet. Ce peut être un gain de trésorerie pour le joueur, une perte de
trésorerie pour le joueur, un déplacement du pion du joueur (par exemple vers la prison),
une carte à conserver par le joueur.
1. La carte tirée est visualisée.
2. L’effet de la carte est rendu visible.
Variantes :
Autres cas liés :
Autres remarques :
19.1.19. Demander la fin du tour
Nom : Demander la fin du tour

Description : Un tour de jeu ne se termine qu’à la demande explicite du joueur qui a la
main. En effet il peut avant effectuer diverses actions facultatives.
Préconditions : Un joueur a la main.
Postconditions : Le joueur suivant prend la main.
1. Le joueur indique qu’il a fini son tour.
Variantes :
Autres cas liés :
Autres remarques :
19.1.20. Vendre un bâtiment
Nom : Vendre un bâtiment

Description : La vente se fait à la banque à la moitié de la valeur d’achat.
Préconditions :
– Le joueur possède un bâtiment sur une de ses propriétés.
– La règle d’uniformité est respectée pour les maisons.
Postconditions :
– Le bâtiment est rendu à la banque.
– La trésorerie du joueur est augmentée du prix de vente prévu.
1. Le joueur demande la vente du bâtiment sur une de ses propriétés.
Variantes :
1. En cas de « crise du bâtiment » une vente aux enchères est démarrée par le jeu après
la vente.
Autres remarques :
19.1.21. Mettre en faillite

Cas traité en exercice.
19.2 LE DIAGRAMME DES CAS D’UTILISATION

Le diagramme des cas est assez complexe car beaucoup de cas sont des extensions possibles
d’autres cas. La figure 19.1 montre l’essentiel de ces dépendances.
F IGURE 19.1 Le diagramme de cas du jeu

EXERCICES
Exercice 19.1. Cas liés à la gestion des hypothèques

Spécifier les cas Hypothéquer une propriété et Lever une hypothèque.
Exercice 19.2. Cas de la mise en faillite

Spécifier le cas Mettre en faillite.
Chapitre 20
Étude de cas 2 – Les classes du domaine
20.1 L’ANALYSE TEXTUELLE

Une analyse textuelle de la description du jeu peut être conduite. Les noms considérés comme
les plus significatifs sont soulignés à leur première apparition.
20.1.1. Le texte
Le jeu utilise le plateau de jeu visible à la figure 18.1, 8 pions indiquant la position des
joueurs, 16 cartes « Caisse de communauté », 16 cartes « Chance », 28 cartes de propriété,
de l’argent, 32 maisons, 12 hôtels, 2 dés.
Il existe trois types de propriété : les terrains nus (par groupes de couleur), les gares (4) et les
compagnies de service public (compagnie d’eau et d’électricité).
Quand un joueur s’arrête sur une case n’appartenant à personne il peut l’acheter en payant le
prix indiqué. Si le joueur n’achète pas le terrain, celui-ci est mis aux enchères. L’objectif est
d’acheter tous les terrains d’une même couleur car les revenus sont augmentés. En outre, il
devient possible de construire des maisons et hôtels qui accroissent encore plus les revenus.
Quand un joueur s’arrête sur une propriété qui appartient à quelqu’un d’autre, il doit payer un
loyer. Le loyer pour un terrain nu, c’est-à-dire non construit, est doublé quand on possède tous
les terrains (non hypothéqués) d’un même groupe de couleur (monopole). Le loyer augmente
aussi selon le nombre de bâtiments construits sur le terrain : terrain nu, une maison, deux
maisons, un hôtel, etc. Si la propriété est hypothéquée il n’y a aucun loyer à payer.
Quand un joueur s’arrête sur une propriété qui lui appartient il ne se passe rien. Le loyer
des gares dépend du nombre de gares possédées. Le loyer est doublé à chaque gare en plus.
Le loyer des compagnies de service public dépend du jet de dés : il faut lancer les dés et
multiplier le résultat par 4 ou 10 si on possède les 2 compagnies.
Quand un joueur arrive sur une case « Chance » ou « Caisse de communauté » il doit prendre
la carte au sommet du tas de cartes correspondant. Il doit ensuite suivre les instructions de
la carte. Il peut recevoir de l’argent ou au contraire payer une taxe. La carte est remise sous
le tas de carte. Si le joueur pioche une carte « Vous êtes libéré de prison » il peut la garder
jusqu’à ce qu’elle lui serve. Il est aussi possible de la vendre à un autre joueur.
Quand un joueur arrive sur une case « Impôts sur le revenu » ou une case « Taxe de luxe », il
doit payer le montant indiqué : 10 % de sa trésorerie plafonné à 200 e pour « Impôts sur le
revenu » et 75 e pour « Taxe de luxe »).
Quand un joueur arrive sur la case « Allez en prison » il doit aller en prison sans passer par
la case départ. Les dés passent au joueur suivant. On peut être envoyé en prison également
quand on tire une carte qui indique d’aller en prison ou quand on fait trois doubles d’affilée
aux dés. Il y a trois moyens pour sortir de prison :
– payer une amende de 50 e au début du tour suivant.
– utiliser une carte « Vous êtes libéré de prison » si le joueur en possède une ou s’il l’achète à
un autre joueur. Après utilisation, la carte est remise en dessous du paquet correspondant.
– attendre la fin des trois tours en essayant de se libérer à chaque tour par un double. Avec
un double le joueur est libéré et repart en relançant les dés. Si à la fin des trois tours le
joueur n’a pas fait de double il doit payer l’amende de 50 e avant de pouvoir repartir.
Quand un joueur arrive sur la case « Prison » lors d’un déplacement normal il est en « simple
visite ». Il n’y a aucune pénalité. Quand un joueur arrive sur la case « Parc gratuit » il ne se
passe rien.
20.1.2. Les concepts retenus

Les noms retenus comme reflétant a priori des concepts importants du domaine sont : jeu,
plateau, pion, joueur, case (et ses spécialisations), carte (et ses spécialisations), dé, maison et
hôtel.
Les noms retenus comme décrivant des valeurs élémentaires, donc des attributs, sont : prix,
loyer et hypothéquée.
20.2 LE MODÈLE DES CLASSES DU DOMAINE

Craig Larman propose la première ébauche de modèle décrite par la figure 20.1.
La classe Jeu (MonopolyGame) est reliée aux différentes classes représentant les composants
du jeu :
– le Plateau (Board), lui-même composé de Cases (Square),
– les Joueurs (Player),
– les Dés (Die).
20 • Étude de cas 2 – Les classes du domaine 249
Les Pions (Piece) sont reliés aux Joueurs et aux Cases.
F IGURE 20.1 Première ébauche de Craig Larman
Sur la base de l’analyse textuelle, on peut aller plus loin dans la modélisation avec les choix
suivants (cf. le modèle complété de la figure 20.2).
– Pour chaque Joueur on peut conserver son dernier tirage de Dés comme un attribut
valeur de l’association a_tiré.
– Les pions ne sont pas obligatoirement représentés comme des objets. La notion peut se
traduire par une association positionné_sur entre Joueur et Case.
– Par contre, la représentation des cartes peut être utile, avec les classes Carte Caisse
de communauté et Carte Chance. Leurs objets sont ordonnés, tirés par les joueurs
et parfois possédés par eux (comme les cartes « Vous êtes libéré de prison »).
Deux associations mémorisent la dernière carte tirée de chaque paquet et qui possède quoi
(dernière_tirée et possédée_par).
La notion de carte de propriété est représentée par l’association (propriétaire_de)
entre Joueur et les cases de type Propriété.
– La classe Case est spécialisée en Propriété, Départ, Parking, Prison simple
visite, Allez en prison, Impôts sur le revenu, Taxe de luxe,
Chance, Caisse de communauté. La classe Propriété est spécialisée en
Terrain, Gare et Compagnie.
Parmi les attributs de Propriété on retient la couleur, le prix, les niveaux de loyer, la
valeur hypothécaire, etc.
– Les maisons et hôtels ne sont pas représentés comme des objets. Pour les connaître il
suffit de compter les maisons et hôtels disponibles au niveau des attributs de la classe Jeu
(maisons_dispo et hôtels_dispo) et de compter les maisons et hôtels construits
sur les cases Propriété (maisons_bâties, hôtels_bâtis).
Les études de cas
Partie 5.
250
F IGURE 20.2 Le modèle complété
20 • Étude de cas 2 – Les classes du domaine 251
20.3 L’ANALYSE DES ENTITÉS COMPLEXES DU DOMAINE

Pour approfondir l’analyse, il est possible de construire des diagrammes d’états décrivant le
« cycle de vie » des entités complexes du domaine.
Par exemple, l’entité Joueur peut passer par quatre états différents : normal, endetté,
emprisonné et en_faillite. Le diagramme d’états permet d’analyser précisément les
événements générateurs des transitions d’états correspondantes.
F IGURE 20.3 Diagramme d’états de l’entité Joueur

252 Exercices
EXERCICES
Exercice 20.1. Les joueurs

a) Donner des raisons qui justifient de stocker la dernière valeur tirée avec les Dés pour
chaque Joueur ?
b) Comment mémoriser le Joueur qui est en train de jouer ?
c) Donner au moins deux attributs supplémentaires utiles à la classe Joueur ?
Exercice 20.2. Le plateau de jeu

Comment spécifier la succession des cases du plateau ?
Exercice 20.3. Diagramme d’états

Donner le diagramme d’états de l’entité Terrain.
Conclusion
L’ABSENCE D’APPROCHE UNIVERSELLE

Arrivé au terme de cet ouvrage, force est de constater qu’il n’y a pas de processus, de méthode
et de notation qui puissent s’appliquer universellement pour conduire l’analyse des besoins.
Tout dépend du type de logiciel à développer et du contexte du développement.
Par exemple, si une démarche empirique autour d’une suite de prototypes peut convenir
parfaitement au développement des jeux, les logiciels embarqués requièrent plutôt
des spécifications initiales très complètes et éventuellement même mathématiquement
formalisées et vérifiées.
LES POINTS CLÉS À SATISFAIRE

Malgré cette diversité inhérente au domaine de l’analyse, il est possible de définir un
ensemble de points clés qu’il est essentiel de satisfaire. Ils s’appliquent en particulier aux
applications web fréquentes aujourd’hui. Ces points clés ont été explicités tout au long de
l’ouvrage.
(1) Bien comprendre les demandes des clients et des utilisateurs finaux et donc bien
communiquer avec eux.
(2) Accepter et prendre en compte les inévitables changements dans ces demandes.
(3) Traiter au plus tôt les points critiques du projet pour éviter au maximum la découverte
tardive de défauts majeurs.
(4) S’appuyer sur une architecture claire et robuste, c’est-à-dire susceptible de résister aux
évolutions inévitables.
254 Conclusion
(5) Mettre en œuvre au maximum les bonnes pratiques pour la qualité, telles les revues et
inspections ou le développement dirigé par les tests.
(6) Favoriser le travail en équipe.
LES APPORTS
Pour répondre à la complexité du domaine du développement logiciel et de sa phase
initiale d’analyse des besoins, cet ouvrage apporte dans sa première moitié des éléments de
compréhension et de culture générale.
Dans sa seconde moitié, l’ouvrage détaille les techniques essentielles pour la compréhension
du contexte métier, le recueil des besoins et leur approfondissement par la modélisation. Le
tableau qui suit donne une indication de leur fréquence d’utilisation dans les deux principales
approches de développement.
Techniques (R)UP Approches agiles

Modélisation des processus métier +++ +
Modélisation du domaine +++ ++
Langage OCL ++
User stories ++++
Cas d’utilisation et diagramme de cas ++++ +
Diagramme de séquence système +++ ++
Diagramme d’activités des cas ++ +
Modèle des classes d’analyse ++ +
Diagramme de séquences + +
Diagramme d’états + +
LE MOT DE CONCLUSION
Avec le volume compagnon dédié à la conception des applications [Lon14], l’ensemble offre
un panorama du développement logiciel dans sa globalité assez complet pour être réaliste et
assez synthétique pour rester compréhensible.
Corrigés des exercices
Exercice 1.1.
L’erreur de base réside dans la réutilisation abusive d’une partie du logiciel des Ariane 4,
avec une insuffisance des tests et simulations avec la trajectoire d’Ariane 5 à la place de
la trajectoire d’Ariane 4. Les deux trajectoires n’étant pas semblables cela a conduit à une
conversion impossible à faire. Autrement dit, un module qui avait une « contrainte cachée »
(BH < 32768), valide pour Ariane 4 mais pas pour Ariane 5, a été abusivement réutilisé et
intégré. Les conditions d’utilisation auraient dû faire partie de la spécification du module.
Le fait que le programme ne contienne pas de protection en cas d’erreur d’opérande, c’est-à-
dire d’exception Ada pour cette conversion alors que d’autres étaient protégées, n’est pas
réellement une erreur de programmation mais une décision de conception prise en 1980
et justifiée pour Ariane 4 en raison des marges de sécurité constatées. Cependant, cette
« optimisation » aurait dû être mieux documentée puisqu’elle générait une contrainte de
validité du module.
On peut enfin souligner l’absence de redondance logicielle (programmes ayant les mêmes
spécifications développés par des équipes différentes). La redondance matérielle, avec des
calculateurs exécutant le même programme, ne protège que contre les pannes matérielles.
Exercice 1.2.
Le matériel, après correction des défauts initiaux, connaît une phase de fonctionnement
optimum avant une dégradation assez rapide en fin de vie pour des problèmes d’usure
(courbe en forme de « baignoire »).
Le logiciel devrait en théorie atteindre un fonctionnement optimum après correction des
bugs initiaux, sans phénomène d’usure. En réalité, tout logiciel subit des évolutions. Chaque
évolution génère de nouveaux bugs qui sont corrigés rapidement. Mais globalement toutes
ces évolutions conduisent à une lente détérioration due à l’augmentation de la complexité et
256 Corrigés des exercices
aux remises en cause plus ou moins maîtrisées de la conception initiale. D’où la croissance
en dents de scie de la courbe de défaillance réelle.
Exercice 1.3.
a) Sécurité, intégrité des données, disponibilité des données, performance des transactions,
convivialité. Autrement dit un site agréable à utiliser dans lequel on peut avoir confiance.
b) Correction, fiabilité, robustesse. Autrement dit un système qui fait tout pour amener la
fusée à sa bonne destination.
c) Correction, fiabilité, réutilisation, interopérabilité. Autrement dit un système efficient et
facile à industrialiser.
Exercice 1.4.
Dans une tâche non partitionnable l’augmentation du nombre d’hommes reste sans effet.
Dans une tâche partitionnable ne nécessitant pas de communication, l’augmentation du
nombre d’hommes diminue la durée, qui tend asymptotiquement vers 0.
Dans une tâche partitionnable nécessitant des communications, l’effort de communication
doit être ajouté à la quantité de travail à faire. Dans le cas d’interrelations complexes cet
effort de communication peut compenser complètement ou même dépasser le gain réalisé en
partageant la tâche.
Si chaque participant doit se coordonner avec chaque autre participant l’effort de commu-
nication ec croit comme n(n − 1)/2 où n est le nombre de participants (n = 2, ec = 1 ;
n = 3, ec = 3 ; n = 4, ec = 6 ; n = 5, ec = 10 ; n = 6, ec = 15 ; n = 7, ec = 21, etc.)
Exercice 2.1.
Les négociations sont utiles en cas de divergence de points de vue (ex. : marketing contre
techniciens, clients contre informaticiens) ou de divergence sur les priorités. L’analyse des
risques associés aux besoins est souvent une technique utile.
Exercice 2.2.
a) Exemples de besoins fonctionnels (certains sont structurés avec des sous-besoins plus
spécifiques et moins abstraits) :
F1 : Le programme doit prendre en compte tout appel externe.
F2 : Le programme doit prendre en compte tout appel interne (sélection d’un étage depuis
l’intérieur de la cabine).
F3 : Le programme doit planifier les activités de l’ascenseur de façon raisonnable.
F3.1 : Si l’ascenseur ne contient pas de passager, il doit demeurer au rez-de-chaussée en
attendant la prochaine requête.
F3.2 : L’ascenseur ne doit pas modifier le sens de son déplacement s’il contient des
passagers qui n’ont pas encore atteint leur destination.
F4 : Le programme doit prendre en compte tout dysfonctionnement.
F4.1 : Il doit détecter et signaler tout dysfonctionnement.
Corrigés des exercices 257
F4.2 : Il doit prendre la décision qui s’impose (arrêter l’ascenseur, bloquer l’ouverture
ou la fermeture des portes, etc.).
F5 : Le programme doit être apte à gérer plusieurs ascenseurs.
b) Exemples de besoins non fonctionnels :

C1 : Chaque appel doit être traité dans un temps raisonnable.
C2 : Il n’y a jamais plus d’une porte palière ouverte à la fois.
C3 : Toutes les portes palière doivent être fermées pendant un déplacement.
Exercice 2.3.
a) Non.
Dupont : 10-5/3 Résultats possibles : 8,33 ou 8 ou 8,5 ou 8,333333
Dutif : 4-16/3 Résultats possibles : -1,33 ou 0 ou -1,5 ou -1,333333
Duduche : 10-3/3+ ? Résultats possibles : 12 ou 8 ou 9
selon les arrondis et la manière de compter les doubles réponses comme justes, fausses ou
pas prises en compte.
b) Une rédaction possible : « l’examen est un ensemble de 20 questions à réponses multiples.
Chaque bonne réponse à une question rapporte 1 point. Chaque mauvaise réponse fait perdre
1/3 de point. Chaque question sans réponse ou avec des réponses multiples donne 0 point. La
note est arrondie au demi-point le plus proche ou au demi-point supérieur en cas d’égalité.
La note minimum est 0 ».
Avec cette spécification non ambiguë, Dupont obtient 8,5, Dutif 0 et Duduche 9.
Exercice 2.4.
La solution de Myers [Mye79] est la suivante. Chaque oui à une question donne un point. À
noter que les programmeurs professionnels obtiennent en moyenne entre 7 et 8.
(1) Présence d’un cas de test pour un triangle équilatéral ?
(2) Présence d’un cas de test pour un triangle isocèle (un vrai, pas (2, 2, 4) qui n’est pas un
triangle) ?
(3) Présence d’un cas de test pour un triangle scalène (un vrai) ?
(4) Présence de cas de test pour les permutations possibles d’un triangle isocèle (ex. : (3, 3,
4), (3, 4, 3), (4, 3, 3)) ?
(5) Présence d’un cas de test avec un côté à 0 ?
(6) Présence du cas de test (0, 0, 0) ?
(7) Présence d’un cas de test avec une valeur négative ?
(8) Présence d’un cas de test avec un côté égal à la somme des deux autres (ex. : (1, 2, 3)) ?
(9) Présence de cas de test pour les permutations possibles du cas précédent (ex. : (1, 2, 3),
(1, 3, 2), (3, 1, 2) . . . ) ?
(10) Présence d’un cas de test où la somme des deux plus petits côtés est inférieure au
troisième (ex. : (2, 3, 6)) ?
(11) Présence de cas de test pour les permutations possibles du cas précédent (ex. : (2, 3, 6),
(2, 6, 3), (3, 2, 6) . . . ) ?
(12) Présence d’un cas de test avec des valeurs non entières ?
(13) Présence d’un cas de test avec une valeur entière trop grande (> maxint) ?
(14) Présence d’un cas de test avec un nombre incorrect de données (ex. : 2 ou 4) ?
(15) Présence de la réponse attendue pour tous les cas de test ?
Exercice 2.5.
Les buts Autoriser les emprunts de longue durée et Assurer une
disponibilité suffisante sont en conflit.
Exercice 2.6.
a) 1. Variable f non initialisée.
2. Tour de boucle en trop.
3. Opération sur un mauvais indice (décrémentation mal placée).
4. Retour d’une mauvaise variable.
Version corrigée :
int factorielle(int n) {
int f = 1;
while (n > 0) {
f = f*n;
n = n-1;
}
return f;
}
b) 1. L’indice doit commencer à 0.

2. Indice hors borne (<).
3. Test par = au lieu de ==.
4. Rattachement ambigu du else (dangling else).
5. Accolades manquantes pour le dernier else.
Version corrigée :
int indicePremierElementNul(int[] tab){
int i;
if (tab.length > 0) {
for(i=0; i < tab.length; i++)
if (tab[i] == 0) return i;
} else {
System.out.println("tab est vide");
return -2;
}
return -1;
}
Exercice 2.7.
a) A et H sont au niveau 0, B, C, I et J au niveau 1, D, E et K au niveau 2, L et F au niveau 3
et G au niveau 4.
Après optimisation des tâches fictives on parvient au graphe PERT suivant :
b) Dates au plus tôt : t0 = 0, t1 = 0 + 3 = 3, t2 = 0 + 5 = 5, t3 = 3 + 1 = 4,

t4 = 5 + 8 = 13, t5 = max(4 + 6, 3 + 5, 13 + 0) = 13, t6 = max(4 + 4, 13 + 2) = 15,
t7 = max(5 + 2, 13 + 3) = 16, t8 = max(15 + 9, 16 + 7) = 24.
Dates au plus tard : T8 = 24, T7 = 24 − 7 = 17, T6 = 24 − 9 = 15, T5 = 15 − 2 = 13,
T4 = min(17−3, 13−0) = 13, T3 = min(13−6, 15−4) = 7, T2 = min(17−2, 13−8) = 5,
T1 = min(13 − 5, 7 − 1) = 6, T0 = min(6 − 3, 5 − 5) = 0.
Marges totales :
Tâche Marge totale Tâche Marge totale

A M T01 = 6 − 0 − 3 = 3 G M T68 = 24 − 15 − 9 = 0
B M T13 = 7 − 3 − 1 = 3 H M T02 = 5 − 0 − 5 = 0
C M T15 = 13 − 3 − 5 = 5 I M T24 = 13 − 5 − 8 = 0
D M T35 = 13 − 4 − 6 = 3 J M T27 = 17 − 5 − 2 = 10
E M T36 = 15 − 4 − 4 = 7 K M T47 = 17 − 13 − 3 = 1
F M T56 = 15 − 13 − 2 = 0 L M T78 = 24 − 16 − 7 = 1
Chemin critique : il est représenté en traits gras sur la figure ci-dessus.
Exercice 3.1.
(1) Agrégation (6) Association
(2) Association (7) Généralisation/spécialisation
(3) Généralisation/spécialisation (8) Agrégation
Exercice 3.2.
a) Graphe non orienté
b) Graphe orienté
Un commentaire exprime une contrainte d’intégrité non modélisable graphiquement. Le

langage OCL (Object Constraint Language) aurait pu également être utilisé.
Exercice 3.3.
Exercice 3.4.
Le diagramme d’activités de la réparation d’un véhicule est donné par l’image de gauche
ci-après. À noter que les acteurs sont représentés par des paquets (packages) alors que la
représentation habituelle utilise plutôt des couloirs (swimlanes).
Exercice 3.5.
Le diagramme des séquences du carnet d’adresses est donné par l’image de droite ci-après.
Exercice 4.1.
a) Le prototypage qui permet de se rendre compte concrètement et rapidement des services
envisagés et des limites de la future application est à privilégier dans ce cas.
b) La cascade ou sa variante en V sont à privilégier car les risques sont faibles grâce à la bonne
connaissance du domaine et à l’expérience de l’équipe de développement. Une planification
du processus est importante pour ce genre de gros projet et ces approches permettent cette
planification.
Exercice 4.2.
– Cascade et V : projet classique, de grande taille.
– Incrémental : projet classique, de petite ou moyenne taille.
– Spirale : projet critique (gestion des risques), de grande taille.
– Prototypage : projet mal défini.
– Agile : projet innovant, de petite ou moyenne taille.
Exercice 4.3.
La communication avec les clients et utilisateurs est fondamentale au niveau du recueil des
besoins. La communication au sein de l’équipe de développement est fondamentale tout au
long du processus.
La planification du déroulement du projet est indispensable. Elle peut être réalisée a priori
comme dans les approches prescriptives (dès que les besoins sont connus) ou de manière
souple et progressive comme dans les approches agiles (avant chaque itération).
La modélisation est une composante essentielle pour comprendre le problème (analyse des
besoins) et produire une solution qui satisfasse ces besoins (conception).
La construction recouvre la génération du code et le test, lors de la phase d’implantation.
Le déploiement de toute l’application ou d’une livraison partielle permet aux clients et
utilisateurs de retourner leur feedback après validation.
Exercice 5.1.
Caractéristique (R)UP XP Scrum

Itérative et incrémentale + + ++
Centrée sur l’architecture ++
Centrée sur les tests ++ +
Centrée sur l’interaction client – développeur ++ +
Centrée sur la qualité du code ++ +
Convient aux grosses équipes ++ +
Convient aux petites équipes ++ +
Centrée sur les cas d’utilisation ++
Convient aux gros projets ++ +
Considère la gestion du risque + + ++
Exercice 5.2.
Q1. Quel rôle est responsable de la définition des priorités au sein du product backlog ?
a) Product Owner
Q2. Quel rôle n’est pas défini dans Scrum ?
c) Product Manager
Q3. Quel document n’est pas un artefact Scrum ?

b) User story
Q4. Quel type de réunion ne fait pas partie de Scrum ?
a) Product review meeting
Q5. Quel est le nom de la réunion dans laquelle l’équipe démontre au Product owner et aux
autres personnes intéressées ce qui a été accompli durant le sprint ?
c) Sprint review meeting
Q6. Quand l’exécution d’un sprint est-elle finie ?
d) À la fin de la durée prévue (timebox)
Q7. Quelle est la durée normale du Daily Scrum meeting ?
a) 15 minutes (pour 5 personnes, soit 3 minutes de parole pour chacun).
Q8. Quelle est la taille recommandée pour une équipe Scrum ?
c) 7 ± 2
Q9. Comment le product backlog est organisé ?
a) Items par importance décroissante
Q10. Qui estime l’effort nécessaire pour réaliser un item du product backlog ?
c) Team
Exercice 5.3.
Un cas conforme au déroulement normal.
Un cas conforme à la variante 1 (règlement immédiat).
Un cas conforme à la variante 2 (réservation avec prestation optionnelle).
Un cas conforme à la variante 3 (voyageur sur la liste noire).
Quatre cas conformes à des combinaisons de variantes (1 et 2, 1 et 3, 2 et 3, 1 et 2 et 3).
Un cas qui viole la précondition 1 (une étape de vol erronée).
Un cas qui viole la précondition 2 (pas de place dans la classe souhaitée sur une étape de vol).
Un cas qui viole la précondition 3 (une contrainte de réservation ou de séjour non satisfaite).
Exercice 5.4.
Un tableau d’entiers non redondant : [4, 7, 2, 8] donne [2, 4, 7, 8].
Un tableau vide : [] donne [].
Un tableau avec une valeur redondante dans différentes positions :
[4, 7, 2, 7] donne [2, 4, 7] (pas en premier)
[7, 4, 7, 2] donne [2, 4, 7] (en premier)
[4, 2, 7, 7] donne [2, 4, 7] (groupées en fin)
[7, 7, 4, 2] donne [2, 4, 7] (groupées en début).
Un tableau avec uniquement des valeurs redondantes : [4, 4, 4] donne [4].
Un tableau avec une seule valeur : [5] donne [5].
Un tableau avec des valeurs nulles : [2, 0, 4, 0] donne [0, 2, 4].
Un tableau avec des valeurs négatives : [−2, 7, −1, 6] donne [−2, −1, 6, 7].
Un tableau avec plusieurs groupes de valeurs redondantes : [2, 3, 2, 3, 4] donne [2, 3, 4].
Un tableau déjà trié : [5, 6, 8] donne [5, 6, 8].
Exercice 5.5.
Le premier test correspond à n = 1. On rappelle que 0 et 1 ne sont pas premiers.
@Test
System.out.println("est premier de 0");
boolean resultat = Premier.estPremier(0);
assertEquals("resultat", false, resultat);
}
Ce code ne compile pas car le code de la méthode estPremier n’est pas écrit.
Pour le faire compiler on peut se contenter dans un premier temps d’écrire :
public static boolean estPremier(int n) {
if (n == 0) return false;
else return true;
}
Le test passe.
On ajoute un deuxième test pour 1.
@Test
}
Le deuxième test ne passe pas. On peut modifier la méthode estPremier a minima par :
if (n <= 1) return false;
else return true;
}
Les deux tests passent.
On ajoute un troisième test pour n = 2.
@Test
assertEquals("resultat", true, resultat);
}
Les trois tests passent.
On ajoute un quatrième test pour n = 3.
@Test
}
Les quatre tests passent.

On ajoute un cinquième test pour n = 4.
@Test
}
Le cinquième test ne passe pas. En effet 4 est divisible par un des entiers qui précèdent.
On peut modifier la méthode estPremier comme suit :
if (n == 2) return true;
for (int candidat = 2; candidat < n; candidat++) {
if (n % candidat == 0) return false;
}
return true;
}
Les cinq tests passent.
On ajoute un sixième test pout n = 5.
@Test
}
Les six tests passent.
On ajoute un septième test pour n = 6.
@Test
}
Les sept tests passent. On se rend compte au passage que le seul nombre pair qui est
premier est 2. On peut remanier le code en éliminant tous les nombres pairs au début et en
incrémentant candidat seulement pour les entiers impairs :
if (n % 2 == 0) return (n == 2);
for (int candidat = 3; candidat < n; candidat=candidat+2) {
}
return true;
}
Les sept tests passent toujours. On se rend compte aussi qu’il est inutile d’incrémenter
candidat jusqu’à n. Il suffit d’atteindre la racine carrée de n autrement dit que
candidat*candidat <= n :
if (n % 2 == 0) return (n == 2);
for (int candidat = 3; candidat*candidat <= n; candidat=candidat+2) {
}
return true;
}
Les sept tests passent toujours.
On ajoute pour terminer deux tests pour n = 13 et n = 15.
@Test
}
@Test
}
Tous les tests passent. On peut être raisonnablement confiant dans cette solution.
Exercice 6.1.
Un Business Use Case (cas métier) est un stéréotype de cas d’utilisation UML (une notation
spécialisée).
Chaque cas métier est caractérisé par une catégorie dont les valeurs sont prises dans une
énumération Process Category avec trois valeurs possibles : core (processus cœur de métier),
support (processus annexe de support technique), management (processus annexe de gestion).
Les autres caractéristiques sont : une description du workflow (du processus métier), une
description des risques (liés à son implantation et/ou son exécution), une description des
possibilités offertes (de l’intérêt du cas), une description des special requirements (autres
exigences ou caractéristiques).
Exercice 6.2.
a) On utilise fréquemment un arbre de décomposition indiquant que tel but assez général
dépend de la satisfaction de tels sous-buts plus précis.
La relation classique de dépendance est utilisable pour spécifier cette décomposition.

b) Un cas métier (Business Use Case) « supporte », c’est-à-dire contribue à satisfaire, un
certain but.
Exercice 6.3.
Un cas métier correspond à un service significatif pour un ensemble de participants. Un cas
d’utilisation correspond à une interaction d’un acteur principal avec le système.
En général, un service significatif met en jeu plusieurs acteurs internes et externes et chacun
d’eux est susceptible d’être l’acteur principal d’une ou plusieurs interactions et donc d’un ou
plusieurs cas d’utilisation.
On peut dire que les cas métiers définissent le contexte dans lequel un ensemble de cas
d’utilisation s’inscrivent pour rendre un service significatif aux utilisateurs.
Exercice 7.1.
a) Le diagramme des cas métier est donné page suivante.
Remarque
On pourrait aussi définir deux cas métier Ramener véhicule et Réglement immédiat
avec une relation « extend » du deuxième vers le premier.
b) Spécification du cas métier Ramener et régler.
Titre : Ramener et régler

Description : Prise en compte d’un retour de véhicule.
Buts :
– Rendre le service rapidement.
– Inciter au règlement immédiat.

Scénario nominal :
1. Accueil du client par l’employé d’agence.
2. Examen du véhicule avec la fiche d’état.
3. Relevé du kilométrage.
4. Facturation.
5. Règlement et rendu de la caution.
Extensions :
1.1. Client non connu par l’agence.
1.2. Chercher l’agence concernée et demander un fax de la fiche d’état.
1.3. Poursuivre la réception normalement.
2.1. Défauts supplémentaires ajoutés à la fiche d’état.
2.2. Évaluation des frais de remise en état.
5.1. Pas de règlement immédiat ni de rendu de la caution.
Propriétés :
1. Préconditions :
– L’agence fonctionne normalement.
– Tous les rôles sont assurés.

– Le client est connu par la société.
2. Postconditions :
– Le véhicule est restitué.
– Le règlement est effectué ou prévu dans les 8 jours.
Exercice 7.2.
Exercice 7.3.
Exercice 7.4.
Exercice 7.5.
Exercice 8.1.
Les noms considérés comme les plus significatifs sont soulignés à leur première apparition.
Les autres noms sont écartés car trop généraux ou redondants.
La société LocAuto loue des voitures et des camionnettes. Le prix de la location est composé
d’un forfait journalier et d’un supplément kilométrique au-delà de 200 km parcourus par jour
de location. La location se fait par journée (nb) sur une ou plusieurs journées consécutives
avec départ et retour à l’agence. Le forfait journalier tient compte de la catégorie (véhicule
léger économique ou véhicule léger luxe ou camionnette) du véhicule et de la période
(semaine, week-end, vacances été). Le supplément kilométrique est fonction de la catégorie
du véhicule. L’âge du conducteur et le nombre d’années depuis l’obtention du permis
influent aussi sur le calcul du prix de la location. Ce prix inclut l’assurance du véhicule et du
conducteur tous deux fonction de la catégorie du véhicule. C’est en fonction de son type
(marque et modèle) qu’un véhicule est affecté à une catégorie.
Lors de la réservation (par téléphone, mail ou visite à l’agence), le client précise à l’employé
d’agence les caractéristiques de sa demande : son nom, adresse et âge, la date d’obtention
de son permis, la date et la durée de la location, la catégorie de véhicule demandée. Il reçoit
une réponse positive ou négative selon les disponibilités à la date indiquée. Un véhicule est
immédiatement réservé. L’employé prépare le contrat de location avant la date prévue pour
l’emprunt du véhicule.
Lors de l’emprunt du véhicule à l’agence le client doit montrer son permis de conduire à
l’employé, signer le contrat de location et déposer une caution (montant) qui dépend de la
catégorie du véhicule. Une fiche indiquant l’état du véhicule lui est soumise. Le client indique
les défauts supplémentaires qu’il constate (ou leur absence) afin de mettre à jour la fiche d’état
qui reste stockée à l’agence. Le kilométrage au départ est relevé.
Lorsque le client ramène le véhicule à l’agence, l’employé compare son état en sa
présence avec la fiche d’état. Les éventuels défauts supplémentaires sont ajoutés sur la
fiche d’état et des frais de remise en état sont évalués. Le kilométrage à l’arrivée est relevé
par l’employé d’agence. La facture incluant la location et les frais de remise en état est
rédigée. Normalement le client la règle immédiatement et la caution lui est rendue. En cas
de non-règlement dans un délai maximum de 8 jours la caution est conservée et le dossier

est transmis au contentieux. Si le client provient d’une autre agence, la réception se fait avec
une copie de la fiche d’état qui est faxée par l’agence concernée.
Périodiquement, le mécanicien de l’agence prend la fiche d’état de chaque véhicule et répare
un maximum de défauts. Il rédige une nouvelle fiche d’état du véhicule.
Sont retenus comme classes, en tant que concepts significatifs porteurs d’informations :
Réservation, Catégorie, Période, Véhicule, Location, Défaut, Client,
Facture, Règlement. Les autres éléments constituent des attributs à ventiler sur ces
classes ou éventuellement sur des associations (comme forfaitJournalier qui dépend
à la fois de la catégorie et de la période).
Exercice 8.2.
Les noms considérés comme les plus significatifs sont soulignés à leur première apparition.
Les autres noms sont écartés car trop généraux ou redondants.
Sont retenus comme classes, en tant que concepts significatifs porteurs d’informations :
Captage, Mois, Réservoir, Analyse, Substance, Technicien. Les autres
éléments constituent des attributs à ventiler sur ces classes.
L’eau provient de captages par forage dans les nappes souterraines. Chaque captage est
caractérisé par un nom, un débit maximum exprimé en m3 d’eau par heure, une profondeur et
un diamètre du forage. Pour chaque captage, on conserve le débit moyen calculé pour chaque
mois de l’année, ce qui permet de prévoir les éventuels problèmes d’alimentation en eau.
Chaque captage alimente grâce à des pompes automatiques un ou des réservoirs (châteaux
d’eau) dont la fonction est le stockage de l’eau à distribuer. Chaque réservoir a un nom et
une capacité maximale. Pour garantir la continuité du service de distribution d’eau potable,
chaque réservoir est relié, en plus de son captage principal, à un ou plusieurs captages de
secours pour le cas où le captage principal soit interrompu. La mise en service de la connexion
d’un réservoir à l’un de ses captages de secours est sous la responsabilité d’un technicien, dont
il faut connaître le nom et le numéro de téléphone portable.
La production d’eau est soumise à des normes de qualité exigeantes. Le syndicat de
communes effectue fréquemment des analyses de l’eau en collaboration avec un laboratoire
indépendant. Ces analyses sont réalisées soit au niveau des captages, soit au niveau des
réservoirs. Deux critères de qualité biologiques sont impératifs : on ne tolère la présence
d’aucune bactérie de type Escherichia Coli ni d’aucun entérocoque dans l’eau. En ce qui
concerne les substances chimiques et les métaux (arsenic, cadmium, cyanure, mercure,
plomb, etc.), la réglementation fixe pour chacun d’entre eux une concentration maximale à
ne pas dépasser exprimée en microgramme par litre. Il est imposé de conserver les résultats
obtenus à chaque analyse.
Exercice 8.3.
Exercice 9.1.
a) context : Emprunt
inv : bien.personne = personne
b) context : Emprunt
inv : dateDébut < dateFin
c) context : Personne
inv : Personne.allInstances->forAll(p1, p2 | p1 <> p2
implies p1.id <> p2.id)
d) Il faut ajouter une méthode calculerMensualité(somme : Real) qui calcule la

mensualité du nouvel emprunt.
context : Personne :: emprunter(somme : Real, achat : Bien)
pre : self.salaire * 3 >= self.emprunt.mensualité -> sum() +
calculerMensualité(somme)
Exercice 9.2.
a) context Employé
inv: self.chef->notEmpty() implies self.age() < self.chef.age()
b) context Employé
inv: self.chef->notEmpty() implies self.salaire < self.chef.salaire
c) context Employé
inv: self.dateEmbauche > self.dateNaissance
d) context Employé
inv: self.gère->notEmpty() implies self.gère.dateDébut >
self.dateEmbauche
e) context Department
inv: self.travaille_dans->includes(self.gère)
f) context Employé
inv: self.travaille_pour.héberge->includesAll(self.travaille_dans)
g) context Employee
inv: let totalHeures : Integer =
self.travaille_dans->collect(heures)->sum() in totalHeures >= 30
and totalHeures <=50
h) context Employé
inv: self.subordonnés->excludes(self)
Exercice 10.1.
a) En tant qu’utilisateur je veux pouvoir maîtriser rapidement l’application.
Non testable sous cette forme (signification de rapidement ?).
b) En tant qu’utilisateur je veux pouvoir éditer mon adresse sur mon CV.
Granularité trop faible (revient à écrire une story par champ modifiable !).
c) En tant qu’administrateur je veux pouvoir accéder au log de toutes les erreurs à l’exécution
afin de pouvoir déboguer l’application.
Correct.
d) En tant qu’utilisateur je veux pouvoir annuler jusqu’à 50 actions.
Correct.
e) En tant que développeur je veux utiliser Log4J afin de gérer les logs.
Ni un besoin ni une contrainte, plutôt un choix technique.
f) En tant qu’utilisateur je veux pouvoir exporter mes données en XML.
Correct.
Exercice 10.2.
a) En tant que client je veux pouvoir ajouter des produits dans mon panier.
En tant que client je veux pouvoir supprimer des produits dans mon panier.
En tant que client je veux pouvoir modifier les quantités dans mon panier.
En tant que client je veux pouvoir valider la commande des articles dans mon panier.
En tant que client je veux pouvoir spécifier les modalités de livraison de ma commande.
En tant que client je veux pouvoir régler ma commande ce qui déclenche sa livraison.
b) En tant qu’internaute je veux pouvoir créer un compte client afin de pouvoir me loguer.
En tant que client je veux pouvoir me loguer afin d’accéder aux pages sécurisées.
En tant que client je veux pouvoir modifier mon compte client.
En tant que client je veux pouvoir supprimer mon compte client.
En tant que client je veux pouvoir changer de mot de passe si je l’ai oublié.
c) En tant que gérant de boutique en ligne je veux pouvoir ajouter des produits au catalogue.
En tant que gérant de boutique en ligne je veux pouvoir supprimer des produits du catalogue.
En tant que gérant de boutique en ligne je veux pouvoir mettre à jour les produits du
catalogue en particulier les prix et les descriptions.
Exercice 10.3. BDD

Étant donné que mon compte courant est créditeur de 900 e et mon compte épargne est
créditeur de 500 e et que je vire 300 e de mon compte courant vers mon compte épargne
alors mon compte courant est créditeur de 600 e et mon compte épargne est créditeur de
800 e.
créditeur de 500 e et que je vire 300 e de mon compte épargne vers mon compte courant
alors mon compte courant est créditeur de 1200 e et mon compte épargne est créditeur de
200 e.
alors le virement est refusé pour défaut de provision.
alors le virement est refusé pour défaut de provision.
alors mon compte courant est créditeur de 0 e et mon compte épargne est créditeur de 700 e.
alors mon compte courant est créditeur de 700 e et mon compte épargne est créditeur de 0 e.
Exercice 10.4. Epic

La décomposition peut se faire selon les opérations CRUD (créer-lire-modifier-supprimer) et
par raffinement des fonctionnalités.
En tant que demandeur d’emploi je veux pouvoir créer un agent automatique de recherche
d’offres d’emploi.
En tant que demandeur d’emploi je veux pouvoir modifier les paramètres de recherche d’un
agent automatique de recherche d’offres d’emploi.
En tant que demandeur d’emploi je veux pouvoir modifier l’heure et la périodicité de

déclenchement d’un agent automatique de recherche d’offres d’emploi.
En tant que demandeur d’emploi je veux pouvoir modifier la manière dont les résultats d’un
agent automatique de recherche d’offres d’emploi me sont transmis.
En tant que demandeur d’emploi je veux pouvoir supprimer un agent automatique de
recherche d’offres d’emploi.
Exercice 11.1. Application web Cyber-cartes
Nom : S’inscrire
Description : Création et enregistrement d’un compte client.
Acteur principal : Internaute
Préconditions : Se trouver sur la page d’accueil.
Postconditions : Le compte client est créé, non validé et donc pas encore utilisable.
1. Remplir le formulaire.
2. Valider le formulaire.
Variantes :
2.1. Saisie refusée.
Contraintes : Sécurisation de la transmission et du stockage des données personnelles.
Nom : Se connecter
Description : Authentification d’un client.
Préconditions :
– Posséder un compte validé.
– Se trouver sur la page d’accueil.
Postconditions : Les actions réservées aux clients sont disponibles.
2. Valider le formulaire.
Variante :
2.1. Saisie refusée.
Contraintes : Sécurisation de la transmission des données personnelles.
Nom : Se déconnecter
Description : Retour au rôle de simple internaute visiteur.

Préconditions :
– Être connecté.
Postconditions : Les actions réservées aux clients sont indisponibles.
1. Appuyer sur le bouton de déconnexion.
Variantes : –
Contraintes : –
Nom : Valider un compte

Description : Validation d’un compte créé et non encore validé.
Préconditions :
– Se trouver sur la page d’administration.
– Avoir sélectionné un compte non validé sur la liste des comptes en attente.
Postconditions : Le compte est validé.
1. Appuyer sur le bouton de validation.
Variantes : –
Contraintes : –
Nom : Créer une carte

Description : Création d’une carte par un client.
Préconditions :
Postconditions : Les actions réservées aux clients sont indisponibles.
1. Choisir l’action créer une carte.
3. Valider la création.
Variantes :
2.1. Annulation.
3.1. Erreur de saisie.
Contraintes : –
Nom : Ajouter une image

Description : Ajout facultatif d’une image à une carte.
Préconditions :
– Se trouver sur la page de création d’une carte.
Postconditions : L’image est ajoutée.
1. Choisir l’action ajouter une image.
2. Sélectionner l’image parmi celles proposées.
3. Valider l’ajout.
Variantes :
2.1. Annulation.
3.1. Image déjà ajoutée (valider le changement).
Contraintes : –
Nom : Ajouter une musique

Description : Ajout facultatif d’une musique à une carte.
Préconditions :
Postconditions : La musique est ajoutée.
1. Choisir l’action ajouter une musique.
2. Sélectionner la musique parmi celles proposées.
3. Valider l’ajout.
Variantes :
2.1. Annulation.
3.1. Musique déjà ajoutée (valider le changement).
Contraintes : –
Nom : Expédier une carte

Description : Envoi de la carte.
Préconditions :
Postconditions : La carte est envoyée.
1. Choisir l’action envoyer la carte.
Variante :
1.1. Erreur de transmission.
Contraintes : –
Le diagramme des cas :
Remarque : On pourrait aussi faire dériver Administrateur de Client avec comme

seul cas spécifique pour Administrateur la validation des comptes.
Exercice 11.2. Application documentaire

a) Acteurs : Personnel, MOE, Annuaire LDAP.
Cas : Consulter, Rechercher, Lire, Imprimer, Authentification légère,

Mettre à jour, Ajouter, Authentification approfondie, Retirer,
Modifier, Enregistrer les accès.
b) Diagramme des cas :
Exercice 11.3. Authentification
Le diagramme distingue les internautes des clients autorisés et montre :

– que la confirmation n’est possible qu’en complément d’un enregistrement,
– que l’oubli de mot de passe est une fonctionnalité utilisable soit directement soit comme
une extension facultative de l’action se loguer.
Exercice 12.1. Démineur
Exercice 12.2. DSS d’une commande web

Exercice 12.3. Diagramme d’activités d’une commande web

Exercice 13.1. Classes d’analyse d’une commande web
Exercice 13.2. Les variantes :

3.1 : ajouter une méthode annulerCommande() à la classe ContrôleurCommande.
4.1 : ajouter un attribut sélectionPaiementDifféré à la classe Page Règlement.
4.2 : ajouter un dialogue ConfirmationRèglementDifféré avec la méthode
afficher() et une méthode afficherConfirmationRèglement Différé() à
la classe ContrôleurCommande.
4.3 : ajouter un paramètre état à la méthode enregistrer Commande().
Exercice 13.3
L’IHM de la recherche d’ouvrages inclut une page pour la recherche simple par mots clés et
une pour la recherche avancée par critères. Après validation des paramètres par l’internaute,
rechercher() appelle chercherLivres() de ContrôleurRecherche. Grâce
à getLivres() de Catalogue une liste de livres est retournée et affichée par le
contrôleur dans la page RésultatRecherche. L’internaute peut la parcourir, la

trier, demander le détail d’un livre et ajouter un livre au panier (cf. les méthodes de
RésultatRecherche). afficherDétailLivre() appelle getInfoLivre() de
ContrôleurFiche Détail. Ce détail obtenu dans Livre est affiché par le contrôleur
dans la page FicheDétail.
Exercice 14.1. Diagramme de séquences de la recherche de livre.
Exercice 14.2. Diagramme d’états du panier d’achats.

Exercice 14.3. Diagramme de séquences d’une commande web.

Exercice 15.1.
Navigation dans une application de gestion de contacts.
Exercice 15.2.
Modèle de navigation sous la forme d’un diagramme d’états.
Exercice 16.1.
On peut discerner deux risques principaux pour ce cas :
– sa complexité, grossièrement évaluable par le nombre élevé de pages à développer,
– le fait d’intégrer l’utilisation d’un service externe pour le règlement. La recherche d’un tel
service, son évaluation, et son intégration au sein de l’application via l’API offerte, peut
être source de difficultés particulières.
Exercice 16.2.
On peut esquisser cette page de la manière suivante :
Exercice 17.1.
Nom : Se connecter
Description : Un internaute peut se connecter afin de prendre le rôle de Client qui
permet de passer des commandes, créer des listes de cadeaux et donner des avis et
commentaires.
Acteur principal : Internaute
Préconditions :
– Ne pas être déjà connecté.
Postconditions :
– L’internaute prend le rôle de Client.
– Les fonctionnalités réservées aux clients apparaissent sur la page d’accueil.
1. L’internaute saisit login et mot de passe et appuie sur le bouton « Connexion ».
2. L’application met à jour la page d’accueil avec les fonctionnalités supplémentaires
offertes aux clients.
Variantes :
1. Si la connexion échoue un message apparaît. Les informations doivent être ressaisies.
Autres cas liés :
Autres remarques :
– En cas d’oubli du mot de passe, en appuyant sur le bouton « Mot de passe oublié »,
une page apparaît avec une question secrète dont il faut donner la bonne réponse pour
pouvoir saisir un nouveau mot de passe.
Nom : S’enregistrer
Description : Un internaute (ou un client qui a oublié une précédente inscription sur le
site) peut s’enregistrer comme Client qui peut passer des commandes, créer des listes
de cadeaux et donner des avis et commentaires.
Préconditions :
– Ne pas être déjà connecté.
Postconditions :
– Un nouveau Client est enregistré.
– Les fonctionnalités réservées aux clients apparaissent sur la page d’accueil.
1. L’internaute appuie sur le bouton « s’enregistrer ».
2. L’application affiche une page demandant de manière obligatoire nom, prénom, mail,
login, mot de passe, réponse à la question secrète et de manière facultative adresse, âge
et numéro de téléphone.
3. L’internaute saisit les données et appuie sur le bouton « Enregistrer ».
4. L’application réaffiche la page d’accueil avec un message demandant de se connecter.
Variantes :
1. Message d’erreur et retour à la page d’enregistrement si des erreurs ou oublis sont
détectés après enregistrement.
Autres cas liés : Maintenir le site (nettoyer le fichier clients).
Autres remarques :
Nom : Consulter ses commandes

Description : L’historique des commandes passées (livrées ou en cours de livraison) est
accessible aux clients.

Préconditions :
Postconditions :
– Le listage de toutes les commandes est affiché.
1. Le client appuie sur le bouton « Mes commandes » de la page d’accueil.
2. L’application affiche la page de l’historique des commandes triée de la plus récente à
la plus ancienne.
Variantes :
Autres cas liés :
Autres remarques :
Nom : Créer une liste de cadeaux

Description : Création d’une liste d’ouvrages souhaités en cadeau avec une liste d’amis
susceptibles de les acheter qui seront prévenus par mail avec un code personnalisé pour
se connecter.
Acteurs secondaires : Ami
Préconditions :
Postconditions :
– La liste est enregistrée.
– Les amis sont prévenus et reçoivent leur code personnalisé.
1. Le client appuie sur le bouton « Créer une liste de cadeaux » sur la page d’accueil.
2. L’application affiche les directives à suivre qui demandent de remplir en premier le
panier avec les cadeaux souhaités et de revenir à cette page.
3. Le client remplit son panier.
4. Le client revient à la page de création pour saisir la description de l’événement fêté
qui sera repris dans le mail aux amis et la liste des amis : nom, prénom, mail.
5. Le client appuie sur le bouton « Créer la liste à partir du panier ».
6. L’application crée la liste, envoie les mails aux amis et confirme au client la création
de la liste.
Variantes :
1. Si le panier est vide la création de la liste échoue.
2. Si la liste des amis est vide la création de la liste échoue.
Autres cas liés :
Autres remarques :
– Les adresses mail des amis doivent être correctes.
Nom : Proposer un avis

Description : Choisir une appréciation sur un ouvrage (note).
Préconditions :
– Se trouver sur la page de description de l’ouvrage.
Postconditions :
– Le score moyen de l’ouvrage est mis à jour ainsi que le nombre d’avis.
1. Le client règle la note sur la valeur souhaitée et appuie sur le bouton « Enregistrer
votre avis ».
2. L’application met à jour l’avis moyen et le nombre d’avis.
Variantes :
Autres cas liés :
Autres remarques :
– La note est limitée à l’intervalle [0-5].
– Un client ne doit pouvoir donner un avis qu’une seule fois sur un ouvrage, ce qui
implique de garder l’historique de tous ses avis.
Nom : Proposer un commentaire

Description : Proposer un texte de commentaire (moins de 500 caractères).
Préconditions :
– Se trouver sur la page de description de l’ouvrage.
– N’avoir pas déjà commenté cet ouvrage.
Postconditions :
– Le commentaire est stocké dans la base, avec un date et un état « à vérifier ». Un
Éditeur devra la valider avant parution sur le site à l’état « vérifié ».
1. Le client appuie sur le bouton « Votre commentaire » sur la page d’un ouvrage.
2. Le client saisit un texte dans la zone de saisie qui apparaît et appuie sur le bouton
« Soumettre pour validation ».
3. L’application stocke le commentaire en attente de validation par un Éditeur.
Variantes :
1. L’opération échoue si le texte est vide.
Autres cas liés :
Examiner les commentaires en attente de validation
Autres remarques :
Nom : Consulter une liste de cadeaux

Description : Consultation d’une liste de cadeau pour laquelle on a été averti par un mail
comportant un code d’accès personnalisé.
Acteur principal : Ami
Préconditions :
– Se trouver sur la page d’accueil (connecté ou non).
– Avoir en sa possession le code d’accès personnalisé.
Postconditions :
– La liste des cadeaux non encore achetés est affichée.
1. L’ami appuie sur le bouton « Accéder à une liste de cadeaux » sur la page d’accueil.
2. L’application demande la saisie du code d’accès personnalisé.
3. L’application affiche, en cas de succès, la page de description des ouvrages avec le
rappel l’événement fêté. Un panier est disponible.
Variantes :
1. S’il ne reste aucun ouvrage dans la liste un message apparaît.
2. Si le code est invalide l’opération échoue avec un message d’erreur.
Autres cas liés : Acheter des cadeaux dans une liste
Autres remarques :
– Si la quantité en stock de l’ouvrage est nulle, le cadeau ne doit plus apparaître dans la
liste.
Nom : Acheter des cadeaux dans une liste

Description : L’ami peut sélectionner un ou plusieurs ouvrages dans la liste des cadeaux
restants et passer commande.
Acteur principal : Ami
Préconditions :
– Se trouver sur la page de description de la liste.
Postconditions :
– Quand la commande est passée avec succès les cadeaux choisis reçoivent une date de
vente (ils seront désormais retirés de la liste des cadeaux restants).
1. L’ami sélectionne un ou plusieurs ouvrages sur la page de description de la liste en les
ajoutant à son panier.
2. L’ami visualise son panier.
3. Le cas Passer une commande se déroule ensuite.
Variantes :
Autres cas liés : Passer une commande
Autres remarques :
Exercice 17.2.
Diagramme de cas du front office : cf. page suivante.
Exercice 17.3.
L’analyse a mis en évidence des manques à la première version, comme les absences :
– de la classe Commentaire avec les attributs texte, date et état (à valider, validé, invalidé)
et son association aux ouvrages,
– de l’historique des avis donnés par les clients sur les ouvrages,
– de la réponse à la question secrète des clients,
– de la description de l’événement fêté par la liste de cadeaux.
Exercice 17.4.
Exercice 17.5.
Exercice 18.1.
Tests d’acceptations de :
Acheter une propriété
(1) Un joueur arrive sur une propriété qui n’appartient à personne. S’il accepte de l’acheter,
il en devient propriétaire et sa trésorerie diminue du prix d’achat.
(2) Un joueur arrive sur une propriété qui n’appartient à personne. S’il refuse de l’acheter,
une enchère est organisée pour déterminer le joueur qui l’achète et le prix auquel il
l’achète.
(3) Un joueur arrive sur une propriété qui lui appartient déjà. Rien ne se passe.
(4) Un joueur passe au-dessus d’une propriété qui n’appartient à personne. Rien ne se passe.
Organiser une enchère

(1) La mise à prix est de 1 e.
(2) Les joueurs enchérissent tour à tour.
(3) Si 30 secondes se passent sans enchère supplémentaire le dernier enchérisseur emporte
l’enchère. S’il n’y en a aucun, l’enchère est infructueuse.
Enchérir
(1) Un joueur propose un prix supérieur au dernier prix proposé (ou initialement la mise à
prix). Il emportera l’enchère à ce prix si aucune enchère supérieure n’est proposée.
(2) Un joueur propose un prix inférieur ou égal ou dernier prix proposé. Son offre est refusée.
Exercice 18.2.
Maquette de l’écran de participation à une enchère : un chronomètre permet de suivre
l’écoulement du temps depuis la dernière offre dont la valeur est rappelée. Le bouton
enchérir arrête le chronomètre et permet la saisie d’une offre.
Exercice 19.1.
Nom : Hypothéquer une propriété

Description : Hypothéquer une propriété permet d’obtenir de la trésorerie supplémentaire.
Préconditions :
– Un joueur a la main.
– Il dispose d’une propriété non bâtie et non hypothéquée.
Postconditions :
– La propriété est hypothéquée.
– La trésorerie du joueur augmente du montant de l’hypothèque.
1. Le joueur demande à hypothéquer la propriété.
Variantes :
Autres remarques :
Nom : Lever une hypothèque

Description : Lever une hypothèque permet de retoucher des loyers.
Préconditions :
– Un joueur a la main.
– Il dispose d’une propriété hypothéquée.
– Il dispose de la trésorerie nécessaire pour lever l’hypothèque.
Postconditions :
– L’hypothèque est levée.
– La trésorerie du joueur diminue du montant de l’hypothèque plus 10 % d’intérêts.
1. Le joueur demande à lever l’hypothèque de la propriété.
Variantes :
Autres remarques :
Exercice 19.2.
Nom : Mettre en faillite

Description : Un joueur est en cessation de paiement. Il est sorti du jeu.
Acteurs secondaires : Joueur
Préconditions : Un joueur ne peut plus régler une dette à un créancier (soit la banque soit
un autre joueur).
Postconditions : Le joueur est sorti du jeu.
1. Le reliquat d’argent est transféré au créancier.
2. Si le créancier est la banque, les propriétés sont mises aux enchères (non hypothéquées),
et les cartes sont remises en bas de leurs tas.
Variantes :
1. Si le créancier est un autre joueur, les propriétés et les cartes lui sont transférées. Il
doit régler immédiatement 10 % des hypothèques.
Autres cas liés :

Autres remarques :
Exercice 20.1.
a) Au début du jeu pour procéder au choix du joueur qui jouera en premier. En cours de jeu
pour détecter les doubles et les successions de doubles.
b) Par exemple, avec un attribut booléen a_la_main dans la classe Joueur.
c) Un attribut entier pour compter les doubles.
Un attribut entier qui indique le nombre de tours à rester en prison.
Exercice 20.2.
Le plus simple est d’ajouter {ordered} à l’agrégation Plateau vers Case. Cela signifie
l’existence d’une liste ordonnée d’objets Case au niveau de l’objet Plateau.
On pourrait aussi introduire une association réflexive suivant au niveau de la classe Case.
Cela signifie gérer une liste chaînée d’objets Case.
Exercice 20.3.
Un Terrain peut être libre d’occupant, occupé ou hypothéqué.

Bibliographie
[Abr96] Jean-Raymond A BRIAL. The B Book – Assigning Programs to Meanings.

Cambridge University Press, 1996.
[AJ02] Scott W. A MBLER et Ron J EFFRIES. Agile Modeling. Wiley, 2002.
[Bec99] Kent B ECK. Extreme Programming Explained: Embrace Change. Addison-
Wesley, 1999.
[Bei90] Boris B EIZER. Software Testing Techniques. International Thomson Computer
Press, 1990.
[BR05] Michael B LAHA et James RUMBAUGH. Modélisation et conception orientées
objet avec UML2. Traduction de Applying Object-Oriented Modeling and
Design with UML, Prentice Hall, 2005. Pearson Education France, 2005.
[Bro75] Frederick P. Jr B ROOKS. The Mythical Man-Month. Addison-Wesley, 1975.
[Bro87] Frederick P. Jr B ROOKS. « No Silver Bullet: Essence and Accidents of Software
Engineering ». Computer 20.4 (1987), p. 10–19.
[Dij72] Edsger W. D IJKSTRA. « Notes on Structured Programming ». In Structured
Programming, Academic Press (1972), p. 1–82.
[DLF93] Anne DARDENNE, Axel van L AMSWEERDE et Stephen F ICKAS. « Goal-
Directed Requirements Acquisition ». Science of Computer Programming
20.1-2 (1993), p. 3–50.
[Fow03] Martin F OWLER. UmlModes. 2003. URL : martinfowler.com/bliki/
UmlMode.html.
[Fow08] Martin F OWLER. AgileVersusLean. 2008. URL : martinfowler . com /
bliki/AgileVersusLean.html.
[Fow97] Martin F OWLER. Analysis Patterns: Reusable Object Models. Addison-Wesley,
1997.
[Gam+95] Erich G AMMA et al. Design Patterns: Elements of Reusable Object-Oriented
Software. Addison-Wesley (version française chez Vuibert), 1995.
302 BIBLIOGRAPHIE
[Gro09] Jean-Claude G ROSJEAN. User Story vs Use case : soyez Agile ! 2009. URL :
www.qualitystreet.fr/2009/02/16/user- story- vs- use-
case-soyez-agile/.
[Jac+92] Ivar JACOBSON et al. Object-Oriented software engineering: A use case driven
approach. Addison-Wesley, 1992.
[JBR99] Ivar JACOBSON, Grady B OOCH et James RUMBAUGH. The Unified Software
Development Process. Addison-Wesley, 1999.
[Jef01] Ron J EFFRIES. Essential XP: Card, Conversation, Confirmation. 2001. URL :
xprogramming.com/xpmag/expCardConversationConfirmation.
[Joh04] Simon J OHNSTON. Rational UML Profile for Business Modeling. 2004. URL :
www . ibm . com / developerworks / rational / library / 5167 .
html.
[Kru04] Philippe K RUCHTEN. The Rational Unified Process: An Introduction. Addison-
Wesley, 2004.
[Kru95] Philippe K RUCHTEN. « Architectural Blueprints – The « 4+1 » View Model of
Software Architecture. » IEEE Software 12.6 (1995), p. 42–50.
[Lar95] Craig L ARMAN. Applying UML and Patterns. Prentice Hall, 1995.
[Lie04] Benjamin L IEBERMAN. UML Activity Diagrams: Detailing User Interface Na-
vigation. 2004. URL : www . ibm . com / developerworks / rational /
library/4697.html.
[Lon14] Jacques L ONCHAMP. Conception d’applications en Java/JEE. Principes,
patterns et architectures. Dunod, 2014.
[Mey85] Bertrand M EYER. « On formalism in specifications ». IEEE Software 2.1 (1985),
p. 6–26.
[Min65] Marvin M INSKY. « Matter, mind and models ». In Proceedings of IFIP
Congress (1965), p. 45–49.
[Mye79] Glenford J. M YERS. The art of software testing. Wiley, 1979.
[Ng02] Pan-Weig N G. « Effective Business Modeling with UML: Describing Business
Use Cases and Realizations ». The Rational Edge (nov. 2002).
[Nor06] Dan N ORTH. Introducing BDD (Behaviour-Driven Development). 2006. URL :
dannorth.net/introducing-bdd/.
[NWM10] John N OLL et Liu W EI -M ING. « Requirements elicitation in open source
software development: a case study ». In Proceedings of the 3rd International
Workshop on Emerging Trends in Free/Libre/Open Source Software Research
and Development (2010), p. 35–40.
[OMG14] OMG. Object Constraint Language. 2014. URL : www . omg . org / spec /
OCL/2.4/PDF.
[OMG97] OMG. UML Extension for Business Modeling. 1997. URL : www.omg.org/
cgi-bin/doc?ad/97-08-07.
[PP03] Mary P OPPENDIECK et Tom P OPPENDIECK. Lean Software Development: An
Agile Toolkit. Addison-Wesley, 2003.
[Pre09] Roger S. P RESSMAN. Software Engineering. A Practitioner’s Approach (7e
édition). McGraw-Hill, 2009.
[Ray99] Eric S. R AYMOND. The Cathedral and the Bazaar: Musings on Linux and Open
Source by an Accidental Revolutionary. O’Reilly Media, 1999.
[Roq06] Pascal ROQUES. UML 2, modéliser une application web. Eyrolles, 2006.
BIBLIOGRAPHIE 303
[Roy70] Winston W. ROYCE. « Managing the Development of Large Software Systems ».

Actes de IEEE Wescon (1970), p. 1–9.
[RV04] Pascal ROQUES et Franck VALLLÉE. UML 2 en action. Eyrolles, 2004.
[SB01] Ken S CHWABER et Mike B EEDLE. Agile Software Development With Scrum.
Prentice Hall, 2001.
[Sca02] Walt S CACCHI. « Understanding the requirements for developing open source
software systems ». In IEE Proceedings – Software 149.1 (2002), p. 24–39.
[SM04] Anthony S ENYARD et Martin M ICHLMAYR. « How to Have a Successful
Free Software Project ». In Proceedings of the 11th Asia-Pacific Software
Engineering Conference (2004), p. 84–91. URL : www . cyrius . com /
publications/.
[Som04] Ian S OMERVILLE. Software Engineering (7e édition). Addison-Wesley, 2004.
[Wak03] Bill WAKE. INVEST in Good Stories, and SMART Tasks. 2003. URL : xp123.
com/articles/invest-in-good-stories-and-smart-tasks/.
Index
abstraction, 46 classe de dialogue, 177

acteur, 159 classe entité, 177
acteur métier, 106, 113 classe frontière, 177
agrégation, 49 clean code, 65
analyse, 4 client sur site, 80
analyse des besoins, 4 CMMI, 8
analyse et spécification des besoins, 22 coach, 82
analyse linguistique, 127 code and fix, 57
analysis pattern, 127 code smell, 81
approche agile, 64 composant, 67
approche formelle, 67 composition, 49
approche prescriptive, 63 conception, 26
appropriation collective, 80 conception simple, 81
architecture, 77, 198 confidentialité, 4
association, 49 confirmation, 152
assurance qualité, 40 construction, 74, 76, 83
contrôle qualité, 40
bazaar, 69 contrôleur, 178
BDD, 154 conversation, 152
behavior-driven development, 154
COTS, 67
besoins bruts, 19
courage, 79
besoins fonctionnels, 18
cow-boy programming, 57
big bang, 58
CQFD, 5
binôme, 80
BOM, 117 crise du logiciel, 5
bug report, 78 critique, 5
build, 97 cycle de vie, 57
business object model, 117
but, 21 décomposition fonctionnelle, 47
but métier, 109 décomposition objet, 47
délégation, 49
cahier des charges client, 19 déploiement, 28
cahier des charges détaillé, 22 développement dirigé par les tests, 81, 92
carte, 152 développement sauvage, 57
cas d’utilisation, 77, 149, 159 daily scrum, 89
cas d’utilisation métier, 114 diagramme d’états, 52, 121
cas métier, 107, 114 diagramme d’activités, 53, 149, 170
cascade, 58 diagramme d’activités métier, 117
cathedral, 69 diagramme de cas d’utilisation, 51, 161, 213
change request, 78 diagramme de cas métier, 116
chaos report, 5 diagramme de classes, 51
classe conceptuelle, 127 diagramme de classes métier, 119
classe de contrôle, 177 diagramme de séquences, 52, 120
306 Index
diagramme de séquences système, 149, 169 métaphore, 81

discipline, 74 mêlée quotidienne, 89
disponibilité, 4 maître d’œuvre, 3
document d’expression des besoins, 19 maître d’ouvrage, 3
documentation, 33 maintenabilité, 4
DSS, 169 maintenance, 29, 83
maintenance adaptative, 29
entité métier, 107 maintenance corrective, 29
exploration, 82 maintenance perfective, 29
extend, 162 manager, 82
extreme programming, 79 manifeste agile, 64
maquette, 21, 204
feature request, 78 maturité, 8
feedback, 76, 79, 91 mise en production, 83
fiabilité, 4 MOA, 3
follow-up meeting, 89 mock, 97
forfait, 84 modélisation de l’application, 22
formule des trois C, 152 modélisation des processus métiers, 22
FURPS+, 25 modélisation du domaine, 22
modélisation métier, 105
généralisation/spécialisation, 48, 163 modèle, 45, 178
gestion de configuration, 33, 38 modèle de classes d’analyse, 175
gestion de la qualité, 33 modèle des classes du domaine, 110, 125
gestion de projet, 33 modèle des classes participantes, 175
gestion des besoins, 33 modèle en spirale, 62
modèle en V, 59
IHM, 21
modèle en Y, 59
implantation, 28
modèle itératif, 61
inception, 74, 195
modèle visuel, 47
include, 162
model-checking, 30
ingénierie des besoins, 3
MOE, 3
inspection, 41
MoSCoW, 24
intégration continue, 80, 97
MVC, 177
intégrité, 4
interface, 49 mythes, 7
intervenant métier, 106
INVEST, 152 object constraint language, 68
iteration plan, 80 objet conceptuel, 25
objet métier, 25
jalon, 74 OCL, 68, 109
JUnit, 93
patron d’analyse, 27, 127
kanban, 66 patron de conception, 27
kanban des tâches, 97 personas, 153
planification itérative, 80
lancement, 74, 75 planning poker, 85
langage formel, 25 polymorphisme, 49
langage naturel, 24 Post-it, 152
langage structuré, 24 preuve de programmes, 30
langage visuel, 24 processus métier, 114
lean, 65 processus unifié, 62
licence, 69 product backlog, 85
livrable, 74 product burndown chart, 88
livraisons fréquentes, 80 product owner, 85
logiciel, 1 profil UML, 106
logiciel libre, 68 prototypage expérimental, 61
loi de Pareto, 8 prototypage rapide, 31, 60
low tech, 97 pseudocode, 24
Index 307
qualité, 4, 78 stéréotype, 163

stakeholder, 84, 152
régie, 84 Standish Group, 5
rétrospective de sprint, 90 story board, 153
rôle, 159 story map, 153
règle métier, 109 système métier, 105
radiateur d’information, 97
recette, 59 tableau kanban, 67
reengineering, 29 test, 30
refactoring, 81 test d’acceptation, 59
refonte, 29 test d’intégration, 59
release, 74 test de validation, 59
release plan, 80 test système, 59
release planning meeting, 80 test unitaire, 59
requirements engineering, 3 tracker, 82
revue, 30, 40 transition, 74, 76
revue de sprint, 90
risque, 63, 77 UML, 49
RUP, 73 unité organisationnelle, 108
rythme soutenable, 80 UP, 73
use case, 77, 149, 159
sécurité, 4 user story, 82, 149
sémantique, 125
sûreté, 4 vélocité, 89
scénario, 164 vérification, 30
Scrum, 84 validation, 30
Scrum de Scrums, 91 version béta, 76
Scrum Master, 85 vue, 46, 177
simplicité, 79 war room, 80
software craftsmanship, 65 waterfall, 58
spécification, 114 worker, 106
sprint, 84, 87
sprint backlog, 87 XP, 79, 151
sprint burndown chart, 87
sprint planning meeting, 88 YAGNI, 81

Recueil Et Specification Demarches Itera

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Recueil Et Specification Demarches Itera

Transféré par

Droits d'auteur :

Formats disponibles

Analyse

CHAPITRE 2 • LES ACTIVITÉS DU DÉVELOPPEMENT

CHAPITRE 3 • LA MODÉLISATION – UML

CHAPITRE 4 • LES MODÈLES DE DÉVELOPPEMENT

CHAPITRE 5 • (R)UP, XP ET SCRUM

CHAPITRE 6 • INTRODUCTION À LA MODÉLISATION MÉTIER

CHAPITRE 7 • LA MODÉLISATION DES PROCESSUS MÉTIER

CHAPITRE 8 • LA MODÉLISATION DU DOMAINE

CHAPITRE 9 • LES SPÉCIFICATIONS FORMELLES AVEC OCL

CHAPITRE 10 • LES USER STORIES

CHAPITRE 11 • LES CAS D’UTILISATION

CHAPITRE 12 • LES AUTRES MODÈLES UML

CHAPITRE 13 • LE MODÈLE DES CLASSES D’ANALYSE

CHAPITRE 14 • LES MODÈLES UML COMPLÉMENTAIRES

CHAPITRE 15 • LE MODÈLE DE NAVIGATION

CHAPITRE 16 • ÉTUDE DE CAS 1 – LA PHASE D’INITIALISATION

CHAPITRE 17 • ÉTUDE DE CAS 1 – LA PHASE D’ÉLABORATION

CHAPITRE 18 • ÉTUDE DE CAS 2 – LES USER STORIES

CHAPITRE 19 • ÉTUDE DE CAS 2 – LES CAS D’UTILISATION

CHAPITRE 20 • ÉTUDE DE CAS 2 – LES CLASSES DU DOMAINE

20.3 L’analyse des entités complexes du domaine 251

CORRIGÉS DES EXERCICES 255

POURQUOI CET OUVRAGE ?

processus de développement avant la présentation des connaissances théoriques et pratiques

Une progression logique des apprentissages

Pour une « culture générale » de l’analyse

L’importance de la mise en pratique

POUR QUELS LECTEURS ?

La troisième partie est dédiée aux techniques de la modélisation des besoins.

La quatrième partie est consacrée aux techniques de la modélisation des applications.

La cinquième et dernière partie du livre présente en détail deux études de cas.

1.1.2. La diversité du logiciel

Dans cette dernière classe, on a coutume de parler plutôt de « développement système »

1.1.3. La complexité du logiciel

1.2 LE DÉVELOPPEMENT LOGICIEL

1.2.2. Les contextes du développement

1.2.3. Les activités du développement

F IGURE 1.1 Le développement logiciel

Comme la manière de conduire une analyse dépend fortement du style de développement

'    () # 

"#    

  !       

F IGURE 1.2 Les thèmes principaux de l’ouvrage

1.3 LA QUALITÉ DU LOGICIEL

Terme français Terme anglais Signiﬁcation

1.4 LA « CRISE DU LOGICIEL »

Année Succès Mitigé Échec

Des exemples d’abandon de logiciels extrêmement coûteux continuent encore et toujours à

1.4.2. L’inﬂuence de la complexité

F IGURE 1.3 Inﬂuence de la complexité sur la réussite des projets

1.4.3. Les causes

1.4.4. Les « mythes » du développement logiciel

1.4.5. Les solutions

1.5 LA MATURITÉ DES ORGANISATIONS

1. La version la plus récente s’appelle CMMI-DEV et date de 2006.

F IGURE 1.4 Les niveaux de maturité

– Au niveau standardisé, on trouve la déﬁnition du processus organisationnel, la focalisation

– Au niveau quantiﬁé, on trouve la gestion quantitative des processus et de la qualité

Exercice 1.1. Les défaillances logicielles de systèmes complexes

Communiqué de presse conjoint ESA-CNES

Rapport de la Commission d’enquête Ariane 501

Président de la Commission : Professeur J.-L. LIONS

Pour améliorer la fiabilité, on a prévu une importante redondance au niveau

le SRI actif est en panne, il passe immédiatement sur l’autre SRI à

' () #

"#

!