Cas d’utilisation

Histoires d’usage

« Le plus difficile dans la construction d’un système informatique c’est précisément savoir ce qu’on doit construire », écrivait F. Brooks dans « No Silver Bullet ». En effet, les autres problématiques peuvent se réduire à de simples considérations techniques, budgétaires ou organisationnelles dès lors qu’on sait précisément ce que le système doit faire.

Dans le chapitre précédent, nous avons vu comment recueillir les exigences d’un produit. Cependant - et malgré son exhaustivité - une SRS pourrait constituer une littérature particulièrement rébarbative si elle n’était qu’un amoncellement de phrases au standard IEEE (Institute of Electrical and Electronics Engineers), du genre « Le système doit faire ceci, le système doit faire cela… ». Il y a un besoin impérieux de centrer l’approche de définition du système sur son usage et de rendre sa lecture abordable. C’est précisément le genre de services que rendent les cas d’utilisation en scénarisant les échanges des acteurs et du système. Un cas d’utilisation est donc une histoire formalisée, faite de dialogues et dont les personnages sont les acteurs et le système. Les histoires sont plus digestes et attractives que les exigences, elles seront donc mieux acceptées et débrideront la créativité.

Les cas d’utilisation sont un excellent outil de spécification d’un produit logiciel. On leur consacre un chapitre spécifique car ils sont une discipline à part entière qui mérite un cadrage serré.

1. Historique

Dans l’historique de la discipline, on doit son invention à Ivar Jacobson lorsqu’il a introduit les diagrammes de cas d’utilisation dans le langage UML. À ce stade, on disposait de la notion d’Acteur, de Système et de Cas d’utilisation ainsi que des différentes relations qui pouvaient exister entre eux (associations, héritage, inclusion, extension…). Il manquait encore un formalisme de scénarisation, qui arrive plus tard avec des auteurs comme Alistair Cockburn dont l’ouvrage...

Diagrammes

Les diagrammes UML de cas d’utilisation ainsi que les relations entre les cas d’utilisation - généralisation, extension, inclusion - seront abordés en détail dans le chapitre Modélisation.

Use Case points

La technique des Use Case Points (UCP) est un outil d’estimation pour les chefs de projet qui permet de présumer des coûts d’implémentation dès les toutes premières phases du projet. Il peut être mis en pratique avec succès dans des processus centrés sur les cas d’utilisation, tels que RUP.

1. Pourquoi l’utiliser ?

Lorsqu’elle est bien utilisée (sur des cas d’utilisation correctement modélisés), cette technique donnera sensiblement les mêmes résultats que les estimations des experts basées sur les designs et l’implémentation. Comme les cas d’utilisation représentent finement les exigences des utilisateurs du système, il est naturel d’estimer la charge de travail sur la base de leur complexité plutôt qu’à l’aide d’autres techniques comme les function points ou le nombre de lignes de code. Un point très important qui plaide en faveur de cette technique est le fait que les outils modernes de génie logiciel permettent d’établir des matrices de traçabilité pour visualiser les dépendances entre tous les artefacts logiciels du produit (cas d’utilisation, exigences, composants, classes, tests…).

L’intérêt réel de cette technique réside dans sa confrontation avec des mesures productivistes telles que la vélocité pour les méthodes agiles. En estimant les Use Case Points avant chaque release d’un produit et en lui mettant en balance les estimations des experts techniques, les délais de production réels et la vélocité agile, on pourra affiner les valeurs des facteurs techniques et organisationnels.

2. Adoption

On doit reconnaître qu’on ne fait pas encore un usage intensif de cette méthode dans l’industrie. Les raisons de cette méfiance sont légitimes :

C’est une technique relativement récente, on a donc peu de recul vis-à-vis d’elle.
Cette technique n’est pas encore couverte par tous les outils de gestion de projet.
Le style de rédaction des cas d’utilisation varie énormément d’un auteur à l’autre.
La difficulté d’implémentation du même cas d’utilisation...

Étude de cas

Ce cas d’utilisation décrit comment un client de banque utilise un distributeur automatique de billets (DAB) pour retirer de l’argent en espèces à partir de son compte bancaire. Le système à l’étude est dans un premier temps exprimé sous forme d’exigences. Ensuite, la première étape de l’analyse consiste à offrir une meilleure compréhension de ces exigences sous forme de cas d’utilisation.

1. Exigences

Voici la liste des exigences pour construire un DAB :

1.	L’interface utilisateur du DAB doit être équipée d’un lecteur de carte magnétique, d’un clavier pour les entrées utilisateur, d’un écran pour afficher des informations à l’utilisateur, d’une sortie de distribution des billets et d’une imprimante pour sortir les reçus.
2.	Le clavier doit comporter les touches numériques, la touche entrée, la touche correction et la touche annulation.
3.	Le DAB doit communiquer avec la banque via Internet.
4.	Le DAB doit effectuer des étapes d’authentification au début de la session telles que : la carte est insérée, la carte doit être valide, on doit demander à l’utilisateur son code confidentiel, le code et la carte doivent être authentifiés vis-à-vis de la banque, il n’y a que trois essais possibles pour une carte.
5.	À la fin de la session, le DAB doit effectuer des opérations telles que : capturer la carte au bout de trois essais infructueux, afficher les messages d’erreur appropriés lorsqu’un problème survient et afficher le menu principal puis fournir un reçu à la fin de la session.
6.	Le reçu doit comporter la date, l’heure, la localisation de la machine, le numéro de compte et le montant de la transaction.
7.	Le DAB doit démarrer une transaction comportant des étapes de vérification : le retrait doit être autorisé par la banque et le montant nécessaire en espèces doit être présent dans la réserve de l’appareil.
8.	Le DAB doit supporter des fonctionnalités de diagnostic : journalisation de toutes les interactions avec le client ainsi que celles avec la banque...