Module Analyse et Conception avec UML (Unified Modelling Language)

Transcription

1 Cas d utilisation : présentation Module Analyse et Conception avec UML (Unified Modelling Language) Les cas d'utilisation (Use Case) les «use case» d Ivar JACOBSON Décrire une utilisation du système (ensemble de séquences d actions) par un acteur particulier Acteurs externes Un acteur = un rôle Modélise l un des aspects (comportement / service) du système par rapport à cet acteur doit renseigner sur le rôle particulier de l acteur (VA) UML VDe 2 Cas d utilisation : présentation Cas d utilisation (2) description du QUOI Qu'est-ce qui se passe dans un cas précis Utilisation d'un téléviseur pour regarder les chaînes publiques Pour regarder le câble Pour enregistrer avec son magnéto-cassette Pour visionner avec son caméscope Pour faire de l'internet Comme miroir! pas du COMMENT, dans le cadre du «métier» de l acteur pas de manipulation d IHM, ni de gestion des erreurs matérielles dans les Use Case l ens. des cas d utilisation doit décrire exhaustivement les exigences attendues du système Expression des besoins fonctionnels chaque use case = une fonction Métier du syst. selon point de vue d un des acteurs Représentation : acteurs et patates! Chaque «patate» est un «cas d utilisation» du système UML VDe 3 UML VDe 4

2 Exemple : diagnostic médical Exemple : agence de banque RDV Prospecter secrétaire facturation Gérer les clients Analyse des symptômes patient guichetier Ouvrir un compte responsable clientèle << include >> Consulter comptes médecin diagnostic << include >> Planifier des rendez-vous traitement Gestion de commande client UML VDe 5 UML VDe 6 Cas d utilisation : construction Construction des cas On part des acteurs identifiés dans l étude préliminaire chercher les intentions (métier) avec lesquelles il utilise le système déterminer dans le CdesCh les services fonctionnels attendus On utilise les échanges de messages identifiés dans le contexte dynamique Distinguer l acteur principal des acteurs secondaires celui pour lequel le Cas produit la plus-value métier (souvent : déclencheur) UML VDe 7 UML VDe 8

3 Validation Etude de cas SIVEX Pour chaque cas d utilisation candidat : vérifier qu il fournit une VA notable à l acteur contrôler qu un événement externe en déclenche l exécution Ne pas descendre trop bas : un UC n est ni une transaction, ni une fonction du système! Ex.: saisie des commandes, elles peuvent l être via le web, via les feuilles issues du service commercial, ou manuellement après contacts téléphoniques. Ca conduit donc à 3 séquences d actions différentes mais pour un seul cas d utilisation : la saisie des commandes. On part du diagramme de contexte dynamique Chercher l «intention fonctionnelle» de chaque acteur dans son intéraction avec le système S inspirer des messages Regrouper les intentions en unités cohérentes UML VDe 9 UML VDe 10 Sivex (suite) Ex. Planification missions Avant les diagrammes de cas d utilisation, on liste les CU candidats avec nom, acteurs, et messages émis et reçus par les acteurs Donner une 1ère description succincte de chaque CU, qui mentionne brièvement l intention et les actions correspondantes Acteur principal = répartiteur Intentions planifier les missions d une agence, permettant la réalisation des commandes en cours Actions : créer une nouvelle mission : regrouper des commandes, affecter des ressources disponibles, établir un parcours, évaluer les durées, le volume nécessaire pour la camionette, etc modifier ou annuler une mission existante UML VDe 11 UML VDe 12

4 Ex. Suivi de mission Use Case : Gestion des missions Acteur principal = chauffeur Intentions Informer en temps réel de l état d avancement de la mission en cours Actions - Transmettre chaque arrêt et départ d étape Répart it eur secondaire Suivi de mission Planification des missions secondaire Chauffeur - Signaler les événements de mission acquittement client, panne, retard, absence client... Planification des missions d'enlèvement Planification des missions de livraison Planification des missions de traction UML VDe 13 UML VDe 14 Formalisme des cas d utilisation Acteurs généralisés Différents types de relations Relation entre un acteur et un cas trait simple : déclenche le cas (flèche vers acteur : acteur récepteur (secondaire)) Utilisateur Authentif ication Relation d héritage entre cas Noter : le rôle secondaire tenu par l acteur principal mentionné sur le graphique Client Réceptionniste Comptable Répartiteur Chauf f eur Opérateur de Quai Responsable Logistique Administrateur Système UML VDe 15 UML VDe 16

