Embed Size (px)
Citation preview
Cas d’utilisation (use case)
Introduction Les cas d’utilisation sont des
descriptions textuelles, largement utilisées pour détecter et consigner les besoins.
Ils influencent de nombreux aspects d’un projet, y compris l’analyse et la conception orientées objet.
Ils sont la source de nombreux autres artefacts des études de cas.
Introduction
Pour simplifier, un cas d’utilisation « raconte » sous forme de texte la façon dont un acteur va utiliser un système pour atteindre un but.
Voyons un exemple.
Exemple de cas d’utilisation Traiter une vente :
Un client arrive à la caisse avec les articles qu’il souhaite acheter.
Pour enregistrer chaque article, la caissier utilise le système informatisé, lequel présente le détail des articles et le montant total des achats.
Le client fournit les informations nécessaires pour le règlement.
Le système valide et enregistre ces informations, puis met à jour les quantités en stock et imprime le ticket de caisse destiné au client.
La vente est terminée et le client peut quitter le magasin.
Cas d’utilisation : texte Remarquons que les cas d’utilisation ne
sont pas des diagrammes, mais des textes.
Se concentrer sur les diagrammes UML dont l’intérêt est secondaire par rapport aux énoncés est une erreur que les novices commettent couramment.
Les cas d’utilisation doivent souvent être plus détaillés ou plus structurés que l’exemple précédent.
La finalité des cas d’utilisation est de détecter et de décrire les besoins fonctionnels, en précisant de quelle manière un système est utilisé pour permettre à un client -au sens large à un utilisateur- d’atteindre ses différents objectifs.
Définitions : acteurs, scénarios et cas d’utilisation Un acteur est une entité qui a un
comportement, comme une personne – un caissier par exemple –, un système ou un entreprise.
Un scénario est une suite spécifique d’actions et d’interactions entre un ou plusieurs acteurs et le système.
C’est une « histoire » particulière de la façon dont on utilise un système, ou l’un des cheminements possibles d’un cas d’utilisation.
Par exemple, le traitement d’une vente a plusieurs scénarios possibles : la vente est validée car le client règle en espèces ou elle est invalidée car la carte de crédit du client est refusée.
Définitions : acteurs, scénarios et cas d’utilisation
Pour simplifier, un cas d’utilisation est une collection de scénarios de réussite ou d’échec qui décrit la façon dont un ou plusieurs acteurs utilisent un système pour atteindre un but.
Voyons un exemple.
Définitions : acteurs, scénarios et cas d’utilisation Traiter un retour
Scénario principal (succès) Un client arrive à la caisse avec les articles qu’il
veut retourner. Le caissier utilise le système automatisé pour enregistrer chaque article retourné …
Autres scénarios Si le client a payé à crédit d’avance et que la
demande de remboursement sur son compte est rejetée, l’en informer et le rembourser en espèce.
Si le code de l’article n’est pas reconnu par le système, informer le caissier et lui suggérer de saisir le code manuellement (l’emballage peut être endommagé).
Si le système ne parvient pas à communiquer avec le système comptable externe…
Pourquoi des cas d’utilisation Nous avons des buts, et nous voulons
des systèmes informatiques qui nous aident à les atteindre.
De brillants analystes ont inventé de nombreux moyens de capturer ces besoins et ces buts, mais les meilleurs sont les plus simples et les plus courants.
Ils facilitent la participation des clients et utilisateurs à leur définition et à leur évaluation, ce qui diminue le risque d’erreur.
Pourquoi des cas d’utilisation L’absence d’implication des utilisateurs
est l’une des principales raisons d’échec des projets logiciels, et tout ce qui peut les aider à demeurer motivés est éminemment souhaitable.
Les cas d’utilisation constituent un procédé qui aide à rester simple, et qui permet aux experts du domaine et/ou aux utilisateurs de les écrire eux-mêmes (ou de participer à leur rédaction).
Pourquoi des cas d’utilisation Un autre intérêt des cas d’utilisation est
qu’ils mettent l’accent sur les points de vue et les buts de l’utilisateur : Qui sont les utilisateurs du système ? Quels sont leurs scénarios d’utilisation type
et quels sont leurs buts ? Cette démarche est plus centrée sur
le client que si nous nous contentions de lui demander une liste des fonctionnalités.
Pourquoi des cas d’utilisation Les cas d’utilisation ont fait l’objet de
nombreux articles et ouvrages. Malgré l’intérêt que ces derniers présentent, leurs auteurs créatifs obscurcissent une idée simple en péchant par excès de complexité ou de sophistication.
On repère généralement un modélisateur novice au fait qu’il s’encombre de questions secondaires telles que les diagrammes de cas d’utilisation, les relations entre cas d’utilisations, les packages de cas d’utilisation et ainsi de suite, au lieu de se concentrer sur la principale difficulté : écrire simplement des descriptions.
Les trois types d’acteur Un acteur est une entité
quelconque ayant un comportement, ce qui inclut le système lui-même quand il fait appel aux services d’autres systèmes.
Les trois types d’acteurs sont : L’acteur principal, L’acteur auxiliaire L’acteur hors champ
Les trois types d’acteur
L’acteur principal. Il a des buts d’utilisateur, qu’il atteint
en utilisant les services du système. Ce peut être, par exemple, le caissier.
Pourquoi l’identifier ? Pour découvrir les buts utilisateurs
qui pilotent les cas d’utilisation.
Les trois types d’acteur
L’acteur auxiliaire. Il fournit un service (par exemple, une
information) au système. Le service d’autorisation de paiement
automatisé en est un. C’est souvent un système
informatique, mais il peut s’agir d’une autre organisation ou d’une personne.
Les trois types d’acteur L’acteur hors champ.
Il a un intérêt dans le comportement du cas d’utilisation, sans être un acteur principal ni auxiliaire.
Il peut, par exemple, s’agir des services fiscaux.
Pourquoi l’identifier ? Pour s’assurer que TOUS les intérêts ont bien été
identifiés et qu’ils sont satisfaits. Les intérêts des acteurs sont parfois subtils et il
est facile de les négliger, sauf lorsque ces acteurs sont explicitement nommés.
Les trois formats des cas d’utilisation
Les cas d’utilisation peuvent prendre différents formats, avec différents niveaux de formalisme : Abrégé, Informel, Détaillé.
Les trois formats des cas d’utilisation Format abrégé :
Résumé succinct qui présente généralement le scénario de base (succès) dans un paragraphe.
C’est le cas de notre premier exemple ‘traiter une vente’
S’utilise lors de la première étude des besoins, pour se faire rapidement une idée du sujet et de son périmètre.
Quelques minutes peuvent suffire à les créer.
Les trois formats des cas d’utilisation
Format informel : Les différents scénarios sont décrits
dans plusieurs paragraphes. C’est le cas de notre deuxième
exemple, ‘Traiter un retour’. S’utilise comme le format abrégé.
Les trois formats des cas d’utilisation
Format détaillé : Toutes les étapes et les variantes sont
indiquées en détail, de même que les préconditions et les postconditions (ou garantie de succès).
S’utilise lorsque de nombreux cas d’utilisation on été identifiés et rédigés au format abrégé.
Documentation d’un cas d’utilisation Description succincte : ce que le UC apporte en terme de
fonctionnalités Intervenants dans l'élaboration du UC : analystes,
utilisateurs, spécialistes du domaine, client Date de création et dates de mises à jour, avec l'énoncé des
modifications Quels sont les utilisateurs (acteurs) susceptibles
d'enclencher le UC Quels sont les effets qui en résultent (mise à jour d'une base,
envoi d'un document, écriture dans un fichier, …) Fréquence d'utilisation : apériodique, 1 x/jour, .. Quelles sont les préconditions pour pouvoir enclencher ce
UC (réalisation d’un autre UC, base de données inexistante, etc…)
Technique de déploiement : enclenché via le web, via un terminal, en intranet, en C/S
Documentation d’un cas d’utilisation Scénarios décrivant le déroulement des
opérations, pour le cas normal. C'est une description en langage clair des interactions entre les éléments intervenants pour mener le UC à bien. On y identifie le ou les acteurs, ainsi que les autres UC éventuellement enclenchés.
Scénarios décrivant les cas "alternatifs" , avec la condition de déclenchement
Scénarios décrivant les cas d'exception (panne réseau, serveur arrêté, …) avec la condition de déclenchement.
Documentation d’un cas d’utilisation Définition des tests qui serviront à valider la réalisation
du UC, appelés parfois "Test cases" : complets et détaillés ! ! !
Informations nécessaires avant d'enclencher le UC (qui seront demandées)
Contraintes préalables (techniques, personnelles, temps d'exécution maximum, etc.)
Estimation des risques : niveau de connaissance du domaine du problème traité par le UC, niveau de compétence de l'équipe de designers, niveau de compétence de l'équipe de programmeurs
Importance de ce UC pour les utilisateurs/clients. Ce point et le point qui précède serviront à classer les UC, pour un ordre "chronologique"
Le dictionnaire des abstractions et des actions associées aux scénarios (des noms et des verbes…)
Documentation d’un cas d’utilisation Cette liste est donnée à titre
indicatif et toutes les rubriques ne doivent pas être complétées, surtout en première analyse.
Cette liste peut varier suivant le contexte stratégique.
D’autres rubriques peuvent être rajoutées.
Exemple : Inscription à une formation Description : le UC permet à l'administratif d'inscrire
un candidat à la prochaine session d'une formation On doit pouvoir trouver ses informations s'il est déjà client, sinon on les demande. Si la prochaine session est complète, on peut l'inscrire dans une liste d'attente.
Intervenants : Analyste : T. Bastianelli Client : Inpres Formation
Date de création : 17 septembre 2007 Mises à jour : 21 septembre 2007, description simple Acteurs : enclenché par un Administratif Effets :
complète la liste des inscrits pour la session choisie. Ajout dans la liste des clients si nouveau client
Exemple : Inscription à une formation Fréquence d'utilisation : apériodique Technique de déploiement : accessible via un PC dans le bureau
des administratifs Préconditions : la liste des formations doit exister sinon ce UC n‘a
pas de sens. Scénario normal :
On présente la liste des formations. Après choix on affiche la date de la prochaine session.
Si pas de session, message. Si le candidat est d'accord, on demande son nom et on cherche s'il est déjà client.
Si oui, on récupère ses coordonnées, sinon on les encode. Scénario alternatif : .
Si la prochaine session est complète. On peut l'inscrire dans une liste d'attente.
Celle-ci sera utilisée pour créer la liste des inscrit de la prochaine session créée.
Scénario d'exception : …
Exemple : Inscription à une formation Tests : on testera avec un nouveau client, un client existant, une
formation sans session, une session non complète et une session complète.
Informations nécessaires : les coordonnées du client (nom, prénom, date de naissance, n° national, adresse, téléphone/GSM, [Email], [coordonnées employeur]
Contraintes : un minimum d'interactions et d'encodage de la part de l'utilisateur.
Risques : connaissance du domaine : bonne compétence designer : moyenne compétence programmeurs : bonne
Importance du UC : grande Dictionnaire abstractions: ListeFormations, Formation, Sessions,
ListeClients, Inscription, ListeAttente, FicheInscriptionSession Dictionnaire opérations : consulterFormations, consulterSession,
inscrireClient, rechercheClient, inscrireListeAttente
Scénario normal Le scénario normal (ou principal) est
également appelé « happy path », ou « scénario de base », « cheminement type ».
Il décrit le scénario type qui satisfait les intérêts des parties intéressées.
Souvent, il ne comprend pas de conditions ni de branchements. On reporte ces traitements conditionnels dans les scénarios alternatifs.
Scénario normal Le scénario est composé d’étapes,
lesquelles sont de trois sortes : Une interaction entre acteurs; Une validation (généralement par le
système); Un changement d’état du système
(enregistrement ou modifications, par exemple).
En général, la première étape d’un cas d’utilisation n’obéit pas à cette classification mais indique l’événement qui déclenche le scénario (« le client arrive à la caisse et … »)
Exemple : Scénario normal d’un paiement électronique1. L’acheteur introduit sa carte dans le terminal. 2. Le commerçant encode le montant. 3. L’acheteur contrôle le montant sur l'écran. 4. Le terminal affiche le message « Code »5. L’acheteur introduit son code secret. 6. Le terminal contacte le réseau Banksys pour la vérification de la
validité de la carte bancaire et la vérification du code secret (c’est Banksys qui effectue la vérification).
7. Banksys contacte la banque de l’acheteur et vérifie que le montant est disponible.
8. Banksys envoie le 'OK' au terminal. 9. Banksys donne l'ordre à la société de clearing (Clearing House) de
transférer l'argent du compte de l’acheteur à celui du commerçant. 10. L'écran affiche un message signalant que le paiement est en ordre. 11. L’acheteur reprend sa carte. 12. Le terminal imprime la souche relative à la transaction.13. Le commerçant remet à l’acheteur la preuve de paiement.
Scénario alternatif Les scénarios alternatifs sont très importants
et forment généralement la plus grande partie du texte.
Ils indiquent tous les autres scénarios ou branchement possibles, tant en cas de succès qu’en cas d’échec.
L’ensemble formé par le scénario normal et les scénarios alternatifs doit satisfaire « presque » tous les intérêts des parties prenantes.
Le scénarios alternatifs sont des branches qui partent du scénario de base : ils doivent donc être numérotés en fonction de la numérotation de celui-ci.
Exemple : Scénario alternatif d’un paiement électronique1.L’acheteur introduit sa carte dans le terminal.
1. La carte est illisible ; le terminal affiche le message « carte illisible » et la transaction est annulée.
2. La carte est lisible ; passage au point 2.2.Le commerçant encode le montant.
1. Le commerçant s’est trompé dans l’encodage du montant ; il annule le montant ; retour au point 2.
2. Le montant a été correctement encodé ; passage au point 3.3.L’acheteur contrôle le montant sur l'écran.
1. Le montant affiché est incorrect :1. L’acheteur ignore l’erreur (erreur en sa faveur) ; passage au
point 4.2. L’acheteur signale l’erreur au commerçant ; retour au point 2.1
2. Le montant affiché est correct ; passage au point 4.4.Le terminal affiche le message « Code ».
Exemple : Scénario alternatif d’un paiement électronique (suite)5. L’acheteur introduit son code secret. 6. Le terminal contacte le réseau Banksys pour la vérification de la
validité de la carte bancaire et la vérification du code secret (c’est Banksys qui effectue la vérification). 1. Vérification de la validité de la carte bancaire.
1. Le numéro de carte est incorrect; le terminal et l’écran du commerçant affichent le message « carte incorrecte » et la transaction est annulée.
2. La carte a été verrouillée ; le terminal et l’écran du commerçant affichent le message « carte verrouillée » et la transaction est annulée (le service « Perte et vol de cartes » de Banksys est averti).
3. La carte a été volée ; le terminal affiche le message et l’écran du commerçant affichent « carte verrouillée » et la transaction est annulée (le service « Perte et vol de cartes » de Banksys est averti).
4. La carte bancaire est valide ; passage au point 6.22. Vérification du code secret de l’acheteur.
1. Le code est incorrect :1. C’est le premier code incorrect de la transaction ; le terminal affiche le message « code incorrect,
2ème essai » ; retour au point 4.2. C’est le deuxième code incorrect de la transaction ; le terminal affiche le message « code
incorrect, dernier essai » ; retour au point 4.3. C’est le troisième code incorrect de la transaction ; la carte est bloquée; le terminal et l’écran du
commerçant affichent le message « code incorrect : carte bloquée » ; la transaction est annulée.2. Le code est correct ; passage au point 7.
Exemple : Scénario alternatif d’un paiement électronique (fin)7. Banksys contacte la banque de l’acheteur et vérifie que
la transaction est autorisée (rappelons que les règles peuvent varier d’une banque et d’un client à l’autre). 1. La transaction est refusée; le terminal et l’écran du
commerçant affichent le message « Transaction refusée » ; la transaction est annulée.
2. La transaction est acceptée; passage au point 8.8. Banksys envoie le 'OK' au terminal. 9. Banksys donne l'ordre à la société de clearing (Clearing
House) de transférer l'argent du compte de l’acheteur à celui du commerçant.
10.L'écran affiche un message signalant que le paiement est en ordre.
11.L’acheteur reprend sa carte. 12.Le terminal imprime la souche relative à la transaction.
Principe : rédigez les UC en style essentiel Lors d’un atelier d’expression des besoins, le caissier
dira par exemple que l’un de ses buts est de « se connecter ».
Il pense probablement à une interface utilisateur, une boîte de dialogue, un nom d’utilisateur, un mot de passe.
Il s’agit là d’un mécanisme qui permet d’atteindre un but et non d’un but en soi.
En remontant la hiérarchie des buts (« quel est le but de ce but »), l’analyste parvient à un but indépendant du mécanisme (« être identifié et authentifié »), voire à un but de niveau supérieur (« empêcher les vols »).
Ce processus de découverte des buts primordiaux peut permettre d’envisager de nouvelles et meilleures solutions.
Par exemple, utilisation d’un lecteur biométrique. Quel est le profil de l’utilisateur type ? Ses doigts sont-ils couverts de graisse ? …
Principe : rédigez les UC en style essentiel Le principe du style essentiel peut
être résumé par « laissez de côté l’interface utilisateur; concentrez-vous sur l’intention ».
Le style essentiel évite les détails de l’IHM et se focalise sur la finalité.
Dans le style essentiel, le scénario est exempt de détails sur la technique et les mécanismes en particulier ceux qui sont liés à l’IHM.
Principe : rédigez les UC en style essentiel Exemple en style essentiel
Gérer les utilisateurs 1. L’administrateur d’identifie 2. Le Système authentifie l’identité
Exemple en style concret Gérer les utilisateurs
1. L’administrateur saisit son identifiant et son mot de passe dans la boîte de dialogue (voir figure X).
2. Le Système authentifie l’administrateur. 3. Le Système affiche la fenêtre « modifier les
utilisateurs » (voir figure Y).
Principe : rédigez les UC en style essentiel
Ces cas d’utilisation concrets peuvent être utiles lors d’une phase ultérieure où on construira les interfaces utilisateurs dans le détail.
Ils ne sont pas souhaitables dans les premières étapes de l’analyse des besoins.
Principe : rédigez avec concision
Rédigez avec concision et supprimez les mots inutiles.
Concis : « qui exprime beaucoup de choses en peu de mots »
Principe : rédigez les UC en « boîte noire » Les cas d’utilisation en boîte noire sont la
forme le plus courante et la plus recommandée.
Il ne décrivent pas le fonctionnement interne du système, ses composants ou sa conception.
En revanche, ils décrivent le système en termes de responsabilités.
Ils décrivent ce que le système fera (le comportement ou les besoins fonctionnels) sans définir comment il le fera (la conception).
Lors de l’analyse des besoins, évitez de prendre des décisions sur le « comment », et spécifiez le comportement du système sous forme de boîte noire.
Principe : rédigez les UC en « boîte noire »
Style en boîte noire: Le système enregistre la vente
Déconseillé Le système enregistre la vente dans
une base de données. Le système génère un ordre SQL
INSERT pour la vente.
Principe : perspective centrée sur les acteurs et sur le buts
Rédiger les spécifications en se centrant sur les utilisateurs et les acteurs du système, en posant des questions sur leurs buts et sur les situations types qu’ils rencontrent.
S’attacher à comprendre ce que l’acteur considère comme un résultat ayant de la valeur.
Principe : perspective centrée sur les acteurs et sur le buts L’importance de se centrer sur la valeur pour
l’utilisateur et sur ses buts peut sembler évidente, mais l’industrie du logiciel compte de nombreux projets ratés qui n’ont pas apporté aux clients ce dont ils avaient réellement besoin.
L’ancienne méthode qui consiste à dresser une liste de caractéristiques et de fonctions peut contribuer à ce résultat négatif, parce qu’elle n’encourage pas les développeurs à se demander qui utilise le produit et quelle est la valeur que celui-ci apporte.
Comment découvrir les cas d’utilisation On définit des cas d’utilisation pour permettre aux
acteurs principaux d’atteindre leurs buts. La procédure de base est donc la suivante :
Délimiter le système. S’agit-il d’une application logicielle, de l’ensemble matériel et application, de cet ensemble plus la personne qui l’utilise ou de toute une organisation ?
Identifier les acteurs principaux, à savoir ceux qui atteignent leurs buts en utilisant les services du système.
Identifier les buts de chaque acteur principal. Définir des cas d’utilisation qui correspondent aux objectifs
des utilisateurs et les nommer conformément à ces buts. En développement itératif, tous les buts et les cas
d’utilisation ne sont naturellement pas entièrement et correctement identifiés d’emblée : il s’agit un processus de recherche évolutif.
Comment découvrir les cas d’utilisation
Étape 1 : choisir les limites du système Définir ce qui est extérieur au
système Acteurs principaux et auxiliaires, Système (système de paiement
électronique)
Comment découvrir les cas d’utilisation
Étape 2 et 3 : Identifier les acteurs principaux et auxiliaires et leurs buts. Parfois ce sont les buts qui révèlent
les acteurs, parfois c’est l’inverse. Principe de base : se concentrer sur la
recherche des acteurs principaux, ce qui fournira le cadre des investigations ultérieures.
Comment découvrir les cas d’utilisation Questions qui permettent d’identifier acteurs et buts :
Qui démarre et arrête le système ? Qui est responsable de la gestion des utilisateurs et de la
sécurité ? Existe-t-il un processus de surveillance qui restaure le
système s’il tombe en panne ? Comment les mises à jour logicielles sont-elle gérées ? Qui assure l’administration du système ? Le « temps » est-il un acteur (événement temporel) ? Qui évalue l’activité ou les performances du système ? Qui évalue les journaux ? Sont-ils récupérés à distance ? Outre les acteurs principaux humains, y a-t-il des systèmes
externes, logiciels ou matériels qui font appel aux services du système ?
Qui reçoit les notifications en cas d’erreur ou de panne ? …
Comment découvrir les cas d’utilisation
Dans un atelier d’expression des besoins, vous pouvez poser ces deux questions : Que faites-vous ? (orientée cas
d’utilisation) Quels sont vos buts dont les résultats
ont une valeur mesurable ? Préférez la seconde question.
Comment découvrir les cas d’utilisation Étape 4 : définir les cas d’utilisation.
On définit généralement un cas d’utilisation pour chaque but utilisateur, et on le nomme d’après ce but.
Exemple : si le but est de traiter une vente, le cas d’utilisations se nomme « traiter une vente »
Nommez les cas d’utilisation par un verbe à l’infinitif.
Exception à la règle « un cas d’utilisation par but » consiste à regrouper les opérations de gestion (création, récupération, modification, …) en un seul cas d’utilisation nommé par convention « Gérer… »
Diagrammes des cas d’utilisation
UML fournit une notation permettant de représenter sous forme de diagrammes les noms des cas d’utilisation, ceux des acteurs et les relations qui existent entre eux.
Voyons un exemple.
Diagrammes des cas d’utilisation
Clients
Formateurs Consulter le planning des formations
Gérer les formations
Assigner les formateurs aux formations
Les Acteurs et les Use-Cases en première analyse T.B. 15 juin 2001
Administratif
requiert les informations
Facturation
Inscription à une session
Diagrammes des cas d’utilisation Pour les dépendances entre cas
d’utilisation, deux stéréotypes sont souvent utilisés : Include : Si un UC inclut un autre, le UC
inclus sera toujours réalisé totalement durant la réalisation du UC qui le contient.
Extend : Si un UC "étend" un autre, il sera éventuellement réalisé (si une condition est remplie) lorsque le UC "étendu" est réalisé.
Diagrammes des cas d’utilisation
Clients
Gérer les formations
Inscription à une session
Consulter le planning des formations Formateur
Administratif
Facturation
Assigner les formateurs aux sessions
Rechercher une Formation
Modifier une Formation
Ajouter une Formation
Supprimer une Formation
<<include>>
<<include>>
<<extend>>
<<extend>>
<<extend>>
<<extend>> requiert les informations
Diagrammes des cas d’utilisation Attention aux excès de diagrammes
Le plus important est la rédaction du texte et non les diagrammes ou les relations entre UC.
Si une équipe passe de nombreuses heures (ou pire encore, des jours) à travailler sur un diagramme et à analyser les relations entre UC au lieu de se consacrer à la rédaction, elle se trompe de priorité et gaspille ses efforts.
