Analyse et conception orienté objet (uml).pdf
- 1. Analyse et conception orientée UML Présenté par : Mr. Mbaye Chef de projet IT / TEQLAB Email : senyr9@gmail.com Skype : senol.mbaye
- 2. Objectif du cours ❑ Etudier de façon pratique l’analyse et la conception orientée objet : UML ❑ Prérequis ❑Aucun ❑Durée : 21H ❑Séances de cours ❑Séances de TD ❑Séances de TP ❑Evaluation ❑Devoir (TP ou Exercices) ❑Examen QCM
- 3. PLAN ❑ Présentation du formateur ❑ Qu’est ce que UML ? ❑ Le Plan du cours ❑ Les références des ressources logicielles ❑ Les liens utiles
- 4. Présentation du Formateur ❑El Hadji Sény Mbaye ❑Email : senyr9@gmail.com / seny.mbaye@teqlab.tech ❑Consultant, Concepteur et Formateur ❑Chef de projet IT, réalisation d’applications web/mobile ❑Co-fondateur de TEQLAB ❑Actuelle en mission sur un projet de recherche: le factchecking (doctorat) ❑Mes références ❑Linkedin : https://www.linkedin.com/in/seny-mbaye/ ❑Skype : @senol.mbaye
- 5. Qu’est ce que UML ? ❑Langage de modélisation « Unified Modeling Language » ❑UML est une notation graphique utilisable pour : ❑Décrire les besoins des utilisateurs sur une application ❑Spécifier un système ❑Concevoir un système informatique ❑Réaliser une documentation ❑Améliorer la communication entre les parties prenantes d’un projet ❑UML peut-être utilisé de manière plus ou moins formelle, tout à fait compatible avec les démarches agiles. UML est un outil
- 6. Plan du cours • Module 1 : Généralités • Chapitre 1 : les diagrammes UML • Chapitre 2 : Mettre en œuvre UML dans le projet • Module 2 : UML pour la maîtrise d’ouvrage • Chapitre 1 : les processus métier • Chapitre 2 : les objets métier • Chapitre 3 : l’expression des besoins • Module 3 : UML en analyse • Chapitre 1 : Découvrir les classes • Chapitre 2 : Les états des objets • Module 4 : UML en conception • Chapitre 1 : Construire le modèle de conception • Chapitre 2 : Passer de l’analyse à la conception
- 7. Les références des ressources logicielles • Visual Paradigm • https://www.visual-paradigm.com/ • Astah • https://astah.net/ • Modelio • https://www.modeliosoft.com/fr/ • Draw.io • https://app.diagrams.net/
- 8. Liens utiles • OMG • https://www.uml.org/ • Les experts • Pascal Roques (googler)
- 9. Module 1 : Généralités Chapitre 1 : les diagrammes UML
- 10. PLAN ❑Rappels sur l’approche orienté objets ❑Pourquoi ? ❑Avantages attendus ❑Vocabulaire
- 11. Pourquoi utiliser cette approche ? ❑Définition naturelle de composants (objets) ❑Meilleure modularité de l’application. ❑Cohérence du code (données/traitements) ❑Mécanismes d’extension (héritage). ❑Séparation des interfaces de l’implémentation.
- 12. Analyse/Conception/Codage ❑Programmation ❑Utiliser un langage orienté objet ❑Conception ❑Mettre en place une solution logicielle utilisant les concepts et suivants les principes ❑Analyse ❑Décrire le problème avec des classes ❑En utilisant le paradigme « orienté objets », problème & solution sont liés
- 13. Objet et Classe ❑Classe ❑Type d’objets ❑Descripteur (usine) d’objets ❑Objet ❑Instance de la classe ❑Connaît sa classe
- 14. Avantages attendus ❑Lisibilité de chaque classe ❑Le code est cohérent car les traitements et les données sont liés par la proximité ❑L’intension est plus clair ❑L’objectif de la classe est mieux compris grâce à la définition des services ❑Sécurité du code ❑Les données sont encapsulées et visible uniquement des traitements autorisés ❑L’état de l’objet est mieux maîtrisé ❑Réutilisabilité du code de chaque classe ❑La classe est définie indépendamment du contexte ❑Replacer la classe dans un contexte différent est donc simple ❑Réutilisabilité de groupes de classes ❑Un groupe de classes (package) est réutilisable s’il est bien construit, avec une forte cohérence interne ❑La réutilisation passe soit par l’héritage, soit par l’implémentation d’interface
- 16. Classification
- 17. Encapsulation
- 18. Abstraction
- 19. Les méthodes et la surcharge
- 20. Les messages 1/2 • Un objet émetteur envoi des messages à un récepteur • Traduit la dynamique du système
- 21. Les messages 2/2 • Les objets s’échangent des messages
- 22. L’héritage
- 23. La redéfinition des méthodes
- 24. Objets
- 25. La validé d’un héritage ❑Un héritage est une relation EST-UN ❑Un héritage est une relation à 100% Exemple qui ne respecte pas la validité
- 26. 14 diagrammes en UML 1) Les diagrammes de classes 2) Les diagrammes de séquences 3) Les diagrammes de use-case 4) Les diagrammes d’activités 5) Les diagrammes de composants 6) Les diagrammes de déploiement 7) Les diagrammes de packages 8) Les diagrammes d’états 9) Les diagrammes de communication 10) Les diagrammes de temps 11) Les diagrammes d’objets, 12) Les diagrammes de vue d’ensemble des interactions 13) Les diagrammes de profils 14) Les diagrammes de structure composites
- 27. Digramme de classes ❑Montre les types d’objets à utiliser ❑Proche du MCD ❑Diagramme très courant ❑Diagramme du structure, et statique, il ne peut rien dire sur la dynamique du système
- 28. Diagrammes d’objets ❑Instance du diagramme de classes ❑Sert à montrer un exemple de la structure, en particulier lorsque le diagramme de classe est interprétable ❑Peu courant, car rapidement complexe et difficile à rendre exhaustif
- 29. Le diagrammes de packages ❑Un package est un regroupement de n’importe quel élément UML ❑Ce diagramme montre les relations entre packages du système étudié ❑A noter que les dépendances entre packages peuvent être étudiées par des indicateurs
- 30. Le diagramme de composant ❑Un composant est un élément offrant des services et nécessitant d’autres composants ❑Il fournit les services via des interfaces et requiert d’autres interfaces ❑Peut-être décomposé ❑Utile lors d’une rétroconception
- 31. Le diagramme de déploiement ❑Montre les nœuds physiques de déploiement : machines, réseaux, … ❑Représentation graphique qui profite des stéréotypes ❑Description des besoins ou expression d’un existant
- 32. Le diagramme de structures composites ❑Représente des compositions complexes de façons non ambigüe ❑Introduit les concepts de classes structurées, de parts, de connectors
- 33. Le digramme de profils ❑Représente les types et stéréotypes disponibles pour la réalisation d’un modèle
- 34. Le diagramme de cas d’utilisation ❑Représentation du comportement du système sous forme de cas d’utilisation ❑Diagramme statique, sert de point d’entrée à l’étude de besoins
- 35. Le diagramme d’activités ❑Représente les enchaînements nécessaires à la réalisation d’un processus ❑Utile dans la description des processus métier ❑Utile dans la description des cas d’utilisation ❑Facile à introduire, simple et efficace
- 36. Le diagramme d’états ❑Représente le cycle de vue d’un objet ❑Utile pour la description d’un objet métier ❑Trouve une traduction aussi dans le code ❑Le contexte peut-être complexe
- 37. Le diagramme de communication ❑Représente ce que le diagramme de séquence sait présenter ❑Disposition spatiale des entités ❑Assez riche, donc rapidement touffu ❑Souvent utilisé sous le nom de digramme de contexte dynamique
- 38. Le diagramme de temps ❑Représente des contraintes de temps dans les interactions entre objets ❑Diagramme complexe, qui mélange les états des objets et les messages entre ces mêmes objets
- 39. La vue d’ensemble des interactions ❑Représente les séquences entre les différentes interactions de l’étude ❑Plutôt utilisé comme un outil de synthèse de plusieurs interaction ❑Possibilités de présentations expressives
- 40. En résumé ❑UML est un langage graphique, mais non une démarche ❑14 diagrammes différents dans UML ❑7 diagrammes de structure ❑7 diagrammes de comportement ❑Certains diagrammes utilisent l’approche orientée objets.
- 41. Les diagrammes de classes
- 42. Plan (rappel) •Usages du diagramme de classes •Syntaxe de base •Syntaxe avancée
- 43. Usages du diagramme de classes • Diagramme de structure, statique • Représentes les types d’objets utilisés • Appliqué aux • Objets métiers • Objets d’analyse • Objets de conception, logiciel
- 44. La syntaxe de base • Classe, attribut, méthode • Association, multiplicité • Généralisation-spécialisation • Classe abstraite • Interface et implémentation
- 45. Classes
- 46. Classes, attributs, méthodes, visibilités
- 49. Classe abstraite
- 51. Syntaxe avancée • Attributs dérivés et constants • Attributs et méthodes statiques • Restriction de navigabilité et noms de rôles • Dépendances contextuelles • Classe d’association • Compositions et agrégations • Notes et contraintes
- 52. Attributs dérivés et constants
- 53. Attributs et méthodes statiques
- 54. Restriction de navigabilité et noms de rôles
- 59. Les diagrammes de Use Case
- 60. PLAN • Usages du diagramme de cas d’utilisation • Syntaxe de base • Syntaxe avancée
- 61. Usages du diagramme de cas d’utilisation • Diagramme de comportement, statique • Le diagramme dédié à la description statique des processus • Ne montre aucune dynamique, liste les fonctionnalités du système
- 62. La syntaxe de base • Acteur, humain ou machine • Cas d’utilisation • Association • Frontière du système
- 63. Définition des cas d’utilisations • Un cas d’utilisation est une fonctionnalité du système, indépendante a priori des autres cas d’utilisation • UML n’a pas inventé les cas d’utilisation • Un acteur est un rôle joué par une entité externe au système, en interaction directe avec le système • Le diagramme des cas d’utilisation est une vue de haut niveau de l’étude de besoins
- 64. Acteur
- 66. Association
- 67. La syntaxe avancée • Acteur abstrait • Cas d’utilisation abstrait, généralisation • Inclusion, extension
- 69. Cas d’utilisation abstrait, généralisation
- 71. Ce qu’on a couvert • Les usages du diagramme de cas d’utilisation • La syntaxe de base : acteur, cas d’utilisation, association • La syntaxe plus avancée : les inclusion, extension et généralisation entre cas d’utilisation, la généralisation entre acteurs
- 73. PLAN • Usages du diagramme de séquences • Syntaxe de base • Syntaxe avancée
- 74. Usage du diagramme de séquences • Diagramme de comportement, dynamique • Un des diagrammes d’interaction entre les objets, il met en valeur les échanges de messages dans le temps • Il peut montrer : • Les interactions entre acteurs métiers • Les interactions entre acteurs du systèmes et le système • Les interactions entre objets d’analyse • Les interactions entre objets logiciels
- 75. Syntaxe de base • Objet, ligne de vie, focus de contrôle • Messages des synchrones, asynchrones • Messages de création, de destruction
- 76. Objet, Ligne de vie, focus de contrôle
- 77. Message (synchrones & asynchrones)
- 78. Message de création, de destruction
- 79. Syntaxe avancée • Les cadres LOOP, ALT, REF, OPT • Auto-messages, messages récursifs
- 80. Cadre LOOP
- 81. Cadre ALT
- 82. Auto-messages et messages récursifs
- 83. Ce qu’on a couvert • Les usages du diagramme de séquences • La syntaxe de base : ligne de vie, focus de contrôle, les retours, messages, synchrones, asynchrones, création et destruction • La syntaxe plus avancée : les cadres (LOOP et ALT), les auto-messages et messages récursifs.
- 84. Exercice pratique (diagramme de séquences) Pour faciliter sa gestion, un entrepôt de stockage envisage de s’informatiser. Le logiciel à produire doit allouer automatique un emplacement pour le chargement des camions qui convoient le stock à entreposer. Le fonctionnent du système informatique doit être le suivant : • déchargement d’un camion : lors de l’arrivée d’un camion, un employé doit saisir dans le système les caractéristiques de chaque article ; le système produit alors une liste où figure un emplacement pour chaque article ; • chargement d’un camion : les caractéristiques des articles à charger dans un camion sont saisies par un employé afin d’indiquer au système de libérer des emplacements. Le chargement et le déchargement sont réalisés manuellement. Les employés de l’entrepôt sont sous la responsabilité d’un chef dont le rôle est de superviser la bonne application des consignes.