- 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'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'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.
Sommaire
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. 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. 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 ou substantif, é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'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.
Plan type d'un cas d'utilisation : "une 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).
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 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[2].
Voir aussi
Références
- (en) Ivar Jacobson, Kurt Bittner, Ian Spence, Use Case Modeling, Addison Wesley Professional, 2002 (ISBN 0-201-70913-9)
- Goal-Driven SOA
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) UseCase.com Forum
- (en) Notions fondamentales sur les cas d'utilisation, d'après A. Cockburn.
Wikimedia Foundation. 2010.
