Unified Modeling Langage Course : Different diagrams and Exemples
- 1. Chapitre I Introduction à UML Mme. ONZY M201 : Préparation d’un Projet Web TS : DEVOWFS
- 2. Sommaire 3 • Génie logiciel • Conduite de projet informatique • Phases de développement • Modèles de développement • Méthodes d’analyse et de conception • Unification des méthodes objet : UML
- 3. Génie logiciel 4 • Définition • « Ensemble de méthodes, techniques et outils pour la réalisation et la maintenance de composants logiciels. » • Justifications : • La complexité des systèmes informatiques
- 4. Qualité du logiciel 5 Facteurs externes (utilisateurs) • Validité • aptitude à répondre aux besoins et à remplir les fonctions définies dans le cahier des charges • Fiabilité (robuste) • aptitude à fonctionner dans des conditions non prévues au cahier des charges, éventuellement anormales • Extensibilité • facilité avec laquelle de nouvelles fonctionnalités peuvent être ajoutées à un logiciel
- 5. Qualité du logiciel (suite) 6 • Compatibilité • facilité avec laquelle un logiciel peut être combiné avec d’autres • Efficacité • utilisation optimale des ressources matérielles (processeur, mémoires, réseau, …) • Convivialité • facilité d’apprentissage et d ’utilisation • facilité de préparation des données • facilité de correction des erreurs d’utilisation • facilité d’interprétation des résultats
- 6. Qualité du logiciel (suite) 7 • Sécurité • aptitude d’un logiciel à protéger son code contre des accès non autorisés. Facteurs internes (concepteur) • Ré-utilisabilité • Aptitude d’un logiciel à être réutilisé, en tout ou en partie, pour d ’autres applications • Vérifiabilité • aptitude d’un logiciel à être testé (optimisation de la préparation et de la vérification des jeux d ’essai)
- 7. Qualité du logiciel (suite) 8 • Portabilité • aptitude d’un logiciel à être transféré dans des environnements logiciels et matériels différents • Lisibilité, •etc.
- 8. Sommaire 9 • Génie logiciel • Conduite de projet informatique • Phases de développement • Modèles de développement • Méthodes d’analyse et de conception • Unification des méthodes objet : UML
- 9. Projet 10 Ensemble d’actions à entreprendre afin de répondre à un besoin défini dans des délais fixés, mobilisant des ressources humaines et matérielles, possédant un coût.
- 10. Acteurs d’un projet 11 •Maître d’ouvrage (MOA) : personne physique ou morale (le client) propriétaire de l’ouvrage. Il détermine les objectifs, le budget et les délais de réalisation. •Maître d’œuvre (MOE) : personne physique ou morale (Le prestataire) qui reçoit mission du maître d’ouvrage pour assurer la conception et la réalisation del’ouvrage.
- 11. Conduite de projet Organisation méthodologique mise en œuvre pour faire en sorte que l’ouvrage réalisé par le maître d’œuvre réponde aux attentes du maître d’ouvrage dans les contraintes de délai, coût et qualité. 12
- 12. Sommaire 13 • Génie logiciel • Conduite de projet informatique • Phases de développement • Modèles de développement • Méthodes d’analyse et de conception • Unification des méthodes objet : UML
- 13. Phases de développement 14 • Étapes dans la vie d’un logiciel: • Étude de la faisabilité ■ Planification • Spécification des besoins (Requirement analysis) • Analyse (Spécification formelle) • Conception (Spécification technique) • Implémentation (Codage) • Tests unitaires • Intégration et tests • Livraison • Maintenance
- 14. Phases de développement 15 Etapes principales du cycle de vie d’un projet web
- 15. Planification 16 • Objectifs : identification de plusieurs solutions et évaluation des coûts et bénéfices de chacune d'elles •Activités : simulation de futurs scénarios de développement • Sortie : un schéma directeur contenant • la définition du problème • les différentes solutions avec les bénéfices attendus • les ressources requises pour chacune d'elles (délais, livraison, etc.)
- 16. Spécification des besoins(suite) 17 • Activités : • Abstraction et séparation des problèmes • Sorties : • Modèle des besoins • Manuel utilisateur provisoire pour les non informaticiens • Plans de tests du système futur (cahier de validation)
- 17. Analyse 18 • Objectifs : • Répondre au « Que fait le système ? » • modélisation du domaine d’application • analyse du métier et des contraintes de réalisation • Activités : • Abstraction et séparation des problèmes • Sorties : • Modèle conceptuel (diagrammes de classes etc.)
- 18. Conception 19 • Objectifs : • Répondre au « Comment faire le système ? • Décomposition modulaire • Activités : • Définition de l’architecture du logiciel • Définition de chaque constituant du logiciel : informations traitées, traitements effectués, résultats fournis, contraintes à respecter • Sorties : • Modèle logique (diagrammes de composants etc.)
- 19. Implémentation • Objectifs : • Réalisation des programmes dans un (des) langage(s) de programmation • Tests selon les plans définis lors de la conception • Activités : • Écriture des programmes • Tests • Mise au point (déboguage) • Sorties : Modèle physique • Collection de modules implémentés, non testés • cod e 20
- 20. Tests unitaires 21 • Objectifs : • Test séparé de chacun des composants du logiciel en vue de leur intégration • Activités : • réalisation des tests prévus pour chaque module • les tests sont à faire par un membre de l'équipe n'ayant pas participé à la fabrication du module • Sorties : Rapport de cohérence
- 21. Intégration et test du système 22 Objectifs : • Intégration des modules et test de tout le système Activités : • Assemblage de composants testés séparément • Tests Alpha : l'application est mise dans des conditions réelles d'utilisation, au sein de l'équipe de développement (simulation de l'utilisateur final) Sorties : • Rapport de conformité • Documentation des éléments logiciels
- 22. Livraison, maintenance, évolution Objectifs : • Livraison du produit final à l'utilisateur, • Suivi, modifications, améliorations après livraison. Activités : • Tests Bêta : distribution du produit sur un groupe de clients avant la version officielle (version d’ évaluation), • Livraison à tous les clients, • Maintenance Sorties : • Produit et sa documentation 23
- 23. Sommaire 24 • Génie logiciel • Conduite de projet informatique • Phases de développement • Modèles de développement • Méthodes d’analyse et de conception • Unification des méthodes objet : UML
- 24. Modèles de développement 25 Objectifs : • Organiser les différentes phases du cycle de vie pour l'obtention d'un logiciel fiable, adaptable et efficace • Guider le développeur dans ses activités techniques • Fournir des moyens pour gérer le développement et la maintenance (ressources, délais, avancement, etc.)
- 25. Modèles de développement (suite) 26 • Modèle (linéaire) en cascade • Modèle en V • Modèle en spirale • Processus Unifié • ...
- 27. Modèle en V 28 Le cycle en V est un modèle d'organisation des activités d'un projet qui se caractérise par un flux d'activité descendant qui détaille le produit jusqu'à sa réalisation, et un flux ascendant, qui assemble le produit en vérifiant sa qualité
- 28. Modèle en V vs Méthodes Agiles De façon générale, l’on peut affirmer que le cycle en V se focalise sur le processus, tandis que les méthodes agiles privilégient le produit. Dans le cadre des méthodes agiles (Scrum, XP, RAD, …), le projet s’affine par itérations , à travers la répétition d’un cycle d’opérations (le sprint dans le cadre de la méthode Scrum ). Le cycle en V définit l’intégralité du produit final dès les premières étapes, et ne laisse que peu de place à l’adaptation dans la suite du cycle. Ensuite, les méthodes agiles permettent d’élaborer le produit par incrémentation . On produit un peu plus à chaque fois, morceau par morceau, pour aboutir au résultat final. Ce manque d’adaptation et de flexibilité du cycle en V a précisément conduit à l’émergence des méthodes agiles, en particulier dans le domaine du logiciel et du marketing, pour répondre aux changements de plus en plus rapides des technologies et des demandes des consommateurs.
- 29. Processus Unifié • UP = démarche une développement itérative et incrémentale • Itérative = le développement s’organise en une série de mini- projet courts, de durée fixe, nommé itération • Le résultat de chaque itération = un système testé, intégré et exécutable • Chaque itération comprend ses propres activités (analyse, conception, implémentation et test) • Incrémentale=le système croît de façon incrémentale, itération par itération)
- 30. Processus Unifié (suite) spécification conception Implémentation + test + intégration Intégration finale + test système spécification conception Implémentation + test + intégration Intégration finale + test système Itération N Itération N+1 Le système Feed-back sur l’itération N entraîne un affinement et une adaptation Des spécification de l’itération N+1 Chaque itération, choisir un petit sous-ensemble de besoins puis concevoir, implémenter et tester rapidement
- 31. Processus Unifié (suite) • Chaque itération, choisir un petit sous-ensemble de besoins puis concevoir, implémenter et tester rapidement UP est incrémental : • le cycle de vie est fondé sur l’accroissance et l’affinement successif du système par le biais des itérations multiples. • Le feed-back, l’adaptation, et implication de l’utilisateur étant les moteurs principaux qui permettent de converger vers un système satisfaisant • Le système croît de façon incrémentale, itération par itération (UP = processus itératif incrémental)
- 32. Sommaire 33 • Génie logiciel • Conduite de projet informatique • Phases de développement • Modèles de développement • Méthodes d’analyse et de conception • Unification des méthodes objet : UML
- 33. Méthode d’analyse et de conception 34 • Proposition d’une démarche distinguant les étapes du développement dans le cycle de vie du logiciel • Utilisation d’un formalisme de représentation qui facilite la communication, l’organisation et la vérification • production de documents (modèles) qui facilitent les retours sur conception et l’évolution des applications
- 34. De nombreuses méthodes 35 • Méthodes données • Entité-Relation, MERISE, ... • Méthodes comportements • SA-RT, Réseaux de Pétri, ... • Méthodes objets • OMT, OOA, Classe-Relation, OOD, ...
- 35. Sommaire 36 • Génie logiciel • Conduite de projet informatique • Phases de développement • Modèles de développement • Méthodes d’analyse et de conception • Unification des méthodes objet : UML
- 36. Unification des méthodes Objet ■ au début des années 90, il existe une cinquantaine de méthodes objet, liées uniquement par un consensus autour d’idées communes (objet, classe, sous- systèmes,…) ■ Chacune possède sa propre notation, SANS arriver à remplir tous les besoins et à modéliser domaines 37
- 37. Recherche d’un langage commun unique D’où la recherche d’un langage qui est: • utilisable par toute méthode objet, dans toutes les phases du cycle de vie, • compatible avec les techniques de réalisation actuelles. □ l’unification des notations donne Naissance de UML (signifie Unified Modeling Language)
- 38. UML • Signifie Unified Modeling Language • Est une notation basée sur les méthodes • Booch, • OMT (Rumbaugh), • OOSE (Jacobson), • A été construit afin de standardiser les artéfacts de développement (modèles, notation, diagrammes) SANS standardiser le processus de développement, • Rôle important de RATIONAL et de 39
- 39. Point de vue des sources 40 • OMT :expressive pour l’analyse et la conception de systèmes d’information à base de données, • BOOCH : expressive durant les phases de design et d’implantation des projets, • OOSE :expressive pour l’analyse des besoins grâce aux cas d’utilisation
- 43. UML, différentes vues (suite) 44 ■ Vue Cas d'utilisation : ■ Décrit le système comme un ensemble de transactions du point de vue de l'utilisateur. Créée lors de la phase d'initialisation ■ Vue Logique : ■ Contient une collection de conteneur, classes et relations. Créée lors de la phase d'analyse et raffinée lors de la phase de développement ■ Vue Composants : ■ Contient une collection de conteneur, et de programmes
- 44. UML, différentes vues (suite) 45 ■ Vue Déploiement : ■ Décrit l'architecture matérielle. Contient une collection d'unités et de processus. Créée lors de la phase d'analyse ■ Vue Implantation : ■ Contient une collection de modules et sous-modules (conteneur).Créée lors de la phase d'analyse et affinée lors de la phase de développement
- 45. Diagrammes d’UML 46 ■ L’UML spécifie treize types de diagrammes de modélisation des systèmes. ■ Chaque diagramme modélise une caractéristique de la structure ou du comportement du système.
- 46. Diagrammes d’UML 47 Diagramme de cas d’utilisation : Décrit les fonctions du système selon le point de vue ses futurs utilisateurs (Jacobson) Diagramme de séquence : représentation des interactions temporelles entre objets dans la réalisation d’une interface Homme Système.
- 47. Diagrammes d’UML 48 ■ Diagramme de classes : ■ structure des données du système définies comme un ensemble de relations entre classes ■ Diagramme d’objets : ■ illustration des objets et de leur relations ■ Diagramme de collaboration : ■ représentation des interactions entre objets ■ Diagramme d’états-transitions : ■ représentation du comportement des objets d’une classe en terme d’états et de transitions d’états ■ Diagramme d’activités : ■ structure d’une opération en actions ■ Diagramme de structure composite (depuis UML 2.x) : permet de décrire sous forme de boîte blanche les relations entre composants d'une classe.
- 48. Diagrammes d’UML ■ Diagramme des paquetages ■ Diagramme de communication (depuis UML 2.x) : représentation simplifiée d'un diagramme de séquence se concentrant sur les échanges de messages entre les objets. ■ Diagramme global d'interaction (depuis UML 2.x, cf. Interaction Overview Diagram) : permet de décrire les enchaînements possibles entre les scénarios préalablement identifiés sous forme de diagrammes de séquences (variante du diagramme d'activité). ■ Diagramme de temps (depuis UML 2.x, cf. Timing Diagram) : permet de décrire les variations d'une donnée au cours du temps.
- 49. Diagrammes d’UML : 50 ■ Diagramme de séquence : ■ représentation des interactions temporelles entre objets dans la réalisation d’une opération ■ Diagramme de déploiement : ■ description du déploiement des composants sur les dispositifs matériels ■ Diagrammes de composants : ■ architecture des composants physiques d’une application
- 52. Les cas d’utilisation ■ Un diagramme de UC modélise les besoins des utilisateurs. ■ Ils permettent de modéliser les besoins des clients. ■ Ils précisent le but à atteindre. ■ Ils permettent d'identifier les fonctionnalités principales (critiques) du système. cas d'utilisation Utilisateur Exprime Programmeur Réalise Analyste Comprend vérifie Testeur 52
- 53. Définition de cas d’utilisation Un cas d’utilisation • correspond à une manière spécifique d’utiliser le système • est la représentation d’une fonctionnalité, déclenchée en réponse à une stimulation du système. • facilite la structuration des besoins des utilisateurs. • exprime les limites et les objectifs du système 53
- 54. Définition de cas d’utilisation (suite) 54 Un cas d’utilisation • est un ensemble des actions réalisées par le système en réponse à une action d’un acteur. • est une suite d’interactions entre un acteur et le système • correspond à une fonction visible par l’utilisateur
- 55. Définition d’acteur Acteur : entité externe qui agit sur le système □prend les décisions contrairement à un élément logiciel □possède un rôle par rapport au système (utilisateur ou un autre système) 55
- 56. Acteur (représentation en UML) Pour chaque acteur : • choisir un identificateur représentatif du rôle • éventuellement accompagné d’une brève description textuelle : 56
- 57. Acteur (suite) 57 Ils peuvent être : • soit des humains ; • soit des logiciels ; On distingue : ■ les acteurs primaires : ceux sont les utilisateurs du système ; ■ les acteurs secondaires : ceux qui interviennent pour le bon fonctionnement du système.
- 58. Exemple de diagramme de cas d’utilisation 58
- 59. Exemple de diagramme de cas d’utilisation 59
- 60. Éléments d’un Diagrammes de cas d’utilisation 1. les acteurs 2. les cas d’utilisation 3. Une relation d’association Un chemin de communication entre un acteur et un cas d’utilisation est représenté un trait continu.
- 61. Diagramme de contexte statique On retrouve également le diagramme de contexte, qui permet de spécifier le nombre d’instances d’acteurs connectés au système à un moment donné. System actor1 actor4 actor2 actor3 0..1 0..* 0..1 0..* Multiplicité Association
- 62. Types d’associations entre cas d’utilisations Il existe principalement deux types de relations : ■ l’inclusion et l’extension (include / extend) ■ la généralisation/spécialisation (héritage)
- 63. Types d’associations entre cas d’utilisations
- 64. La relation uses (ou include) Une relation d’inclusion définit que le cas d’utilisation contient le comportement définit dans un autre cas d’utilisation. 67 Relation d’inclusion Cas d’utilisation de base Cas d’utilisation inclus
- 65. Exercice 1 MonAuto est une entreprise qui fait le commerce, l'entretien et les réparations de voitures. MonAuto désire exploiter un logiciel de gestion des réparations, elle dispose déjà d’un logiciel comptable. Les factures de réparations seront imprimées et gérées par le logiciel comptable. Le logiciel de gestion des réparations devra communiquer avec le logiciel comptable pour lui transmettre les réparations à facturer. Le logiciel de gestion des réparations est destiné en priorité au chef d'atelier, il devra lui permettre de saisir les Fiches de réparations et le travail effectué par les divers employés de l'atelier. Pour effectuer leur travail, les mécaniciens et autres employés de l'atelier vont chercher des pièces de rechange au magasin. Lorsque le logiciel sera installé, les magasiniers ne fourniront des pièces que pour les véhicules pour lesquels une fiche de réparation est ouverte; ils saisiront directement les pièces fournies de puis un terminal installé au magasin. Lorsqu’une réparation est terminée, le chef d'atelier va essayer la voiture. Si tout est en ordre, il met la voiture sur le parc clientèle et boucler la fiche de réparation informatisée. Les fiches de réparations bouclées par le chef d'atelier devront pouvoir être importées par le comptable dans le logiciel comptable.
- 66. Solution
- 67. Exercice 2 On considère le système suivant de gestion d’un GAB (Guichet automatique de billets) : - le distributeur délivre de l’argent à tout porteur de carte (carte Visa ou carte de la banque) - pour les clients de la banque, il permet la consultation du solde du compte et le dépôt d’argent (chèque ou numéraire) - toute transaction est sécurisée et nécessite par conséquent une authentification - dans le cas où une carte est avalée par le distributeur, un opérateur de maintenance se charge de la récupérer. C’est la même personne qui recharge le distributeur. Modéliser cette situation par un diagramme de cas d’utilisation
- 68. Solution 1
- 69. Relation extends entre cas d’utilisation Une relation d’extension définit que l’instance d’un cas d’utilisation peut être augmentée avec un comportement quelconque définis dans un cas d’utilisation étendu. Il faut spécifier le point d’extension sur le cas d’de destination. ■ Les deux UC peuvent s’exécuter indépendamment 68
- 70. Relation extends entre cas d’utilisation 68
- 71. Relation de Généralisation/Spécialisation Cette relation entre deux cas d’utilisation, signifie que le cas d’utilisation spécialisé est plus spécifique que le cas d’utilisation général. Le spécialisé hérite de toutes les propriétés et les associations du cas d’utilisation.
- 72. Relation de Généralisation/Spécialisation ■ En pratique, l'arborescence des cas d'utilisations correspondra à l'arborescence du menu de l'application
- 73. Relation de Généralisation/Spécialisation Cette relation entre deux cas d’utilisation, signifie que le cas d’utilisation spécialisé est plus spécifique que le cas d’utilisation général. Le spécialisé hérite de toutes les propriétés et les associations du cas d’utilisation. Spécialisation Généralisation
- 74. Exemples d’associations Exemple Généralisation/Spécialisation Virement bancaire Virement par internet Identific ation « include » Consulter boite Emails enregistrer Enregistre r sous « extend» Exemple Extension Exemple Inclusion
- 75. Une description textuelle couramment utiliséese compose de trois parties. 1- La première partie permet d’identifier le cas d’utilisation Nom : Utiliser un verbe à l’infinitif (ex : Retirer de l’argent). Objectif : Une description résumée permettant de comprendre l’intention principale du cas d’utilisation. Acteurs primaires: Ceux qui vont réaliser le cas d’utilisation Acteurs secondaires : Ceux qui vont collaborer Dates : Les dates de créations et de mise à jour de la description courante. Responsable : Le nom des responsables. Version : Le numéro de version. Description textuelle d’un cas d’utilisation
- 76. 2. La deuxième partie contient la description du fonctionnement du cas sous la forme d’une séquence de messages échangés entre les acteurs et le système. Elle contient Toujours une séquence nominale qui décrit le déroulement normal du cas. À la séquence Nominale s’ajoutent fréquemment des séquences alternatives (des embranchement dans la séquence nominale) et des séquences d’exceptions (qui interviennent quand une erreur se produise). Les préconditions : elles décrivent dans quel état doit être le système (l’application) avant que ce cas d’utilisation puisse être déclenché. Des scénarios : Ces scénarios sont décrits sous la forme d’ échanges d’évènements entre l’acteur et le système. On distingue le scénario nominal, qui se déroule quand il n’y a pas d’erreur, des scénarios
- 77. Des postconditions : Elle décrivent l’ état du système à l’issue des différents scénarios. La troisième partie (optionnelle): Elle contient des spécifications non fonctionnelles, (spécifications matérielle et technique portant sur le temps de réponse, outils, Mono Multitâche…
- 78. Exemple : Scénario nominal Enchaînements alternatifs : A1 : nom d’enchaînement - Le point de démarrage à partir d’un point x du scénario nominal - Les actions numérotées du système avec des numéros -Le scénario nominal reprend au point y Enchaînements des erreurs : - E1 : Nom d’erreur - Le point de démarrage à partir d’un point x du scénario nominal - Les actions numérotées du système suite à cette erreur Remarque : Les enchaînements alternatifs et d’erreurs sont causé par l’utilisateur Actions acteurs principal Actions Système 1 2 3 Description textuelle d’un cas d’utilisation
- 79. Exemple: Les cas d’utilisation d’une vente de produits 78
- 80. Exemple: Les cas d’utilisation d’une vente de produits 78
- 81. Exemple complet avec tous les types de relation
- 82. Cas d’utilisation et scénarios 81 ■ Le système = ensemble de cas d’utilisation ■ Un cas d’utilisation = ensemble de scénarios (chemins d’exécution possibles) ■ Un scénario est une séquence d’événements, et c’est un chemin particulier d’exécution ■ On peut dire que: un scénario est une instance d’un cas d’utilisation. ■ Une instance d’acteur crée un scénario ■ Un cas d’utilisation peut être décrit à l’aide d’un diagramme d’activités ■ Un scénario peut être décrit à l’aide d’un diagramme de séquences
- 83. Une entreprise a mis en place un logiciel pour le suivi de ses produits. Tout le personnel de cette entreprise peut consulter le système, soit pour vérifier qu’un produit existe, soit pour un parcours libre des informations. Les ingénieur Toute consultation doit être précédée d’une authentification légère dans laquelle la personne précise son nom et son service. s peuvent effectuer plusieurs opérations de mise à jour pour les produits (ajout, retrait, modification). Ces opérations doivent être précédées d’une authentification plus approfondie où l’ingénieur précise son nom, son service et introduit un mot de passe qui est vérifié en contactant le système de gestion du personnel. Toutes les opérations (consultation et mise à jour) donnent lieu à un enregistrement dans un journal des accès et peuvent optionnellement s’accompagner d’une impression des documents à destination du directeur. Exercice 3
- 84. Solution
- 85. Exercice 4 Une plateforme en ligne propose des cours et des formations. Les utilisateurs peuvent s'inscrire pour suivre des cours et accéder à leur contenu. Avant de pouvoir suivre un cours, un utilisateur doit obligatoirement s'inscrire à la plateforme et valider son inscription via un e-mail de confirmation . Une fois inscrit, l'utilisateur peut parcourir le catalogue des cours, ajouter des cours à ses favoris et s'inscrire à un cours spécifique. L'utilisateur peut également télécharger des ressources supplémentaires fournies avec certains . Si un utilisateur oublie son mot de passe, il peut demander une réinitialisation via un e-mail . Les formateurs, quant à eux, peuvent publier de nouveaux cours et répondre aux questions des étudiants via un forum dédié.
- 87. □Une classe est une description abstraite (modèle) d’un ensemble d’objets ayant : - des propriétés similaires, - un comportement commun, - des relations communes avec d’autres objets -des sémantiques communes □Un objet est représentation individuelle(instance) d’une classe. 2 Classe et Objet
- 88. Représentation d’une classe en UML Nom de la classe Attribut s Opérations Note: Les compartiments d’une classe peuvent être omis si leur contenu n’est pas intéressant dans le contexte d’un diagramme 3
- 89. Représentation d’une classe en UML 4 Étudiant nom préno m date de naissa nce Age() Personne Filière Exemple :
- 90. Attributs de classes 5 Un attribut de classe définit une propriété commune aux objets d’une classe. (Équivalent à une variable membre en C++) ▪Les noms d’attributs d’une classe sont uniques. ▪Chaque objet, instance d’une classe, a sa propre identité, Indépendante des valeurs de ses attributs. ▪L’identification d’un objet est donc facultative. Nom de la classe Nom d’attribut :Type=valeur initiale
- 91. Attributs de classes 6 Exemple: Personne Nom:chaîne Prénom:chaîn e Date de naissance : Date Voiture Immatriculation:chaî ne Puissance: chaîne Marque : chaîne
- 92. Opérations de classe 7 - Une opération définit une fonction appliquée à des objets d’une classe (Équivalent à une fonction membre en C++) Personne nom d’opération ( liste d’arguments ) : type de retour - Elle représente le service que la classe doit fournir à ces utilisateurs
- 93. Opérations de classe 8 Exemple: Étudiant nom préno m date de naissa nce Age() changerAdresse ObjetGéométrique Couleur: chaîne Position: entier déplacer(dx:vecteur) sélectionner(p:point):boole an
- 94. Accessibilité aux attributs et opérations d’une classe 9 Trois niveau de protection: • Public (+) : accès à partir de toute entité interne ou externe à la classe • Protégé (#) : accès à partir de la classe ou des sous-classes • Privé (-) : accès à partir des opérations de la classe Étudiant - nom - prénom - date de naissance + Age() + changerAdresse()
- 95. Exercice d’application Une personne est caractérisée par son nom, prénom et âge. Les objets de la classe Personne doivent pouvoir calculer leurs revenus et leurs charges. Les attributs de la classe sont privés qui doivent être accessible par des opérations publiques. Donner une représentation UML de la classe Personne
- 97. Associations Les associations représentent les liens unissant les instances des classes Personne Voiture Société 1
- 98. Classe association - Une association peut être transformée en une classe appelée classe associative ou classe association, lorsque elle possède des attributs ou des opérations. Enseignant Classe Cours - durée - début - coutenu + EcrireContenu() Matière 1
- 99. Classe attribuée Une association qui contient des attributs et qui ne participe pas à des relations avec d’autres classe est appelée classe attribuée. Classe A Classe B Classe C Attributs 1
- 100. Nommage des associations • Nom de l’association en italique au milieu de la ligne • On note en général les association par une forme verbale, soit active, soit passive Travaille pour Personn e Sociét é Est la Voiture propriété de Personne 13
- 101. Nommage des rôles 1 Toute association binaire possède 2 rôles : -un rôle définit la manière dont une classe intervient dans une relation -Le nommage des associations et le nommage des rôles ne sont pas exclusifs l’un de l’autre Travaille pour Personne Société employé employeur - Intérêt des rôles dans le cas où plusieurs associations lient deux classes : distinction des concepts attachés aux associations
- 102. Nommage des rôles 1 Exemple : Pilot e Avion Personne passager
- 103. Associations entre classes On peut ajouter du texte afin d’exprimer l’intérêt de cette relation.
- 104. Associations entre classes Association réflexive : Lie une classe avec elle-même
- 105. Associations entre classes Association n-aire (Rarement utilisé) Une association qui lie plus de deux classes (n >=3) Remplacer par :
- 106. Associations reliant plusieurs classes – Classe association Une association peut apporter de nouvelles informations ( attributs et méthodes) qui n’appartiennent à aucune des deux classes
- 107. Multiplicité des associations 1 La multiplicité est une information portée par le rôle, qui indique le nombre d’objets successibles de participe à une association 1..1 Un et un seul 0..1 Zéro ou Un M..N De M à N (entiers naturels) * De zéro à plusieurs 0..* De zéro à plusieurs 1..* De un à plusieurs N Exactement N
- 108. Association particulière: agrégation •L'agrégation est un cas particulier d'association lorsqu'un objet « possède » un autre objet, l'une des extrémités joue un rôle prédominant par rapport à l’autre. Agrégat A Agrégé B - Une classe B « fait partie » intégrante d’une classe A L’agrégation indique qu’un objet A possède un autre objet B , mais contrairement à la composition, l’objet B peut exister indépendamment de l’objet A. La suppression de l’objet A n’entraîne pas la suppression de l’objet B. Elle se représente par un losange vide du coté de l’objet conteneur
- 109. Agrégation : Exemple 2 Catégorie Produit Email Fichier Livre Couverture
- 110. Association particulière : Composition La composition est une forme particulière d’agrégation (agrégation forte). Le composant est « physiquement » contenu dans l’agrégat. La composition indique qu’un objet A (appelé conteneur) est constitué d’un autre objetB. Cet objet A n’appartient qu’a l’objet B et ne peut pas être partagé avec un autre objet C’est une relation très forte, si l’objet A disparaît, alors l’objet B disparaît aussi. Elle se représente par un losange plein du coté de l’objet conteneur 0..1 2 * Objet A Objet B
- 111. Association particulière : Composition 2 Immeuble Appartement Livre Chapitre Exemples de Composition :
- 112. Activité - Un répertoire contient des fichiers - Une pièce contient des murs - Les modems et les claviers sont des périphériques d’entrée/sortie - Une transaction boursière est achat ou une vente Déterminer la relation statique appropriée (généralisation, composition, agrégation ou association) dans chaque phrase. Proposez le diagramme de classe correspondant.
- 113. Généralisation - Spécialisation Définition : relation (irréflexive, antisymétrique, transitive) entre une classe plus générale et une classe plus spécifique (signifie “est un” ou “est une sorte de”). Ce n’est pas une association. Exemple : un animal est un concept plus général qu’un chat ou un chien. Inversement un chien est un concept plus spécialisé qu’un animal. La classe Animal est une généralisation de la classe Chat ou la classe Chien. La classe Chien est une pécialisation de la classe Animal. Animal Chat Souris Chien Spécialisation 2 Généralisation
- 114. Généralisation - Spécialisation L'héritage est l'un des concepts fondamentaux des langages de programmation orientée objet (POO). C’est un qui permet de dériver une classe (classe fille ) d'une autre classe (classe mère) pour créer une hiérarchie de classes qui partagent un ensemble d'attributs et de méthodes .
- 115. Exercice 1 : Class Diagram Un système de transport aérien utilise le diagramme de classes incomplet suivant: -Règles de gestion • Une compagnie emploie plusieurs pilotes et un pilote travail chez une seule compagnie • Un vol correspond à une seule compagnie et assuré • par un seul pilote • Un pilote assure plusieurs vols • Un vol utilise un seul avion et un avion peut assurer plusieurs vols • Un billet est relative à un vol unique et un passager unique • Un billet correspond à un seul siège Proposez un diagramme de classes en ajoutant les multiplicités des associations.
- 116. On souhaite gérer les réservations de vols effectués dans une agence. D’après les interviews réalisées avec les membres de l’agence, on sait que : · Les compagnies aériennes proposent différents vols · Un vol est ouvert à la réservation et refermé sur ordre de la compagnie · Un client peut réserver un ou plusieurs vols, pour des passagers différents · Une réservation concerne un seul vol et un seul passager · Un vol a un aéroport de départ et un aéroport d’arrivée · Un vol a un jour et une heure de départ, et un jour et une heure d’arrivée · Un vol peut comporter des escales dans un ou plusieurs aéroport(s) · Une escale a une heure de départ et une heure d’arrivée · Chaque aéroport dessert une ou plusieurs villes
- 117. Exercice 1 : Class Diagram
- 118. Une académie souhaite gérer les cours dispensés dans plusieurs collèges. Pour cela, on dispose des renseignements suivants : · Chaque collège est structuré en départements, qui regroupe chacun des enseignants spécifiques. Parmi ces enseignants, l’un d’eux est responsable du département. · Un enseignant se définit par son nom, prénom, tél, mail, date de prise de fonction et son indice. · Chaque enseignant ne dispense qu’une seule matière. · Les étudiants étudient plusieurs matières et reçoivent une note pour chacune d’elle. · Pour chaque étudiant, on veut gérer son nom, prénom, tél, mail, ainsi que son année d’entrée au collège. · Une matière peut être enseignée par plusieurs enseignants mais a toujours lieu dans la même salle de cours (chacune ayant un nombre de places déterminé). · On désire pouvoir calculer la moyenne par matière ainsi que par département · On veut également calculer la moyenne générale d’un élève et pouvoir afficher les matières dans lesquelles il n’a pas été noté · Enfin, on doit pouvoir imprimer la fiche (prénom, tél, mail) d’un enseignant ou d’un élève.