Cas d'utilisation, une introduction

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).

Table des matires

1. Introduction ...................................................................................................... 1 1.1. Avertissement ......................................................................................... 1 1.2. Expression des besoins ............................................................................. 2 2. Description textuelle des cas d'utilisation ................................................................ 2 2.1. Format de prsentation pour les cas d'utilisation ............................................ 2 2.2. Niveaux d'objectif ................................................................................... 5 2.3. Porte des cas d'utilisation ......................................................................... 5 3. Recommandations pour l'criture des cas d'utilisation ............................................... 6 3.1. Douze recommandations d'criture ............................................................. 6 3.2. Exemple ................................................................................................ 6 4. Exercices ......................................................................................................... 8 4.1. Remplacer sa photo ................................................................................. 8 4.2. Transfrer de compte compte .................................................................10 5. Reprsentation graphique des cas d'utilisation avec UML .........................................12 5.1. Introduction ..........................................................................................12 5.2. lments graphiques UML .......................................................................12 5.3. Relations entre cas d'utilisation .................................................................13 5.4. Relation entre acteurs ..............................................................................14 5.5. Classification des acteurs .........................................................................15 6. Conclusion ......................................................................................................16 7. Bibliographie ...................................................................................................16

1. Introduction
1.1. Avertissement
CERTA - Avril 2004 1

Cas d'utilisation, une introduction

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...)

1.2. Expression des besoins

Les cas d'utilisation sont recueillis, organiss, dcomposs dans la phase d'acquisition des besoins du projet. Qu'attendent les utilisateurs du futur systme ? Quel est le comportement attendu du systme face ces requtes? Etant donn que, par dfinition, l'utilisateur est le mieux plac pour parler de ses besoins, il est ncessaire d'utiliser un formalisme clair qui permet de faire participer cette phase des non informaticiens (reprsentant d'utilisateurs, experts du domaine ou autres managers...). UML propose un ensemble de symboles graphiques ddis la reprsentation des cas d'utilisation. L'usage excessif de ces symboles, que seuls les informaticiens peuvent dcoder, va parfois l'encontre des objectifs viss. En revanche, il est courant de prciser des cas d'utilisation par des diagrammes d'activits, de squence et d'tat/transition.

2. Description textuelle des cas d'utilisation

2.1. Format de prsentation pour les cas d'utilisation
UML n'impose ni ne prconise 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 succs (le cas nominal) accompagn d'informations de contexte, 2/ les variations du CERTA - Avril 2004 2

Cas d'utilisation, une introduction

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

CERTA - Avril 2004

Cas d'utilisation, une introduction

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.

Prsentation des items

Les acteurs , ce sont les acteurs dclencheurs du cas. La liste des parties prenantes et intrts met l'accent sur les objectifs mtier du cas, gnralement les acteurs bnficiaires du cas. Le niveau nous donne une indication de lecture (les dtails que l'on s'attend ou non trouver). La porte dlimite le primtre du cas. Les pr-conditions dfinissent les conditions de dclenchement du cas. Les post-conditions dterminent ce qui est vrai aprs l'excution du scnario nominal ralis avec succs.

CERTA - Avril 2004

Cas d'utilisation, une introduction

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]).

2.2. Niveaux d'objectif

Un cas d'utilisation, comme tout diagramme UML, permet de dcrire une ralit selon diffrents niveaux de raffinement. Il convient, entre autres, de signaler le "niveau d'abstraction" de la vue afin de permettre au lecteur une meilleure interprtation de ce qui est et n'est pas montr. Concernant les cas d'utilisation, nous parlons alors de niveaux d'objectif. Cockburn (Cockburn, 2003) dfinit trois niveaux d'objectif : Niveau stratgique Prsente le contexte gnral, les grandes fonctions du systme (approche mtier), ses objectifs. Un cas d'utilisation de niveau stratgique implique plusieurs objectifs utilisateur et s'tale gnralement sur plusieurs jours, semaines, mois ou annes. Exemple : 1/ L'tudiant s'inscrit une formation. 2/ L'tudiant s'inscrit des modules 3/ L'tudiant passe un examen partiel 4/ L'tudiant obtient son diplme. Niveau objectif utilisateur C'est l'objectif suivi par un acteur en interaction avec le systme. L'objectif utilisateur est celui qui reprsente le plus d'intrt. Il correspond au processus mtier lmentaire en ingnirie des processus mtier (Cockburn, 2003). Sa dure, de 2 20 minutes, peut tre rduite si le dclencheur est un systme. Exemple : Inscription un module. Niveau sous-fonctionnalit Ce sont des cas d'utilisation qui participent au bon droulement de cas d'utilisation de niveau objectif utilisateur. Un cas d'utilisation de sous-fonctionnalit remplit un objectif partiel d'un cas d'utilisation d'objectif utilisateur, auquel il est li par une relation d'inclusion (<<include>>). Exemple : Identifier un utilisateur.

