Cas d'utilisation

En génie logiciel et en ingénierie des systèmes, un cas d'utilisation définit une manière d'utiliser le système et permet d'en décrire les exigences fonctionnelles. D'après Bittner et Spence, « Un cas d'utilisation, défini simplement, permet de décrire une séquence d'événements qui, pris tous ensemble, définissent un système faisant quelque chose d'utile ». Chaque cas d'utilisation contient un ou plusieurs scénarios qui définissent comment le système devrait interagir avec les utilisateurs (appelés acteurs) pour atteindre un but ou une fonction spécifique d'un travail. Un acteur d'un cas d'utilisation peut être un humain ou un autre système externe à celui que l'on tente de définir.

Les cas d'utilisation tentent d'éviter tout jargon technique et essayent au contraire d'adopter le langage de l'utilisateur final ou de l'expert du domaine. Les cas d'utilisation sont souvent écrits à la fois par les analystes, les utilisateurs finaux ou un expert. En UML, chaque cas d'utilisation est représenté au sein d'un diagramme de cas d'utilisation, chacun des scénarios de celui-ci étant décrit par un ou plusieurs diagrammes dynamiques : diagrammes d'activités, de séquence, diagrammes de communication ou d'états-transitions.

Dans l'Unified Process, l'ensemble des spécifications d'un système informatique sont décrites dans la vue des cas d'utilisation, celle-ci étant constituée de plusieurs cas d'utilisation, chacun correspondant, grosso-modo, à un incrément du cycle de développement. Un cas d'utilisation correspond, ici, à un ensemble autonome de fonctionnalités possédant une forte cohésion.

Historique

En 1986, Ivar Jacobson, par la suite contributeur important à la fois du langage UML (Unified Modeling Language) et du RUP (Rational Unified Process), codifia le premier la technique de la visualisation par modèle pour spécifier des cas d'utilisation. À l'origine, il utilisa les termes de scénarios d'usage (usage scenario) et cas d'usage (usage case) mais il trouvait que ces termes ne sonnaient pas bien en anglais. Il préféra le terme "use case" qu'il est commun de traduire par "Cas d'utilisation" en français. À sa suite, plusieurs contributeurs ont amélioré cette technique parmi lesquels on peut citer Kurt Bittner, Alistair Cockburn, Gunnar Overgaard et Geri Schneider.

Pendant les années 90, les cas d'utilisation devinrent une des pratiques les plus usitées pour travailler sur la relation fonctionnelle. Ils furent notamment populaires au sein de la communauté "orienté-objet", dont est issu le concept de cas d'utilisation. Cependant leur usage ne se résume pas aux systèmes orientés-objet, les cas d'utilisation n'étant pas orientés-objet par nature.

Écrire un cas d'utilisation

Un cas d'utilisation (use case) commence toujours par un verbe (au présent, évitez l'infinitif qui pourrait faire penser à une fonction et non à un cas d'utilisation décrivant une action (exemple: Afficher une image)) et s'attache ensuite à décrire les processus menant au bon fonctionnement de cette action (exemple: 1. L'application lit dans la base de données, l'application affiche l'image sur l'écran). Il est ici inutile de préciser tous les processus techniques menant aux actions, il suffit de les modéliser en langage simple et compréhensible. Les cas d'utilisation seront modélisés par des développeurs sous forme technique dans une seconde étape.

Les douze recommandations d'écritures d'Alistair Cockburn

1. Partir des grandes fonctions et se maintenir le plus possible au niveau objectif utilisateur.
2. Centrer son attention sur le cas nominal.
3. Préciser toujours les parties prenantes et leurs intérêts.
4. Utiliser le présent de l’indicatif.
5. Utiliser la voie active pour décrire les sous-objectifs en cours de satisfaction.
6. Le sujet doit être clairement localisable.
7. Rester concis et pertinent ; éviter les longs documents.
8. Éviter le conditionnel, et placer les comportements alternatifs dans les extensions.
9. Signaler les sous-cas d’utilisation, représentés par la relation d’inclusion « include ».
10. Identifier le bon objectif.
11. Signaler la portée.
12. Laisser de côté l’interface utilisateur.

Niveaux d'objectif

Les cas d'utilisation ont pour vocation de donner une représentation de la réalité à différents "niveaux d’abstractions". Il est indispensable que le lecteur est connaissance du niveau d'abstraction du cas d'utilisation qu'il étudie, ce afin de pouvoir mieux l'interpréter. Ces différents niveaux d'abstractions sont nommés en matière de cas d'utilisation niveaux d'objectif

• Niveau Stratégique : Il est ici question du contexte général, des fonctions principales du système ainsi que de ses objectifs. On parle également d'approche métier. Ce type d'objectif inclus plusieurs objectifs utilisateur et se caractérise par une durée relativement longue (semaines, années)
• Niveau Objectif utilisateur : Ce niveau est le niveau le plus important. Il s'agit de l'objectif poursuivi par un utilisateur lorsqu'il utilise le système. En ingénierie des procesus métier (Cockburn, 2003), on parle de processus métier élémentaire. On estime que sa durée est comprise entre 2 et 20 min
• Niveau Sous-fonctionnalité : Ils participent à la réalisation d'un objectif utilisateur auquel ils sont liés par une relation de type inclusion

Portée des cas d'utilisation

