Use case

 Ne pas confondre avec les diagrammes de 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 »^[1]. 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'utilisations 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'utilisations 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, qui fut, par la suite, un contributeur important à la fois du langage UML Unified Modeling Language (Unifed Modeling Langage) et du RUP Unified Process (Rational Unified Process), a le premier codifié la technique de la visualisation par modèle pour spécifier des cas d'utilisation. A 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 en anglais . Il préféra le terme "use case" qu'il est commun de traduire par "Cas d'utilisation" en français. A 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. Notamment, ils furent populaires au sein de la communauté "orienté-objet" d'où le concept de Cas d'utilisation est issu, mais leur usage ne se résume pas aux systèmes orientés-objet, parce que les Cas d'utilisation ne sont 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 ou participe présent, évitez l'infinitif qui pourrait faire penser à une fonction et non à un cas d'utilisation) décrivant une action (exemple: Affichage d'une image) et s'attachera 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, mais de les modéliser en langage simple et compréhensif. Les cas d'utilisation seront modélisés par des développeurs sous forme technique dans une seconde étape.

Plan type d'un cas d'utilisation

voici un exemple de cas d'utilisation Cas D’utilisations 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 a la page d’accueil et s’identifie en rentrant son CIP et son Code personnel si toutefois il désire bénéficier des services de la PECUS (Puisque pour pouvoir acheter vendre échanger ou louer des livres il faudrait déjà être étudiant a l’université de Sherbrooke et donc avoir un CIP et un code d’accès).

- Le Système vérifie alors l’identification de l’usager et dépendamment de la réponse permet ou pas a l’utilisateur d’accéder a la partie réservée uniquement aux membres qui sont les étudiants de l’université.

- L’utilisateur qui réussit l’identification accède a la partie Membre 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 "membre", sinon il redonne une dernière chance à l’utilisateur avant de bloquer l’accès pendant une période donnée (T=10min).

Les cas d'utilisation dans le processus du développement logiciel

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 causent 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

Références

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].
  Egalement disponible en langue anglaise (ISBN 0201702258).
   

Liens externes

• (en) UseCase.com Forum
• (en) Notions fondamentales sur les cas d'utilisation, d'après A. Cockburn.
• (en) Estimer Redmine de isotrol.org: plugin de redmine pour estimer un projet software en point de cas d'utilisation et point de fonction.