Vous êtes sur la page 1sur 33

Chapitre 3 : Le modle des cas dutilisation Squence 1 : La notion de cas dutilisation

Objectifs : Comprendre la notion de cas dutilisation Savoir interprter un diagramme de cas dutilisation Mots cls : Cas dutilisation, scnario, acteur principal, acteur secondaire

Cas Dutilisation et scnario


Dfinition 1 : la notion de Cas dutilisation ( Use Case )
Un cas dutilisation permet de dcrire un service attendu du systme par un acteur. Il reprsente un ensemble de squences possibles d'actions ralises par le systme et produisant un rsultat observable et mesurable afin de satisfaire les objectifs dun utilisateur particulier du systme. Un cas dutilisation est une manire spcifique dutiliser un systme. Un cas dutilisation reprsente lactivit interne dun systme en rponse un stimuli dun acteur. Les Use cases sont dfinis du point de vue de lutilisateur Le diagramme des cas dutilisation permet de visualiser les cas dutilisation. Le diagramme des cas dutilisation permet de recentrer les besoins sur les utilisateurs Un cas dutilisation est dcrit en langage naturel Exemple 1: le cas d'utilisation "achat" Dans le contexte du dveloppement d'un site d'achat, le cas d'utilisation "achat" correspond un service de vente en ligne que doit offrir le systme dvelopper aux clients. Exemple 2: le cas d'utilisation retirer de largent Dans le contexte du dveloppement d'un distributeur dargent, le cas d'utilisation "retirer de largent" correspond un service attendu par les usagers.

Dfinition 2 : la notion de scnario


Un cas dutilisation se compose dun ou plusieurs scnarios. Un scnario de cas d'utilisation est une squence possible d'oprations permettant de le parcourir. Un scnario dcrit, dune manire textuelle, une squence spcifique dactions qui illustre un comportement fonctionnel (correct ou incorrect) : une situation potentielle pour un acteur du systme.

Un scnario montre la rponse du systme en raction aux vnements particuliers Un scnario dcrit la manire dont le systme est utilis et les squences d'vnements (contrles, actions faire, quand linteraction a lieu, quest-ce qui est chang, etc.) Un scnario peut avoir des squences conditionnelles. Un scnario peut tre reprsent de plusieurs manires Exemple Pour le cas dutilisation retirer de largent , plusieurs scnarios peuvent se drouler : le scnario o le solde du compte bancaire nest pas suffisant, le scnario o le code secret de la carte est inconnu ou encore le scnario normal o lusager a pu retirer de largent. Commentaires Lanalyse par les cas dutilisation a t initialement formalise par Ivar Jacobson dans le gnie langage naturel; une srie de phrases ordonnes, lordre dans lequel les choses se produisent interactions dobjets langage formel

logiciel orient objet [Jacobson, 1992]

Un cas d'utilisation peut comporter un nombre quelconque de scnarios. Chaque scnario correspond un rsultat possible de l'excution d'un cas d'utilisation. Un ensemble de scnarios pour un cas d'utilisation identifie tout ce qui peut advenir lorsque ce cas d'utilisation est mis en uvre. Chaque scnario peut tre vu comme une instance du cas, en ce sens, il en est une des ralisations, ou excutions possibles. En gnral dans un mme cas d'utilisation, on distingue un scnario nominal (il s'agit du chemin le plus "gnral"), des scnarios alternatifs et des scnarios d'exception.

Dfinition 3 : Scnario nominal ("basic path")


Il sagit du chemin dexcution le plus gnral du cas dutilisation. Cest le chemin qui nimplique pas derreurs.

Dfinition 4 : Scnario alternatif


Un scnario alternatif est une succession dune ou plusieurs tapes qui peuvent remplacer une ou plusieurs tapes du scnario nominal. Un scnario alternatif propose une autre possibilit de droulement du cas dutilisation que celle prvue dans le scnario nominal.

Dfinition 5 : Scnario d'exception


Une exception est une succession dune ou plusieurs tapes qui sajoutent au scnario nominal en cas derreur(s) survenue(s) lors de la ralisation dune tape du scnario nominal. Ces erreurs sont telles que les post-conditions ne sont pas vrifies et entranent larrt du cas dutilisation. Commentaires Plusieurs scnarios alternatifs sont possibles pour un mme enchanement dun cas dutilisation.

Un scnario alternatif a une condition de ralisation. Si cette condition est satisfaite, le scnario alternatif est excut. Lorsque les actions du scnario alternatif ont t excutes, un saut une tape prcise du scnario nominal permet de poursuivre le droulement du cas dutilisation partir de cette tape. Un scnario d'exception entrane une fin anormale du cas d'utilisation. La description dun cas dutilisation avec ses scnarios peut prendre diffrentes formes : langage naturel, texte structur.. [LIEN SUR FORMES DE SPECIFICATION DES CAS DUTILISATION]

Illustration 1 : Le cas dutilisation achat et ses scnarios


Titre du cas d'utilisation : Achat
Scnario nominal

