Cas d’utilisation ( use case )

1. Cas d’utilisation (use case)

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

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

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

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

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

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

8. 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…

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

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

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

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

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

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

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

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

17. 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é.

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

19. 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é.

20. 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é.

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

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

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

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

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 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 : • …

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

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 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 … »)

30. Exemple : Scénario normal d’un paiement électronique • L’acheteur introduit sa carte dans le terminal. • Le commerçant encode le montant. • L’acheteur contrôle le montant sur l'écran. • Le terminal affiche le message « Code » • L’acheteur introduit son code secret. • 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). • Banksys contacte la banque de l’acheteur et vérifie que le montant est disponible. • Banksys envoie le 'OK' au terminal. • 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. • L'écran affiche un message signalant que le paiement est en ordre. • L’acheteur reprend sa carte. • Le terminal imprime la souche relative à la transaction. • Le commerçant remet à l’acheteur 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 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.

32. Exemple : Scénario alternatif d’un paiement électronique • L’acheteur introduit sa carte dans le terminal. • La carte est illisible ; le terminal affiche le message « carte illisible » et la transaction est annulée. • La carte est lisible ; passage au point 2. • Le commerçant encode le montant. • Le commerçant s’est trompé dans l’encodage du montant ; il annule le montant ; retour au point 2. • Le montant a été correctement encodé ; passage au point 3. • L’acheteur contrôle le montant sur l'écran. • Le montant affiché est incorrect : • L’acheteur ignore l’erreur (erreur en sa faveur) ; passage au point 4. • L’acheteur signale l’erreur au commerçant ; retour au point 2.1 • Le montant affiché est correct ; passage au point 4. • Le terminal affiche le message « Code ».

33. Exemple : Scénario alternatif d’un paiement électronique (suite) • L’acheteur introduit son code secret. • 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). • Vérification de la validité de la carte bancaire. • 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. • 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). • 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). • La carte bancaire est valide ; passage au point 6.2 • Vérification du code secret de l’acheteur. • Le code est incorrect : • C’est le premier code incorrect de la transaction ; le terminal affiche le message « code incorrect, 2ème essai » ; retour au point 4. • C’est le deuxième code incorrect de la transaction ; le terminal affiche le message « code incorrect, dernier essai » ; retour au point 4. • 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. • Le code est correct ; passage au point 7.

34. Exemple : Scénario alternatif d’un paiement électronique (fin) • 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). • La transaction est refusée; le terminal et l’écran du commerçant affichent le message « Transaction refusée » ; la transaction est annulée. • La transaction est acceptée; passage au point 8. • Banksys envoie le 'OK' au terminal. • 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. • L'écran affiche un message signalant que le paiement est en ordre. • L’acheteur reprend sa carte. • Le terminal imprime la souche relative à la transaction.

35. 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 ? …

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

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

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

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

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 qu’ils rencontrent. • S’attacher à comprendre ce que l’acteur considère comme un résultat ayant de la valeur.

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

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

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

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

47. 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 ? • …

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

49. 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… »

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