Version du 02-12-05, Mise jour le 03-07-22

FICHE TECHNIQUE

Les cas dutilisation1 dUML

A use case is a collection of possible sequences of interactions between the system
under discussion and its external actors, related to a particular goal2 Alistair Cockburn3

Le cas dutilisation est une des techniques utilises pour modliser une organisation ou un systme dinformation au moyen du langage de modlisation standardis UML4 (Unified Modeling Language). Le cas dutilisation tire son origine de la mthode OOSE (Object-Oriented Software Engineering) de Ivar Jacobson, un des trois crateurs dUML. Un cas dutilisation dcrit ce que fait un systme (le quoi ) et non comment il le fait. Gnralement, il prsente la vision qua un utilisateur externe dun systme et il aide communiquer cette vision des fonctionnalits du systme aux autres acteurs. Il sagit donc principalement dune technique danalyse centre sur lusager. Lusage des cas a cependant t tendu pour montrer aussi des interactions internes au systme, avec les sous-systmes et aux objets. Les cas dutilisation sont prsents la fois sous forme de diagramme et sous forme de description textuelle standardise. Le cas dutilisation sert principalement, la phase de planification, capturer et clarifier les besoins fonctionnels et techniques, notamment en servant doutil de communication avec le client. Il est aussi la base de la conception, puisquil permet lidentification des classes, de leurs attributs, des oprations et la segmentation du travail en modules. Il peut aussi servir tester le systme conu laide des scnarios prioritaires. Comme lensemble de lapproche de modlisation en UML, il met lemphase sur la modularit, en dcomposant chaque processus en squences dactions et la rutilisation, en permettant de rutiliser ces squences dans dautres cas ou dutiliser de nouveau les cas pour un autre systme. Il fait aussi partie dune dmarche itrative, o on revient complter linformation au fur et mesure du dveloppement, et incrmentale, chaque lment tant affin et dtaill chaque itration. Le cas dutilisation nest pas une technique aussi formalise que les autres mthodes dUML. Une des faons de construire les cas dutilisation est de : 1. Dlimiter le systme ltude. Il peut sagir par exemple dun systme dinformation ou dun processus. 2. Identifier qui utilisera le systme : ce seront les acteurs du cas. Un acteur nest pas une personne mais un rle jou par une personne ou un systme. Un acteur primaire a besoin du systme pour accomplir un de ses buts. Le systme est lui-mme un acteur primaire. Les acteurs primaires peuvent tre externes. Il sagira alors gnralement de personnes, de groupes ou dautres systmes. Les acteurs internes sont des sous-systmes ou des objets du systme. On identifiera comme acteurs secondaires les autres participants; ce sont gnralement des personnes ou systmes qui reoivent ou fournissent de linformation5, ou soccupent de la supervision ou de lentretien du systme.

1 2

Use Case en anglais. Traduction : Un cas dutilisation est une collection de squences dinteraction possibles entre le systme ltude et ses acteurs externes, en relation avec un but particulier 3 Voir http://www.usecases.org/ 4 Les termes en italique et en caractre gras renvoient une autre fiche technique. 5 Ils sont parfois dfinis comme un acteur dont le systme a besoin pour raliser lobjectif.

Gilles E. St-Amant

On peut aussi choisir dlaborer les cas dutilisation en identifiant dabord les vnements externes au systme, lis ensuite aux acteurs. 3. Pour chaque acteur, tablir ses objectifs6 ou, en dautres mots, quels sont les rsultats attendus par lacteur en cause de ce systme. Les objectifs peuvent tre formuls sous forme de questions de type: Comment lacteur peut-il atteindre le rsultat x ? ; par exemple : Comment le client dun guichet automatique peut-il retirer de largent ? . Lensemble des scnarios lis un objectif constituera un cas dutilisation. Le nombre de cas peut cependant devenir important. Il faut donc se centrer, particulirement dans cette premire itration, sur les objectifs principaux. 4. Fixer lvnement dclencheur (dbut) et les conclusions possibles (fin) du cas. Chaque scnario du cas se termine quand le but est ralis ou abandonn. 5. Rsumer le cas en quelques phrases, en spcifiant lobjectif poursuivi par lacteur principal , ce qui dclenche le cas et ce qui y met fin et les principales actions qui sy droulent, de faon bien communiquer, tant aux utilisateurs quaux programmeurs, lintention et le contenu du cas. Cas dutilisation : Acteur principal : Acteurs secondaires : Type de cas: Objectif Dbut : Fin Rsum des actions No et nom Acteur x Nil Primaire ou secondaire Ex : Obtenir Ce cas commence quand lacteur x. Il se termine quand Lorsque lacteur principal a., le systme.