1. Le client parcourt le catalogue et slectionne les produits quil souhaite acheter. 2. Le client valide ses choix. 3. Le client fournit les informations concernant la livraison (adresse, livraison en 24 heures ou 3 jours) 4. Le systme affiche les lments de facturation et les informations concernant la livraison. 5. Le client fournit les informations concernant la carte de crdit. 6. Le systme valide la transaction. 7. Le systme confirme la transaction immdiatement 8. Le systme expdie un e-mail de confirmation au client.
Scnario alternatif : chec de l autorisation (pour la premire ou deuxime fois)

A ltape 6, la transaction nest pas valide par le systme Autoriser le client saisir nouveau les informations concernant sa carte de crdit et ressayer.
Scnario alternatif : Client rgulier

3a . Le systme affiche les informations associes ce client concernant la livraison, les critres de tarification et les quatre derniers chiffres de son numro de carte de crdit. 3b. Le client peut accepter ou modifier les valeurs affiches Retourner au scnario principal ltape 6.
Scnario dexception : 3me chec de lautorisation

A ltape 6, la transaction ne peut plus tre valide. Le cas dutilisation est termin. ! ! ! ! (un mail ou non pur dire erreur ou il a pas reconnu)

Le concept dacteur
Dfinition 1
Un acteur est un rle jou par une personne ou une machine ou encore un autre systme qui est l'extrieur du systme, donc du primtre dtude, et qui interagit avec lui. Un acteur cest toute chose externe au systme qui : change de linformation avec le systme fournit des entres au systme reoit de linformation du systme

On trouve les acteurs en examinant : celui qui utilise directement le systme celui qui est responsable de maintenir le systme tout matriel externe qui interagit avec le systme tous les autres systmes qui interagissent avec le systme

Exemple
Lacteur client pour le cas dutilisation achat

Commentaire
Un seul acteur peut raliser plusieurs cas et inversement un cas dutilisation peut avoir plusieurs acteurs. Un acteur reprsente un rle jou par un utilisateur lorsquil utilise le systme La mme personne physique peut agir comme plusieurs acteurs

Exemple
Lagent de maintenance dun distributeur automatique (ATM) peut aussi tre un acteur

Commentaire
Les acteurs ne sont pas ncessairement humains, il peut sagir dun systme externe avec lequel le systme tudi doit interagir.

Exemple
Les acteurs client et systme bancaire pour le cas dutilisation retirer de largent

Commentaire
Il peut y avoir une relation de gnralisation entre acteurs comme dans lillustration ci-dessous. Le lien de gnralisation sapplique entre des acteurs.

Exemple
Lacteur client peut tre spcialis en client rgulier et client occasionnel

Commentaire

Plusieurs utilisateurs peuvent agir comme un mme acteur

Exemple
Tous les clients dune banque

Dfinition 2 : Acteur principal, Acteur secondaire


Lacteur principal est souvent celui qui dclenche le cas dutilisation ou qui utilise les fonctions principales du systme. Les acteurs secondaires sont les autres participants du cas d'utilisation qui peuvent tre sollicits pour obtenir des informations.

Les associations entre acteurs et cas dutilisation


Dfinition 1 : association
Cest une relation dfinie entre un acteur et un cas dutilisation.

Exemple 1: Association entre un cas d'utilisation et un acteur principal

association

Gestion des clients

Rceptionniste

Association entre cas dutilisation et acteur

Exemple 2 : Association entre un cas d'utilisation et un acteur secondaire


Il est possible de diffrencier graphiquement un acteur secondaire dun acteur principal.

secondaire

Suivi de mission

secondaire Rpartiteur
Planification de mission

Chauffeur

Association entre cas dutilisation et acteur secondaire


Commentaires :
Deux acteurs sont reprsents sur ce diagramme de cas dutilisation : Le rpartiteur planifie les missions dune agence pour la ralisation de commandes en cours. Le chauffeur effectue la mission et informe le systme en temps rel sur lavancement de la mission . Dans lillustration ci-dessus, le cas dutilisation "Suivi de mission" a un acteur principal (le chauffeur) et un acteur secondaire (le rpartiteur). Le cas dutilisation "Planification de mission" a un acteur principal (le rpartiteur) et un acteur secondaire (le chauffeur).

Suivi de mission

secondaire secondaire Rpartiteur


Planification de mission

Chauffeur

Exemple 3 : associations orientes


Associations orientes entre cas dutilisation et acteurs

Commentaires
Lassociation oriente du cas dutilisation vers lacteur indique que lacteur consulte ou reoit les informations provenant du systme : Il ny a pas de flux de lacteur vers le systme donc lacteur

ne modifie pas le systme. Ici, Le rpartiteur utilise les informations venant du suivi des missions pour amliorer la planification des missions et contrler le droulement dune mission. Et le chauffeur a besoin de la fiche de description de la planification de sa mission pour pouvoir leffectuer. Lassociation sans flche correspond une flche dirige dans les deux sens. La communication se fait dans les deux sens. Ainsi, le rpartiteur cre, modifie et annule des missions mais il utilise aussi la disponibilit des ressources par rapport aux autres missions en attente de ralisation pour crer et modifier des missions.

