 |
 |
 |
|
|
|
 |
Accueil | IGC | STG | BTSIG | Cours | Didactique | Exos | Glossaire | Labo | Sujets | Outils |  |
|
|
|
|
|
|
Travaux de relecture: Christine Gaubert-Macon, Valérie Emin 23 Avril 2004 Résumé Les cas d'utilisation sont définis par une description textuelle, décrivant les objectifs et interactions entre le système et ses acteurs. Le format de présentation textuelle des cas d'utilisation est libre, mais il existe quelques propositions reconnues dans le domaine, notamment l’ouvrage d’Alistair Cockburn Rédiger des cas d'utilisation efficaces aux éditions Eyrolles). UML propose certains concepts et formalismes dédiés à la représentation graphique des cas d'utilisation. Ainsi le système à concevoir peut-il être modélisé sous l'angle de ses responsabilités vis-à-vis de ses acteurs. Ce type de modèle, appelé Modèle des cas d'utilisation (UP/RUP), regroupe l'ensemble des cas d'utilisation du système. Les cas d'utilisation donnent une vue d'altitude des interactions visibles d'un système, ils ne fournissent pas d'information sur la structure interne. Ils mettent en évidence les rôles de ses utilisateurs, et contribuent à catégoriser ces derniers, définir leurs attentes (objectifs du système) et obligations (pilotage du système). La recherche des cas d'utilisation permet, en particulier, de formaliser les réponses aux questions : "Pourquoi" (les intentions du système) et "Pour qui" (les acteurs). Table des matières Le terme use case (cas d'utilisation) a été introduit par Ivar Jacobson en 1992 et fait partie intégrante d'UML. Toutefois, UML ne fournit pas de consignes d'écriture et ne précise pas de format de présentation textuelle pour les cas d'utilisation. Nous nous référons pour cela aux travaux de Alistair Cockburn (Cockburn, 2001) où dans la préface, il rappelle que l'écriture d'un cas d'utilisation est essentiellement du domaine de « l'écriture d'essais en prose, avec toutes les difficultés d'expression que suppose en général ce type d'exercice ». UML dispose d'une batterie de concepts et de formalismes graphiques (diagrammes de séquence, état-transition...) très utiles pour préciser un cas d'utilisation. Les symboles UML dédiés aux cas d'utilisation sont présentés au paragraphe UML et représentation des cas d'utilisation. Ce document a pour objectif de sensibiliser le lecteur à une approche d'expression des besoins dans un contexte de développement d'applications piloté par les cas d'utilisation. Les courtes définitions ci-dessous sont issues des spécifications UML. Un cas d'utilisation spécifie une séquence d'actions, avec variantes éventuelles, réalisée par le système en interaction avec des acteurs du système. Un acteur est une entité externe au système, en interaction avec ce dernier. L'entité est un rôle joué par un utilisateur, par exemple un comptable, ou par un autre système, un capteur par exemple. Un scénario est un chemin particulier au travers de la description abstraite et générale fournie par le cas d'utilisation (Muller, 2003). Les cas d'utilisation décrivent le comportement attendu des utilisateurs et du système. Le système offre des services à ses utilisateurs. La grande difficulté, pour le rédacteur de cas d'utilisation, est de se maintenir à ce niveau d'observation et de description (service), se centrant principalement sur le comportement superficiel du système, le POURQUOI. Il n'est toutefois pas interdit de modéliser l'état interne du système. Il en résulte un ensemble de documents compréhensibles par tout acteur du projet. Les cas d'utilisation permettent de ne pas perdre de vue les objectifs du système en construction. Ils pilotent le projet tout au long de sa vie. Ils sont le fil conducteur de tous les acteurs du projets (analystes, architectes, qualiticiens, managers, utilisateurs, clients, développeurs, testeurs...) Les cas d'utilisation sont recueillis, organisés, décomposés dans la phase d'acquisition des besoins du projet. Qu'attendent les utilisateurs du futur système ? Quel est le comportement attendu du système face à ces requêtes? Etant donné que, par définition, l'utilisateur est le mieux placé pour parler de ses besoins, il est nécessaire d'utiliser un formalisme clair qui permet de faire participer à cette phase des non informaticiens (représentant d'utilisateurs, experts du domaine ou autres managers...). UML propose un ensemble de symboles graphiques dédiés à la représentation des cas d'utilisation. L'usage excessif de ces symboles, que seuls les informaticiens peuvent décoder, va parfois à l'encontre des objectifs visés. En revanche, il est courant de préciser des cas d'utilisation par des diagrammes d'activités, de séquence et d'état/transition. UML n'impose ni ne préconise aucun format particulier de description textuelle des cas d'utilisation. Un cas d'utilisation est composé de deux grandes parties : 1/ La description des interactions dans un cas typique de succès (le cas nominal) accompagné d'informations de contexte, 2/ les variations du cas (cas particuliers, extensions), contraintes diverses, questions ouvertes et 3/ diverses illustrations comme des diagrammes de séquence système par exemple. A ce sujet, Craig Larman (Larman, 2003) détaille également la notion de contrats d'opération système . L'idée est de fournir un format de présentation textuelle à la fois souple et riche. En nous inspirant du livre d’Alistair Cockburn sur la question (CockBurn, 2003) , nous retiendrons le format suivant :
Les titres entre crochets sont considérés comme optionnels. Il est bien entendu que ce n'est qu'une simple recommandation . En phase d'élaboration, lors de la découverte des besoins, il convient de ne pas chercher l'exhaustivité dans la rédaction des cas d'utilisation. On peut très bien rédiger un cas ne comportant que son nom suivi des différentes étapes. Plusieurs exemples de rédaction sont présentés dans ce document, mais vous gagnerez à aller voir http://alistair.cockburn.us/ . Exemple Un établissement public d'enseignement technique met en place un système de portes ouvertes permanentes sur la toile. Les visiteurs sont invités à communiquer leurs coordonnées et divers renseignements.
Présentation des items
Un cas d'utilisation, comme tout diagramme UML, permet de décrire une réalité selon différents niveaux de raffinement. Il convient, entre autres, de signaler le "niveau d'abstraction" de la vue afin de permettre au lecteur une meilleure interprétation de ce qui est et n'est pas montré. Concernant les cas d'utilisation, nous parlons alors de niveaux d'objectif. Cockburn (Cockburn, 2003) définit trois niveaux d'objectif :
Alors que le niveau d'objectif renseigne sur la granularité (verticalité, niveau d'abstraction), la portée renseigne sur l'impact (horizontalité, périmètre). Trois sortes de portées sont fréquemment utilisées :
Le coeur de la rédaction d'un cas d'utilisation se situe dans la description des étapes du scénario nominal élu. Le style d'écriture doit être clair, précis et concis, sans ambiguïté. La description des différentes étapes sert à la fois l'utilisateur et le développeur. Le langage naturel doit être un minimum "guidé" afin que tout le monde puisse s'y retrouver. N'oublions pas que le développeur en déduit un système déterministe qui doit satisfaire l'utilisateur final. Les recommandations essentielles présentées ci après, sont largement discutées dans l'ouvrage de Cockburn (Cockburn, 2003). En voici un résumé :
Nous allons compléter la description du cas d'utilisation vu précédemment : un établissement public d'enseignement technique met en place un système de portes ouvertes permanentes sur la toile. Les visiteurs sont invités à communiquer leurs coordonnées et divers renseignements.
Réécrire ce cas d'utilisation, en respectant les recommandations d'écriture. Un employé souhaite changer sa photo stockée dans l'annuaire LDAP de son organisation.
Quelques commentaires
Réécrire ce cas d'utilisation, en respectant les recommandations d'écriture. Une personne, décide de réaliser des transferts de compte à compte.
Quelques commentaires
Un dessin vaut-il mieux qu'un court discours ? Non certainement pas dans le cas présent où les cas d'utilisation participent activement au cahier des charges d'un projet informatique. UML propose de représenter les cas d'utilisation sous une forme graphique nommée diagramme de cas d'utilisation appartenant au modèle des besoins. Les rôles sont définis pour chaque acteur. Une relation entre acteurs et cas représente une communication entre l'acteur et le cas. Le cas (d'utilisation) est représenté par une ellipse qui porte son nom (à l'intérieur ou en dessous). Des notes peuvent être portées sur le diagramme afin d'y ajouter des informations. Un diagramme de cas d'utilisation montre acteurs et cas d'utilisation ensemble avec leur relations. La relation entre un acteur et un cas d'utilisation est appelée association et correspond au fait que l'acteur participe à un cas d'utilisation. Les cas d'utilisation représentent les fonctionnalités d'un système, ou d'une entité d'un système, telles qu'elles sont sollicitées en interaction avec des événements extérieurs. Ils donnent une vision "haute" et dynamique du système.
UML propose trois types de relations standard entre cas d'utilisation, <<include>> , <<extend>> et généralisation . Les deux premières sont représentées par un stéréotype de dépendance, l'autre étant la relation de généralisation représentée en UML par une flèche creuse à pointe fermée. <<include>> : Stéréotype représentant le fait qu'un cas d'utilisation inclut un autre cas d'utilisation. On utilise ce stéréotype lorsque que l'on souhaite factoriser un cas d'utilisation partagé par plusieurs autres cas d'utilisation. Par exemple, une opération de retrait et une opération de transfert nécessitent toutes deux une opération de vérification de l'identité du client. <<extend>> : Un cas d'utilisation peut déclarer des points d'extension ( extension point ). Un point d'extension localise un endroit (un point) unique dans le cas d'utilisation. C'est dans les limites de ce point que d'autres cas d'utilisation pourront étendre ( extend ) le comportement initial du cas d'utilisation. C'est un moyen pratique de mettre en avant une fonctionnalité optionnelle. Par exemple, lors de la conception d’un site marchand pour un fabricant de produit de beauté, on souhaite proposer à certains visiteurs de promouvoir la marque dans leur région. Généralisation : Une relation de généralisation d'un cas d'utilisation B vers un cas d'utilisation A signifie que B est une spécialisation de A. Contrairement aux deux autres relations, la relation de généralisation n'est pas un stéréotype. Elle indique qu'un cas d'utilisation est une variation d'un autre. Cette relation se différencie de <<extend>> par le fait que le cas d'utilisation peut varier en tout point de celui hérité. Par exemple dans l'UC "Retirer de l'argent", si il s’agit de retirer de l’argent sur un compte sur livret le comportement de l'UC peut être tout à fait différent. La relation de généralisation est applicable dans le cas où un rôle est une spécialisation ( une sorte de ) d'un autre. Un client "boursicoteur" est un client comme un autre, mais ayant en plus la possibilité de consulter des informations boursières. Les acteurs sont des entités en interaction avec le système. Le niveau de détail de présentation d'un cas d'utilisation correspond à la vision de l'acteur auquel il est relié. Il est d'usage, mais absent de la norme UML, de distinguer les acteurs principaux des acteurs secondaires. Les fonctionnalités principales du système ont été définies pour les acteurs principaux . Afin d'atteindre cet objectif, il est en général nécessaire de réaliser des opérations en amont et en aval de ces fonctions principales. C'est le rôle des acteurs secondaires . Cela peut être par exemple la gestion des droits utilisateurs, la sauvegarde de la base de données, etc. Dans bien des cas, cette classification s'avère suffisante, toute fois certains professionnels proposent de l'affiner : Un acteur peut être humain ou purement informatique, hardware ou software (voir les articles de Thierry Cros sur le thème des cas d'utilisation et sur l'approche objet en général). Un acteur peut avoir de multiples "personnalités", jouer plusieurs rôles dans un ou plusieurs cas d'utilisation; on en identifie quatre (Miller, 2001) : initiateur , serveur , receveur et facilitateur .
Par convention, le lecteur s'attend à trouver, dans un diagramme de cas d'utilisation, les acteurs principaux à gauche du contexte des ellipses et les acteurs secondaires à droite, comme l'illustre l'exemple ci-dessous. Les cas d'utilisation jouent un rôle fondamental dans le cycle de vie d'un projet de développement logiciel. En phase initiale, ils permettent d' identifier les utilisateurs et de comprendre leurs attentes . En phase d'élaboration, les développeurs s'appuient sur eux pour découvrir les objets métier et constituer le modèle de domaine . Bertrand Meyer met en garde à ce sujet : il ne faut pas tomber dans le piège d'une conception descendante du système qui consisterait à déduire l'architecture du système directement de l'analyse, ce qui serait en exacte opposition avec une conception orientée objet. ( voir l’article ). En conception et en implémentation, les cas d'utilisation font office de garde-fou auprès des développeurs, leur permettant de garder en ligne de mire les objectifs utilisateur. Les cas d'utilisation sont d'une grande utilité pour la conception des tests fonctionnels et de la documentation utilisateur.
Les adresses de sites indiquées sont valides en date du 23 Avril 2004. |
||
|
_____________________________________________
|
