La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Cas dutilisation (use case). Introduction Les cas dutilisation sont des descriptions textuelles, largement utilisées pour détecter et consigner les besoins.

Présentations similaires


Présentation au sujet: "Cas dutilisation (use case). Introduction Les cas dutilisation sont des descriptions textuelles, largement utilisées pour détecter et consigner les besoins."— Transcription de la présentation:

1 Cas dutilisation (use case)

2 Introduction Les cas dutilisation sont des descriptions textuelles, largement utilisées pour détecter et consigner les besoins. Ils influencent de nombreux aspects dun projet, y compris lanalyse et la conception orientées objet. Ils sont la source de nombreux autres artefacts des études de cas.

3 Introduction Pour simplifier, un cas dutilisation « raconte » sous forme de texte la façon dont un acteur va utiliser un système pour atteindre un but. Voyons un exemple.

4 Exemple de cas dutilisation Traiter une vente : Un client arrive à la caisse avec les articles quil 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.

5 Cas dutilisation : texte Remarquons que les cas dutilisation ne sont pas des diagrammes, mais des textes. Se concentrer sur les diagrammes UML dont lintérêt est secondaire par rapport aux énoncés est une erreur que les novices commettent couramment. Les cas dutilisation doivent souvent être plus détaillés ou plus structurés que lexemple précédent. La finalité des cas dutilisation 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- datteindre ses différents objectifs.

6 Définitions : acteurs, scénarios et cas dutilisation 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 dactions et dinteractions entre un ou plusieurs acteurs et le système. Cest une « histoire » particulière de la façon dont on utilise un système, ou lun des cheminements possibles dun cas dutilisation. Par exemple, le traitement dune 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.

7 Définitions : acteurs, scénarios et cas dutilisation Pour simplifier, un cas dutilisation 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.

8 Définitions : acteurs, scénarios et cas dutilisation Traiter un retour Scénario principal (succès) Un client arrive à la caisse avec les articles quil veut retourner. Le caissier utilise le système automatisé pour enregistrer chaque article retourné … Autres scénarios Si le client a payé à crédit davance et que la demande de remboursement sur son compte est rejetée, len informer et le rembourser en espèce. Si le code de larticle nest pas reconnu par le système, informer le caissier et lui suggérer de saisir le code manuellement (lemballage peut être endommagé). Si le système ne parvient pas à communiquer avec le système comptable externe…

9 Pourquoi des cas dutilisation 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 derreur.

10 Pourquoi des cas dutilisation Labsence dimplication des utilisateurs est lune des principales raisons déchec des projets logiciels, et tout ce qui peut les aider à demeurer motivés est éminemment souhaitable. Les cas dutilisation 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).

11 Pourquoi des cas dutilisation Un autre intérêt des cas dutilisation est quils mettent laccent sur les points de vue et les buts de lutilisateur : Qui sont les utilisateurs du système ? Quels sont leurs scénarios dutilisation 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.

12 Pourquoi des cas dutilisation Les cas dutilisation ont fait lobjet de nombreux articles et ouvrages. Malgré linté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 quil sencombre de questions secondaires telles que les diagrammes de cas dutilisation, les relations entre cas dutilisations, les packages de cas dutilisation et ainsi de suite, au lieu de se concentrer sur la principale difficulté : écrire simplement des descriptions.

13 Les trois types dacteur Un acteur est une entité quelconque ayant un comportement, ce qui inclut le système lui-même quand il fait appel aux services dautres systèmes. Les trois types dacteurs sont : Lacteur principal, Lacteur auxiliaire Lacteur hors champ

14 Les trois types dacteur Lacteur principal. Il a des buts dutilisateur, quil atteint en utilisant les services du système. Ce peut être, par exemple, le caissier. Pourquoi lidentifier ? Pour découvrir les buts utilisateurs qui pilotent les cas dutilisation.

15 Les trois types dacteur Lacteur auxiliaire. Il fournit un service (par exemple, une information) au système. Le service dautorisation de paiement automatisé en est un. Cest souvent un système informatique, mais il peut sagir dune autre organisation ou dune personne.

16 Les trois types dacteur Lacteur hors champ. Il a un intérêt dans le comportement du cas dutilisation, sans être un acteur principal ni auxiliaire. Il peut, par exemple, sagir des services fiscaux. Pourquoi lidentifier ? Pour sassurer que TOUS les intérêts ont bien été identifiés et quils 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.

