UML
au service de l'analyse des métiers (Business Analysis)
Préface
Introduction
1. Pourquoi ce livre ?13
1.1 Pourquoi UML ?13
1.2 Pourquoi la business analysis (analyse du métier) ?15
1.3 La genèse d'UML16
2. Fil rouge : la société LOCA'ROYANS17
2.1 L'activité de LOCA'ROYANS17
2.2 Les responsables opérationnels de LOCA'ROYANS18
2.3 Compte rendu des entretiens : extraits19
2.3.1 L'informatique : état actuel19
2.3.2 Quelques anomalies de fonctionnement énumérées par M. Centplont19
2.3.3 Attentes émanant des métiers20
Chapitre 1
Ingénierie de l'analyse du métier
1. Pourquoi l'analyse du métier ?23
1.1 Les compétences de l'analyste du métier24
1.2 L'analyste du métier et le chef de projet25
1.3 Les facteurs de réussite des projets28
2. Les changements et les adaptations de l'entreprise par les projets29
2.1 Adapter l'entreprise29
2.1.1 Améliorer en profitant des nouvelles technologies29
2.1.2 Transformer l'entreprise31
2.2 Penser une véritable ingénierie du besoin34
2.2.1 Collecter les besoins34
2.2.2 Organiser, hiérarchiser et administrer les besoins34
2.2.3 Formaliser les besoins37
2.2.4 Vérifier l'implémentation correcte des besoins38
2.2.5 Légitimer les besoins38
3. L'International Institute of Business Analysis (IIBA)40
4. Le cycle de vie du projet42
5. Le cycle de vie de la solution43
6. Le cycle de vie des exigences44
7. À retenir pour la suite45
7.1 Le cycle de vie du produit (de la fourniture)45
7.2 Les différentes parties prenantes d'un projet46
Chapitre 2
Description dynamique (les acteurs agissent)
1. L'état des lieux49
1.1 La description dynamique50
1.2 Les autres descriptions50
2. La notion de processus51
3. La représentation formelle de processus : trois niveaux52
3.1 La représentation minimaliste52
3.2 La représentation développée54
3.3 La représentation détaillée56
4. L'identification des processus d'une entreprise58
4.1 Le bien ou le service fourni58
4.2 Les événements déclencheurs59
4.3 Le nommage des processus59
4.4 Les trois catégories de processus60
4.5 Les notions de partie prenante et d'acteur61
5. Quelques processus de LOCA'ROYANS62
5.1 Le processus louer Véhicule63
5.1.1 La description littérale63
5.1.2 L'analyse63
5.1.3 La représentation minimaliste64
5.1.4 La représentation développée65
5.1.5 La représentation détaillée66
5.1.6 Les éléments majeurs du modèle66
5.2 Le processus restituer Véhicule70
5.2.1 La description littérale70
5.2.2 L'analyse71
5.2.3 La modélisation UML : le diagramme d'activité (représentation détaillée)71
5.2.4 Les éléments du modèle72
5.2.5 Le flux de contrôle et les flux d'objets72
5.2.6 Les processus sont paramétrables74
6. Le cycle de vie des objets du métier75
7. Le référentiel UML du projet75
8. Pour aller plus loin78
9. À retenir79
10. Les prochaines étapes79
Chapitre 3
Description dynamique (l'information se transforme)
1. L'état des lieux81
2. La notion de machine à états83
2.1 Définition84
2.2 Le diagramme de la machine à états85
2.2.1 Le diagramme minimaliste85
2.2.2 Le diagramme développé86
2.2.3 Le diagramme détaillé87
2.2.4 Les autres renseignements portés par les transitions88
2.2.5 La jonction entre les transitions : la complexité événementielle89
3. Les propriétés de l'état90
3.1 La transition et le comportement90
3.1.1 L'autotransition90
3.1.2 La transition interne92
3.2 La hiérarchie entre états (automate hiérarchique)93
3.3 Les actions et les activités94
3.4 Les pseudo-états95
3.4.1 Les pseudo-états attachés aux flux de contrôle95
3.4.2 Les pseudo-états attachés aux états composites97
3.4.3 Les états concurrents d'un système complexe98
4. La description de la sémantique du système100
4.1 Les diagrammes de protocole d'utilisation100
4.2 Les diagrammes de protocole de calcul102
5. Pour aller plus loin103
5.1 Les comportements déterministes et non déterministes103
5.2 À quels objets UML attacher une machine à états ?103
5.3 La syntaxe des diagrammes d'activité et de cycle de vie104
6. À retenir104
7. Les prochaines étapes105
Chapitre 4
Description fonctionnelle du système
1. L'état des lieux107
2. La notion de cas d'utilisation109
2.1 Définition109
2.2 Exemples de cas d'utilisation110
2.3 Le cas d'utilisation et processus112
2.4 Le diagramme des cas d'utilisation114
2.4.1 Le diagramme minimal114
2.4.2 Le diagramme développé117
2.4.3 Le diagramme détaillé119
2.4.4 Les insuffisances du diagramme des cas d'utilisation121
3. La description textuelle des cas d'utilisation122
3.1 La description textuelle minimale123
3.1.1 Le cas d'utilisation choisir Véhicule123
3.1.2 Les règles du contenu124
3.1.3 Les transactions métier125
3.1.4 L'interface homme-machine (IHM)125
3.2 La description textuelle développée126
3.3 La description textuelle détaillée128
3.3.1 Le cas d'utilisation choisir Véhicule128
3.3.2 Les règles de gestion130
3.3.3 Les exceptions et les extensions131
4. Les concepts UML en jeu133
4.1 Le cas d'utilisation133
4.2 L'acteur134
4.3 Les représentations135
5. Pour aller plus loin136
5.1 Le cas d'utilisation et le pilotage de projet136
5.2 Le cas d'utilisation et l'architecture logicielle136
5.3 Les cas d'utilisation et le modèle économique137
5.3.1 Les quatre dimensions d'un modèle économique137
5.3.2 Le système d'information et le modèle économique138
6. À retenir139
6.1 Le double avantage à tirer d'une formalisation des cas d'utilisation139
6.2 Le double devenir des cas d'utilisation140
Chapitre 5
Description structurale du système
1. L'état des lieux141
2. Les notions de classe et de composant142
2.1 Définitions142
2.2 Exemples145
2.3 Les diagrammes de classes147
2.3.1 Le diagramme de classes minimaliste147
2.3.2 Le diagramme de classes développé150
2.3.3 Le diagramme de classes détaillé154
2.4 La notion UML de composant157
2.5 Les autres notions de la vue statique159
2.5.1 L'héritage159
2.5.2 Le diagramme d'instances (ou diagramme d'objets)164
2.5.3 Les associations qualifiées166
2.5.4 Les classes associations167
2.6 Les ports et les interfaces170
3. Les concepts UML en jeu173
3.1 La classe173
3.2 Le port et l'interface175
3.3 L'association175
3.4 Le composant177
4. Pour aller plus loin182
4.1 La classe paramétrée182
4.2 L'association ternaire183
4.3 Les stéréotypes et la valeur attachée186
4.3.1 Le stéréotype186
4.3.2 La valeur attachée188
4.4 Le paquetage189
5. Conclusion189
5.1 Les solutions spécifiques : l'analyse préfigure la conception189
5.2 Les solutions industrielles : adapter afin d'adopter190
5.3 Et toujours : structurer pour simplifier191
Chapitre 6
Description collaborative du système
1. L'état des lieux193
2. La notion de comportement195
2.1 Spécifier un comportement en UML196
2.2 Synchroniser des comportements196
2.3 Comportement... de qui ?197
2.4 Déclencher des comportements : les signaux et les événements199
2.5 Les interactions201
2.5.1 Le diagramme de séquences202
2.5.2 Le diagramme de communication210
2.5.3 Le diagramme d'interaction211
3. Les concepts UML en jeu212
3.1 L'interaction, le fragment combiné, la ligne de vie, l'appel d'interaction (interaction use)212
3.2 Le message, le signal, l'événement, le comportement215
3.3 L'invariant d'état219
4. Pour aller plus loin220
5. Conclusion221
Chapitre 7
UML au service de l'architecture
1. L'état des lieux223
2. L'architecture en entreprise228
2.1 Répondre à deux besoins : généricité et cohérence interne228
2.2 L'architecture comme source de cohérence et support de la transformation232
2.2.1 C'est une métaphore232
2.2.2 La définition normée de l'architecture d'entreprise232
2.2.3 Les autres définitions : l'architecture selon TOGAF et Praxeme233
3. L'architecture en entreprise selon TOGAF et Praxeme236
3.1 Le framework TOGAF version 9.1236
3.1.1 La mise en oeuvre de TOGAF236
3.1.2 Les outils proposés par TOGAF238
3.2 La méthodologie Praxeme241
3.2.1 Les produits242
3.2.2 Les procédés et processus246
3.3 TOGAF et Praxeme : des réponses pertinentes aux exigences de cohérence et de généricité ?247
3.4 Un retour sur la généricité251
3.4.1 La généricité selon TOGAF251
3.4.2 La généricité selon Praxeme251
4. Les apports d'UML à l'architecture253
4.1 Les diagrammes UML natifs au service de l'architecture254
4.1.1 TOGAF et UML254
4.1.2 Praxeme et UML259
4.2 Les diagrammes d'architecture natifs proposés par UML262
4.2.1 Le diagramme de composants262
4.2.2 Le diagramme de structure composite262
4.2.3 Le diagramme de déploiement263
4.3 Spécialiser UML : les profils264
5. Pour aller plus loin266
6. Conclusion267
Chapitre 8
Rédiger le cahier des charges fonctionnel d'un projet
1. L'état des lieux269
2. La notion de cahier des charges fonctionnel (CdCF) ?271
2.1 Définition271
2.2 Déterminer les fonctions de service a minima272
2.3 Les autres manières de déterminer les fonctions de service272
2.4 Naissance du CdCF en France274
2.5 Qu'est-ce qu'un besoin ?275
2.5.1 Les besoins implicites et explicites276
2.5.2 La mise en cohérence des besoins277
3. Le plan-type proposé par la norme ISO278
3.1 Les chapitres du CdCF278
3.2 Les modèles UML pouvant alimenter ce CdCF279
4. Le cahier des charges dans le cycle en V et les cycles agiles280
4.1 Le cycle en V : exposer le problème, puis le résoudre280
4.1.1 Le cahier des charges, un référentiel accompagnant le produit toute sa vie280
4.1.2 Le cahier des charges, un référentiel à deux étages281
4.2 Les cycles agiles : poser le problème tout en le résolvant284
4.2.1 Rejeter le CdCF : un choix managérial qui ne s'impose pas284
4.2.2 L'agilité appelle à la généricité du CdCF, non à son abolition285
5. Livré mais toujours sous responsabilité287
6. Pour aller plus loin289
Chapitre 9
Les impacts d'UML sur la recette d'un livrable
1. L'état des lieux291
2. Les types fondamentaux de recettes293
3. La recette technique d'un produit spécifié en UML295
3.1 Les tests de cas d'utilisation295
3.1.1 Le scénario de tests296
3.1.2 La fiche de tests299
3.1.3 Le résultat des tests301
3.1.4 La décision d'acceptation ou de refus du cas d'utilisation303
3.1.5 L'environnement des tests unitaires304
3.2 Les tests d'assemblage306
3.2.1 Ce qui doit être testé en assemblage306
3.2.2 Ce qu'il est inutile de tester en assemblage309
3.3 Les autres tests pouvant être facilités par UML309
3.4 Les apports d'UML à la recette technique309
4. La priorisation des tests par les risques310
4.1 L'évaluation du risque311
4.2 L'analyse de risques de deux cas d'utilisation de LOCA'ROYANS312
4.2.1 L'identification du risque312
4.2.2 L'évaluation du risque312
4.2.3 La priorisation : la comparaison des risques312
4.3 La répartition des ressources en fonction des risques313
5. Pour aller plus loin314
Chapitre 10
Évaluation des charges d'un projet spécifié en UML
1. L'état des lieux315
2. Comment évaluer les charges316
3. Exemple de méthode de répartition proportionnelle316
4. Le modèle COCOMO317
5. La méthode d'évaluation analytique319
6. La méthode des points de fonction320
7. L'évaluation de la charge d'un projet UML : la méthode Karner320
7.1 La détermination du poids non ajusté des acteurs321
7.2 La détermination du poids non ajusté des cas d'utilisation321
7.3 Le calcul du nombre de points brut du CU322
7.4 Le calcul du nombre de points ajusté du CU322
7.4.1 La complexité technique322
7.4.2 L'environnement324
7.4.3 Le nombre de points ajusté de deux CU de LOCA'ROYANS325
7.5 L'évaluation et la ventilation de la charge326
8. Pour aller plus loin327
9. Conclusion328
Index331