Si le niveau d’objectif renseigne sur le niveau de détail du cas d’utilisation, la portée elle indique le périmètre d’action. On distingue alors 3 niveaux de portée :

• La portée entreprise : on va s’attaquer alors aux fonctions importantes de l’entreprise

• La portée système : on va s’axer sur le projet en lui-même

• La portée sous-système : on va s’intéresser à une partie seulement du projet

Description textuelle d'un cas d'utilisation

Il est tout d'abord important de rappeler que l'UML ne préconise pas de format particulier pour la présentation. En la matière, et au-delà de la norme, c'est le livre d'Alister Cockburn qui fait référence. Ce dernier préconise une décomposition en trois grandes parties.

• Définition des interactions en cas de succès (Cas nominal).
• Cas particuliers et leurs contraintes diverses.
• Présentations du cas par des illustrations.

Exemple de format textuel selon Alister Cockburn

Dans le déroulé ci-dessous, les lignes en italiques sont optionnelles.

• Cas d'utilisation : (nom du cas d'utilisation)

• Acteur : (Acteur(s) principaux, déclencheurs du cas)
• Evénement déclencheur
• Parties prenantes et leurs intérêts : (sous forme de liste)
• Niveau : (Stratégique, Objectif utilisateur ou Sous-fonctionnalité)
• Portée : (Délimite le périmètre d'action du cas)
• Pré-conditions : (conditions requises pour que le cas soit applicable)
• Post-conditions : ( conséquences du succès de l'application du système)
• Scénario nominal : (Liste des différentes actions en cas de succès du système)
• Extensions : (Liste de tous les scénarios différents du nominal, suivis de leurs conditions de réalisations ainsi que de leurs action et éventuellement sous-cas d'utilisation)
• Contraintes : (Par exemple la confidentialité, réactivité des acteurs...
• Questions ouvertes : (permettent l'amélioration du cas en appuyant sur les zones d'ombres du projet)
• Annexes

Autre exemple de format textuel d'un cas d'utilisation  : "Inscription à un examen d'Université"

Cas d’utilisation numéro 1

Nom

• identification version 1.0
• Description : l’utilisateur se connecte en tapant l’url du site web et s’identifie dans la partie réservée à cet effet ;
• Acteurs : le membre ou l’utilisateur du site web ;
• Références : aucune pour le moment ;
• Préalables : site web opérationnel ;
• Conséquents : le membre est identifié et peut naviguer sur la partie lui étant réservée.

Séquences d’événements

• l’utilisateur ouvre le navigateur et tape l’url du site ;
• le système ouvre la page d’accueil du site ;
• l’utilisateur accède ainsi à la page d’accueil et s’identifie en rentrant son identifiant et son code personnel ;
• le système vérifie alors l’identification de l’usager et en fonction de la réponse permet ou non à l’utilisateur d’accéder à la partie réservée uniquement aux membres qui sont étudiants à l’université ;
• l’utilisateur qui réussit l’identification accède à la partie membres et découvre les services qui lui sont offerts.

Exceptions

• l’utilisateur s’identifie en rentrant son CIP et son code personnel ;
• le système décèle une erreur d’identification et offre une nouvelle possibilité d’identification en affichant un message d’erreur (Veuillez retaper votre CIP et votre code personnel) ;
• l’utilisateur essaye de s’identifier une seconde fois ;
• le système vérifie à nouveau le code personnel et le CIP ; si l’identification est réussie, le système permet alors l’accès à la zone membres, sinon il redonne une dernière chance à l’utilisateur avant de bloquer l’accès pendant une période donnée (T=10 minutes).

Avantages et limites des cas d'utilisation

Avantages

Les cas d'utilisation sont efficaces pour le recueil des exigences sur la base des scénarios d'utilisation d'un système car ils se focalisent sur les interactions acteurs / système selon les choix de leurs utilisateurs. Ils permettent également de préparer les tests de recette basés sur l'utilisation du système.

Limites

Par contre, ils masquent les règles métier derrière les interactions acteurs / système. Cette « invisibilité directe » des règles cause des problèmes d'accès direct à ces dernières lorsqu'on est amené à les faire évoluer suite aux changements des besoins.

Le mélange des interactions acteurs / système et des règles métier au sein des cas d'utilisation cause par ailleurs un handicap dans le cadre de l'évolution d'une Architecture Orientée Service (SOA) dont les services sont basés sur les cas d'utilisation. Une alternative basée sur la séparation des règles métier et des cas d'utilisation et permettant respectivement aux services SOA d'encapsuler les règles métier et aux cas d'utilisation de se focaliser seulement sur les choix de navigation des utilisateurs est proposée dans la démarche Goal-Driven SOA.

Voir aussi

• Diagramme des cas d'utilisation

Bibliographie

• (en) Ivar Jacobson, M. Christerson, P. Jonsson, G. Overgard, Object-Oriented software engineering: A use case driven approach, Addison Wesley Professional (réimpr. 1992) (ISBN 0201544350)
  Ouvrage de référence. Une ancienne édition est disponible en langue française. Une nouvelle édition anglaise est à paraître courant 2007.
• Alistair Cockburn, Rédiger des cas d'utilisation efficaces [« Writing effective use cases »], Eyrolles, 1999 (ISBN 2212092881, présentation en ligne)
  Également disponible en langue anglaise (ISBN 0201702258).

Liens externes

• (en) Notions fondamentales sur les cas d'utilisation, d'après A. Cockburn.