6. Construire le ou les diagrammes de cas dutilisation. La reprsentation des cas dutilisation est simple. Le cas est plac dans un ovale. Chaque acteur prend la forme dun bonhomme allumette et chaque communication la forme dun trait. Le systme ltude est reprsent par un rectangle.
Systme ltude Cas dutilisation Acteur

7. Revoir les cas. Assurez-vous que chaque cas correspond bien un objectif de lutilisateur et non une simple modalit dopration de votre systme. Noubliez pas quun cas reprsente une fonctionnalit de haut niveau et non une opration marginale. 8. tablir la priorit des cas. On recommande gnralement de dvelopper dabord les cas primaires cest--dire les processus majeurs, principalement ceux mettant en cause lacteur principal client . On dterminera ultrieurement les processus secondaires (ou mineurs) et les processus optionnels. 9. Valider avec le client. Les cas dutilisation permettent un dialogue avec les clients et les usagers et facilitent ainsi la comprhension des besoins et du systme par toutes les parties prenantes. Comme ils sont la base des dveloppements ultrieurs, il est important quils traduisent bien les oprations voulues. De l, la ncessit de valider dabord la pertinence des cas choisis..

6 Certains auteurs prfrent dabord dfinir les responsabilits des acteurs, puis les diffrents objectifs associs chaque responsabilit.

Gilles E. St-Amant

Une fois cette premire itration complte, il faut dtailler les cas et donc dvelopper leur description textuelle. Pour chacun 10. Identifier les conditions de succs et dchec (sialorsautrement). Chaque condition mnera deux ou plusieurs scnarios diffrents, lensemble constituant le cas dutilisation. Il peut sagir de scnarios de succs (le but est atteint), dchec (le but est abandonn) et, parfois, de succs partiel. 11. Dvelopper le scnario principal. On dveloppe dabord le cheminement principal (main course) cest--dire la squence dinteractions courante o tout se droule comme prvu, sans chec. Une squence est un groupe dinteractions, manuelles ou automatises, qui na pas dalternatives ou dembranchements. Une interaction peut tre un simple message. On peut donc identifier les interactions partir des messages. Les interactions dcrivent un change entre un acteur et un systme; gnralement, ils auront donc la forme : lment temporel + acteur primaire + action , suivie de condition + systme + action . Gardez la description un niveau gnral, sans tenir compte des particularits de linterface (ex :. aprs avoir consult les renseignements gnraux, le client choisit une catgorie de produits , plutt que : aprs avoir atteint lindex, le client appuie licne dun produit ). Vous viterez ainsi de faire trop htivement des choix technologique et de design et garderez le texte lisible pour les non-initis. Chaque interaction est gnralement numrote et spars par un bris de paragraphe. Le plus souvent, on dbute par des descriptions brves qui seront dtailles dans des cycles ultrieurs. On ajoute donc au tableau prcdent une description qui peut prendre la forme suivante : Version : Description : No de la version et date de la mise jour tape Action 1. 2. 3. Ex : sources consultes et/ou raison dune modification Le nombre doccurrences sur une priode pr-dtermine Nom du rdacteur

Commentaires : Frquence prvue : Auteur du cas :

