Remerciez-le!

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

Véronique DESLANDRES UML, Master Miage Parcours SIGS Modélisation Conception Ob

Véronique DESLANDRES UML, Master Miage Parcours SIGS Modélisation Conception Objet des S.I. Cours 5 – UML, Diagramme des Cas d’Utilisation (DCU) Plan de ce cours • Diagrammes de cas d'utilisation • Quelques exercices – s45 • Regroupement en packages 2 Diagrammes de cas d'utilisation, DCU Use Case 3 4 Cas d’utilisation : présentation • Les « use case » d’Ivar JACOBSON • Décrire les différentes utilisations du système par des acteurs particuliers UML V. Deslandres – IUT de LYON VISION UTILISATEUR Un Cas d’utilisation, c’est : • Une fonctionnalité complète du système • Exemple : – Dans le système Guichet automatique d’une banque (GAB), « retirer de l’argent » est un CU. – C’est une fonctionnalité complète du système qui va de l’insertion de la carte par le client, jusqu’à la récupération de la carte par le client. 5 UML V. Deslandres – IUT de LYON Use Case / scénarios • Un use case = un ensemble de scénarios, détaillant tous les cas possibles • Exemple pour le retrait, un scn d’exception : – Dans le GAB, un client tente de retirer de l’argent mais son compte est insuffisamment alimenté : refus • Un scénario = une instance d’un CU, comme un Objet est une instance de classe 6 UML V. Deslandres – IUT de LYON 7 Cas d’utilisation : les acteurs UML V. Deslandres – IUT de LYON l Un acteur = une abstraction d’un acteur l Acteur concret = le client Mme Martin l On parle de rôle : un même acteur concret peut jouer différents rôles dans l’utilisation du système l Ex.: dans le GAB, l’agent de maintenance du GAB peut aussi retirer de l’argent acteurs Modélisation d’un garage Monsieur Fiat est là un jour pour vendre ses voitures, un autre jour pour faire la vidange d’un client, une autre fois pour faire les comptes du garage. Quels sont les acteurs et les cas d’utilisation ? Exercice : quels sont les acteurs ? Types d’acteurs • Un acteur peut être une personne ou un système logiciel ou un serveur externe – Ex. GAB sollicite le serveur du consortium pour savoir quelle banque est associée à la carte de retrait • Acteur actif / passif 9 Flèche vers l’acteur passif Acteurs : externes • Le client est client de la banque 10 • Mais il est externe au système du GAB Exercice : acteur interne ou externe ? • Pour un système de pilotage d’un ascenseur : appeler l’ascenseur, déplacer la cabine, définir le prochain arrêt, ouvrir les portes, etc. – Usager – Portes de l’ascenseur – Moteur des portes – Agent de maintenance – Moteur de cabine 11 Souvent acteur « interne » = composant du système Acteur / événement • Souvent un acteur (externe) génère un « événement » qui se traduit par une action du système (réponse) – ex.: Appel de l’ascenseur = événement, un bouton d’étage transmet un signal au système de pilotage de l’ascenseur – Le système enclenche le moteur de dépla-cement de la cabine (action) 12 C’est la dynamique du système, qui sera modélisée par un diagramme d’activité ou de séquence 13 Use Case : Gestion comptabilité F a ctu ra tio n P rog icie l d e C o m p ta bilité S u iv i d e s R è g le m e n ts C o m p tab le UML V. Deslandres – IUT de LYON Observez bien cet acteur : c’est un système externe 14 Cas d’utilisation : décrire le QUOI UML V. Deslandres – IUT de LYON l Diagramme de description du QUOI FAIRE l Quelles sont les fonctionnalités : on décrit les cas précis d'utilisation de l'application Ex.: Utilisations d'un téléviseur l Pour regarder la TV l Comme 2ème écran de son PC l Pour visionner avec son caméscope l Pour aller sur internet l Mais pas du COMMENT l Ni manipulation d’IHM, ni gestion des erreurs matérielles Relations entre cas d’utilisation : « include, extend » X Cas de base Y Cas inclus <<include>> Y Extension <<extend>> L’extension Y est un extension possible du cas de base X Le cas de base X passe systématiquement par le cas Y X Cas de base 15 Quand on est en X, on peut être amené à faire Y (sous certaines conditions) Exemples de Relations « include, extend » Saisie des commandes Saisie articles & quantités <<include>> Saisie des Commandes Gestion Client <<extend>> Le cas « Saisie des Commandes » peut mener à la création d’un Client La saisie d’une commande passe systématiquement par la saisie des articles et quantités. Le cas « Saisie de la commande (article, qté) » ne se fera jamais tout seul, mais depuis la saisie, et d’autres cas éventuellement. S’il n’est pas connu de la société 16 Quand fait-on un include ? • On pourrait en effet le considérer comme faisant partie du CU de base… • On met des CU inclus dans 3 cas : 1. Quand on pense que cela apporte un plus à la compréhension du diagramme 2. Quand le CU inclus est partagé par plusieurs CU – factorisation 3. Quand le CU inclus est aussi un CU pour un acteur – Il peut souhaiter directement utiliser le système via ce cas 17 18 SIVEX : DCU Gestion des Commandes Consultation d'en-cours Client Réceptionniste Gestion de Commande (acteur secondaire) Gestion des Clients <<extend>> Point d'extension : nouveau client UML V. Deslandres – IUT de LYON 19 Exemples Quelles relations utiliser ? UML V. Deslandres – IUT de LYON Modification document Vérification droit d’accès include ? Retirer de l’argent Editer un ticket ? Saisie commande Vérification stock Modification document Vérification droit d’accès ? Retirer de l’argent Editer un ticket extend Saisie commande Vérification stock include Relations : Acteurs / Cas • Initialisation d’un CU, généralisation d’acteurs • Généralisation : seule relation possible entre les acteurs dans un DCU ! 20 21 Héritage entre Acteurs Client Réceptionniste Comptable Répartiteur Chauffeur O pérateur de Q uai Responsable L ogistique Administrateur Système Utilisateur Authentification UML V. Deslandres – IUT de LYON 22 Use Case : généralisation des cas SIVEX - Gestion des missions UML V. Deslandres – IUT de LYON Planification des missions Répartiteur Chauffeur secondaire Suivi de mission secondaire Planification des missions d'enlèvement Planification des missions de livraison Planification des missions de traction 23 Exemple1 : diagnostic médical médecin patient secrétaire Règlement / facturation Élaboration d’un diagnostic Proposition du traitement Analyse des symptômes Gestion des RDV << include >> << include >> UML V. Deslandres – IUT de LYON Application du poste secrétaire Application du poste médecin Un Cas d’utilisation = un menu ou un bouton de l’IHM 24 25 Erreur type : diagnostic médical médecin patient secrétaire Règlement / facturation Élaboration d’un diagnostic Proposition du traitement Analyse des symptômes Gestion des RDV << include >> << include >> UML V. Deslandres – IUT de LYON Demande absence NON On ne modélise que les interactions avec le système Exemple2 : une agence de banque Effectuer opérations sur les comptes Gérer les rendez-vous Gestion de commande responsable clientèle Gérer les clients Ouvrir un compte Prospecter 26 Exemple3: développement de logiciel Chef de projet (maîtrise d'œuvre) Maître d'ouvrage Architecte logiciel Architecte technique Utilisateur Développeur Piloter le processus dvpt Objet Concevoir une architecture technique Organiser le développement logiciel et les tests Définir les besoins Tester Utilisateur 27 28 Exemple 4 : eLearning Internaute Chercher un cours Visualiser les pré requis du cours Télécharger un cours Authentification Serveur de Cours Récupérer les cours ouverts « include » UML V. Deslandres – IUT de LYON Abonné S’abonner « extends » Extension : si l’abonné n’est pas déjà connecté Je réflechis Pourquoi ne voit-on pas le cas « Visualiser le descriptif du cours » (mais les pré-requis) ? Pourquoi voit-on le cas « Chercher un Cours » ? Que représentent les cas inclus pour l’application ? Pourquoi les isole-t-on ? Questions sur l’ex 4 eLearning UML V. Deslandres – IUT de LYON eLearning : corrigé (1) • Le cas « Visualiser le descriptif du cours » n’a aucun effet de bord sur le reste du logiciel – C’est effectivement un besoin exprimé par le client, mais d’une façon générale, on a toujours besoin de voir / consulter les objets manipulés par un logiciel : ces visualisations existeront de toute façon • On ne les mentionne pas, ce sont des cas d’utilisation « triviaux » • On peut les mettre, mais ils surchargent les diagrammes • Par contre la visualisation des pré-requis apporte une vraie plus- value Métier – Il est important pour celui qui souhaite suivre un cours, de connaître les pré requis, donc on le mentionne 30 UML V. Deslandres – IUT de LYON eLearning : corrigé (2) • Le cas « Chercher un Cours » requerra sans doute un filtre – Recherche par critères : nom, matière, mot-clefs • Il correspond à un traitement logiciel qu’il faudra développer • Il répond à un besoin Métier • Les cas inclus représentent une tâche effectuée uploads/Finance/ cours5-uml-dcu-exos-pdf.pdf