Le diagramme des cas dutilisation


Le rle du diagramme des cas d'utilisation est de dfinir ce que les utilisateurs attendent du systme. Un diagramme de cas dutilisation comporte les cas dutilisation, les acteurs et les relations entre les cas dutilisation. Un diagramme des cas dutilisation est un type particulier de diagramme UML. Comme tous les diagrammes, il peut contenir des notes et des contraintes. Un diagramme de cas dutilisation peut tre organis en paquetages. En gnral ce diagramme est document par une description narrative de chaque cas d'utilisation.

Illustration

Diagramme de cas dutilisation

Bibliographie
[Jacobson 92] I. Jacobson, M. Christerson, P. Jonsson, G. Oevergaard, Object-Oriented Software Engineering : A Use Case Driven Approach Addison-Wesley, 1992

Squence 2 : Organisation des cas dutilisation


Objectifs : Comprendre les formes de liens entre les cas dutilisation. Mots cls : Cas dutilisation, lien extend , lien include , lien de gnralisation

Dans cette squence, nous introduisons les liens entre cas dutilisation. Trois types de lien sont utiliss : le lien dinclusion, dextension et de gnralisation.

La relation "include" (ou inclusion)


Dfinition
Cette relation existe quand un cas d'utilisation de base contient un autre cas d'utilisation. Le cas dutilisation de base contient les fonctionnalits du cas dutilisation inclus. Exemple :

Relation dinclusion entre cas dutilisation


Commentaire La figure ci-dessus exprime que les trois cas dutilisation Achat en ligne , Suivi livraison et Consultation catalogue ncessite lauthentification du client Proprits Le lien dinclusion est reprsent par une flche en pointill avec le strotype <<Include>> Le cas d'utilisation inclus n'est jamais excut seul, mais seulement en tant que partie du cas de base.

La relation dinclusion permet le partage de squences communes plusieurs cas d'utilisation.

La relation de gnralisation
Dfinition
Cette relation existe quand un cas dutilisation hrite de la fonctionnalit d'un autre cas d'utilisation. Il est possible d'augmenter de rajouter dans les cas dutilisation enfant des interactions supplmentaires ou de modifier les interactions hrites

Exemple

Retirer des euros Retirer Argent Retirer des dollars

Spcialisation de cas dutilisation

La relation "extend" ( tend ou extension)


Dfinition
Un cas dutilisation peut tre complt par un autre, sous certaines conditions, et uniquement certains points particuliers de son flot dvnements appels points d'extension. Exemple

G estio n d es clie n ts

G estio n d e co m m a n d e

extend ( no u veau c lie nt)

p o in t d e x te ns io n n ou v ea u client infos livra is on

Relation dextension entre cas dutilisation


Commentaire Dans le cas dune prise de commande, il peut tre ncessaire si le client nexiste pas de crer ce nouveau client.

Proprits
Le lien dextension est reprsent par une flche en pointill avec le strotype <<extend>> Le cas d'utilisation tendu peut fonctionner sans son extension Cette relation est souvent utilise pour distinguer le comportement optionnel ( les variantes ) du comportement obligatoire.

Illustration : Un diagramme de cas dutilisation avec les trois formes de relation

Relations entre cas dutilisation


Commentaires Le virement par minitel est une spcialisation du virement effectu en agence. Dans les deux cas, le client doit tre identifi mais la vrification du solde de son compte est ralise uniquement si le montant du virement est suprieur 500F.

Squence 3 : Documenter les cas dutilisation


Objectifs : Savoir crire des cas dutilisation Apprhender les diffrentes formes de spcification des cas dutilisation Savoir documenter un cas dutilisation avec un diagramme dactivit Savoir documenter un scnario avec un diagramme de squence Savoir documenter un scnario avec un diagramme de collaboration Mots cls : Cas dutilisation, scnario, diagramme dactivit, diagramme de squence, diagramme de collaboration, Pr conditions, post-conditions, enchanements Pr requis : Notion de cas dutilisation, Diagrammes dactivits, diagramme de squence, diagramme de collaboration Ressources pdagogiques: Un fichier word contenant un squelette de description textuelle et tabulaire de cas dutilisation Introduction Chaque cas dutilisation et chaque scnario de cas dutilisation doit tre document pour tre lu et compris par les diffrents acteurs du projet: Client, Utilisateur, Dveloppeur , Analyste/Concepteur, Testeur, Rdacteur technique etc. La description des cas dutilisation peut tre textuelle ou graphique. Il est possible dutiliser certains diagrammes UML pour reprsenter les cas dutilisation et les scnarios. La spcification des cas dutilisation ne fait lobjet daucune normalisation particulire. Il existe ainsi dans la littrature de nombreux styles de prsentation et de spcification des cas dutilisation. Ces diffrents formats ne sopposent pas, ils se compltent. Il est ainsi tout fait possible denvisager dutiliser plusieurs formats de spcification, chacun adapt une phase du processus de dveloppement. Dans cette squence nous donnons quelques exemples de formats de descriptions de cas dutilisation proposs dans la littrature Description textuelle de cas d'utilisation.[Roques 00] La description est compose de quatre rubriques : Sommaire didentification (rubrique obligatoire) Inclut titre, but, rsum, dates, version, responsable, acteurs Description des enchanements (rubrique obligatoire) Dcrit les enchanements nominaux, les enchanements exceptionnels, les exceptions mais aussi les pr conditions et les post conditions. Besoins dIHM (rubrique optionnelle) Ajoute ventuellement les contraintes dinterface homme-machine : cequil est ncessaire