Une fois lensemble des scnarios principaux dtaills : 12. Dterminer les variations. Les variations sont le plus souvent des moyens alternatifs utiliss dans le cadre du scnario, par exemple : un contact peut provenir dun client actuel, pass ou dun nonclient; un contact peut tre fait par lettre, tlphone ou tlcopieur. 13. Rdiger les extensions. Une extension se produit quand une interaction choue ou, en dautres mots, si une condition ne se ralise pas. Lextension porte le nom de cette condition, par exemple : Code Didentification Erron . 14. Comparer les cas pour y trouver des inclusions ou fragments communs. Il sagit dlments communs plus dun cas qui contribuent rendre les cas rutilisables. . Ils doivent tre formuls pour pouvoir simbriquer intgralement dans le cas 15. Valider, de nouveau, avec le client. Il est important que le client valide aussi les activits incluses dans les cas. Il faut donc lui soumettre aussi les cas dvelopps. 16. Dtailler et complter au besoin. Ne tentez toutefois pas de tout inclure dans les cas dutilisation : utilisez plutt les autres modles dUML. Pour tre utiles, les cas ne doivent pas devenir dmesurment complexes : ne dtaillez que lorsque cest clairement utile. 17. Complter le diagramme de cas dutilisation, en y ajoutant les extensions et les fragments communs.

Gilles E. St-Amant

Exemple Louis, informaticien chez Dbut, une jeune entreprise de formation multimdia, doit modliser le systme de commande de formation par Internet que Dbut veut mettre en place. Comme certains des membres de son quipe connaissent UML et quil sagit l dun standard reconnu, il dcide de lutiliser pour la modlisation, en commenant par la dfinition des besoins au moyen de cas dutilisation. 1. Le systme dlimiter sera dans ce cas le systme de commerce lectronique de Dbut. Louis le voit cependant comme plus large que le systme informatis et veut plutt couvrir tout le processus qui mne la livraison dune commande. 2. Parmi les acteurs Identifier, Louis sait dj quils incluront des systmes : les bases de donnes internes de lorganisation sur ses clients et celles des banques qui traiteront le paiement des transactions. Les autres acteurs comprendront bien entendu, comme acteurs primaires, les clients externes. Louis se sert de certains lments de lanalyse des parties prenantes pour identifier dautres utilisateurs potentiels. Pour complter son identification des acteurs et commencer prciser leurs objectifs et les scnarios qui y sont lis, il rencontre les reprsentants des diffrents services de Dbut touchs par le projet : Ahmed des ventes et Monique du soutien pour dterminer les principaux scnarios lis aux clients, puis Lise des finances pour tablir ceux lis au transit des paiements, Frdric de lexpdition pour clarifier les modes de livraison et ses propres collgues des services techniques, pour tablir les principales activits lies la mise jour et lentretien du systme. Aprs cette premire discussion, il exclut les fournisseurs daccs Internet de sa premire liste dacteurs, mais y inclut, en plus des deux systmes et des clients, la banque du client et celle de Dbut, le webmestre qui concevra et mettra jour le site, conjointement avec les concepteurs des formations, le vendeur qui utilisera les donnes clients pour le solliciter, via le site ou autrement, le commis la livraison, qui prpare la commande et le transporteur qui la livre, de mme que les responsables du soutien aux usagers, qui rpondent leur demande. 3. Pour chaque acteur, il dresse une premire liste dobjectifs. Ainsi, un client externe peut avoir pour objectif dobtenir de linformation, dobtenir un produit ou dobtenir de laide en relation avec le produit. Chaque objectif peut se subdiviser en sous-objectifs. Par exemple, dans le deuxime cas, le client voudra successivement commander, payer et recevoir le produit de formation. Louis se demande sil fera de cet objectif dobtention du produit un seul cas ou plusieurs. Il dcide de dvelopper le cas commander pour voir sil sera dun niveau trop ou pas assez dtaill. 4. Dans le cas commander , lvnement dbute lorsque le client indique quil veut commander et se termine quand le client a soit complt son bon de commande, soit abandonn le processus de commande. 5. Il rsume le cas commander en utilisant le tableau ci-dessous et fait de mme pour tous les autres acteurs et objectifs identifis. Cas dutilisation : 01- Commander un produit Client Acteur principal : Acteurs secondaires : Base de donnes client Primaire Type de cas: Se procurer facilement le produit voulu Objectif Ce cas commence quand le client indique au systme quil est prt Dbut : commander. Il se termine quand le bon de commande est complt avec succs Fin ou que le client abandonne la commande Une fois le client prt commander, le systme lui demande de Rsum des actions sidentifier, vrifie ou enregistre son identit, lui soumet un bon de commande complter, fait le total de ses achats et lui demande de le confirmer.

