Modélisation Des Besoins avec UML
Transcription
Modélisation Des Besoins avec UML
13/02/2013 Modélisation Des Besoins avec UML (basé sur Enterprise Java with UML) 1 13/02/2013 Buts Définir les fonctionnalités du système du point de vue des utilisateurs Délimiter le système - ce qui est extérieur et qui communique avec le système - ce qui est interne au système Donner une description cohérente de toutes les vues que l’on peut avoir du système PG / UML - Modélisation Des Besoins / v 1.2 Page 2 2 13/02/2013 Processus • Interviewer/écouter les clients – Experts du domaine – Utilisateurs finals => Notes de meeting • • • • Trouver les Acteurs Trouver les Cas d’Utilisation (CU) Spécifier/détailler chaque CU Faire valider par le client PG / UML - Modélisation Des Besoins / v 1.2 Page 3 3 13/02/2013 Interview du client YAPS Premier Meeting avec le client Dév : Yet Another Pet Shop, quel nom étrange? Client : La société YAPS vend des animaux de compagnie. Dév : Vous voudriez informatiser la gestion de vos clients? Client : Oui, prioritairement. Dév : Qui va utiliser l’application? Client : Bill, notre employé qui assure la relation clientèle. Dév. : Comment fait-il pour le moment? Client : Il gère des fiches cartonnées Dév. : D’autres besoins? … PG / UML - Modélisation Des Besoins / v 1.2 Page 4 4 13/02/2013 Concepts : Acteur Entité externe au système qui interagit avec lui. • Peut-être un humain, un dispositif physique, un sous-système ... <<Actor>> <<Actor>> Pilote Logiciel de comptabilité Client PG / UML - Modélisation Des Besoins / v 1.2 Page 5 5 13/02/2013 Concepts : Acteur • L’acteur interagit avec le système. • Un acteur doit être identifié en fonction de son rôle. Système Informatique Employé Franchisé PG / UML - Modélisation Des Besoins / v 1.2 Administrateur Internaute Page 6 6 13/02/2013 Concepts : Diagramme de Use Case Cas d’utilisation Acteur Représente des Acteurs reliés par des relations à des cas d’utilisation. PG / UML - Modélisation Des Besoins / v 1.2 Page 7 7 13/02/2013 Diagramme de Use Case - Exemple Source http://uml.free.fr/ PG / UML - Modélisation Des Besoins / v 1.2 Page 8 8 13/02/2013 Processus : trouver les Acteurs • Les acteurs sont des noms découverts en lisant les interviews Exemples : – – – – employé, service clientèle, internaute, client, … • Synthétiser/Regrouper PG / UML - Modélisation Des Besoins / v 1.2 Page 9 9 13/02/2013 Processus : trouver les CU • Les CU sont des actions découvertes en lisant les interviews Exemples : – gérer les clients – gérer le catalogue –… • Synthétiser/Regrouper PG / UML - Modélisation Des Besoins / v 1.2 Page 10 10 13/02/2013 YAPS : 1-er Diagramme de CU PG / UML - Modélisation Des Besoins / v 1.2 Page 11 11 13/02/2013 Concepts : include et extend Les CU peuvent être structurés par deux relations : • Inclusion : stéréotype « include ». Le CU inclus fait partie du déroulement habituel du CU de base. • Extension : stéréotype « extend ». Le CU de base peut quelque fois faire appel à un autre CU qui ne fait pas partie du déroulement habituel du CU de base. PG / UML - Modélisation Des Besoins / v 1.2 Page 12 12 13/02/2013 Concepts : include et extend <<include>> Identifier client Passer une commande Le client doit s’être préalablement identifié avant de passer une commande Passer une commande <<extend>> Créer un compte Pour passer une commande, le client doit avoir un compte PG / UML - Modélisation Des Besoins / v 1.2 Page 13 13 13/02/2013 YAPS : Diagramme de CU PG / UML - Modélisation Des Besoins / v 1.2 Page 14 14 13/02/2013 Description textuelle de CU Un CU ne se limite pas à un diagramme Il est détaillé par une description textuelle Non normalisée mais comportant obligatoirement • les acteurs impliqués • le scénario nominal (80%) • les scénarios alternatifs PG / UML - Modélisation Des Besoins / v 1.2 Page 15 15 13/02/2013 CU et scénario nominal Scénario nominal = séquence (numérotée) d’étapes Types d’étapes : • interaction entre l’acteur et le système (expliciter l’échange d’information) • opération du système • vérification par un intervenant PG / UML - Modélisation Des Besoins / v 1.2 Page 16 16 13/02/2013 CU et scénarios alternatifs Plusieurs scénarios alternatifs possibles Un scénario alternatif • utilise le numéro de l’étape concernée du scénario nominal • précise la condition d’exécution • liste la suite des étapes alternatives PG / UML - Modélisation Des Besoins / v 1.2 Page 17 17 13/02/2013 CU - scénario générique Scénario nominal 1. l’utilisateur saisie des données 2. le système vérifie les données 3. le système calcule des résultats 4. le système affiche les résultats Scénarios alternatifs 2a saisie erronée 2a1 : le système renvoie un message d’erreur PG / UML - Modélisation Des Besoins / v 1.2 Page 18 18 13/02/2013 CU – exemple 1/3 Retrait à un Distributeur Automatique Bancaire • Nom : Retirer de l’argent à un DAB • Résumé : … • Acteur : Client • Intervenants : Banque, Client • Pré-condition : compte du client approvisionné • Postcondition : compte débité, argent retiré PG / UML - Modélisation Des Besoins / v 1.2 Page 19 19 13/02/2013 CU – exemple 2/3 Scénario nominal 1. le Client introduit sa carte dans le lecteur 2. le DAB décrypte l’identifiant de la carte 3. le Client saisit son code secret 4. le DAB valide le code saisi 5. le Client sélectionne un montant 6. le DAB soumet la demande à la banque 7. le DAB délivre la carte, l’argent et un reçu PG / UML - Modélisation Des Besoins / v 1.2 Page 20 20 13/02/2013 CU – exemple 3/3 Scénarios alternatifs 2a carte volée 2a1 : le DAB confisque la carte 4a code saisi invalide 4a1 : le DAB demande de ressaisir le code 7a solde insuffisant 7a1 : le DAB rend la carte en précisant que la somme demandée est trop élevée PG / UML - Modélisation Des Besoins / v 1.2 Page 21 21 13/02/2013 Description textuelle de CU Arrington • • • • • Nom Résumé Acteurs Pré-conditions Description (= scénario nominal) • Exceptions (= scénario alternatifs) • Diagramme d’activités • Questions ouvertes PG / UML - Modélisation Des Besoins / v 1.2 Page 22 22 13/02/2013 Description textuelle CU1 Nom : S’identifier Résumé : permet à un client de s’authentifier Acteurs : Client. Pré-condition : le client doit préalablement exister dans le système Description : 1 le client se connecte au système informatique. 2 le système demande un identifiant et un mot de passe 3 le client fournit son identifiant et son mot de passe. 4 le système affiche un message de bienvenue; le client est connecté au système. Exceptions : 3a le client s’aperçoit qu’il n’est pas connu du système; il a la possibilité de créer un compte 4a les informations fournies sont incorrectes, le système redemande l’identifiant et le mot de passe. Diagramme d’activités : voir figure 3.1 Post-condition : le client est identifié. PG / UML - Modélisation Des Besoins / v 1.2 Page 23 23 13/02/2013 Diagramme d’activités du CU1 PG / UML - Modélisation Des Besoins / v 1.2 Page 24 24 13/02/2013 Description textuelle CU2 Nom : Visualiser le catalogue Résumé : permet de visualiser le catalogue d’animaux Acteurs : Franchisé. Pré-condition : Le franchisé s’est authentifié. Description : 1 Le franchisé sélectionne une catégorie; les produits de la catégorie sélectionnée s’affichent 2 Il sélectionne un produit; les articles du produit sélectionné s’affichent. 3 Il sélectionne un article; les détails de l’article (photo et prix) s’affichent 4 A tout moment il peut afficher la liste des produits d'une catégorie Exceptions : Diagramme d’activités : voir figure 3.2 Post-condition : PG / UML - Modélisation Des Besoins / v 1.2 Page 25 25 13/02/2013 Diagramme d’activités du CU2 PG / UML - Modélisation Des Besoins / v 1.2 Page 26 26