de montrer, en conjonction avec les oprations que lutilisateur peut dclencher Contraintes non-fonctionnelles (rubrique optionnelle) Ajoute ventuellement les information suivantes : frquence, volumtrie, disponibilit, fiabilit, intgrit, confidentialit, performances. Nous illustrons ce format avec un exemple emprunt [Roques 00] But : Planification des missions dune agence partir de la connaissance du plan de transport, des ressources disponibles et des commandes assurer quotidiennement Rsum : cration dune nouvelle mission denlvement, de livraison ou de traction partir des commandes confirmes. Modification et annulation de mission Acteurs : rpartiteur (principal), chauffeur (secondaire) Pr conditions : 1. 2. le rpartiteur est authentifi Les commandes planifier dans les missions sont confirmes

Enchanements et tablit obligatoirement la nature (enlvement, livraison ou traction) de la mission quil veut crer Sil sagit dune mission de traction, le rpartiteur doit indiquer une agence principale de destination

Enchanement (a) Crer une mission en attente Le rpartiteur fournit un nom dauthentification

Enchanement (b) Affecter les commandes Le rpartiteur affecte les commandes une mission.

Le systme value au fur et mesure des affectations le tonnage et la dure estims de la mission. Il propose galement lordre des tapes suivre. Si aucun parcours nexiste entre deux sites desservir alors il faut excuter [Exception 3 : EstimationIncomplte]

mission, en fonction du tonnage valu

Enchanement Affecter les ressources Le rpartiteur affecte un vhicule et un chauffeur la

Si la mission dpasse la capacit du vhicule alors il faut excuter [Exception 1 : DpassementTonnage] Si le chauffeur na pas les qualifications requises pour conduire le vhicule alors il faut excuter [Exception 2 : chauffeurNonQualifi]

Enchanement (d) Modifier une mission en attente


Le rpartiteur dsaffecte une commande, ou affecte nouveau le vhicule et le chauffeur dune mission en attente. Le rpartiteur peut modifier galement l ordre des tapes proposes pour la mission.

Enchanement (e) Valider une mission en attente


Le rpartiteur valide une mission en attente; il doit alors prciser lheure de dpart prvue. heure avant son dpart. Toute modification dune mission valide, entranant son invalidation, il doit donc ensuite la valider nouveau en prcisant une heure de dpart.

Enchanement (f) Modifier une mission valide Le rpartiteur peut encore modifier une mission 1

Enchanement (g) Annuler une mission


Le rpartiteur annule une mission non encore valide ou une mission valide au minimum 1h avant son dpart Enchanement (h) diter les bordereaux de mission Le rpartiteur dite les

bordereaux de mission dune mission valide. Ces bordereaux contiennent une fiche de description et de rception par commande ainsi quune feuille de route dcrivant les tapes et les horaires estims. Ce cas dutilisation se termine lorsque le rpartiteur a: amen la mission jusqu son dpart, ou bien annul la mission

Exceptions [Exception 1 : dpassementTonnage] ou [Exception 2 : chauffeurNonQualifi] : la mission est marque en anomalie tant que le rpartiteur n a pas corrig l erreur. Il ne peut plus valider une telle mission. [Exception 3 : estimationIncomplte] : la dure estime est initialise 0. Le rpartiteur peut alors introduire une estimation pour chaque parcours entre les sites de la mission, de manire alimenter cette information Post conditions : Une mission ne contient que des commandes enlever, livrer ou tracter Le chauffeur affect une mission valide possde la qualification ncessaire Le vhicule affect une mission valide possde la capacit de tonnage ncessaire Les commandes dune mission valide sont considres comme programmes du point de vue du rceptionniste Aprs validation, les horaires dtape et les dlais dacheminement des commandes de la mission sont indiqus

.
Prsentation tabulaire de cas dutilisation Le format ci-dessous permet de mettre en vidence la notion dinteraction entre lutilisateur et le systme, le contenu restant le mme. Par exemple, Scnario principal (succs) Action de lacteur 1. Le caissier dmarre une nouvelle vente 2. Le caissier entre le code de larticle 3. Le systme enregistre larticle et prsente sa description, son prix et le total en cours Le caissier rpte ltape 2 jusqu ce que tous les articles soient passs 4. Le systme prsente le total avec les taxes calcules 5. Le caissier communique le total au client et en demande le paiement Responsabilits du systme