Gilles E. St-Amant

6. Il construit le diagramme de cas dutilisation principal. Il prvoit le dtailler en construisant un diagramme plus toff pour chaque acteur.
Concevoir Site

Webmestre

Systme de commerce lectronique

Mettre jour Information Obtenir Information Commander

Concepteur Enregistrer Client Vendeur Valider Commande Base Donnes Clients Autoriser livraison Prparer Commande Solliciter Client

Payer Client

Commis Livreur Vrifier le crdit Banque Client Transfrer fonds

Confirmer Paiement

Avoir du soutien Recevoir le produit Soutien

Banque Compagnie

Transporteur

7. Louis revoit les cas. Il constate par exemple que le transporteur est un acteur secondaire du cas Prparer Commande et donc quun lien devrait tre ajout du cas lacteur. 8. Il tablit la priorit des cas. Il prvoit dvelopper dans une premire phase les cas centraux la commande lectronique, cest--dire les cas commander et payer du client et les trois cas relis de la base de donnes clients. Il dvelopperait ensuite obtenir de linformation , les clients ayant dj accs des sources alternatives de renseignements, reverrait en troisime lieu larrimage des modules lis la livraison, puisquils son intimement lis la satisfaction du client. et complterait le systme en dveloppant les modules de ventes et de soutien, les cas lis au paiement tant impartis aux banques. 9. Il valide avec son client, qui est ici son patron , Paul, le directeur des services informatiques et la directrice des ventes, Diane, qui a initi le projet. Paul croit que le diagramme devrait aussi prvoir le lien avec la production, cest--dire avec le service qui reproduit les formations, pour quil puisse ajuster rapidement la production aux commandes. Par ailleurs, il souhaite que le systme fournisse aussi des donnes sur linformation consulte et sur les commandes abandonnes. On ajoute donc un objectif et donc un cas- Recueillir Donnes au webmestre. Diane sinterroge plutt sur les priorits : elle croit quil faut dvelopper le cas Obtenir Information en priorit : une information complte et bien structure contribuerait selon elle aux ventes, mme si le module de commande lectronique nest pas encore install. la suite de cette runion, Louis et son quipe entreprennent de dvelopper la description textuelle, en dbutant par le cas Commander . Ainsi :

Gilles E. St-Amant

10. Il identifie les conditions de succs du cas, cest--dire si : le client sidentifie correctement, si la vrification de son identit russit, sil confirme la commande, etc. Il dveloppera la liste des conditions et leurs alternatives dans les tapes suivantes. 11. Il dveloppe le scnario principal en utilisant le format suivant : Version : Description : Cas 01, version 1, 15 dcembre 2002 tape Action 1. Le client indique au systme quil dsire commander 2. Le systme lui demande les renseignements ncessaires son identification 3. Si le client connat ses identificateurs, il les transmets au systme 4. Le systme vrifie la validit de linformation entre 5. Si la vrification est russie, le systme affiche les renseignements dtenus sur le client 6. Le systme demande de confirmer lexactitude des renseignements 7. Si le client confirme lexactitude des renseignements, le systme vrifie si le client a dj plac des marchandises dans son panier (voir cas 02) 8. Si le client a des marchandises dans son panier, le systme les affiche 9. Le systme affiche la liste des autres marchandises disponibles 10. Le client indique les quantits dsires de chaque produit 11. Le systme demande de confirmer lexactitude des quantits entres 12. Si le client confirme lexactitude des quantits, le systme affiche les quantits commandes et le montant de la commande (le bon de commande) 13. Le systme demande au client sil veut procder au paiement 14. Si le client accepte de procder au paiement, la procdure de paiement est initie Produire un prototype tester avec un groupe dusagers Environ 100 commandes par jour Louis Ramirez