5 Fiche Cas d utilisation «Planification des missions» (1/5) On décrit les cas d utilisation sous forme textuelle d abord, et éventuellement avec des diagrammes Structure de description des cas d utilisation qui permet de mieux les exploiter par la suite : sommaire d identification (titre, but, résumé, acteurs, dates, version, responsable) description des enchaînements (nominaux, exceptionnels, pré-post conditions) éventt : besoins d IHM éventt : contraintes non-fonctionnelles (fréquence, volumétrie, disponibilité, confidencialité, performances ) BUT : planification des missions d enlèvement, de transport ou de livraison, d une agence à partir du plan de transport, des commandes à assurer quotidiennement et des ressources disponibles RESUME : création d une nouvelle mission à partir des cdes confirmées, modification et annulation d une mission existante. ACTEURS : répartiteur (ppal), chauffeur (sec.) PRE-CONDITIONS : - le répartiteur est authentifié - les commandes à planifer sont confirmées UML VDe 17 UML VDe 18 Enchaînements Enchaînement nominal = fonctionnement normal ex.: dans le processus d appel téléphonique, fonctionnement nominal = Décrocher combiné, entendre sonnerie attente, composer numéro, attendre sonnerie appel, communiquer, raccrocher Enchaînement exceptionnel = fonctionnement anormal, traitement des événements exceptionnels ex.: dans le processus d appel téléphonique, fonctionnement exceptionnel = Décrocher combiné, pas de sonnerie d attente, vérifier branchement ligne, (suite) UML VDe 19 «Planification des missions» (2/5) Enchaînements identifiés : créer une mission en attente affecter des commandes à une mission affecter les ressources modifier une mission en attente (désaffecter une commande, modification des chauffeurs ou véhicule, modification des étapes ) valider une mission en attente modifier une mission validée annuler une mission (en attente ou validée) éditer les bordereaux de mission UML VDe 20

6 «Planification des missions» (3/5) «Planification des missions» (4/5) Exceptions identifiées : Pour une mission donnée, dépassement de tonnage véhicule Chauffeur sélectionné non qualifié pour conduire le véhicule choisi pour la mission Tonnage de réserve entammé (chaque agence doit se réserver un certain tonnage pour pouvoir répondre à des commandes prioritaires ou de dépannage) Estimation de temps incomplète pour une étape donnée donc pour la mission comportant cette étape Post-conditions Tout ce qui est connu à l issue du cas Besoins d IHM Pour lister les commandes de l agence, le répartiteur doit pouvoir répertorier les commandes de l agence par type, poids, site desservi, affectée/non affectée, tarification urgent/non urgent Les commandes non affectées doivent être de couleur différente UML VDe 21 UML VDe 22 «Planification des missions» (5/5) Contraintes non fonctionnelles : temps de réponse Interface répartiteur : moins de 2 secondes Autres contraintes : Concurrence : les validations de mission doivent être notifiées aux lecteurs potentiels par un message d avertissement en TR Disponibilité : le système doit être accessible au répartiteurs 6 jours sur 7, aux heures d ouverture des agences Etc cf slide du cas complet UML VDe 23 Autres relations entre cas Relation d inclusion «include» : La réalisation d un cas de base passe obligatoirement par celle d un cas spécifique inclus (objectif : factorisation) Ex. : procédure d authentification Relation d extension «extend» : Cas de base incorpore une extension, à un point d extension prévu (obj.: représenter un comportement optionnel) Ex. : la prise de commande peut conduire à la création d un nouveau client UML VDe 24

7 Relations «includes, extends» Exemples Cas de base <<include>> Cas inclus Cas de base <<extend>> extension Quelles relations utiliser? Entre un cas «modification document» et un cas «vérification droit d accès» include Entre un cas «développement pages d un site web» et un cas «définition charte extend graphique» Entre un cas «saisie commande» et un cas «vérification stock» include UML VDe 25 UML VDe 26 Use Case : Gestion des Cdes Use Case : Gestion comptabilité Gestion des Clients <<extend>> (nouveau client) Gestion de Commande Point d'extension : nouveau client secondaire Comptable Facturation Progiciel de Comptabilité Réceptionniste Consultation d'en-cours Client Suivi des Règlements UML VDe 27 UML VDe 28