6. Le client paie 7. Le systme traite le paiement 8. Le systme enregistre la vente et transmet les informations au systme de comptabilit externe et au systme dinventaire. Il prsente un reu.

Documenter un cas dutilisation avec un diagramme dactivit Un diagramme dactivit peut tre utilis Pour reprsenter les flots de contrle internes attachs un cas dutilisation. Il est donc possible de reprsenter le droulement dun cas dutilisation dans une organisation de rfrence. Le diagramme dactivits ci-dessous est utilis pour reprsenter lorganisation des scnarios du cas dutilisation planifier mission .

Crer mission

Modifier mission

[ Parcours incomplet ]

[ annulation ] [ > 1 heure avant dpart ]

Estimer parcours
[ rserve entame ]

[pas danomalie]

Afficher rserve entame


[ dpart mission]

Valider mission

Imprimer bordereau

Diagramme dactivits dcrivant lorganisation des scnarios dun cas dutilisation


Documenter un scnario avec un diagramme de squences

Il est possible dutiliser un diagramme de squence (ou de collaboration) pour reprsenter un

scnario dun cas dutilisation. Par exemple le diagramme de squence ci-dessous prsente le scnario dajout dune ligne dans un panier dachat. Il sagit dun scnario du cas dutilisation grer son panier dachat .

Diagramme de squence dun scnario dun cas dutilisation

Squence 4 : Usage des cas dutilisation


Objectifs : Savoir utiliser les cas dutilisation pour reprsenter le contexte dun systme Savoir utiliser les cas dutilisation pour exprimer les besoins fonctionnels dun systme Savoir utiliser les cas dutilisation pour exprimer des besoins techniques Savoir utiliser les cas dutilisation pour conduire le processus Savoir utiliser les cas dutilisation pour organiser le dveloppement Mots cls : Cas dutilisation, Modlisation de contexte, besoins fonctionnels, besoins techniques

Dans lapproche UML, les cas dutilisation ont diffrents rles. Ils peuvent tre utiliss comme un mcanisme de modlisation des besoins mais ils peuvent aussi tre utiliss pour dfinir les frontires du systme ou encore pour organiser et grer le droulement du projet.

Modliser le contexte dun systme de cartes de crdit


Tous les lments externes au systme qui dialoguent avec lui constituent le contexte du systme. Ils sont les acteurs des cas dutilisation. Les cas dutilisation peuvent tre contenus dans un rectangle qui reprsente les limites du systme. Les acteurs sont reprsents lextrieur de ce rectangle puisquils ne font pas partie du systme.

Client

Systme de validation de cartes de crdit Raliser transaction carte

Institution Traiter facture client commerciale

Ajuster transaction Institution Client individuel nt Entreprise cliente Grer compte client Financire caution

Exprimer des besoins fonctionnels


Les cas d'utilisation sont le plus souvent utiliss pour exprimer les besoins fonctionnels. Dans ce contexte un cas d'utilisation dcrit une fonction que doit remplir le systme en rponse une intention dun acteur. Le modle des cas d'utilisation fournit une description de l'ensemble des besoins. Les cas dutilisation sont dfinis pour permettre aux acteurs datteindre des buts.

Par exemple ce diagramme de cas dutilisation exprime en terme de services attendus les besoins de linternaute.

Exprimer les besoins techniques


Les cas d'utilisation sont aussi utiliss pour exprimer les besoins techniques. Dans ce contexte un cas d'utilisation dcrit un besoin technique que doit remplir le systme. Cette approche est propose dans [Roques 2000], nous lillustrons en empruntant un exemple cet auteur. Dans ce contexte les acteurs sont les exploitants et les cas dutilisation sont appels cas dutilisation techniques. Un exploitant est un acteur UML ne bnficiant que des fonctionnalits techniques du systme. Un cas dutilisation technique est destin lexploitant. Cest une squence dactions produisant une valeur ajoute oprationnelle ou purement technique. Cas dutilisation techniques : pertinence et gestion du cycle de vie des objets manipuls, intgrit, quilibrage de la charge, authentification,

Des cas usuels de cas dutilisation techniques sont : z

aide contextuelle, traabilit et services dalerte, scurit : authentification, habilitation, cryptage et audit.

Le diagramme des cas dutilisation ci-dessous est un diagramme de cas dutilisation dans lequel tous les cas dutilisation sont des cas dutilisation techniques.

Une autre utilisation des cas dutilisation techniques est utilise pour spcifier les responsabilits des diffrentes couches logicielles. Chaque couche contient ainsi des cas dutilisation pilots non pas par un exploitant mais par les couches du niveau immdiatement suprieur. Par exemple, considrons une organisation classique compose de cinq niveaux : niveau 1 : prsentation niveau 2 : application niveau 3 : mtier niveau 4 : accs aux donnes niveau 5 : stockage des donnes Les cas dutilisation techniques de la couche dvelopper sont prsents globalement, en faisant intervenir si besoin est les cas dutilisation fournisseurs ou bnficiaires faisant partie dautres couches. Des liens <<delegate>> identifient les dlgations dun cas dutilisation vers un autre. Par

