Lecon n° 1: Diagramme de cas d'utilisation Introduction La modélisation des besoins d'un systéme implique de définir ce qu’il doit faire, d’un point de vue externe au systéme, sans avoir a préciser comment. Dans ce cas, on élabore le diagramme de cas d'utilisation pour spécifier le comportement attendu du systéme. Ainsi, un diagramme de cas d’utilisation permet de visualiser le systéme entier comme une boite noire, permettant de voir ce qui se passe a l’extérieur du systéme ainsi que la facon dont le systéme réagit par rapport aux éléments externes. Le diagramme de cas d'utilisation permet de décrire linteraction entre le systéme et un acteur (utilisateur du systéme). Cest un moyen de recueillir et de décrire les besoins des acteurs du systme. Formalisme La figure n°l, ci-dessous, illustre un diagramme de cas d'utilisation d’un systéme de distribution de billets automatique. Le systéme 4 modéliser apparait dans un cadre, les utilisateurs sont représentés par des petits bonshommes et les grandes fonctionnalités (les cas d'utilisation) par des ellipses. L’ensemble des cas d'utilisation contenus dans le cadre constitue le systéme. Les petits bonhommes sont appelés des acteurs. Ils sont connectés au systéme par des simples traits appelés ass cas d’ utilisation et mettant en évidence les interactions possibles entre le systéme et le monde extérieur. Chaque cas d'utilisation modélise une fagon particuliére et cohérente d’uliliser un systéme pour un acteur donné, Figure n°1 : Diagramme de cas d utilisation modélisant un systéme DAB 11 Le systéme Le systéme constitue le domaine d’étude, il est entouré par un cadre a fin de séparer le systéme a modéliser du domaine extérieur.Exemples de systéme ‘* Systéme de gestion d’octroi des crédits * Systéme de gestion d’un parc informatique, etc. 1.2 Acteur 1.24. Définition Unacteur est un utilisateur du systéme. Il représente un ensemble cohérent de réles joués par les utilisateurs vis-a-vis du systéme. Un acteur communique et interagit avec les cas d'utilisation du systéme en échangeant des messages. Un acteur représente un role qu’un homme, une machine ou un méme un autre systéme joue avec le systéme. Exemple : Une personne qui travaille pour une banque sera le Gestionnaire de Préts. Si elle a son compte dans la méme banque, elle jouera aussi le role clu Client. QO & K — Réle de facteur Figure n°2 : Notation d/unacteur dans un diagramme de cas d’ utilisation Remarques R1) Ine faut pas confondre un acteur et une personne utilisant le systéme, en effet : Y Une méme personne peut jouer plusieurs réles par rapport au systéme étudié et étre modélisée par plusieurs acteurs. Par exemple, une personne qui travaille pour une banque aura le rle Gestionnaire de préts, Si elle a un compte dans la méme banque, elle jouera aussi le role du Client. ¥ Plusieurs personnes peuvent jouer un méme 10le. Elles seront alors modélisées par le méme acteur. Y Unacteur n’est pas forcément une personne physique. R2) Chaque acteur du systéme doit étre nommé, Pour lui attribuer un nom, il faut penser a son réle vis-a-vis d’un systéme. Ainsi, pour un logiciel de gestion de paie le nom correct de I'acteur est Comptable plutot que Mr X. Le nom d’un acteur peut étre accompagné dune breve description textuelle.oe aa oy peer ore atan: Prema Figure n°3 : Commentaire décrivant le rdle de facteur « Guichetier » dans le systeme bancaire 1.2.2. Types d’acteurs En plus des utilisateurs humains qui utilisent le systme a travers une interface graphique, les acteurs peuvent étre : Y Des logiciels : Ce sont des logiciels externes au systéme et qui communiquent avec lui, Par exemple le Systéme de carte visa dans le cas d’un systéme de vente en ligne Y Des_matériels: Ce sont les périphériques manipulés par le systéme. Par exemple des robots ou des automates qui envoie des données au syst@me ou qui est piloté par le systéme. 13 Cas d'utilisation (use case) 13.1 Définition Un Cas d’ utilisation : Y Est une représentation d'une fonctionnalité (ensemble des actions) réalisées par le systéme en réponse a une action d’un acteur. ¥ Constitue une description du comportement (actions +réactions) du systeme du point de vue de son utilisateur. Y Estune suite d’interactions entre un acteur et le systeme, Y Permet datteindre un objectif aux yeux de l'utilisateur. Y Doit étre utile. Le cas dlutilisation est connecté a un acteur a travers une association représentée par une ligne continue : Remarque : Un cas dutilisation est caractérisé par : Y Unnom : Utiliser un verbe & l'infinitif (Ex : Réceptionner un colis) ¥ Des acteurs principaux : Ce sont les utilisateurs qui utilisent les fonctionnalités principales du systéme a travers l'interface graphique du systéme. Y Des acteurs secondaires : qui regroupent les personnes qui exécutent les taches administration ou de maintenance.Borne interactive dune banque Classe Nom du systéme onannooneC 35 0 tlisation Frontiere du systeme,, Consulter comptes fees tentatives eg aes eae ES Ong eT) Figure n°4 : Exemples de diagramme d'utilisation13.2. Cas d'utilisation et scénarios Un cas d'utilisation est une collection de scénarios de succés ou d’échec qui décrit la fagon dont un acteur particulier utilise un systéme pour atteindre un objectif. Un scénario est une séquence spécifique dlactions qui illustre le comportement. Les scénarios sont aux cas d'utilisation ce que les objets sont aux classes : ils sont en fait des instances des cas d'utilisation. Le diagramme de cas utilisation décrit les. grandes fonctionnalités d’un systéme du point de vue des acteurs, mais n’expose pas de facon détaillée le dialogue entre les acteurs et les cas utilisation. On distingue trois types de scénarios : Y Unscénario nominal : celui qui satisfait les objectifs des acteurs par le chemin le plus direct de succds. Y Un scenario alternatif : Il diverge du scénario nominal. C’est un embranchement dans un scénario nominal mais y revient toujours et il posséde une fin normal. Y Un scénario d'exception : Il intervient quand une erreur se produit. le scénario nominal s'interrompt, sans retour au scénario nominal. Il s’agit d’un échec. scénarlos échec > jo Figure n°5 : Illustration graphique des scénarios dun cas d'utilisation Chaque scénario est composé d’étapes qui peuvent étre de trois sortes : ¥ un message d’un acteur vers le systéme, ¥ une validation ou un changement d'état du systéme, v un message du systéme vers un acteur. Les étapes sont numérotées séquentiellement afin de pouvoir facilement indiquer par la suite les alternatives possiblesCas d'utilisation : Retirer de Uargent au distributeur (DAB) avec une carte bancaire. 1. Le client introduit sa carte dans le DAB. 2. Le DAB vérifie que la carte introduite est bien une carte bancaire. 3. Le DAB demande au client de fournir son code d’identification. 4. Le client entre son code d’identification. 5. Le DAB valide le code d’identification. 6. Le DAB demande une autorisation au syst®me d‘autoris 7. Le systéme d’autorisation externe donne son accord et indique le solde hebdomadaire. 8. Le DAB demande au client de saisir le montant désiré du retrait. 9, Le client saisit son montant de retrait. 10. Le systéme vérifie que le montant de retrail est autorisé. 11. Le systéme délivre au client I'argent et la carte bancaire. tion externe. Exemple de scénarios d‘alternatif : 5a. Le DAB détecte que le code saisi est erroné, pour la premiere ou deuxitme fois. 1. Le DAB indique au client que le code est erroné. 2. Le DAB enregistre I’échec de l’opération et le cas d'utilisation reprend a Yétape 4 du scénario nominal. Exemple de scénarios d’exception 2a. La carte introduite nest pas reconnue par le DAB. 1. Le DAB éjecte la carte et Je cas d'utilisation se termine en échec. 5b. Le DAB détecte que le code saisi est erroné, pour la troisiéme fois, 1. Le DAB indique au client que le code est erroné pour la troisiéme fois. 2. Le DAB confisque la carte 3. Le DAB informe le systéme d’autorisation externe et le cas d’utilisation se ter mine en échee.14 Organisation des cas d'utilisation Pour darifier un diagramme, UML permet d’établir des relations entre les cas utilisation. Il existe principalement deux types de relations permettant d’organiser les cas dutilisations Y Les dépendances stérotypées : sont des dépendances dont la portée est explicitée par le nom du stéréotype. Les stéréoty pes les plus utilisés sont linclusion : <> et extension <>. Y La généralisation. 1.4.1 Relation d’inclusion Un cas A est inclus dans un cas B, illustré par le stéréotype <>, si le comportement décrit par le cas A est inclus dans le comportement du cas B : on dit alors que le cas B depend de A <> ee Figure n°6 : Formalisme de la relation dinclusion entre cas d'utilisation Les liens d’utilisation permettent de : V Factoriser les cas d‘utilisation qui peuvent servir pour d’autres cas utilisation, en faisant l’extraction d’une séquence d'interactions communes présentes dans le scénario de plusieurs cas d'utilisation. Exemple : Figure n°7 : Relation de dépendance « include » entre cas d'utilisation pour Factoriser les cas d'utilisation ¥ Simplifier les cas d’utilisations en montant leur décompositionFigure n°8 : Relation cle dépendance « include » entre cas utilisation pour cécomposer un cas complexe Remarques : Ri) Le cas utilisation inclus n’est jamais tout seul, il fait toujours partie d’un cas utilisation qui lenglobe. RQ) [inclusion peut étre assimilée au cas d utilisation principal qui tire un comportement du cas d'utilisation fournisseur. 14.2 Relation d’extension Si le comportement d’un cas d'utilisation B peut étre étendu par le comportement du cas d’utilisation A, on dit alors que le cas d’utilisation A étend le cas d’utilisation B. Une extension est souvent soumise 4 condition. Le cas dlutilisation B peut exister tout seul, il peut aussi tre complété par le cas d'utilisation A, sous certaines conditions. L'extension est utilisse pour modéliser la partie d'un cas d'utilisation considérée comme facultative dans le comportement du systéme. Elle permet de séparer le comportement obligatoire du comportement optionnel.CasB <> Figure n°9 : Formalisme de la relation d’extension entre cas d’ utilisation Exemples : Rim NE ON Reco ete cet avec debit différé K Préposé aux commandes Figure n°0 : Exemples de Relation de dépendance « extend » entre cas d'utilisation14.3 Relation de généralisation Un cas d'utilisation A est une généralisation d’un cas d'utilisation B si le cas ‘utilisation B est un cas particulier de A. Cette relation consiste & dire que I’on a un cas utilisation dit « de base » (le cas d'utilisation A), générique, qui déerit des séquences WEvenements et dautres cas d'utilisation (Cas s“utilisation B) qui hérivent de ce comportement de base et le spécialise suivant différents critéres. La relation de _généralisation/ spécialisation est présente dans la plupart des diagrammes UML et se traduit par le concept d’héritage dans les langages orientés objet. Figure n°11 : Formalisme de la relation de généralisation entre cas d'utilisation Exemples : fo‘Figure n°12 : Exemples de relation de généralisation entre cas d’ utilisation L5 Relation de généralisation entre acteurs La seule relation possible entre deux acteurs est la généralisation : un acteur A est une généralisation d’un acteur B si ’acteur A peut étre substitué par Vacteur B (tous les cas d'utilisation accessibles 4 A le sont aussi a B, mais linverse n’est pas vrai, Figure n°13 : Exemples de relation de généralisation entre acteursIL Description textuelle des cas d'utilisation Bien que de nombreux diagrammes d’UML permettent de décrire un cas utilisation (diagramme de séquence, diagramme de collaboration), il est recommandé de rédiger une description textuelle car c/est une forme souple qui convient dans bien. des situations. Une description textuelle, couramment utilisée, se compose deux parties : sommaire d’ identification et d’une description de scénarii, & savoir : 1- Sommaire d’identification : contient les informations suivantes : + le nom du cas d'utilisation ; * un résumé de son objectif ; * les acteurs impliqués (principaux et secondaires) ; les dates de création et de mise a jour de la description courante ; + lenom des responsables ; + un numéro de version. 2 Description des scénarii: Elle contient toujours un scénario nominal qui correspond au fonctionnement nominal du cas d'utilisation (par exemple, unt retrait d'argent qui se termine par Vobtention des billets demandés par V'utilisateur). Ce scénario nominal commence par préciser I’événement qui déclenche le cas ('utilisateur introduit sa carte bancaire par exemple) et se développe en trois points : a. Les pré-conditions. Elles indiquent dans quel état est le systéme avant que se déroule la séquence (le distributeur est alimenté en billets par exemple), b. Lesscénarii i, Le scénario nominal, fi, le scénario allernatif, iii, le scénario d’exceptions. c. Les post-conditions. Elles indiquent dans quel état se trouve le syst@me aprés le déroulement de la séquence nominale (ite transaction a été enregistrée par Ia banque par exemple), marques R1) Parfois la séquence correspondant a un cas d’utilisation a besoin d’étre appelée dans une autre séquence (par exemple quand une relation d’inclusion existe entre deux cas d'utilisation). Signifier l'appel d'une autre séquence se fait de la facon suivante : « appel du cas X », ott X est le nom du cas. R2) Les acteurs n’étant pas sous le controle du systéme, ils peuvent avoir des comportements imprévisibles. La séquence nominale ne suffit done pas pour décrire tous les comportements possibles. A un scénario nominal, s‘ajoutent fréquemment des scénarii alternatifs et des scénarios d’exceptions, qui se décrivent de la méme fagon.IIL Les étapes d’élaboration d’un diagramme de cas d'utilisation 1. Définir les bornes du systéme. 2. Identifier les acteurs et les cas d'utilisation Qui utilisera les fonctionnalités principales du systéme ? Quia besoin du support du systéme pour effectuer ses téches quotidiennes ? Qui doit mettre a jour, administrer et veiller au fonctionnement du systéme ? Quels systémes de matériel le syst@me logiciel doit- il manipuler ? Avec quels autres systémes le systéme interagit-il ? Qui a un intérét pour les résultats produits ? 3. Définir les relations entre les cas d'utilisation. 4, Valider et vérifier le modéle.QCM Diagramme de cas d'utilisation ‘A une question correspond une seule réponse juste. Indiquer la lettre de la bonne réponse, 1- Les cas d'utilisation correspondent 4 un ensemble d’interactions entre un utilisateur et le systeme. A) Vrai B) Faux Un cas d’utilisation prend en compte les objectifs non fonctionnels d’un utilisateur. A) Vrai B) Faux 3 Dans un cas d'utilisation, un acteur représente un utilisateur jouant un 16] précis dans utilisation du systeme. A) Vrai B) Faux 4- Pour les acteurs primaires, Vobjectif du cas dutilisation est essentiel. A) Vrai B) Faux 5- Pour les acteurs secondaires, l'objectif du cas dutilisation est également essentiel. A) Vrai B) Faux 6 Unacteur est une personne interne au systéme. A) Vrai B) Faux Un acteur est obligatoirement une personne physique. A) Vrai B) Faux 8 Larelation de communication lic un acteur au systéme. A) Vrai B) Faux 9 Tous les cas d'utilisation ont une relation de communication directe avec un acteur. A) Vrai B) Faux 10- La relation de généralisation/spéci. utilisation. A) Vrai B) Faux 2 7 isation est une relation liant deux casCorrigé QCM Diagramme de cas d'utilisation ‘A une question correspond une seule réponse juste. Indiquer la lettre de la bonne réponse, Lt 10- Les cas d’utilisation correspondent a un ensemble d'interactions entre un utilisateur et le systéme. B) Faux Un cas d'utilisation prend en compte les objectifs non fonctionnels d’un ulilisaleur, A) Vrai Dans un cas d'utilisation, un acteur représente un utilisateurjouant un role précis dans 'utilisation du systeme. B) Faux Pour les acteurs primaires, Vobjectif du cas d'utilisation est essentiel. B) Faux Pour les acteurs secondaires, 'objectif du cas d'utilisation est également essentiel. A) Vrai Un acteur est une personne interne au systéme. A) Vrai Un acteur est obligatoirement une personne physique. A) Vrai La relation de communication lie un acteur au syst2me. B) Faux Tous les cas d'utilisation ont une relation de communication directe avec un acteur. A) Vrai La relation de généralisation/sp isation est une relation liant deux casExercice d’application SYSTEME LOGICIEL D’UNE CAISSE ENREGISTREUSE Il s'agit d'un systéme simplifié de caisse enregistreuse de supermarché. Le déroulement normal d'utilisation de la caisse est le suivan © Un client arrive & la caisse avec des articles & payer. caissier enregistre le numéro d'identification de chaque article, que la quantité si elle est supérieure & un. La caisse affiche le prix de chaque article et son libellé. Lorsque tous les achats sont enregistrés, le caissier signale Ia fin de la vente. La caisse affiche le total des achats. Le client choisit son mode de paiement : > Liquide : le caissier encaisse Pargent regu, la caisse indique la monnaie & rendre au client, > Chéque : le caissier vérifie la solvabilité du client en transmettant une requéte 3 un centre d’autorisation via la caiss > Carte de crédit : un terminal baneaire fait partie de la caisse. Tl transmet une demande d’autorisation & un centre d’autorisation en fonction de type de la carte, # La caisse enregistre la vente et imprime un ticket. © Le caissier donne le ticket de caisse au client. Aprés la saisie des articles, le client peut présenter au caissier des coupons de réductions pour certains articles, Lorsque le paiement est terminé, la caisse transmet les informations sur le nombre d’articles vendus au systtme de gestion de stocks. Tous les matins, le responsable du magasin initialise les caisses pour la journée. Questions : 1- Elaborer le diagramme de cas d'utilisation du systéme de la caisse enregistreuse en suivant la démarche suivante : a. Identifier les acteurs. b. Identifier les objectifs de chaque acteur. c. Représenter les cas d'utilisation. d. Représenter les associations entre acteurs et cas d'utilisation e. Elaborer une structuration des cas d'utilisation, si elle existe. 2 Blaborer une description textuelle du cas Putilisation « Traiter passage en caisse »Proposition de Corrigé ‘Systéme logiciel d’une caisse enregistreuse Y Le diagramme de cas d'utilisation du systéme de la caisse enregistreuse. Diagramme de cas d'utilisation du systéme de la caisse enregistreuse 2 ‘Sommaire d’identification Titre :« Trater le passage en caisse » But: détailler les étapes permettant au caissier d'enregistrer les achats dun client et récupérer le paiement. Acteur principal : Caissier Acteur secondaire : Client Date de eréation : 20/04/2017 Date de mise a jour : 27/04/2017 Version :1Le cas d'utilisation commence quand un client arrive & la caisse avec des articles qu’il souhaite acheter. Préconditions - La caisse est ouverte (en service) ; un caissier y et connecté, Scénario nominal 1. Le caissier enregistre chaque article. S‘il_ya a plus d'un exemplaire par article, le caissier indique également la quantité. Puis il appuie sur le bouton de validation. 2 La caisse détermine le prix de Varticle et ajoute les informations sur article & la vente en cours. La caisse affiche la description et le prix de article en question. 3. Apres avoir enregistré tous les articles, le caissier inclique que la vente est terminée, 4, La caisse calcule et affiche le montant total de la vente. 5. Selon le mode de paiement du client a. En cas de paiement en espace, exécuter le cas d'utilisation « Traiter le paiement en liquide »; b. En cas de paiement par carte de crédit, exécuter le cas d’ utilisation « Traiter le paiement par carte cle crédib> ; En cas de paiement par chaque, exécuter le cas d'utilisation « Traiter le paiement par cheque 6. La caisse enregistre la vente qui vient d’étre effectué et imprime un ticket, Scénario alternatif AL: Le numéro ‘identification est inconnu L’enchainement A1 démarre au point 2 du seénario nominal 2. La caisse indique au caissier que le numéro d'identification de article est inconnu. Varticle ne peut pas étre pris en compte dans la vente en cours. Le scénario nominal reprend au point 1. Scénario d’exception EL: Le client ne peut pas payer L’enchainement E1 démarre au point 5 du scénario nominal. 5. Le dient ne peut pas payer le total avec aucun moyen de paiement autorisé, 6. Le caissier annule l'ensemble de la vente et le cas d'utilisation est terminé.