2.3. Porte des cas d'utilisation

Alors que le niveau d'objectif renseigne sur la granularit (verticalit, niveau d'abstraction), la porte renseigne sur l'impact (horizontalit, primtre). CERTA - Avril 2004 5

Cas d'utilisation, une introduction

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. Recommandations pour l'criture des cas d'utilisation

Le coeur de la rdaction d'un cas d'utilisation se situe dans la description des tapes du scnario nominal lu. Le style d'criture doit tre clair, prcis et concis, sans ambigut.

3.1. Douze recommandations d'criture

La description des diffrentes tapes sert la fois l'utilisateur et le dveloppeur. Le langage naturel doit tre un minimum "guid" afin que tout le monde puisse s'y retrouver. N'oublions pas que le dveloppeur en dduit un systme dterministe qui doit satisfaire l'utilisateur final. Les recommandations essentielles prsentes ci aprs, sont largement discutes dans l'ouvrage de Cockburn (Cockburn, 2003). En voici un rsum : R1 : Partir du sommet (les grandes fonctions), et se maintenir le plus possible au niveau objectif utilisateur. R2 : Centrer son attention sur le cas nominal (un scnario typique de succs). R3 : Prciser toujours les parties prenantes et leurs intrts. R4 : Utiliser un verbe au prsent de l'indicatif chaque tape. R5 : Utiliser la voie active pour dcrire les sous-objectifs en cours de satisfaction. R6 : Le sujet doit tre clairement localisable (en dbut de phrase gnralement). R7 : Rester concis et pertinent (viter les longs documents). R8 : Eviter les si , et placer les comportements alternatifs dans les extensions . R9 : Signaler les sous-cas d'utilisation. Ils sont toujours reprsents par la relation d'inclusion include [13] d'UML. R10 : Identifier le bon objectif. R11 : Signaler la porte. R12 : Laisser de ct l'interface utilisateur.

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.

CERTA - Avril 2004

Cas d'utilisation, une introduction

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.

CERTA - Avril 2004

Cas d'utilisation, une introduction

Figure 1. Diagramme de squence systme

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.

CERTA - Avril 2004

Cas d'utilisation, une introduction

4.1.2. Une solution

Cas d'utilisation : Remplacer sa photo Acteur : Employ Parties prenantes et intrts : Employ : Souhaite changer sa photo d'identit. Entreprise : Souhaite disposer d'une collection de photos de ses employs continuellement mise jour.

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.

Extensions 1 4, L'employ peut annuler l'opration : Le cas s'arrte.

3a. l'employ n'est pas connu du systme : Retour en 1.

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.

CERTA - Avril 2004

Cas d'utilisation, une introduction

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.

4.2. Transfrer de compte compte

4.2.1. Enonc
Rcrire ce cas d'utilisation, en respectant les recommandations d'criture. Une personne, dcide de raliser des transferts de compte compte. 1. 2. 3. 4. 5. 6. 7. 8. 9. Le client se connecte au systme pour une opration de transfert. Le systme le reconnat et lui retourne la liste de ses comptes. Le client slectionne un de ses comptes. Le systme lui transmet le solde de ce compte. Le montant est saisi par le client. Le client slectionne un autre compte (compte de destination). Si le montant est suprieur au solde du compte, le systme en informe le client qui doit alors modifier le montant. Le systme demande confirmation du transfert au client. Le client confirme.

10. Le nouveau solde du compte slectionn est communiqu au client. 11. Si le client le souhaite, le client retourne en 3.

4.2.2. Une solution

CERTA - Avril 2004 10

Cas d'utilisation, une introduction

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.

7. Le client ne confirme pas : Retour en 2.

CERTA - Avril 2004

11

Cas d'utilisation, une introduction

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.

5. Reprsentation graphique d'utilisation avec UML

5.1. Introduction

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.

5.2. lments graphiques UML

