A la lecture de la plupart des Cas d’Utilisation (Use Case) produits par les élèves, on peut se poser la question. On a trop souvent l’impression de voir un Cas d’Utilisation comme un exercice imposé pour réaliser une analyse UML sans en connaître précisément le but recherché.
Il est à noter que le cas examiné ci dessous est simpliste et que bien entendu
Ce que n’est pas un Use Case
Un Use Case est souvent présenté comme une liste de fonctionnalités de la future application. Mais ce n’est pas forcément l’outil le plus adapté pour cela.
Partons sur un projet d’informatisation d’une école de type collège par exemple, avec des élèves qui appartiennent à des classes (4e3 par exemple) et chaque classe va suivre des matières (mathématiques, anglais …)
Comme l’indique Laurent Audibert dans son cours sur developpez.com
Bien souvent, la maîtrise d’ouvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un moyen simple d’exprimer leurs besoins. C’est précisément le rôle des diagrammes de cas d’utilisation qui permettent de recueillir, d’analyser et d’organiser les besoins, et de recenser les grandes fonctionnalités d’un système. Il s’agit donc de la première étape UML d’analyse d’un système.
Par contre, là où mon avis diverge, c’est que l’auteur de ce schéma doit être un concepteur de l’équipe de développement et donc ni la maîtrise d’ouvrage ni les utilisateurs, il faut pour cela maîtriser un minimum la normalisation UML.
Alors, dans ce cas, qu’amène comme information ce type de schéma à la maîtrise d’ouvrage ? Ce schéma ne comporte aucun mot clef inhérent aux Use Cases (include, extend, condition …). Donc la maîtrise d’ouvrage en retire juste l’information qu’elle a en face d’elle quelqu’un qui a compris son besoin, si ce n’est la présence des acteurs ( afin de schématiser l’information sur le qui fait quoi; on pourrait rajouter le chef d’établissement, par exemple, avec des droits spécifiques).
C’est quand même un peu juste comme résultat, car ça, dans son for intérieur, elle espérait bien que l’équipe de développeurs avait compris son besoin, c’est un minimum.
J’ai bien peur que ce Cas d’Utilisation ne subisse le même destin que le tout premier Cas d’Utilisation de ma carrière qui, aussitôt terminé et validé par mon chef de projet, fut classé et archivé dans le dossier de conception du projet, pour ne plus être ni consulté ni utilisé.
Ce document devrait plutôt servir à échanger avec la maîtrise d’ouvrage afin d’avoir un point de validation pendant le processus de conception.
Un schéma de ce type serait donc plus judicieux :
On a la même information que précédemment, mais en plus on présente l’arborescence applicative (ou du site). Donc, la maîtrise d’ouvrage en retire vraiment une information sur la représentation future de ce que pourrait être son application, ou son site.
Mais ces deux schémas ont le même défaut : ils montrent un système ouvert accessible à tout le monde : aucune nécessité d’authentification pour accéder aux différentes fonctionnalités.
Ce que devrait être un Use Case
On a vu précédemment qu’un Cas d’Utilisation devrait servir de point de validation avec la maîtrise d’ouvrage. Pour cela il doit amener de l’information, et être facilement compréhensible, soit immédiatement, soit via une explication simple de sa codification ou de ses implications.
Un Cas d’Utilisation, comme son nom l’indique, n’est qu’un cas. Cela veut dire que plutôt que lister toutes les fonctionnalités d’un système, on va en décrire une seule, en la détaillant. Un dossier d’analyse devra donc comporter plusieurs Cas d’Utilisation, l’ensemble de ces cas décrivant la liste des fonctionnalités principales (on ne va pas faire un cas d’utilisation pour décrire la lecture par un visiteur des mentions légales d’un site).
Pour revenir à l’exemple du Use Case ci-dessus, on va commencer par le Cas d’Utilisation gestion des élèves. On pourrait alors traditionnellement avoir un schéma de ce type :
Et enfin, souvenons nous de la question initiale : Quelle est l’utilité d’un Use Case ?
Apporter de l’information à la maîtrise d’ouvrage afin qu’elle valide dès le début de la conception certains points déterminants.
C’est pourquoi au formalisme traditionnel ci-dessus, je préfère un formalisme plus intuitif pour les maîtrises d’ouvrage. Le schéma devient alors :
Pourquoi ce schéma est-il plus adapté à une validation ?
L’information est plus dense
Par rapport au tout premier schéma, on a un détail de la fonctionnalité, il devient donc plus aisé de détecter en amont les lacunes éventuelles de la solution proposée.
L’information est plus intuitive
Nous avons l’habitude de lire de gauche à droite, aussi si on regarde le schéma ci-dessus, on devine plus facilement l’enchaînement des pages (bon d’accord, il manque la page d’accueil, mais rien n’empêche de la rajouter).
Et si la maîtrise d’ouvrage valide ce schéma, elle valide de facto l’enchaînement des pages induit (au concepteur d’attirer l’attention de la maîtrise d’ouvrage sur ce point lors de la réunion de validation).
Et si la validation de l’enchaînement des pages est acquise, un pas important est fait en direction des maquettes, car c’est naturellement l’étape qui suit ces Use Cases.
Cerise sur le gâteau : Si la maîtrise d’ouvrage refuse de valider un Use Case, vous pouvez le refaire beaucoup plus rapidement qu’une maquette (Rappel : une maquette doit contenir les enchaînements d’écrans). Vous avez gagné du temps !!