exemple il existe un lien <<delegate>> entre le cas dutilisation rechercher un objet de la couche Prsentation et le cas dutilisation Exploiter une classe de la couche Accs aux donnes.

Diagramme de cas dutilisation appartenant des couches logicielles diffrentes

Conduire le processus de dveloppement


Dans lapproche UML, les cas dutilisation fournissent une aide lanalyse et la conception objet. Ils conduisent sintresser un ensemble de classes qui collaborent dans un certain contexte (celui du cas dutilisation). Ainsi le concepteur dcrit : la structure de la collaboration (ensemble des classes participantes un cas dutilisation) le comportement de la collaboration (interactions entre les objets des classes participantes au cas dutilisation)

Selon le principe du processus unifi, il est possible de raisonner sur un cas dutilisation, depuis sa spcification jusqu sa ralisation. Il est ainsi possible de raliser un diagramme de classes et un diagramme dinteraction par cas dutilisation. Ce raisonnement pilot par les cas dutilisation permet dassurer une certaine traabilit entre les besoins et les lments qui composent le systme logiciel.

Le processus de dveloppement conduit par les cas dutilisation

Organiser et grer le dveloppement


Les cas dutilisation peuvent aussi tre utiliss dans la gestion de projets. Il s permettent dtablir, dune part, des priorits en terme de dveloppement et dautre part, des niveaux de risque. La ralisation des cas dutilisation se fait travers les itrations (incrment) et leur ordre de ralisation travers les itrations permet de planifier le projet. Il est usuel dans les projets mens avec une approche UML de construire sur le modle ci-dessous un tableau des priorits, des risques et de lordre des cas dutilisation.

Cas dutilisation
Rechercher des ouvrages Grer son panier Passer ses commandes moyen Bas lev

Risque
Haute Haute Haute Basse Basse Moyenne Haute Moyenne

Priorit
1 1 1 2 3 3 1 3

Incrment

Consulter ses commandes passes Moyen et en cours Obtenir un devis Maintenir le site Maintenir le catalogue Maintenir ditoriales les informations Bas Bas lev Bas

Bibliographie
[Roques 2000] P. Roques, F. Valle, UML en action , Eyrolles 2000

Squence 4 : Exercices
Objectifs : Mots cls : Modles de produits, Modles de processus, Mta-modle Pr-requis : Avoir une bonne connaissance de la mthode MERISE

Cette squence dexercices permet dillustrer les concepts du modle des cas dutilisation. Par ailleurs cette squence conduit aussi ltudiant une recherche et une tude comparative des styles de description des cas dutilisation..

Exercice 1 : Distributeur de billets


Cette tude de cas concerne un systme simplifi de guichet automatique de banque (GAB). Le guichet offre les services suivants : 1) Distribution dargent tout porteur de carte de crdit (carte VISA ou carte de la banque), via un lecteur de carte et un distributeur de billets 2) Consultation de solde de compte, dpt en numraire et dpt de chques pour les clients de la banque porteurs dune carte de crdit de la banque Toutes les transactions doivent tre scurises et il est ncessaire de recharger le distributeur.

Exercice 2 : Rservation de salles


La mairie de la ville de X souhaite informatiser les rservations de ses salles. La mairie dispose plusieurs btiments dans lesquels des salles sont mises la disposition. Les salles possdent un numro et sont situes une certain tage. Les salles disposent de matriels, mais des matriels trs spcifiques peuvent tre demands au moment de la rservation. Certaines salles peuvent tre loues avec une cuisine et le matriel associ. Les tarifs des salles varient en fonction de la superficie, du type de salle (salle de runion, amphithtre, cuisine.) de la dure, et du statut du demandeur (particulier, association, entreprise). Le systme doit permettre deffectuer les rservations et les annulations de salle, de calculer les tarifs de location, de fournir les plannings doccupation, des factures hebdomadaires par demandeur et des taux doccupation des salles.

Exercice 3 : Styles de description des cas dutilisation


Rechercher des modles de descriptions de cas dutilisation et effectuer une analyse des styles de prsentation et des langages de spcification proposs. Dans [Cockburn 98] vous trouverez deux styles de prsentation des cas dutilisation.

Exercice 4 : Etude comparative entre modles des cas dutilisation et modles de buts
Il existe plusieurs approches de spcification des besoins : approche par les cas dutilisation, approche par les buts. On vous demande didentifier et de prsenter deux approches et de les comparer lapproche des cas dutilisation.

