Chapitre 2 : Diagrammes de cas d’utilisation I. Introduction UML permet de donn

Chapitre 2 : Diagrammes de cas d’utilisation I. Introduction UML permet de donner une description globale et non détaillée du système / de l’application à modéliser. Cette description a pour objectif de bien cerner le problème à résoudre, et d’identifier les fonctionnalités clés. Cette description est le point de départ essentiel de tout développement orienté objet, elle permet d’analyser les besoins des futurs utilisateurs. Cette description se base dans UML sur les Diagrammes de Cas d’Utilisation D.C.U. Les Cas d’Utilisation (C.U) ou User Case (U.C) ont, initialement été définis pas Ivar Jacobson en 1992 dans sa méthode OOSE. Ils permettent de décrire le comportement du système étudié selon le point de vue de l’utilisateur, en phase d’analyse pour la compréhension des besoins. En effet un DCU est recentre l’expression des besoins sur l’utilisateur, en partant du principe qu’un système est construit, avant tout, pour ses utilisateurs. L’élaboration du DCU passe par une phase de spécification des besoins qui va identifier et documenter ce qui est demandé en terme de : - Objectifs du projet - Fonctions métier Cela pour arriver à définir comment les utilisateurs veulent interagir avec le système et ce qui doit être fait pour obtenir le résultats attendus. Objectif d’un CU : - Capturer le comportement attendu du système - Spécifier ce que le système fait, mais pas comment il le fait - Servir de moyen d’échange entre les différents intervenants (utilisateurs, concepteurs, clients, experts) - Servir de référence pour valider l’architecture logiciel qui sera développée. II. Concepts de base II.1. Cas d’utilisation : Un CU est une manière spécifique d’utiliser un système. Il décrit la séquence d’évènement dans laquelle, un utilisateur va utiliser le système pour accomplir une tâche. Un CU peut aussi être défini comme les fonctions du système futur visibles par les utilisateurs. Exemple : Cas d’utilisation du téléphone portable : répondre à un appel, envoyer un sms Cas d’utilisation d’un site de messagerie : rédiger un mail, consulter les mail reçus Au fait l’identification des CU passe d’abord par l’identification des acteurs qui vont modéliser les utilisateurs du système. En UML un CU est représenté par un oval plat à l’interieur duquel est inscrit le nom du CU. Le nom d’un CU est généralement composé d’un verbe à l’infinitif avec un complément. 1 II.2. Acteur Entité externe qui interagit avec le système à travers un cas d’utilisation. L’acteur représente un rôle joué vis-à-vis du système. Un acteur peut être instancié par une ou plusieurs personnes physiques, comme il peut l'être par un dispositif matériel ou un logiciel d'un autre système. Un acteur peut intervenir dans plusieurs CU. Un cas d’utlisation est alors défini par un ensemble d’actions réalisées par le système en réponse à la stimulation d’un acteur. Exemple d’acteurs : Client pour un Distributeur Automatique de Billet DAB Personne pour un téléphone portable Un internaute pour un site ... UML représente l’acteur par le stickman ainsi représenté : Nom-acteur II.3. Interaction / Association : Elle lie un acteur à un CU est montre l’acteur ou les acteurs qui réalisent le CU. Un acteur peut interagir avec le système via un nombre de CU Un CU peut avoir plus d’un acteur. UML représente l’interaction par un trait plein, liant le CU à ou aux acteurs qui le réalisent. Exemple : Tout système peut être représenté par un nombre de CU et d’acteurs 2 Le DCU regroupe les concepts :  Acteur  CU  Relation entre les CUs Acteur principal / acteur secondaire : L’acteur principal est l’utilisateur qui interagit directement avec le système via un CU. L’acteur secondaire est soit :  L’acteur qui déclenche l’utilisation sans manipuler le système (ex : le client qui désire acheter dans un système de caisse éléctronique, l’étudiant qui se présente pour s’inscrire)  L’acteur qui interagit secondairement avec le CU pour le réaliser. Il n’est pas le déclencheur du CU (ex : le système central des CCP Alger pour un distributeur de billet d’Algérie poste) CU principal / Secondaire Un CU principal est celui qui répond à un objectif clé du système. Il est, à lui seul, une finalité dans l’utilisation du système. Un CU secondaire est un CU complémentaire ou supplémentaire dans le fonctionnement du système. Exemple : « Gérer contact » et « Gérer message » sont des CUs principaux « atteindre page » dans Microsoft Word et « attribuer photo au contact » dans un téléphone protable sont des CUs secondaires II.4. Structuration d’un CU : La structuration permet de mettre en évidence les différentes articulations qui réalisent un CU. Elle permet aussi d’organiser les CUs collectés et de donner une meilleure représentation du futur système. La structuration est une vision plus détaillée du CU, issue d’une meilleure compréhension des besoins et des fonctionnalités requises dans le futur système. On structure un CU pour : - Identifier les comportements récurrents et partagés dans les UCs, et les mettre en facteur. - Identifier et mettre en évidence les comportements optionnels dans un ou pluiseurs CUs. - Généraliser un ensemble de CUs par un objectif ou une caractéristique commune. - Spécialiser un CU. UML offre 03 relations qui peuvent être utilisées pour structurer un CU : II.4.1. La relation d’inclusion : Permet de factoriser les interactions communes et récurrentes dans plusieurs CUs. L’interaction ainsi identifiée est isolée, nommée et reliée au CUs d’origine par une relation d’inclusion. Un cas d’utilisation A inclut ou utilise un cas d’utilisation B signifie que lors de l’execution: - Une instance de A engendre une instance de B et l’exécute. - A dépend du déroulement et du résultat de B - B n’existe pas seul et A n’existe pas sans B UML représente l’inclusion par une flèche en pointillés qui pointe l’UC inclut. 3 Exemple :  Lorsque le CU « Retirer argent » s’execute, il engendre une instance du CU « Authentification » et l’exécute  « Retirer argent » dépend du résultat de « authentification »  « Authentification » n’existe pas seul et « Retirer argent » n’existe pas sans « authentification » II.4.2. La relation d’extension : Permet d’étendre les interactions d’un UC par des interactions optionnelles. Ces dernières sont regroupées dans un CU qui peut venir compléter l’exécution du CU de base à certains points appelés points d’insertion. La relation d’extension permet de séparer le comportemant optionnel du comportment obligatoire d’un CU. Un CU B étend un CU A signifie que :  Une instance de A peut engendre une instance de B et l’exécuter dans certaines cas. B sait alors où s’insérer dans A.  B n’existe pas seul et A existe sans B UML représente l’extension par une flèche en pointillées qui pointe le CU optionnel. Exemple : Le CU « propriété impression » étend le CU « imprimer » dans Microsoft Word. Le CU « imprimer » peut engendrer une instance de « propriété impression » et l’executer Le CU « imprimer » peut exister seul, ce qui n’est pas le cas de « propriété impression ». II.4.3. Généralisation / Spécialisation : C’est le meilleur moyen offert par UML pour organiser les CUs identifiés, c’est inspiré de l’héritage du paradigme O.O. Lorsque un ensemble de CUs sont des formes différentes d’un même objectif métier, il est préférable de les généraliser (ex : « ajouter contact », « modifier contact », « supprimer contact » ont le même objectif métier : gérer les contacts). Lorsqu’un CU peut avoir plusieures formes d’execution pour le même objectif métier, il est préférable de le spécialiser en un nombre de CUs (ex : « recruter » est un UC qui se déroulera différemment selon la personne recrutée : enseignant ou personnel administratif) UML représente de la même manière la généralisation / spécialisation par une flèche pleine qui pointe le CU générique. 4 Exemple : III. Description de CU : Après identification de tous les CUs, il est important d’élaborer pour chacun, une fiche descriptive qui recapitule les connaissances acquises et en ajoute d’autres. Définition1 : La description d’un CU est un document narratif qui décrit la séquence d’interactions dans laquelle un acteur utilise le système pour arriver à un résultat qui satisfait l’objectif initial du CU. Définition 2 : Un scénario est une instance d’exécution d’un CU. Un CU est une abstraction de plusieurs chemins d’exécution possibles d’une utilisation du système. Mais, la Description d’un CU ne reviens pas à décrire tous ses chemins d’exécution possibles. Il suffit de donner le scénario nominal. Définition 3 : Un scénario nominal est le scénario le plus représentatif qui mènent à une terminaison avec succés de l’UC. La fiche descriptive d’un CU est constituée de 03 éléments :  Une entête comportant : nom du CU, Acteurs (principal et éventuellement secondaire), But, Type du CU (principal / Secondaire)  Le scénario nomimal  Une description des alternatives de déroulement Fiche descriptive d’un CU : Nom du CU : .................... Acteur principal :.......................................... ; Acteur secondaire :.......................... But :....................................................................................................................................................... ................................................................................................................................................................ ............................................................................................................................................................... Type : .............................................................. Scénario / Déroulement : <Action en uploads/Finance/ chapitre-2-dcu.pdf

  • 22
  • 0
  • 0
Afficher les détails des licences
Licence et utilisation
Gratuit pour un usage personnel Attribution requise
Partager
  • Détails
  • Publié le Nov 12, 2021
  • Catégorie Business / Finance
  • Langue French
  • Taille du fichier 0.1176MB