Expo diagramme cas d'utilisation

7 675 vues

Publié le

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Expo diagramme cas d'utilisation

  1. 1. Modélisation des SI avec UML -DIAGRAMME DES CAS D’UTILISATION- PRÉPARÉ PAR: AMINE SENNOUNI ENCADRÉ PAR: PR.BOUBKER SBIHI
  2. 2. Plan 2 Introduction: UML Définitions Diagramme de cas Acteur Cas dutilisation Associations et cas dutilisation Exercice d’application Conclusion
  3. 3. Introduction: UML 3 UML permet de construire plusieurs modèles d’un système : certains montrent le système du point de vue des utilisateurs, d’autres montrent sa structure interne, d’autres encore en donnent une vision globale ou détaillée. Les modèles se complètent et peuvent être assemblés. Ils sont élaborés tout au long du cycle de vie du développement d’un système (depuis le recueil des besoins jusqu’à la phase de conception). Dans cet exposé, nous allons étudier l’un des modèles , en l’occurrence le premier à construire : le diagramme de cas d’utilisation. Il permet de recueillir, d’analyser et d’organiser les besoins. Avec lui débute l’étape d’analyse d’un système.
  4. 4. UML: Diagramme de cas 4 Les diagrammes de cas dutilisation sont des diagrammes UML utilisés pour donner une vision globale du comportement fonctionnel dun système Logiciel Ils sont utiles pour desprésentations auprès de Un cas dutilisation la direction ou des représente une unitéacteurs dun projet, mais discrète dinteraction pour le développement, entre un utilisateur les cas d’utlisation sont (humain ou machine) plus appropriés. et un système.
  5. 5. Diagramme de cas 5 Vue Vue logique implémentationdiagrammes de classes diagrammes de composantesdiagrammes dobjets Vue utilisateur diagrammes de casdiagrammes détatsdiagrammes dactivités diagrammes de déploiementdiagrammes de séquencediagrammes de collaboration Vue Vue comportement déploiement
  6. 6. Définition 6Définition des cas d’utilisation («use cases») Permettent d’impliquer les utilisateurs dès les premiers stades du développement pour exprimer leurs besoins. Décrivent les fonctionnalités offertes par le système (le « quoi? » avant le « comment? ») :  délimitation du système par l’ensemble des fonctions qu’il offre,  relations avec son environnement (acteurs). Modélisent à la fois les traitements (fonctionnalités) et les communications (interactions) ≠ acteurs/flux de Merise. Utilisables pour tout projet indépendamment d’UML et de l’approche objet.
  7. 7. Définitions 7Acteurs et cas Acteur : personne ou système qui interagit avec le système étudié en échangeant de l’information. Ex: utilisateurs directs du système (bénéficiaires des services), responsables de son fonctionnement (ex: administrateur), autres systèmes qui interagissent avec lui… Un acteur représente un rôle. La même personne physique peut jouer le rôle de plusieurs acteurs et plusieurs personnes physiques peuvent jouer le même rôle et donc agir comme un même acteur. Cas : interaction avec le système par un acteur dans une certaine intention; un service rendu par le système; une fonctionnalité.
  8. 8. Diagrammes de cas d’utilisation 8 Décrivent les interactions entre les acteurs et le système représenté comme un ensemble de cas. Les interactions sont orientées (avec une flèche) ou non. Découvrons comment ?
  9. 9. Diagrammes de cas d’utilisation 9 Groupement éventuel des cas en Le système paquetage(s) cas d’utilisation interaction Xacteur acteur humainFrontière cas du d’utilisation acteur «<<actor>> sticksystème Y man » acteur L’acteur est source et/ou système destination d’une interaction
  10. 10. Diagramme de cas ACTEURS
  11. 11. Acteur 11 Un acteur est la description dun ensemble cohérent de rôles quun utilisateur (personne ou système) joue lorsquil interagit avec le système. Exemple : <<acteur>> Bibliothéquaire Client
  12. 12. Représentation graphique dun acteur 12 Un acteur est une classe stéréotypée représentée par un rectangle avec le stéréotype «acteur» ou par une icône. <<acteur>> Bibliothéquaire Client
  13. 13. Nommer un acteur 13 Chaque acteur doit avoir un nom qui le distingue des autres acteurs - Unicité du nom complet (noms des packages englobant + le nom de lacteur). En pratique les noms de acteurs sont des noms pris dans le vocabulaire du domaine. Il est dusage de capitaliser la première lettre de chaque mot. <<acteur>> ClientBanque PréposéBanque
  14. 14. Types des acteurs 14 Utilisateurs principaux (client) PériphériquesUtilisateurs externessecondaires ( horloge(directeur) interne) Système externes (système inter- bancaire)
  15. 15. Généralisation entre acteurs 15 Les acteurs peuvent avoir des associations de généralisation Exemple : Client Particulier Entreprise
  16. 16. Acteurs vs utilisateurs 16 Ne pas confondre les 2 notions Un acteur décrit un rôle Un utilisateur = personne utilisant le système Une même personne peut avoir deux rôles Maurice, directeur de banque et guichetier Plusieurs personnes peuvent avoir le même rôle Pierre et Paul sont 2 clients
  17. 17. Diagramme de cas CAS DUTILISATION
  18. 18. Cas dutilisation 18 Un cas est est une classe qui représente un ensemble de fonctions ou de comportements fournis par un système à un ou des acteurs.(exigences fonctionnelles du système) Exemple : Signer Contrat Assurance Acheter Automobile
  19. 19. Représentation graphique dun cas 19 Un cas est représenté par une ellipse un ensemble de cas peut être placé dans un rectangle qui symbolise le système
  20. 20. Nommer un cas 20 Chaque cas doit avoir un nom qui le distingue des autres cas - Unicité du nom complet (noms des packages englobant + le nom du cas). En pratique les noms de cas sont des verbes pris dans le vocabulaire du domaine. Emprunter Livre Accorder Crédit
  21. 21. Organiser les cas 21niveau système Serviceniveau sous-système Serviceniveau classe Opération
  22. 22. Cas d’utilisation 22
  23. 23. Description du cas d’utilisation 23 Identification Nom du cas : « Rechercher une vidéo ». But : décrire les étapes permettant au client de rechercher une vidéo via le distributeur automatique. Acteur principal : XXXX Acteur secondaire : XXXX Date de création : le jj/mm/aaaa. Responsable : M. XXXX Version : 1.0.
  24. 24. La description du cas d’utilisation 24Chaque cas d’utilisation doit être précisé par une description textuelle qui peut être structurée en plusieurs sections : conditions au démarrage (pré-conditions), conditions à la terminaison (post-conditions), étapes du déroulement normal (« nominal »), variantes possibles et les cas d’erreurs, informations échangées entre acteur et système, contraintes non fonctionnelles (performance, sécurité, disponibilité, confidentialité…).Exemple : cas RetirerArgentDistributeur
  25. 25. Description du cas d’utilisation 25 • contient des billets ; en attente d’une opération : ni en panne, ni en maintenance.précondition • si de l’argent a pu être retiré, la somme sur le compte est égale à la somme qu’il y avait avant moins le retrait. Sinon, la somme sur le compte est inchangée.postcondition • (1) le client introduit sa carte bancaire, (2) le système lit la carte et vérifie si la carte est valide, (3) le système demande au client de taper son code, (4) le client tape son code confidentiel, (5) le système vérifie que le code correspond à la carte, (6) le client choisitDéroulement une opération de retrait, (7) le système demande le montant à retirer, etc. normal
  26. 26. Description du cas d’utilisation 26 • (A) Carte invalide : au cours de l’étape (2), si la carte est jugée invalide, le système affiche un message d ’erreur, rejette la carte et le cas d’utilisation se termine. • (B) … variantes • (A) Performance : le système doit réagir dans un délai inférieur à 4 secondes, quelque soit l’action de l’utilisateur. • (B) Sécurité …contraintes
  27. 27. La description du cas d’utilisation 27 Les cas d’utilisations peuvent être vus comme des classes de scénarios. Chaque scénario correspond à une utilisation particulière ou une manière d’exécution du cas d’utilisation, par un acteur donné, dans des circonstances données.
  28. 28. Un exemple de scénario 28 • Le client insère sa carte dans le distributeur d2103 Le système accepte la carte et lit le numéro de compte Le système demande le code Le client tape ‘ 1234 ’ Le système indique que ce n’est pas le bon code Le système affiche un message et propose de recommencer …
  29. 29. Diagramme de casASSOCIATIONS ET CAS DUTILISATION
  30. 30. Généralisation 30 Lassociation de généralisation entre cas dutilisation a la même sémantique que pour les classes Valider usager Vérifier Scanner mot de passe rétine
  31. 31. « communique » 31 La relation communique permet de modéliser les échanges de messages entre acteurs et cas dutilisation <<communique>> Cas Acteur
  32. 32. Relations entre cas 32 A <<include>> B : le cas A inclut obligatoirement le cas B (permet de décomposer et de factoriser). A <<extend>> B : le cas A est une extension optionnelle du cas B à un certain point de son exécution.
  33. 33. Relations entre cas 33 attention auClient Commander sens des flèches <<include>> <<include>> <<extend>> Choisir Payer articles Demander catalogue <<xxx>> est un stéréotype UML c’est à dire un moyen de caractériser et classer des éléments des modèles UML; certains sont prédéfinis, mais les utilisateurs peuvent en définir d’autres.
  34. 34. « étend » 34 Permet d’étendre, de façon structurée, le comportement d’un cas d’utilisation de base en utilisant un autre cas d’utilisation à un point d’extension spécifique.Points dextension Traiter une <<étend>> (établir priorité) Traiter une commande commande Points dextension urgente établir priorité
  35. 35. « inclut » 35 La relation inclut permet de modéliser linclusion de cas dutilisation pour éviter les répétitions Factoriser des sous-fonctions qui sont communes à d’autres cas d’utilisation Valider <<inclut>> Traiter une Utilisateur commande
  36. 36. Exercice d’application: Enoncé 36 Modélisez avec un diagramme de cas d’utilisation le fonctionnement d’une banque qui interagit avec ses clients. Les guichetiers créent les comptes, déposent l’argent des clients dans les comptes, et peuvent aussi fermer le compte, le guichetier chef peut en plus de ceci annuler ce compte. l’opération de dépôt d’argent peut se faire de deux manières différentes: en numéraire ou par voie de chèques.
  37. 37. Corrigé 37 Créer un compteGuichetier Déposer Fermer un compte numéraire Déposer de l’argent sur un compte Déposer chèques Guichetier Annuler un Chef compte
  38. 38. Explications relatives au corrigé 38 Un ‘Guichetier Chef’ est un ‘Guichetier’ spécialisé qui peut faire tout ce que peut faire un Guichetier et, en plus, il peut annuler un compte. L’héritage simplifie le dessin (moins d’interactions à dessiner). ‘Déposer chèques’ et ‘Déposer numéraire’ sont 2 spécialisations de ‘Déposer de l’argent sur un compte’ (2 manières de faire).
  39. 39. Conclusion 39 L’objectif de cette phase de la modélisation est donc de clairement identifier les frontières du système et les interfaces qu’il doit offrir à l’utilisateur. Si cette étape commence avant la conception de l’architecture interne du système, il est en général utile, quand la réflexion est suffisamment poussée, de poser les bases de la structure interne du système, et donc d’alterner analyse des besoins et ébauche des solutions envisagées. Le diagramme de cas d’utilisation est un premier modèle d’un système. Que savons- nous sur le système après avoir créé ce diagramme ? Sur le système lui-même, en interne, pas grand-chose à vrai dire. C’est encore une boîte noire à l’architecture et au mode de fonctionnement interne inconnus. Donc, a fortiori, à ce stade, nous ne savons toujours pas comment le réaliser. En revanche, son interface avec le monde qui l’entoure est partiellement connue : nous nous sommes placés du point de vue des acteurs pour définir les spécifications fonctionnelles.
  40. 40. Références 40 Ambler, S.W. (2003) The Elements of UML Style , Londres : Cambridge University Press. Cockburn, A. (2001). Rédiger des cas dutilisations efficaces , Paris : Eyrolles. (voir aussi http://alistair.cockburn.us/ ) -Consulté le 24/12/2012- C. Larman, UML 2 et les Design Patterns, 2005, Campus Press. A. Cockburn, Rédiger des cas d’utilisation efficaces, 2002, Eyrolles. G. Overgaard, K. Palmkvist, Use Cases - Patterns and Blueprints, 2004, Addison Wesley E. Yourdon, Managing Software Reqs - A Use Case Approach, 2003, Addison Wesley D. Kulak, Use Cases: Requirements in context, 2003, Addison-Wesley K. Bittner, I. Spence, Use Case Modeling, 2003, Addison-Wesley

×