Basic Use Case Template Alistair Cockburn Human and Technology 7691 Dell Rd, Salt Lake City, UT 84121 (801)943-8484 fax: 801/943-8499 email: arc@acm.org home page: http://members.aol.com/acockburn Document: TR.96.03a This Version Date: October 26, 1998 Version: 2 Previous Version Date: April 26, 1996 Per popular request, I am putting forward a basic template for use cases matching the document Structuring Use Cases with Goals, HaT.TR.95.1 (available at the same address and web site), and the course / tutorial of a similar name. This document is copyrighted by Humans and Technology as HaT technical report TR 96.03a, also found at http://members.aol.com/acockburn. You have permission to copy and distribute the documents as long as you reference the source of the originals. You may use the templates in courses and presentations with proper reference. You may use and vary the template on your projects without reference. Do note that the template may evolve over time according to your feedback. Additions to the text may appear in

italics, like this (added, v.2).

help you decide when to omit information, I include a section on Using, Staging, Tailoring the Template. The base template is given twice, once in simple word-processing format and then again in table format so you can choose the one that best suits your tool set. Personally, I find that people work best with the simple text format. You will find that the collection of use cases
is easier to work with in something like Lotus Notes than in a word processor.

The template has the sections: name (which is the goal), goal in context, scope, level, trigger, pre- and postconditions, main course, extensions, sub-variations, and other characteristic data for the use case. You may easily graft more information on to the end, or omit information. To

In this version of the template, I write Sub-Variation as an attempt to make it more distinct from Extensions. Refer to the original paper.
This document has the following parts: Template in plain text Template in table form Example in plain text Example in table form

Using, Staging, Tailoring the Template

The word binary of this document may be available on the web site. Use Case: <number> <the name should be the goal as a short active verb phrase> -------------------------------------------------CHARACTERISTIC INFORMATION Goal in Context: <a longer statement of the goal, if needed> Scope: <what system is being considered black-box under design> Level: <one of: Summary, Primary task, Subfunction> Preconditions: <what we expect is already the state of the world> Success End Condition: <the state of the world upon successful completion> Failed End Condition: <the state of the world if goal abandoned> Primary Actor: <a role name for the primary actor, or description> Trigger: <the action upon the system that starts the use case, may be time event> ---------------------------------------MAIN SUCCESS SCENARIO <put here the steps of the scenario from trigger to goal delivery, and any cleanup after> <step #> <action description> ---------------------EXTENSIONS <put here there extensions, one at a time, each refering to the step of the main scenario> <step altered> <condition> : <action or sub.use case> <step altered> <condition> : <action or sub.use case> -------------------SUB-VARIATIONS <put here the sub-variations that will cause eventual bifurcation in the scenario> <step or variation # > <list of sub-variations> <step or variation # > <list of sub-variations> ---------------------RELATED INFORMATION (optional) Priority: <how critical to your system / organization> Performance Target: <the amount of time this use case should take> Frequency: <how often it is expected to happen> Superordinate Use Case: <optional, name of use case that includes this one> Subordinate Use Cases: <optional, depending on tools, links to sub.use cases> Channel to primary actor: <e.g. interactive, static files, database> Secondary Actors: <list of other systems needed to accomplish use case> Channel to Secondary Actors: <e.g. interactive, static, file, database, timeout> ----------------------------

OPEN ISSUES (optional) <list of issues about this use cases awaiting decisions> --------------------------SCHEDULE Due Date: <date or release of deployment> ...any other schedule / staffing information you need... Table format:

USE CASE # Goal in Context

< the name is the goal as a short active verb phrase> <a longer statement of the goal in context if needed>

Scope & Level

<what system is being considered black box under design> <one of : Summary, Primary Task, Subfunction>

Preconditions Success End Condition Failed End Condition Primary, Secondary Actors Trigger DESCRIPTION

<what we expect is already the state of the world> <the state of the world upon successful completion> <the state of the world if goal abandoned> <a role name or description for the primary actor>. <other systems relied upon to accomplish use case> <the action upon the system that starts the use case> Step 1 Action <put here the steps of the scenario from trigger to goal delivery,and any cleanup afte> 2 3 <...>

EXTENSIONS

Step 1a

Branching Action <condition causing branching> : <action or name of sub.use case>

SUBVARIATIONS

Branching Action

<list of variation s>

RELATED INFORMATION Priority: Performance Frequency Channels to actors OPEN ISSUES

<Use case name> <how critical to your system / organization> <the amount of time this use case should take> <how often it is expected to happen> <e.g. interactive, static files, database, timeouts> <list of issues awaiting decision affecting this use case >

Due Date ...any other management information... Superordinates Subordinates

<date or release needed> <...as needed>

<optional, name of use case(s) that includes this one> <optional, depending on tools, links to sub.use cases>

Sample:
Use Case: 5 Buy Goods -------------------------------------------------CHARACTERISTIC INFORMATION Goal in Context: Buyer issues request directly to our company, expects goods shipped and to be billed. Scope: Company Level: Summary Preconditions: We know Buyer, their address, etc. Success End Condition: Buyer has goods, we have money for the goods. Failed End Condition: We have not sent the goods, Buyer has not spent the money. Primary Actor: Buyer, any agent (or computer) acting for the customer Trigger: purchase request comes in.

