Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
Un use case UML ( cas d'utilisation ) est une activité métier comme par exemple un acte de gestion exécuté par un acteur externe à l'application.
Un acteur au sens UML du terme, est un rôle qui correspond à son activité métier au moment ou il utilise le système.
Par exemple, un directeur commercial peut avoir plusieurs rôles au sein de l'application. Si celle-ci propose une fonctionnalité d'aide à la rédaction de propositions commerciales, lorsqu'il veut en rédiger une ( activité identifiée normalement dans la modélisation des processus métier ), il endosse le rôle de "rédacteur de proposition commerciale".
Pour la gestion des prospects son rôle est alors "ingénieur commercial" et lorsqu'il souhaite gérer les tableaux de bord de ses commerciaux, "directeur commercial".
Le rôle « directeur commercial » hérite de tous les rôles précédents.
Ces rôles sont des profils fonctionnels par rapport à l'exercice d'une activité composée d'une suite d'actions.
Les acteurs sont identifiées à partir des fonctions existantes dans l'entreprise et à partir des processus métiers de la vue modélisation métier de l'urbanisation du Système d'Information.
Un use case comporte un ou plusieurs scénarios composés de une ou plusieurs étapes.
Les scénarios peuvent être des cas nominaux où tout se passe bien, des cas alternatifs ou des cas exceptionnels conduisant à une exception métier.
La bonne pratique est de toujours commencer par analyser les scénarios nominaux puis les décrire jusqu'à obtenir une version stable.
Il est alors plus aisé d'identifier les scénarios alternatifs et exceptionnels à partir de la séquence normale des étapes des scénarios principaux.
Un scénario nominal conduit au résultat attendu, un scénario alternatif va mener à une fin normale mais en empruntant un autre chemin c'est à dire une autre suite d'étapes pour des conditions particulières, quand au scénario exceptionnel, il conduit toujours à une fin anormale correspondant à la génération d'une exception métier comme par exemple une donnée de paramétrage inexistante.
D'après l'ouvrage culte d'Alistair Cockburn "Writing effective use case", on peut définir 3 niveaux de use case qui sont pour reprendre son allégorie : le niveau nuage, le niveau de la mer et le fond de la mer.
Le niveau nuage correspond à des use case à fortes granularités, stratégiques comme par exemple "Gérer un prêt bancaire". Ces use case sont trop "gros", ils doivent être décomposés en use case du niveau de la mer.
Le niveau de la mer correspond bien à un use case utilisateur pour l'application cible, l'exemple précédent se décomposerait en 3 use case : "Gérer une demande de prêt bancaire", "Analyser une demande de prêt bancaire" et "Valider une demande de prêt bancaire".
Et le niveau fond de la mer, correspond à une fonction élémentaire simple non décomposable comme par exemple "Imprimer la demande de prêt bancaire". Ces use case correspondent à une simple étape d'un scénario.
Pour synthétiser, tout se résume à déterminer la bonne granularité d'un use case.
Alors comment faire pour trouver les bons use case, ni trop gros, ni trop fin ?
Les retours d'expérience ont permis d'élaborer la méthode dite des "10 ; 10".
Un use case doit avoir en moyenne 10 scénarios composés chacun d'environ 10 étapes. De plus il doit être déclenché par un unique acteur ( rôle ), exécuté dans une limite de temps, être transactionnelle, avoir un début et une fin et pour terminer on doit avoir unicité de lieu.
Donc si ron eprend l'exemple du use case niveau nuage "Gérer un prêt bancaire", on voit qu'il faut d'abord faire une demande de prêt déclenchée par un chargé de clientèle, puis cette demande est analysée par un analyste financier et ensuite validée par le directeur d'agence.
Il y a donc 3 acteurs différents, intervenant à des moments différents dans des lieux éventuellement différents. Par conséquent, le use case doit être décomposé pour satisfaire la méthode des "10 ; 10".
Examinons cette décomposition.
La gestion de la demande exige environ une dizaine de scénarios ( utilisation, type de prêt, ... ) et pour chaque scénario on aurait approximativement une dizaine d'étapes ( situation de famille, recensement des revenus, existence d'autres prêts, même établissement, propositions de différentes solutions de remboursement, ... ).
Le use case "Gérer une demande de prêt bancaire" est déclenché par un seul acteur le chargé de clientèle, il débute quand celui décide de créer/modifier une nouvelle demande et se termine quand celle-ci est créée ou modifiée.
Le use case "Analyser un prêt bancaire" est déclenché par l'analyste, commence lorsqu'il décide d'analyser une demande en attente et se termine lorsqu'il a émis une recommandation. On peut identifier une dizaine de scénarios constitués d'une dizaine d'étapes.
Le même raisonnement s'applique pour "Valider un prêt bancaire" déclenché par le directeur d'agence.
Si un même use case doit être factorisé et exécuté systématiquement dans plusieurs autres, on utilise la relation de dépendance <<include>>, du use case inclus vers celui qui le contient. Typiquement c'est le cas de l'authentification qui doit être obligatoirement effectuée au début de chaque use case.
Un use case peut être le prolongement d'un autre, on dit qu'il étend un use case ( relation <<extend>> attention au sens de la flèche qui va de celui qui étend vers celui qui est prolongé ).
Par exemple, pour analyser une demande de prêt, il faut les rechercher et les consulter donc le use case "Analyser une demande de prêt" étend le use case "Rechercher et consulter une demande", sachant que l'on peut juste vouloir consulter sans faire d'analyse. L'appel au use case qui étend est donc facultatif.
On vérifie que toutes les exigences sont implémentées dans au moins un use case.
Si ce n'est pas le cas c'est qu'on n'a pas encore terminé le travail de recensement des use case ou bien que les exigences restantes sont en dehors du périmètre de l'application.
Cette traçabilité est assurée par des relations d'implémentation UML allant de l'exigence modélisée comme une classe vers le use case.
Chaque scénario doit être décrit de manière textuelle en adoptant un formalisme qui constitue le modèle de fiche de use case.
Les AGL offrent des modèles prêts à l'emploi.
L'avantage est que cette description textuelle est stockée directement dans le référentiel de l'AGL. La traçabilité est ainsi assurée, on peut générer automatiquement la documentation et faire des estimations avec les modules de points de use case.
La méthode empirique d'identification des use case dite des "10 ; 10" a toujours donné de bons résultats et surtout permet d'avoir un cadre pour se prémunir des pièges lorsqu'on débute dans la modélisation des exigences et obtient donc une note de 10/10.
Rhona Maxwel
@rhona_maxwel
"Dans le sommeil, ce voyage aventureux de tous les soirs, il y a quelque chose de positivement miraculeux c'est un miracle dont la ponctualité a émoussé le mystère."
Charles Baudelaire
Articles conseillés :
SysML : le diagramme de cas d'utilisation (use case diagram)
SysML : les use case "top level" et opérationnels (tutorial SysML partie 4)
Partir du bon pied dans un projet informatique : la modélisation métier
A découvrir aussi
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 766 autres membres