Acteur : un bonhomme en fil de fer ( stick man ) ou une classe strotype <<actor>>. Son rle est dcrit sous ses pieds. Cas d'utilisation : une ellipse. Le nom du cas d'utilisation est plac soit dans l'ellipse soit en dessous. Association : (participation d'un acteur un cas d'utilisation) un trait plein pouvant tre orient (pointe de flche) et dcor (multiplicit).

Figure 2. Cas d'utilisation et acteur

CERTA - Avril 2004

12

Cas d'utilisation, une introduction

Figure 3. Exemple d'un cas d'utilisation : Changer sa photo

5.3. Relations entre cas d'utilisation

UML propose trois types de relations standard entre cas d'utilisation, <<include>> , <<extend>> et gnralisation . Les deux premires sont reprsentes par un strotype de dpendance, l'autre tant la relation de gnralisation reprsente en UML par une flche creuse pointe ferme. <<include>> : Strotype reprsentant le fait qu'un cas d'utilisation inclut un autre cas d'utilisation. On utilise ce strotype lorsque que l'on souhaite factoriser un cas d'utilisation partag par plusieurs autres cas d'utilisation. Par exemple, une opration de retrait et une opration de transfert ncessitent toutes deux une opration de vrification de l'identit du client.

Figure 4. Exemple de relation "include"

<<extend>> : Un cas d'utilisation peut dclarer 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 dun site marchand pour un fabricant de produit de beaut, on souhaite proposer certains visiteurs de promouvoir la marque dans leur rgion.

CERTA - Avril 2004

13

Cas d'utilisation, une introduction

Figure 5. Exemple de relation "extend"

Gnralisation : Une relation de gnralisation d'un cas d'utilisation B vers un cas d'utilisation A signifie que B est une spcialisation de A. Contrairement aux deux autres relations, la relation de gnralisation n'est pas un strotype. Elle indique qu'un cas d'utilisation est une variation d'un autre. Cette relation se diffrencie de <<extend>> par le fait que le cas d'utilisation peut varier en tout point de celui hrit. Par exemple dans l'UC "Retirer de l'argent", si il sagit de retirer de largent sur un compte sur livret le comportement de l'UC peut tre tout fait diffrent.

Figure 6. Exemple de relation de gnralisation

5.4. Relation entre acteurs

La relation de gnralisation est applicable dans le cas o un rle est une spcialisation ( une sorte de ) d'un autre.

CERTA - Avril 2004

14

Cas d'utilisation, une introduction

Figure 7. Exemple de la relation entre acteurs

Un client "boursicoteur" est un client comme un autre, mais ayant en plus la possibilit de consulter des informations boursires.

5.5. Classification des acteurs

Les acteurs sont des entits en interaction avec le systme. Le niveau de dtail de prsentation 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 fonctionnalits principales du systme ont t dfinies pour les acteurs principaux . Afin d'atteindre cet objectif, il est en gnral ncessaire de raliser des oprations en amont et en aval de ces fonctions principales. C'est le rle des acteurs secondaires . Cela peut tre par exemple la gestion des droits utilisateurs, la sauvegarde de la base de donnes, etc. Dans bien des cas, cette classification s'avre 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 [2]sur le thme des cas d'utilisation et sur l'approche objet en gnral). Un acteur peut avoir de multiples "personnalits", jouer plusieurs rles dans un ou plusieurs cas d'utilisation; on en identifie quatre (Miller, 2001) : initiateur , serveur , receveur et facilitateur . Initiateur : Rle jou par un acteur qui dclenche le cas, qui met en mouvement le systme. Serveur : Rle jou par un acteur lorsqu'il aide le systme assumer ses responsabilits. Receveur : Rle jou par un acteur lorsqu'il reoit des informations du systme (par exemple un

[2] http://tcros.free.fr/articles.htm

CERTA - Avril 2004

15

Cas d'utilisation, une introduction

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.

Figure 8. Exemple d'acteurs

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 ,

[3] http://www.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html [4] http://alistair.cockburn.us/usecases/usecases.html

CERTA - Avril 2004

16

Cas d'utilisation, une introduction

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,

OMG (2003). Spcification UML , http://www.omg.org/technology/documents/formal/uml.htm

Les adresses de sites indiques sont valides en date du 15 Avril 2004.

[5] http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html [6] http://magda.elibel.tm.fr/refs/UML/didacticiel.pdf [7] http://www-106.ibm.com/developerworks/library/j-jmod0508/index.html [8] http://www.omg.org/technology/documents/formal/uml.htm

CERTA - Avril 2004

17