---------------------------------------MAIN SUCCESS SCENARIO 1. Buyer calls in with a purchase request. 2. Company captures buyers name, address, requested goods, etc. 3. Company gives buyer information on goods, prices, delivery dates, etc. 4. Buyer signs for order. 5. Company creates order, ships order to buyer. 6. Company ships invoice to buyer. 7. Buyers pays invoice. ---------------------EXTENSIONS 3a. Company is out of one of the ordered items: 3a1. Renegotiate order. 4a. Buyer pays directly with credit card: 4a1. Take payment by credit card (use case 44) 7a. Buyer returns goods: 7a. Handle returned goods (use case 105) -------------------SUB-VARIATIONS 1. Buyer may use phone in, fax in, use web order form, electronic interchange 7. Buyer may pay by cash or money order check credit card ---------------------RELATED INFORMATION Priority: top Performance Target: 5 minutes for order, 45 days until paid Frequency: 200/day Superordinate Use Case: Manage customer relationship (use case 2) Subordinate Use Cases: Create order (use case 15) Take payment by credit card (use case 44)

Handle returned goods (use case 105) Channel to primary actor: may be phone, file or interactice Secondary Actors: credit card company, bank, shipping service Channels to Secondary Actors: ---------------------------OPEN ISSUES What happens if we have part of the order? What happens if credit card is stolen? --------------------------SCHEDULE Due Date: release 1.0

Sample in table format:

USE CASE 5 Goal in Context Scope & Level Preconditions Success End Condition Failed End Condition Primary, Secondary Actors Trigger DESCRIPTION

Buy Goods Buyer issues request directly to our company, expects goods shipped and to be billed. Company, Summary We know Buyer, their address, etc. Buyer has goods, we have money for the goods. We have not sent the goods, Buyer has not spent the money. Buyer, any agent (or computer) acting for the customer. Credit card company, bank, shipping service purchase request comes in. Step 1 2 3 4 5 Action Buyer calls in with a purchase request Company captures buyers name, address, requested goods, etc. Company gives buyer information on goods, prices, delivery dates, etc. Buyer signs for order. Company creates order, ships order to buyer.

6 7 EXTENSIONS Step 3a

Company ships invoice to buyer. Buyers pays invoice. Branching Action Company is out of one of the ordered items: 3a1. Renegotiate order.

4a

Buyer pays directly with credit card: 4a1. Take payment by credit card (use case 44)

7a

Buyer returns goods: 7a. Handle returned goods (use case 105)

SUBVARIATIONS 1

Branching Action Buyer may use phone in, fax in, use web order form, electronic interchange 7 Buyer may pay by cash or money order check credit card

RELATED INFORMATION Priority: Performance Frequency Channel to actors OPEN ISSUES

5. Buy Goods top 5 minutes for order, 45 days until paid 200/day not yet determined What if we have part of the order? What is credit card is stolen?

Due Date ...any other

release 1.0

management information... Superordinates Subordinates Manage customer relationship (use case 2) Create order (use case 15) Take payment by credit card (use case 44) Using, Staging, Tailoring the Template My (and others') experience is that at early stages of the project the template is too long and too complete to fill out all at one time - at the beginning of the project, it is appropriate to work with less information (see the chapter, "Managing Precision, Accuracy and Scale" in my book, Surviving Object-Oriented Projects). Therefore... 1. Learn to fill in all the fields of the template in several passes, at several moments in the project's requirements gathering and project setup work. Here is a sample sequence. First, fill in just these fields, for all the use cases you need to consider at this time:

Use Case: <number> <the name should be the goal as a short active verb phrase> Goal in Context: <a longer statement of the goal, if needed> Scope: <what system is being considered black-box under design> Level: <one of: Summary, Primary task, Subfunction> Primary Actor: <a role name for the primary actor, or description> Priority: <how critical to your system / organization> Frequency: <how often it is expected to happen>
2. Stare at what you have so far. Think. Examine. Can you merge or remove some of them? Can you partition them into ones that should be developed together, or written later? For the ones you determine to pursue now, fill in the following fields:

Trigger: <the action upon the system that starts the use case, may be time event> MAIN SUCCESS SCENARIO
3. Now you have enough information to check your project's scope and look for surprises. Before you are done describing the system's functioning, you have to fill out:

EXTENSIONS SUB-VARIATIONS Superordinate Use Case: <optional, name of use case that includes this one> Subordinate Use Cases: <optional, depending on tools, links to sub.use cases>

4. You now have the system's functionality captured. When you are ready to work on your estimations, fill in: Performance Target: <the amount of time this use case should take>

OPEN ISSUES SCHEDULE


5. Finally, when you are in the final stages of project estimating, you need to identify all the systems to which you will have to build interfaces. Fill in: Channel to primary actor: <e.g. interactive, static files, database> Secondary Actors: <list of other systems needed to accomplish use case> Channel to Secondary Actors: <e.g. interactive, static, file, database, timeout>

Vous aimerez peut-être aussi