17 Les trois formats des cas dutilisation Les cas dutilisation peuvent prendre différents formats, avec différents niveaux de formalisme : Abrégé, Informel, Détaillé.

18 Les trois formats des cas dutilisation Format abrégé : Résumé succinct qui présente généralement le scénario de base (succès) dans un paragraphe. Cest le cas de notre premier exemple traiter une vente Sutilise 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.

19 Les trois formats des cas dutilisation Format informel : Les différents scénarios sont décrits dans plusieurs paragraphes. Cest le cas de notre deuxième exemple, Traiter un retour. Sutilise comme le format abrégé.

20 Les trois formats des cas dutilisation 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). Sutilise lorsque de nombreux cas dutilisation on été identifiés et rédigés au format abrégé.

21 Documentation dun cas dutilisation 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 dun autre UC, base de données inexistante, etc…) Technique de déploiement : enclenché via le web, via un terminal, en intranet, en C/S

22 Documentation dun cas dutilisation 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.

23 Documentation dun cas dutilisation 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…)

24 Documentation dun cas dutilisation 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. Dautres rubriques peuvent être rajoutées.

25 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

26 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 na 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 : …

27 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, [ ], [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

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

29 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 dun cas dutilisation nobéit pas à cette classification mais indique lévénement qui déclenche le scénario (« le client arrive à la caisse et … »)

30 Exemple : Scénario normal dun paiement électronique 1. Lacheteur introduit sa carte dans le terminal. 2. Le commerçant encode le montant. 3. Lacheteur contrôle le montant sur l'écran. 4. Le terminal affiche le message « Code » 5. Lacheteur 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 (cest Banksys qui effectue la vérification). 7. Banksys contacte la banque de lacheteur 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 lacheteur à celui du commerçant. 10. L'écran affiche un message signalant que le paiement est en ordre. 11. Lacheteur reprend sa carte. 12. Le terminal imprime la souche relative à la transaction. 13. Le commerçant remet à lacheteur la preuve de paiement.

31 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 quen cas déchec. Lensemble 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.

32 Exemple : Scénario alternatif dun paiement électronique 1. Lacheteur 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 Le commerçant encode le montant. 1. Le commerçant sest trompé dans lencodage du montant ; il annule le montant ; retour au point Le montant a été correctement encodé ; passage au point Lacheteur contrôle le montant sur l'écran. 1. Le montant affiché est incorrect : 1. Lacheteur ignore lerreur (erreur en sa faveur) ; passage au point Lacheteur signale lerreur au commerçant ; retour au point Le montant affiché est correct ; passage au point Le terminal affiche le message « Code ».

33 Exemple : Scénario alternatif dun paiement électronique (suite) 5. Lacheteur 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 (cest 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 Vérification du code secret de lacheteur. 1. Le code est incorrect : 1. Cest le premier code incorrect de la transaction ; le terminal affiche le message « code incorrect, 2ème essai » ; retour au point Cest le deuxième code incorrect de la transaction ; le terminal affiche le message « code incorrect, dernier essai » ; retour au point Cest 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.

34 Exemple : Scénario alternatif dun paiement électronique (fin) 7.Banksys contacte la banque de lacheteur et vérifie que la transaction est autorisée (rappelons que les règles peuvent varier dune banque et dun client à lautre). 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 lacheteur à celui du commerçant. 10.L'écran affiche un message signalant que le paiement est en ordre. 11.Lacheteur reprend sa carte. 12.Le terminal imprime la souche relative à la transaction.

35 Principe : rédigez les UC en style essentiel Lors dun atelier dexpression des besoins, le caissier dira par exemple que lun de ses buts est de « se connecter ». Il pense probablement à une interface utilisateur, une boîte de dialogue, un nom dutilisateur, un mot de passe. Il sagit là dun mécanisme qui permet datteindre un but et non dun but en soi. En remontant la hiérarchie des buts (« quel est le but de ce but »), lanalyste 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 denvisager de nouvelles et meilleures solutions. Par exemple, utilisation dun lecteur biométrique. Quel est le profil de lutilisateur type ? Ses doigts sont-ils couverts de graisse ? …

36 Principe : rédigez les UC en style essentiel Le principe du style essentiel peut être résumé par « laissez de côté linterface utilisateur; concentrez-vous sur lintention ». Le style essentiel évite les détails de lIHM 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 à lIHM.

37 Principe : rédigez les UC en style essentiel Exemple en style essentiel Gérer les utilisateurs 1. Ladministrateur didentifie 2. Le Système authentifie lidentité Exemple en style concret Gérer les utilisateurs 1. Ladministrateur saisit son identifiant et son mot de passe dans la boîte de dialogue (voir figure X). 2. Le Système authentifie ladministrateur. 3. Le Système affiche la fenêtre « modifier les utilisateurs » (voir figure Y).

38 Principe : rédigez les UC en style essentiel Ces cas dutilisation concrets peuvent être utiles lors dune phase ultérieure où on construira les interfaces utilisateurs dans le détail. Ils ne sont pas souhaitables dans les premières étapes de lanalyse des besoins.

39 Principe : rédigez avec concision Rédigez avec concision et supprimez les mots inutiles. Concis : « qui exprime beaucoup de choses en peu de mots »

40 Principe : rédigez les UC en « boîte noire » Les cas dutilisation 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 lanalyse 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.

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

42 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 quils rencontrent. Sattacher à comprendre ce que lacteur considère comme un résultat ayant de la valeur.

43 Principe : perspective centrée sur les acteurs et sur le buts Limportance de se centrer sur la valeur pour lutilisateur et sur ses buts peut sembler évidente, mais lindustrie du logiciel compte de nombreux projets ratés qui nont pas apporté aux clients ce dont ils avaient réellement besoin. Lancienne méthode qui consiste à dresser une liste de caractéristiques et de fonctions peut contribuer à ce résultat négatif, parce quelle nencourage pas les développeurs à se demander qui utilise le produit et quelle est la valeur que celui-ci apporte.

44 Comment découvrir les cas dutilisation On définit des cas dutilisation pour permettre aux acteurs principaux datteindre leurs buts. La procédure de base est donc la suivante : Délimiter le système. Sagit-il dune application logicielle, de lensemble matériel et application, de cet ensemble plus la personne qui lutilise 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 dutilisation qui correspondent aux objectifs des utilisateurs et les nommer conformément à ces buts. En développement itératif, tous les buts et les cas dutilisation ne sont naturellement pas entièrement et correctement identifiés demblée : il sagit un processus de recherche évolutif.

45 Comment découvrir les cas dutilisation É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)

46 Comment découvrir les cas dutilisation É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 cest linverse. Principe de base : se concentrer sur la recherche des acteurs principaux, ce qui fournira le cadre des investigations ultérieures.

47 Comment découvrir les cas dutilisation Questions qui permettent didentifier 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 sil tombe en panne ? Comment les mises à jour logicielles sont-elle gérées ? Qui assure ladministration du système ? Le « temps » est-il un acteur (événement temporel) ? Qui évalue lactivité 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 derreur ou de panne ? …

48 Comment découvrir les cas dutilisation Dans un atelier dexpression des besoins, vous pouvez poser ces deux questions : Que faites-vous ? (orientée cas dutilisation) Quels sont vos buts dont les résultats ont une valeur mesurable ? Préférez la seconde question.

49 Comment découvrir les cas dutilisation Étape 4 : définir les cas dutilisation. On définit généralement un cas dutilisation pour chaque but utilisateur, et on le nomme daprès ce but. Exemple : si le but est de traiter une vente, le cas dutilisations se nomme « traiter une vente » Nommez les cas dutilisation par un verbe à linfinitif. Exception à la règle « un cas dutilisation par but » consiste à regrouper les opérations de gestion (création, récupération, modification, …) en un seul cas dutilisation nommé par convention « Gérer… »

50 Diagrammes des cas dutilisation UML fournit une notation permettant de représenter sous forme de diagrammes les noms des cas dutilisation, ceux des acteurs et les relations qui existent entre eux. Voyons un exemple.

51 Diagrammes des cas dutilisation

52 Pour les dépendances entre cas dutilisation, 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é.

53 Diagrammes des cas dutilisation

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


Télécharger ppt "Cas dutilisation (use case). Introduction Les cas dutilisation sont des descriptions textuelles, largement utilisées pour détecter et consigner les besoins."

Présentations similaires


Annonces Google