Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

UML - Diagramme de cas d’utilisation (Use case diagram) case diagram) Diagramme

UML - Diagramme de cas d’utilisation (Use case diagram) case diagram) Diagramme de cas d’utilisation • Le diagramme Use Case ou Cas d’utilisation est utilisé dans l’activité de spécification des besoins • Il est utilisé pour : – recueillir, analyser et organiser les besoins – recenser les fonctionnalités d’un système – recenser les fonctionnalités d’un système • ce qu’il devra faire (et pas "comment") • description du comportement sous forme d’actions/réactions • représentation des fonctions du système du point de vue des utilisateurs. • déterminer les limites du système • Le diagramme Use Case doit permettre de répondre à la question Qui fait quoi ? Diagramme de cas d’utilisation • Pour construire le diagramme de cas d’utilisation il faut : – identifier les rôles qui interagissent avec (acteurs) – déterminer les grandes catégories d’utilisation – déterminer les grandes catégories d’utilisation (Use cases) – décrire textuellement les interactions (scénarios) Les éléments du diagramme de cas d’utilisation • Le diagramme est constitué de – système – acteurs – cas d’utilisation – cas d’utilisation • Exemple : Acteur • Un acteur (actor ) est un rôle joué par l’utilisateur du système logiciel. • En plus des personnes physiques, les acteurs peuvent être : – Des périphériques manipulés par le système (imprimantes, – Des périphériques manipulés par le système (imprimantes, robots, . . . ) ; – Des logiciels déjà disponibles à intégrer dans le projet ; – Des systèmes informatiques externes au système mais qui interagissent avec lui, etc. • Les acteurs se trouvent obligatoirement à l’extérieur du système. Acteur • Les acteurs sont souvent spécifiés sous forme de personnages stylisés. • Ils peuvent également être représentés par un rectangle doté • Ils peuvent également être représentés par un rectangle doté du stéréotype "actor" ou par un pictogramme (par exemple un symbole d’ordinateur). Acteur • Attention ! • Un acteur correspond à un rôle, pas à une personne physique. – Une même personne physique peut être représentée par plusieurs acteurs si elle a plusieurs rôles. – Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles – Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles seront représentées par un seul acteur. – un acteur n’est pas forcément "humain" Acteur principal ou secondaire • Un acteur principal est celui pour qui le cas d’utilisation produit un résultat observable. • l’acteur principal est à l’initiative des échanges nécessaires pour réaliser le cas d’utilisation (C’est lui qui déclenche le cas d’utilisation). • Les acteurs secondaires sont souvent sollicités pour des informations complémentaires ; ils peuvent uniquement consulter ou informer le complémentaires ; ils peuvent uniquement consulter ou informer le système lors de l’exécution du cas d’utilisation. • dans la mesure du possible, disposez les acteurs principaux à gauche des cas d’utilisation et les acteurs secondaires à droite. Cas d’utilisation (CU) • Un cas d’utilisation (use case) est une manière spécifique d’utiliser le système. • Il permet de décrire ce que le futur système devra faire, sans spécifier comment il le fera. • généralement modélisés sous forme d’ellipse • Le nom peut figurer à l’intérieur de l’ellipse ou au-dessous • Le nom peut figurer à l’intérieur de l’ellipse ou au-dessous • peuvent éventuellement être représentés par un rectangle doté d’un pictogramme d’ellipse Recenser les cas d’utilisation • Il n’y a pas une manière mécanique et totalement objective de repérer les cas d’utilisation • Il faut se placer du point de vue de chaque acteur et déterminer : – comment il se sert du système, dans quels cas il l’utilise, – dans quels cas il l’utilise, – à quelles fonctionnalités il doit avoir accès. • Pour chaque acteur, il convient de : – Rechercher les différentes intentions avec lesquelles il utilise le système – Déterminer dans le cahier des charges les services fonctionnels attendus du système Recenser les cas d’utilisation • Il faut éviter les redondances et limiter le nombre de cas en se situant au bon niveau d’abstraction (par exemple, ne pas réduire un cas à une action). • Il ne faut pas faire apparaître les détails des cas d’utilisation, mais il faut rester au niveau des d’utilisation, mais il faut rester au niveau des grandes fonctions du système. • Il ne doit pas y avoir de notion temporelle dans un diagramme de cas d’utilisation (sera pris en compte dans le diagramme de séquence par exemple). Scénario • Un scénario représente une séquence d’interactions entre le système et ses acteurs • Il décrit une exécution particulière d’un cas d’utilisation du début à la fin • Un cas d’utilisation contient en général : • Un cas d’utilisation contient en général : – un scénario nominal et – plusieurs scénarios alternatifs (qui se terminent de façon normale) ou d’erreur (qui se terminent en échec). Documentation d’un cas d’utilisation • Fiche de description textuelle d’un CU – pas normalisé par UML, mais fortement recommandé – champs de description (nom, acteur principal, – champs de description (nom, acteur principal, préconditions, etc.) – lisible et informel Documentation d’un cas d’utilisation Documentation d’un cas d’utilisation - Exemple Documentation d’un cas d’utilisation - Exemple Documentation d’un cas d’utilisation - Exemple Relation acteur-cas d’utilisation • Une ligne entre un acteur et un cas d’utilisation signifie qu’une communication est établie. Elle est modélisée sous forme d’association en UML. • Le système observé (subject) est modélisé dans le diagramme de cas d’utilisation sous forme de grand rectangle comprenant de cas d’utilisation sous forme de grand rectangle comprenant tous les cas d’utilisation. Relation acteur-acteur • Une seule relation possible : la généralisation/spécialisation Relation cas d’utilisation-cas d’utilisation • généralisation/spécialisation : principe d’héritage entre CU • l’inclusion («include») : la réalisation d’un CU nécessite la réalisation d’un autre CU nécessite la réalisation d’un autre CU • l’extension («extend») : le comportement d’un CU peut être complété par un autre CU (avec condition éventuelle) Relation d’inclusion • La relation include (include relationship) permet à la fonctionnalité commune de plusieurs cas d’utilisation d’être décrite par un cas d’utilisation (Ex. s’authentifier). • La relation include évite la description multiple du même comportement. comportement. Relation d’inclusion • Quand un cas est trop complexe (faisant intervenir un trop grand nombre d’actions), on peut procéder à sa décomposition en cas plus simples. simples. Relation d’extension • On utilise principalement cette relation pour séparer le comportement optionnel (les variantes) du comportement obligatoire. • Le cas d’utilisation A est complété par le cas d’utilisation B. • Le cas d’utilisation A décrit la fonctionnalité de base, le cas d’utilisation B spécifie les extensions. • Le cas d’utilisation A peut être exécuté seul ou avec les extensions. • Le cas d’utilisation A peut être exécuté seul ou avec les extensions. Relation de généralisation Relation cas d’utilisation-cas d’utilisation - Exemple Relation entre éléments de base (acteur, CU) • Attention ! – Les communications internes (entre cas d’utilisations) ne sont pas modélisées – Les communications externes (entre acteurs) ne – Les communications externes (entre acteurs) ne sont pas modélisées. Étude d’un guichet automatique de banque (GAB) Étape 1 - Identification des acteurs du GAB Étape 2 - Identification des cas d’utilisation Étape 3 - Réalisation de diagrammes de cas d’utilisation Acteurs secondaires Acteurs secondaires • Solution : distinguer deux cas d’utilisation pour le retrait d’argent : – Retirer de l’argent – Retirer de l’argent avec une carte de la banque. – Retirer de l’argent avec une carte de la banque. Étape 4 - Description textuelle des cas d’utilisation Pré-Conditions • Préconditions • La caisse du GAB est alimentée (il reste au moins un billet !). • Aucune carte ne se trouve déjà coincée dans • Aucune carte ne se trouve déjà coincée dans le lecteur. • La connexion avec le Système d’autorisation est opérationnelle. Scénario nominal Scénario nominal • 1. Le Porteur de carte introduit sa carte dans le lecteur de cartes du GAB. • 2. Le GAB vérifie que la carte introduite est bien une carte bancaire. • 3. Le GAB demande au Porteur de carte de saisir son code d’identification. • 4. Le Porteur de carte saisit son code d’identification. • 5. Le GAB compare le code d’identification avec celui qui est codé sur la • puce de la carte. • 6. Le GAB demande une autorisation au Système d’autorisation. • 7. Le Système d’autorisation donne son accord et indique le solde hebdomadaire. • 8. Le GAB demande au Porteur de carte de saisir le montant désiré du retrait. • 9. Le Porteur de carte saisit le montant désiré du retrait. • 10. Le GAB contrôle le montant demandé par rapport au solde hebdomadaire. • 11. Le GAB demande au Porteur de carte s’il veut un ticket. • 12. Le Porteur de carte demande un ticket. • 13. Le GAB rend sa carte au Porteur de carte. • 14. Le Porteur de carte reprend sa carte. • 15. Le GAB délivre les billets et un ticket. • 16. Le Porteur de carte prend les billets et le ticket. Scénarios alternatifs ou d’erreur Scénarios alternatifs ou d’erreur Scénarios alternatifs ou d’erreur Post conditions • Postconditions • La uploads/Finance/ cas-d-x27-utilisation.pdf