8 Structuration des cas d utilisation Techniques de regroupement Structuration par package : regroupement fonctionnel de haut niveau Package en UML = concept commun de regroupement d éléments d un modèle de diagrammes de ces éléments d autres packages Contrainte : ensemble cohérent au niveau sémantique (expertise métier) Par domaine d expertise métier regroupement le plus intuitif et efficace permet de faciliter la spécilisation des analystes organiser facilement la répartition des experts Par acteur facile si chaque cas est relié à UN seul acteur Par lot de livraison client dans le cas d un développement incrémental, c est parfois un critère utilisé UML VDe 29 UML VDe 30 Regroupement en packages : SIVEX Quel format pour les Use Cases Logistique Gestion clientèle Gestion missions Services support Gestion comptabilité Traitement colis - Par domaine d expertise métier - Ensembles d acteurs fortement liés Il existe différents modèles de cas d utilisation détaillé Le plus répandu est celui de (correspond en gros à celui présenté pour SIVEX) Description : Titre, acteur principal, parties prenantes et intérêts, pré et post conditions, scénario principal (happy path, succès) sans condition ni branchement, extensions (scénarios d exception); spécifications particulières (hors contraintes fonctionnelles : interface, langue, temps de réponse); technologies envisagées ou évolutions à MT (ex. actuellement chèque accepté, en Juin 2003, plus de chèque), questions à se poser. global UML VDe 31 UML VDe 32

9 Exercice : quelle validité des UC Use Cases : réponse Soit un système de vente en ligne Lesquels de ces cas d utilisation seraient valides (utiles)? Supprimer un article Négocier un contrat avec un fournisseur Traiter les retours Se connecter Imprimer un document Les 3 cas du milieu sont utiles à différents niveaux d abstraction, en fonction des acteurs et des objectifs La question plutôt à se poser est : À quel niveau faut-il exprimer un cas d utilisation de façon à se qu il soit utile pour l analyse des besoins? Il faut pour cela identifier les Processus métier élémentaires (PME) Terme issu du BPR «tâche utilisateur» en ergonomie UML VDe 33 UML VDe 34 Quels cas d utilisation créer Exemple sur l exercice Ceux pour lesquels il y a valeur ajoutée observable et mesurable Qui laissent le système dans un état stable et cohérent Définir les acteurs externes et internes et se concentrer sur leurs intentions Notamment ne pas raisonner en interface utilisateur «se connecter» : plus value? Non, but secondaire «se connecter pour commander» : OK ( traiter vente) «se connecter pour enregistrer les ventes du mois» : OK ( enrichir statistiques) «se connecter pour mettre à jour le catalogue» : OK ( gérer articles) «Supprimer un article» : secondaire aussi! Gestion Article plus appropriée «Imprimer un document» : inutile ici activité technique, pas un besoin Métier (D après l expérience : l étape d authentification est rarement processus métier élémentaire!) UML VDe 35 UML VDe 36

10 Risques associés aux Cas Autres risques Ne pas réinventer la décomposition fonctionnelle! On fait de l analyse ORIENTEE OBJET!! Ne pas aller trop loin dans le détail, on en est à la capture des besoins fonctionnels. Limiter à 10 le nombre de («grands») CU, rester synthétique Les Cas d utilisation ne sont pas une fin en soi, leur objectif est de : dialoguer avec le client, le rassurer sur ce qu on a compris analyser les besoins métier, démarrer l analyse en identifiant les classes candidates. UML VDe 37 Ne pas mélanger l IHM et le fonctionnel on décrit le métier des acteurs, indépendamment des choix d interface qui pourront évoluer ex.: préférer «lors d une 1ère commande, le réceptionniste enregistre les caractéristiques du nouveau client dans le système»à: «le réceptionniste saisit le nom du client en 8 car. max, en majuscules, appuie sur ENTER, puis saisit le prénom en minuscules» ou à «le réceptionniste enregistre par un syst. de reconnaissance vocale les nom, prénom, adresse et code postal du client» UML VDe 38 Exemples Exemples Cas d'utilisation décrivant le contexte dans lequel vous allez apprendre à concevoir avec UML à l'iut impétrant assister aux cours lire ouvrages rechercher informations Présenter le formalisme UML Proposer des exercices Evaluer impétrants enseignant UML VDe 39 Cas d'utilisation de développement de logiciel Chef de projet (maîtrise d'œuvre) architecte logiciel utilisateur Piloter le processus dvpt Objet Concevoir une architecture technique Organiser le développement logiciel et les tests Tester Définir les besoins développeur Maître d'ouvrage architecte technique UML VDe 40

11 Exemple : site vente en ligne Site vente en ligne Client : consulte, achète des produits, demande un renseignement, souhaite obtenir un RV personnalisé, etc. Administrateur : ouvre comptes, etc. Responsable pdt : MàJ le catalogue, veille Technicien : répond aux questions techniques sur les produits admistrateur client authentification include extend Maintenance site Consultation Catalogue MàJ Catalogue Commandes extend Clients Renseignements techniques Veille technologique Resp.Produit technicien UML VDe 41 UML VDe 42