D IAGRAMME   D E   C AS  D’ U TILISATION   ( U SE   C ASES ) H ERAGUEMI  K AMEL  E DDINE P REPARER PAR
Plan de travail <ul><li>Technique de modélisation Orientée Objet. </li></ul><ul><li>UML  2.0 ( U nified  M odeling  L angu...
Technique de modélisation Orientée Objet. <ul><li>L’émergence des approches ’objet’ (1990-1995) </li></ul><ul><li>Prise de...
UML 2.0 (Unified modeling language) <ul><li>Auteurs: </li></ul><ul><li>James Rumbaugh, Grady Booch et Yvar Jacobson </li><...
UML 2.0 (Unified modeling language)/2 <ul><li>Définition: </li></ul><ul><li>Un  langage   pas une méthode : UML définit de...
UML 2.0 (Unified modeling language)/3
Diagramme de Cas d’utilisation  <ul><li>QU’EST-CE QU’UN CAS D’UTILISATION: </li></ul><ul><li>Un  cas d’utilisation  (Use C...
<ul><li>QU’EST-CE QU’UN  Acteur: </li></ul><ul><li>Personne  ou  Système  qui interagit avec le système étudié en échangea...
Acteurs et cas 2 <ul><li>QU’EST-CE QU’UN  CAS: </li></ul><ul><li>Un cas d'utilisation représente une  fonctionnalité fourn...
Acteurs et cas 3 Comment identifier les cas ?  <ul><li>Chaque cas d’utilisation doit décrire les exigences fonctionnelles ...
Les relations  dans un diagramme  cas d’utilisation <ul><li>Il existe 4 relations principales :  </li></ul><ul><li>La rela...
Les relations  dans un diagramme  cas d’utilisation 5 <ul><li>Une relation d’association : est un  chemin de communication...
Les relations  dans un diagramme  cas d’utilisation 4 <ul><li>Héritage (généralisation)  :  le cas d’utilisation dérivé es...
Les relations  dans un diagramme  cas d’utilisation 2 La relation d’ inclusion  ( « Include » ): un cas d’utilisation a be...
Les relations  dans un diagramme  cas d’utilisation 3 La relation d’extension  (« Extend » )  :  le cas source ajoute son ...
Description narrative des cas d’utilisation <ul><li>Comme la plupart des diagrammes UML, le diagramme des cas d’utilisatio...
Conclusion <ul><li>Le diagramme de cas d’utilisation est plus riche que le diagramme  acteurs/flux  de  Merise .  </li></u...
Prochain SlideShare
Chargement dans…5
×

7 diagramme de cas d'utilisation

18 443 vues

Publié le

0 commentaire
4 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
18 443
Sur SlideShare
0
Issues des intégrations
0
Intégrations
55
Actions
Partages
0
Téléchargements
432
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

7 diagramme de cas d'utilisation

  1. 1. D IAGRAMME D E C AS D’ U TILISATION ( U SE C ASES ) H ERAGUEMI K AMEL E DDINE P REPARER PAR
  2. 2. Plan de travail <ul><li>Technique de modélisation Orientée Objet. </li></ul><ul><li>UML 2.0 ( U nified M odeling L anguage ). </li></ul><ul><li>Diagramme de Cas d’utilisation (Use Cases) </li></ul>
  3. 3. Technique de modélisation Orientée Objet. <ul><li>L’émergence des approches ’objet’ (1990-1995) </li></ul><ul><li>Prise de conscience de l’importance d’une approche spécifiquement objet : comment structurer un système sans centrer l’analyse uniquement sur les données ou uniquement sur les traitements (mais sur les deux) ? </li></ul><ul><li>Plusieurs méthodes objet sont apparues durant cette période (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) ! </li></ul><ul><li>Méthodes ont émergé du lot : </li></ul><ul><li>OMT (Object Modelling Technique) , par James Rumbaugh, </li></ul><ul><li>OOD (Object Oriented Design) , par Grady Booch ; </li></ul><ul><li>OOSE (Object Oriented Software Engineering) , par Ivar Jacobson, </li></ul>Ce sont les ascendants d’ UML
  4. 4. UML 2.0 (Unified modeling language) <ul><li>Auteurs: </li></ul><ul><li>James Rumbaugh, Grady Booch et Yvar Jacobson </li></ul><ul><li>Objectifs: </li></ul><ul><li>Faciliter la communication entre les différents acteurs d’un projet </li></ul><ul><li>Faciliter la communication avec la machine </li></ul><ul><li>Limiter les ambiguïtés </li></ul><ul><li>Construire (interpréter les diagrammes pour code) </li></ul>
  5. 5. UML 2.0 (Unified modeling language)/2 <ul><li>Définition: </li></ul><ul><li>Un langage pas une méthode : UML définit des modes de représentation (diagrammes et notations) mais n’impose pas de démarche standardisée. </li></ul><ul><li>Un langage de modélisation objet permettant de documenter dans des modèles toutes les phases du développement (analyse, conception et implantation). </li></ul>
  6. 6. UML 2.0 (Unified modeling language)/3
  7. 7. Diagramme de Cas d’utilisation <ul><li>QU’EST-CE QU’UN CAS D’UTILISATION: </li></ul><ul><li>Un cas d’utilisation (Use Cases) est un diagramme qui modélise une interaction entre le système informatique à développer et un utilisateur ou acteur interagissant avec le système. </li></ul><ul><li>Permettent de définir les besoins des utilisateurs et les fonctionnalités du système : </li></ul><ul><ul><li>Limitation du système, </li></ul></ul><ul><ul><li>Relations avec son environnement, </li></ul></ul><ul><ul><li>Fonctions attendues. </li></ul></ul>
  8. 8. <ul><li>QU’EST-CE QU’UN Acteur: </li></ul><ul><li>Personne ou Système qui interagit avec le système étudié en échangeant de l’information. </li></ul><ul><ul><li>Il possède un rôle par rapport au système, </li></ul></ul><ul><ul><li>Il peut consulter ou modifier l’état d’un système. </li></ul></ul><ul><ul><li>Il existe 4 catégories principales d’acteur: </li></ul></ul><ul><li>Acteur PRINCIPAL : Les personnes qu’utilisent la fonction principale du système. </li></ul><ul><ul><li>Acteur SECONDAIRE : Les personnes qu’effectuent des taches administratives ou maintenance du système </li></ul></ul><ul><ul><li>Matériels Externes : Les périphériques qui doit être utiliser(Ex :imprimante...) </li></ul></ul><ul><ul><li>Autre Systèmes: Les systèmes avec lesquels le système doit être interagit. </li></ul></ul>Acteurs et cas Acteur
  9. 9. Acteurs et cas 2 <ul><li>QU’EST-CE QU’UN CAS: </li></ul><ul><li>Un cas d'utilisation représente une fonctionnalité fournie par le système , typiquement décrite sous la forme Verbe . </li></ul><ul><li>Les cas d'utilisation sont représentés par une ellipse contenant leurs nom. </li></ul>Nom du cas
  10. 10. Acteurs et cas 3 Comment identifier les cas ? <ul><li>Chaque cas d’utilisation doit décrire les exigences fonctionnelles du système. </li></ul><ul><li>Chaque cas d’utilisation correspond à une fonction du système (besoins des utilisateurs et possibilités du système). </li></ul><ul><li>Donc il faut chercher pour chaque acteur : </li></ul><ul><ul><li>Les différentes intentions métier avec lesquelles il utilise le système, </li></ul></ul><ul><ul><li>Déterminer les services fonctionnels attendus du système. </li></ul></ul>
  11. 11. Les relations dans un diagramme cas d’utilisation <ul><li>Il existe 4 relations principales : </li></ul><ul><li>La relation d’ association </li></ul><ul><li>La relation de généralisation </li></ul><ul><li>La relation d’ inclusion </li></ul><ul><li>La relation d’extension </li></ul>Exemple System de gestion de Compte bancaire
  12. 12. Les relations dans un diagramme cas d’utilisation 5 <ul><li>Une relation d’association : est un chemin de communication entre un acteur et un cas d’utilisation. </li></ul>Exemple Retirer des billées Chargement des billées Admistrateur Client (Acteur Primaire ) (Acteur Secondaire)
  13. 13. Les relations dans un diagramme cas d’utilisation 4 <ul><li>Héritage (généralisation) : le cas d’utilisation dérivé est une spécialisation du cas d’utilisation parent (même notion d’héritage entre les classes) ; </li></ul>Exemple Le cas VIREMENT PAR INTERNET hérite de tout les caractéristique du cas VIREMENT VIREMENT VIRMENT PAR INTERNET
  14. 14. Les relations dans un diagramme cas d’utilisation 2 La relation d’ inclusion ( « Include » ): un cas d’utilisation a besoin d’un autre cas d’utilisation pour réaliser sa tâche ; Exemple Pour qu’ un utilisateur réalise le cas de VIREMENT il fait qu’il passe le cas d’IDENTIFICATION . Donc l’opération virement utilise l’opération d’identification Virement Identification « Include »
  15. 15. Les relations dans un diagramme cas d’utilisation 3 La relation d’extension (« Extend » ) : le cas source ajoute son comportement au cas destination (cible). L’extension peut être soumise à une condition. Exemple VERIFICATION DE SOLDE Retire de solde « Extend »
  16. 16. Description narrative des cas d’utilisation <ul><li>Comme la plupart des diagrammes UML, le diagramme des cas d’utilisation nécessite souvent une description narrative (textuelle) associée ; </li></ul><ul><li>Décrire un cas d’utilisation consiste à définir son contexte, et à détailler la communication entre le cas et l’acteur ; </li></ul><ul><li>Dans la plupart des cas, on peut adopter le plan suivant : </li></ul><ul><li>Pré condition : conditions garantissant que le cas d’utilisation peut démarrer correctement. </li></ul><ul><li>Processus ou dialogue : c’est la description pas à pas des échanges entre l’acteur et le cas d’utilisation. </li></ul><ul><li>Arrêt : liste des fins possibles du cas. </li></ul><ul><li>Postcondition : ensemble de conditions qui doivent être satisfaites à la fin du cas, pour garantir que le système est dans un état cohérent. </li></ul>
  17. 17. Conclusion <ul><li>Le diagramme de cas d’utilisation est plus riche que le diagramme acteurs/flux de Merise . </li></ul><ul><li>En plus des acteurs et des communications, il liste les principales fonctionnalités attendues . Il permet de les organiser grâce aux relations d’héritage, d’inclusion et d’extension. </li></ul><ul><li>Avec les descriptions textuelles et les scénarios , l’analyste dispose de moyens simples pour exprimer de manière semi-formelle les besoins fonctionnels et non fonctionnels du système étudié . </li></ul>

×