Académique Documents
Professionnel Documents
Culture Documents
Cas D'utilisation, Une Introduction PDF
Cas D'utilisation, Une Introduction PDF
Olivier Capuozzo
Travaux de relecture: Christine Gaubert-Macon, Valrie Emin 13 Mars 2004 Les cas d'utilisation sont dfinis par une description textuelle, dcrivant les objectifs et interactions entre le systme et ses acteurs. Le format de prsentation textuelle des cas d'utilisation est libre, mais il existe quelques propositions reconnues dans le domaine, notamment louvrage dAlistair Cockburn Rdiger des cas d'utilisation efficaces aux ditions Eyrolles). UML propose certains concepts et formalismes ddis la reprsentation graphique des cas d'utilisation. Ainsi le systme concevoir peut-il tre modlis sous l'angle de ses responsabilits vis--vis de ses acteurs. Ce type de modle, appel Modle des cas d'utilisation (UP/RUP), regroupe l'ensemble des cas d'utilisation du systme. Les cas d'utilisation donnent une vue d'altitude des interactions visibles d'un systme, ils ne fournissent pas d'information sur la structure interne. Ils mettent en vidence les rles de ses utilisateurs, et contribuent catgoriser ces derniers, dfinir leurs attentes (objectifs du systme) et obligations (pilotage du systme). La recherche des cas d'utilisation permet, en particulier, de formaliser les rponses aux questions : "Pourquoi" (les intentions du systme) et "Pour qui" (les acteurs).
1. Introduction
1.1. Avertissement
CERTA - Avril 2004 1
Le terme use case (cas d'utilisation) a t introduit par Ivar Jacobson en 1992 et fait partie intgrante d'UML. Toutefois, UML ne fournit pas de consignes d'criture et ne prcise pas de format de prsentation textuelle pour les cas d'utilisation. Nous nous rfrons pour cela aux travaux de Alistair Cockburn (Cockburn, 2001) o dans la prface, il rappelle que l'criture d'un cas d'utilisation est essentiellement du domaine de l'criture d'essais en prose, avec toutes les difficults d'expression que suppose en gnral ce type d'exercice . UML dispose d'une batterie de concepts et de formalismes graphiques (diagrammes de squence, tat-transition...) trs utiles pour prciser un cas d'utilisation. Les symboles UML ddis aux cas d'utilisation sont prsents au paragraphe UML et reprsentation des cas d'utilisation. Ce document a pour objectif de sensibiliser le lecteur une approche d'expression des besoins dans un contexte de dveloppement d'applications pilot par les cas d'utilisation. Les courtes dfinitions ci-dessous sont issues des spcifications UML. Un cas d'utilisation spcifie une squence d'actions, avec variantes ventuelles, ralise par le systme en interaction avec des acteurs du systme. Un acteur est une entit externe au systme, en interaction avec ce dernier. L'entit est un rle jou par un utilisateur, par exemple un comptable, ou par un autre systme, un capteur par exemple. Un scnario est un chemin particulier au travers de la description abstraite et gnrale fournie par le cas d'utilisation (Muller, 2003). Les cas d'utilisation dcrivent le comportement attendu des utilisateurs et du systme. Le systme offre des services ses utilisateurs. La grande difficult, pour le rdacteur de cas d'utilisation, est de se maintenir ce niveau d'observation et de description (service), se centrant principalement sur le comportement superficiel du systme, le POURQUOI. Il n'est toutefois pas interdit de modliser l'tat interne du systme. Il en rsulte un ensemble de documents comprhensibles par tout acteur du projet. Les cas d'utilisation permettent de ne pas perdre de vue les objectifs du systme 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, dveloppeurs, testeurs...)
cas (cas particuliers, extensions), contraintes diverses, questions ouvertes et 3/ diverses illustrations comme des diagrammes de squence systme par exemple. A ce sujet, Craig Larman (Larman, 2003) dtaille galement la notion de contrats d'opration systme . L'ide est de fournir un format de prsentation textuelle la fois souple et riche. En nous inspirant du livre dAlistair Cockburn sur la question (CockBurn, 2003) , nous retiendrons le format suivant : Cas d'utilisation : <ici le nom du cas d'utilisation> Acteur : <ici le nom du ou des acteurs principaux, dclencheurs du cas> [Evnement dclencheur] : <ici l'vnement dclencheur du cas> Parties prenantes et intrts : <listes des parties prenantes et leurs intrts> Niveau : <ici une valeur parmi { Stratgique, Objectif utilisateur, Sous-fonctionnalit }> Porte : <ici la porte du cas> (voir plus loin) [Pr-conditions] : <ici les pr-conditions ventuelles> [Post-conditions] : <ici les post-conditions ventuelles> Scnario nominal 1. 2. 3. 4. <description de l'action> <description de l'action> ... <description de la dernire action avant la fin du cas>
[Extensions] <numro de l'tape> : <condition> : <action ou sous-cas d'utilisation> <numro de l'tape> : <condition> : <action ou sous-cas d'utilisation>
[Contraintes] ... [Questions-ouvertes] ... [Annexes] ... Les titres entre crochets sont considrs comme optionnels. Il est bien entendu que ce n'est qu'une simple recommandation . En phase d'laboration, lors de la dcouverte des besoins, il convient de ne pas chercher l'exhaustivit dans la rdaction des cas d'utilisation. On peut trs bien rdiger un cas ne comportant que son nom suivi des diffrentes tapes. Plusieurs exemples de rdaction sont prsents dans ce document, mais vous gagnerez aller voir http://alistair.cockburn.us/ [1].
[1] http://alistair.cockburn.us/usecases/usecases.html
Exemple Un tablissement public d'enseignement technique met en place un systme de portes ouvertes permanentes sur la toile. Les visiteurs sont invits communiquer leurs coordonnes et divers renseignements. Cas d'utilisation : Communiquer des renseignements Acteur : visiteur Parties prenantes et intrts : Visiteur : il veut communiquer ses coordonnes l'tablissement afin d'tre contact ultrieurement sur les formations qu'il aura slectionnes. Service Administratif : il veut pouvoir contacter, en temps voulu, les personnes ayant manifest un intrt pour les formations disponibles dans l'tablissement.
Niveau : Objectif utilisateur Porte : Systme Porte Ouverte Pr-conditions : aucune Post-conditions : Les donnes communiques par le visiteur sont accessibles par le service administratif. Scnario nominal 1. 2. 3. 4. 5. 6. Le visiteur communique au systme un choix de formation. Le systme communique un formulaire d'identification. Le visiteur s'identifie. Le systme prsente un formulaire correspondant la formation choisie. Le visiteur renseigne le formulaire et le soumet au systme. Le systme lui confirme l'enregistrement des informations.
Le scnario nominal est un scnario typique de succs. Il raconte, tape par tape, l'histoire des interactions entre acteur et systme, dans le meilleur des cas, ou plus prcisment dans le meilleur des scnarios . Les extensions correspondent aux autres scnarios possibles, avec branchements et incidents de parcours, conduisant aussi bien au succs qu' l'chec. Ils sont de la forme <condition : tapes numrotes >. contraintes : ce sont les contraintes non fonctionnelles, telles que temps de rponse, capacit de monte en charge, confidentialit, date de disponibilit, format de stockage des donnes... questions ouvertes : tout questionnement susceptible de pointer des zones d'ombre. Annexe : Illustrations et autres informations concernant le cas. On peut, ici, prsenter une instance du cas d'utilisation (scnario) sous la forme d'un diagramme de squence systme (DSS) par exemple. Un DSS (Larman, 2003) est un diagramme de squence de haut niveau reprsentant les interactions entre les acteurs externes et le systme, ce dernier tant vu comme une bote noire (voir exemple de DSS [7]).
Trois sortes de portes sont frquemment utilises : Entreprise : Concerne les processus gnraux d'une organisation. Systme : Centr sur le logiciel concevoir. Sous-systme : Restreint une partie seulement du logiciel, par exemple un framework , une couche technique ou un sous-ensemble fonctionnel.
3.2. Exemple
Nous allons complter la description du cas d'utilisation vu prcdemment : un tablissement public d'enseignement technique met en place un systme de portes ouvertes permanentes sur la toile. Les visiteurs sont invits communiquer leurs coordonnes et divers renseignements.
Cas d'utilisation : Communiquer des renseignements Acteur : visiteur Parties prenantes et intrts : Visiteur : il veut communiquer ses coordonnes l'tablissement afin d'tre contact ultrieurement sur les formations qu'il aura slectionnes. Service Administratif : il veut pouvoir contacter, en temps voulu, les personnes ayant manifest un intrt pour les formations disponibles dans l'tablissement.
Niveau : Objectif utilisateur Portee : Systme Porte Ouverte Pr-conditions : aucune Post-conditions : Les donnes communiques par le visiteur sont accessibles par le service administratif. Scnario nominal 1. 2. 3. 4. 5. 6. Le visiteur communique au systme un choix de formation. Le systme communique un formulaire d'identification. Le visiteur s'identifie. Le systme prsente un formulaire correspondant la formation choisie. Le visiteur renseigne le formulaire et le soumet au systme. Le systme enregistre les informations et signale le succs de l'opration.
Extensions *. A tout moment : le visiteur peut abandonner l'opration en cours. 1a. Le visiteur est dj authentifi : aller en 4 2a. Le visiteur n'est pas connu du systme : sous-cas d'utilisation Cration visiteur 5a. Certains champs obligatoires ne sont pas renseigns : aller en 4.
Contraintes Temps de rponse : La rception d'une rponse l'identification (tape 4) ne doit pas dpasser 3 secondes.
Annexe Illustration du cas par un scnario reprsent par un diagramme de squence systme (DSS). Dans ce scnario, le visiteur est connu du systme et n'abandonne pas l'opration.
4. Exercices
4.1. Remplacer sa photo
4.1.1. Enonc
Rcrire ce cas d'utilisation, en respectant les recommandations d'criture. Un employ souhaite changer sa photo stocke dans l'annuaire LDAP de son organisation. 1. 2. 3. 4. 5. 6. 7. 8. L'utilisateur fournit son login et son mot de passe. Si le systme le reconnait, alors aller en 5. Si le systme ne le reconnat pas, alors aller en 1. Le systme transmet la photo l'utilisateur. L'utilisateur peut slectionner une nouvelle photo, via un explorateur et une liste droulante . La photo est transmise au systme. Si la photo est au bon format, le systme remplace l'ancienne par la nouvelle. Le systme informe l'utilisateur que l'opration s'est bien droule.
Niveau : Objectif utilisateur Portee : Gestion des informations des employs Scnario nominal 1. 2. 3. 4. 5. 6. Le systme communique un formulaire d'identification. L'employ renseigne les champs et valide le tout. Le systme transmet la photo de l'employ. L'employ slectionne une autre photo qu'il transmet au systme. Le systme remplace l'ancienne photo par la nouvelle. Le systme confirme le succs de l'opration.
3b. l'employ n'a pas encore de photo : Le systme transmet l'image d'un pingouin ;-).
4, le systme ne reconnat pas le format de l'image transmise par l'employ : Le systme en informe l'employ. Retour en 3.
Questions ouvertes Faut-il se proccuper du poids de l'image transmise par l'employ ? (du point de vue systme de rception et systme de stockage).
Quelques commentaires
Les traitements conditionnels sont placs dans les extensions . Nous remarquerons que la rfrence au moyen de stockage (LDAP) est absente de la solution. Selon le cas, le serveur LDAP pourrait apparatre dans les contraintes . Les composants IHM ( explorateur, liste droulante ) ne sont plus mentionns. La voie active remplace la voie passive (tape 3 de la solution). La rdaction des extensions favorise la dcouverte de problmes venir, par exemple le cas "absence de photo" et le problme du poids. L'un est rgl par une extension, l'autre fait l'objet d'une question ouverte.
10. Le nouveau solde du compte slectionn est communiqu au client. 11. Si le client le souhaite, le client retourne en 3.
Cas d'utilisation : Transfrer de compte compte Acteur : Client Parties prenantes et intrts : Client : Souhaite grer ses comptes. Banque : Souhaite soulager les oprations guichet, en dlguant au titulaire de comptes la gestion de ses derniers pour des oprations courantes.
Post-condition : Le solde global des comptes reste inchang. Niveau : Objectif utilisateur Portee : Auto-gestion des comptes client Scnario nominal 1. 2. 3. 4. 5. 6. 7. 8. Le client se connecte (sous cas d'utilisation : "identification client"). Le systme retourne la liste de ses comptes. Le client slectionne un de ses comptes (compte source). Le systme lui transmet le solde de ce compte. Le client saisit un montant transfrer (du compte slectionn) et un compte de destination. Le systme demande confirmation du transfert au client. Le client confirme. Le systme communique le solde des comptes slectionns.
--- le client peut retourner au point 2 pour poursuivre les oprations de transferts --Extensions 1. Le client ne peut se connecter : Le cas s'arrte.
6. Le montant du transfert est plus lev que le solde du compte source : Le systme informe le client du dpassement. Retour en 2.
11
Quelques commentaires
Le scnarion alterne action de l'acteur et rponse du systme. Un trop grand dsquilibre de cette squence type (acteur/systme), par exemple peu d'actions utilisateur et beaucoup de rponses systme (ou inversement), peut tre le signe d'une mauvaise rdaction. La boucle est note sous forme de commentaire (et non comme tape) dans la partie descriptive du scnario.
des
cas
Un dessin vaut-il mieux qu'un court discours ? Non certainement pas dans le cas prsent o les cas d'utilisation participent activement au cahier des charges d'un projet informatique. UML propose de reprsenter les cas d'utilisation sous une forme graphique nomme diagramme de cas d'utilisation appartenant au modle des besoins. Les rles sont dfinis pour chaque acteur. Une relation entre acteurs et cas reprsente une communication entre l'acteur et le cas. Le cas (d'utilisation) est reprsent par une ellipse qui porte son nom ( l'intrieur ou en dessous). Des notes peuvent tre portes 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 appele association et correspond au fait que l'acteur participe un cas d'utilisation. Les cas d'utilisation reprsentent les fonctionnalits d'un systme, ou d'une entit d'un systme, telles qu'elles sont sollicites en interaction avec des vnements extrieurs. Ils donnent une vision "haute" et dynamique du systme.
12
13
14
[2] http://tcros.free.fr/articles.htm
15
SGBD ou un systme de backup ). Facilitateur : Rle jou par un acteur lorsqu'il ralise une action pour le bnfice d'un autre (un guichetier pour un client par exemple).
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.
6. Conclusion
Les cas d'utilisation jouent un rle fondamental dans le cycle de vie d'un projet de dveloppement logiciel. En phase initiale, ils permettent d' identifier les utilisateurs et de comprendre leurs attentes . En phase d'laboration, les dveloppeurs s'appuient sur eux pour dcouvrir les objets mtier et constituer le modle de domaine . Bertrand Meyer met en garde ce sujet : il ne faut pas tomber dans le pige d'une conception descendante du systme qui consisterait dduire l'architecture du systme directement de l'analyse, ce qui serait en exacte opposition avec une conception oriente objet. ( voir larticle [3]). En conception et en implmentation, les cas d'utilisation font office de garde-fou auprs des dveloppeurs, 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.
7. Bibliographie
Ambler, S.W. (2003) The Elements of UML Style , Londres : Cambridge University Press. Cockburn, A. (2001). Rdiger des cas d'utilisations efficaces , Paris : Eyrolles. (voir aussi : http://alistair.cockburn.us/ [4]) Meyer, B. (1997). UML: the positive spin ,
16
http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html [5] Muller, PA., Gaertner, N. (2003). Modlisation objet avec UML , Paris : Eyrolles. Muller, PA. (). Didacticiel de modlisation http://magda.elibel.tm.fr/refs/UML/didacticiel.pdf [6] Larman, C. (2003). UML et les design patterns , Paris : Campus Press. Miller, G. (2001). Introduction to diagramme http://www-106.ibm.com/developerworks/library/j-jmod0508/index.html [7]
[8]
objet
avec
UML,
sequence,
17