Commentaires : Frquence prvue : Auteur du cas :

12. Il dtermine ensuite les variations. Dans ce cas-ci, les variations ont trait au point un, cest--dire au type de client et au moyen choisi pour indiquer son dsir de commander. Ainsi, contrairement aux individus, les institutions denseignement connues, en plus de bnficier de tarifs spciaux, ne paient que sur livraison. Par ailleurs, si on veut modliser tout le processus de commande et non seulement le commerce lectronique, on inclurait le tlphone, le tlcopieur, le courrier lectronique et les visites en personne comme moyen de commande. Si Louis voulait formaliser ces variations, elles pourraient tre dabord rsumes comme dans le tableau suivant, puis dtailles sous forme textuelle.

Gilles E. St-Amant

Variations : Description :

Cas 01, version 1, 15 dcembre 2002 tape Action 1 1,1 Le client est : 1,11 Une institution denseignement connue 1,12 Une institution denseignement non encore enregistre 1,13 Un individu ou autre 1 1,2 Lintention dachat est exprim 1,21 Par le bouton commander maintenant 1,22 Par courrier lectronique 1,23 Par tlphone 1,24 Par tlcopieur 1,25 En personne

13. Il rdige ensuite les extensions, cest--dire ce qui se produit quand les conditions ne se ralisent pas. Il aura alors une longue liste dnoncs, comprenant : Extensions : Description : Cas 01, version 1, 15 dcembre 2002 tape Action 3a Client Sans Identificateur (nouveau client) 3a1 Le systme lui demande dentrer ses coordonnes compltes 3a2 Le client entre toutes ses coordonnes 3a3 Le systme vrifie les coordonnes 3a4 Le systme attribue un identificateur 3a5 Le systme enregistre les donnes dans la base de donnes clients 3b Identificateurs Oublis 3b1 Le systme lui demande des renseignements pour retrouver ses identificateurs 5a Identificateur Incorrect 5a1 Le systme indique que lidentification est errone et demande de ressayer 5a2 Si lentre est de nouveau incorrecte, voir 3a1 7a Renseignements Non Valides 7a1 Le systme permet aux clients de les modifier Etc. Dtailler de la mme faon pour chaque condition non remplie

Gilles E. St-Amant

14. Lquipe peut dores et dj penser des inclusions ou fragments communs7. Par exemple, on a prvu, dans le cas obtenir soutien , que les clients devraient sidentifier pour accder laide pertinente. Les tapes 2 4 du cas commander seraient donc un fragment commun plus dun cas. 15. Les cas sont valids, de nouveau, avec le client. Par exemple, Diane soulve la question Quarrivet-il si les articles de la commandes ne sont pas en stock ? . Louis ajoute donc une tape, en remplacement de ltape 9, leffet que le systme vrifie les marchandises disponibles et en affiche la liste. 16. La remarque de Diane lamne aussi complter ses cas. Il ajustera le cas Obtenir Information pour que les marchandises en rupture de stock soient indiques et ne puissent tre ajoutes au panier. Il se rend aussi compte quil devra en consquence mettre en place linterne un meilleur systme de contrle des stocks, jour en tout temps. 17. Il complte le diagramme de cas dutilisation, en y ajoutant les extensions et les fragments. Par exemple, en incluant les extensions et des inclusions dj repres, le diagramme client pourrait stre enrichi de la faon suivante.

Systme de commerce lectronique

Obtenir Information
tend

Identificateur NonValide

Commander
tend
Renseignements Errons

Base Donnes Clients

inclut

Payer Client
Sidentifier

Banque Client

inclut

Obtenir Soutien

Recevoir Produit Transporteur

Soutien

En anglais, on utilise les termes uses ou includes pour dsigner les fragments communs.

Gilles E. St-Amant