Définition du cas d’utilisation Acteurs dans les cas d'utilisation Cas d’utilisation, Scénario Relations entre cas d’utilisation Description des cas d’utilisation Diagramme de cas d’utilisation Etapes pour établir un diagramme Utilité du diagramme de cas d’utilisation Objectif du diagramme de cas d’utilisation 3 Bien identifier : les besoins des utilisateurs la manière dont sera utilisé le système
Bien comprendre : qui sont les utilisateurs les tâches qu’ils doivent réaliser
Décrire : comment l’utilisateur interagit avec le système pour accomplir les tâches qui lui sont fixées Définitions du cas d’utilisation 4 Définition 1: Un cas d’utilisation (use case) modélise une interaction entre le système informatique à développer et un utilisateur ou acteur interagissant avec le système. Définition 2: Un cas d’utilisation décrit un ensemble d’actions réalisées par le système qui produit un résultat observable pour un acteur.
Constatations: - Modélise : pas de détails (pas d’algorithme des interactions) - les actions représentées par les CU sont automatisées et non manuelles
Ils sont utilisables pour tout projet, indépendamment
d’UML et de l’approche objet. Acteurs dans les cas d'utilisation 5 Définition 1 : Représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel, ou autre système) qui interagit directement avec le système étudié Définition 2 : Une entité externe agissant sur le système qui peut : Échanger de l’information avec ce système consulter ou modifier l'état du système, Les acteurs sont : Déterminés en examinant les : Utilisateurs directs du système Responsables de l’exploitation et/ou de la maintenance Autres systèmes interagissant avec le système Représentés sous forme de petits personnages ou sous forme de rectangle avec le mot clé <<acteur>> Acteurs dans les cas d'utilisation 6 Il existe 4 grandes catégories d'acteurs : les acteurs principaux. Cette catégorie regroupe les personnes qui utilisent les fonctions principales du système. Dans le cas d'un distributeur de billets, il s'agit des clients.
les acteurs secondaires. Cette catégorie regroupe les personnes qui
effectuent des tâches administratives ou de maintenance. Dans le cas d'un distributeur de billets, il s'agit de la personne qui recharge la caisse du distributeur.
le matériel externe. Cette catégorie regroupe les dispositifs matériels
autres que les ordinateurs comme les périphériques. Dans le cas d'un distributeur de billets, il s'agit de l'imprimante, du lecteur de carte, de la trieuse de billets.
les autres systèmes. Cette catégorie regroupe les systèmes avec
lesquels le système interagit. Dans le cas d'un distributeur de billets, il s'agit du groupement bancaire qui gère l'ordinateur central qui relie tous les distributeurs. Acteurs dans les cas d'utilisation 7 Les acteurs : Doivent être décrits d’une manière simple et précise Avec des phrases en langage naturel Peuvent être reliés par des liens de généralisation/spécialisation Utilisateur / Administrateur Exemple d’acteurs : Humains : les utilisateurs du logiciel à travers son interface graphique Logiciels : déjà disponibles qui communiquent avec le système grâce à une interface logicielle Matériels : robots et automates qui exploitent les données du système ou qui sont pilotés par le système Cas d’utilisation, Scénario 8 Définition 1 : Un ensemble d'actions réalisées par le système, en réponse à une action d'un acteur Définition 2 : Modélise une fonctionnalité d’un système ou d’une classe
Les cas d’utilisation :
sont représentés par des ellipses
Peuvent être contenus dans un rectangle (représentant le système)
Sont déterminés en observant et en précisant
Acteur par acteur les scénarios du point de vue utilisateur Sont décrits en termes : d’informations échangées et d’étapes d’utilisation du système. Cas d’utilisation, Scénario 9 exemple :
Un cas d’utilisation : Regroupe une famille de scénarios d’utilisation Est une abstraction du dialogue système/utilisateurs
Quand un acteur interagit avec le système:
Le cas d’utilisation instancie un scénario L'ensemble des cas d’utilisation décrit les objectifs du système Utilité des cas d’utilisation pour : les utilisateurs : exprimer les besoins Les analystes : comprendre Les programmeurs : réaliser Les testeurs : vérifier Relations entre cas d’utilisation 10 Extension : spécifier des interactions optionnelles entre 2 cas tenant compte de cas exceptionnels L’instance du CU source ajoute son comportement au CU destination (si la condition est réalisée). Le CU destination étend son comportement par l’ajout de celui du CU source, si la condition est vérifiée. Note : le < < é te n d > > comportement [c o n d it io n d ' exte n s i o n ] du CU1 s’il existe étend le C a s U ti li s a ti o n 1 C a s U ti l i s a ti o n 2 comportement du CU2 exemple : Relations entre cas d’utilisation 11 Relation d’extension (suite) : Peut être soumise à une condition : Le comportement ajouté est inséré au niveau d’un point d’extension Ce point d’extension est défini dans le CU destination Permet de modéliser des variantes de comportement d’un CU Selon les interactions des acteurs et l’environnement du système la condition d’extension peut être spécifiée à côté du mot-clés <<extend>>
Point d’extension : Possède un nom Décrit : Un emplacement dans le CU destination où le comportement du CU source sera inséré. UML ne définit aucun format de description de point d’extension La relation d’extension 12
Extension (suite):
24/09/2021 Relations entre cas d’utilisation 13 Inclusion : l’instance du CU source contient aussi le comportement décrit par le CU destination. La relation d’inclusion a un caractère obligatoire: La source doit indiquer à quel endroit le CU cible doit être inclus Permet de : Décomposer les comportements et Définir des comportements partageables entre plusieurs CU. Note : le < < i n c l u t> > comportement du CU1 nécessite le C a s U ti l i s a ti o n 1 C a s U ti l i s a ti o n 2 comportement du CU2
exemple : Relations entre cas d’utilisation 14 Généralisation / Spécialisation : rassembler des actions communes en « super-cas » décrire des variantes d’un cas général (« sous-cas ») notion d’héritage Le cas d’utilisation Fils est une spécialisation du cas d’utilisation Parent
CasUtilisationParent
CasUtilsationEnfant
exemple : Exemple 1 15
On désire représente par un diagramme de CU les virements
bancaires effectués par des clients:
• Un client peut être local ou distant
• Un client peut effectuer un virement via Internet ou direct (banque) • Dans tous les cas, on doit procéder à une identification du client • Dans le cas d’un virement dont le montant dépasse 500, on procède à une vérification du solde du compte du client. Exemple 2 16 Dans un établissement scolaire, on désire gérer la réservation des salles de cours ainsi que du matériel pédagogique (ordinateur portable ou/et Vidéo projecteur). Seuls les enseignants sont habilités à effectuer des réservations (sous réserve de disponibilité de la salle ou du matériel). Le planning des salles peut quant à lui être consulté par tout le monde (enseignants et étudiants). Par contre, le récapitulatif horaire par enseignant (calculé à partir du planning des salles) ne peut être consulté que par les enseignants. Enfin, il existe pour chaque formation un enseignant responsable qui seul peut éditer le récapitulatif horaire pour l’ensemble de la formation. Description des cas d’utilisation 17 Il n’existe pas de norme (UML) établie pour la description textuelle des cas d’utilisation.
Généralement, on y trouve pour chaque cas d’utilisation :
son nom, un bref résumé de son déroulement, le contexte dans lequel il s’applique, les acteurs qu’il met en jeu, une description détaillée : le déroulement nominal de toutes les interactions, les cas nécessitant des traitements d’exception, les effets du déroulement sur l’ensemble du système, etc. Description des cas d’utilisation 18 Sommaire d’identification Titre : ……………….. Type : ………………… Résumé :……………………………………………………………………………… Acteurs : Date de création : Date de mise à jour :………………………………… Version : Auteur(s) :
Description des Enchaînements :
Pré-conditions : Scénario nominal :
Représente le déroulement normal d’un cas d’utilisation : les différentes interactions utilisateur / système permettant l’exécution réussie du traitement 1. 2. … Enchaînements alternatifs : Quand l’enchaînement précisé par le scénario nominal ne peut pas se dérouler comme prévu : Le cas d’utilisation converge tout de même. Alt1… Alt2… Scénario d’erreur : Quand l’enchaînement précisé par le scénario nominal ne peut pas se dérouler : Le cas d’utilisation se termine par un échec. E1 : E2 : …. Post-condition Description des cas d’utilisation 19 Quelques conseils : Un cas d’utilisation doit être : Simple Décrit de manière claire et concise Le nombre d’acteurs interagissant avec le CU doit être limité Lors de la construction d’un CU, il faut se demander : Quelles sont les tâches de l’acteur ? Quelles informations l’acteur doit-il créer, sauvegarder, modifier, détruire ou simplement lire ? L’acteur devra-t-il informer le système des changements externes ? Le système devra-t-il informer l’acteur des conditions internes ?
Modélisation objet avec UML
P.A. Muller, N. Gaertner Diagramme de cas d’utilisation 20
diagramme de cas d’utilisation :
un ensemble de cas d’utilisation, liés aux acteurs impliqués des relations entre cas d’utilisation (inter-dépendances) une description des cas d’utilisation (textuelle, scénarios) Etapes pour établir un diagramme 21
définir les bornes du système
identifier les acteurs et les cas d’utilisation
définir les relations entre les cas d’utilisation
valider le diagramme avec les utilisateurs
Utilité du diagramme de cas d’utilisation 22
Utile quand les utilisateurs sont amenés à intervenir :
expression des besoins Décrire l’existant, découvrir les besoins Guider le recueil d’information (interviews, …) modélisation du futur système Décrire concrètement les différents processus du système D’autres diagrammes complèteront cette description tests et validation Mise en avant de la logique utilisateur Structuration des tests, validation mise en œuvre Vue « utilisateur » des actions du système Structurer les manuels d’utilisation Résumé 23 identifier, comprendre, représenter : manières d’utiliser un système périmètre, acteurs impliqués
notions : cas d’utilisation, acteur
liens entre cas d’utilisation : extension, inclusion, héritage
description de cas d’utilisation :
nature, acteurs impliqués, actions règles de gestion, documents utilisés et produits
intervient en phase amont :
définir et valider les exigence définir des scénarios de tests structurer les manuels d’utilisation Conclusion 24 Les cas d’utilisation : Sont de bons moyens pour modéliser les besoins des utilisateurs par les utilisateurs. Les avantages : Un formalisme simple : Les concepts proposés sont faciles à comprendre et à utiliser. Les modélisations résultats (UC): Faciles à comprendre, à lire et à interpréter. Un bon moyen de communication : client/concepteur et concepteur/concepteur Les limitations : Subjectifs, dépendant de l’utilisateur : Peuvent être peu précis, ne reflétant pas les besoins majeurs de l’utilisateur ou interprétés différemment. Pas formels : pas de vérification automatique possible ni de génération des autres diagrammes, … Exemple 2 complet 25 Fonctionnement des caisses enregistreuses d’un super marché : Un client arrive à la caisse avec des articles à payer. Le caissier enregistre le numéro d’identification de chaque article, ainsi que la quantité si elle est > 1. La caisse affiche le prix de chaque article et son libellé. Quand tous les achats sont enregistrés, le caissier signale la fin de la vente. La caisse affiche alors la fin des achats et le prix total à payer. Après la saisie des articles, le client peut présenter des coupons de réduction pour certains articles Le client choisit son mode de paiement : Liquide : le caissier encaisse l’argent reçu, la caisse indique le montant à rendre au client. COMPLÉTEZ LES DESCRIPTIONS TEXTUELLES AVEC DES DIAGRAMMES DYNAMIQUES SIMPLES ! 26
Pour documenter les cas d’utilisation, la description textuelle est indispensable,
car elle seule permet de communiquer facilement et précisément avec les utilisateurs.
La description textuelle est également l’occasion de s’entendre sur la
terminologie employée, ainsi que d’identifier le contexte d’exécution de l’un ou de l’autre des enchaînements. En revanche, le texte présente des désavantages puisqu’il est difficile de montrer comment les enchaînements se succèdent ; en outre la maintenance des évolutions s’avère souvent périlleuse.
Il est donc recommandé de compléter la description textuelle par un ou plusieurs
diagrammes dynamiques, qui apporteront un niveau supérieur de formalisation. À vous de décider en fonction de votre contexte si vous montrez ces diagrammes au futur utilisateur, ou si vous les utilisez uniquement comme support d’analyse pour lui poser des questions supplémentaires, et ainsi mieux valider votre texte. COMPLÉTEZ LES DESCRIPTIONS TEXTUELLES AVEC DES DIAGRAMMES DYNAMIQUES SIMPLES ! 27 COMPLÉTEZ LES DESCRIPTIONS TEXTUELLES AVEC DES DIAGRAMMES DYNAMIQUES SIMPLES ! 28 Exemple de description d’un cas d’utilisation : Description via des diagrammes de séquences
Diagrammes de séquences "systèmes" Méthodologie de conception UML 29
