• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Uml classes Par les exemples
 

Uml classes Par les exemples

on

  • 24,087 views

Introduction aux diagrammes de classes par des exemples. ...

Introduction aux diagrammes de classes par des exemples.

Ce cours fait suite à des cours passés qui ont introduit les use cases et diagrammes de séquences.

Les étudiants de l'IUT connaissent lors de l'introduction de ce cours déjà le concept d'objet.

Statistics

Views

Total Views
24,087
Views on SlideShare
24,087
Embed Views
0

Actions

Likes
4
Downloads
638
Comments
3

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

13 of 3 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Ok, merci !
    Are you sure you want to
    Your message goes here
    Processing…
  • En effet, la bibliographie a sauté dans cette version des slides, je recharge dans la journée une version qui l'intègre. Je recommande votre livre sur le site du module par ailleurs.
    Are you sure you want to
    Your message goes here
    Processing…
  • Merci de citer la source de votre exemple de réservation de vols : le chapitre 3 du livre UML2 par la pratique, Pascal Roques, Eyrolles, 2001-2009 ...
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • \n
  • Les objets sont représentés par un rectangle, avec leur nom suivi de : puis le nom de leur classe, le tout souligné. Les objets, instances des classes, sont manipulés dans les «collaboration diagramm»\nLes classes d'objets, ou plus simplement classes, possèdent des attributs et des opérations. Les attributs peuvent avoir un type et une valeur par défaut. Les opérations peuvent avoir des paramètres, typés ou non, et une valeur de retour.\n\nDans un souci de clarté des diagrammes, on peut considérer que telle ou telle information n'est pas importante à ce niveau de l'analyse et donc décider de ne pas la faire apparaître.\nPour la même raison, les zones des attributs et des opérations sont optionnelles.\nUne ellipse à la fin d’une liste d’attributs ou d’opérations signifie qu’il existe d’autres éléments dans le modèle, mais qu’ils dépendent de critères de sélection qui ne les font pas apparaître.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Figure 11 shows a sequence diagram that references the sequence diagrams "Balance Lookup" and "Debit Account."\n The sequence starts at the top left, with the customer sending a message to the teller object. The teller object sends a message to the theirBank object. At that point, the Balance Lookup sequence diagram is called, with the accountNumber passed as a parameter. The Balance Lookup sequence diagram returns the balance variable. Then the option combination fragment's guard condition is checked to verify the balance is greater then the amount variable. In cases where the balance is greater than the amount, the Debit Account sequence diagram is called, passing it the accountNumber and the amount as parameters. After that sequence is complete, the withdrawCash message returns cash to the customer.\nIt is important to notice in Figure 11 that the lifeline of theirBank is hidden by the interaction occurrence Balance Lookup. Because the interaction occurrence hides the lifeline, that means that the theirBank lifeline is referenced in the "Balance Lookup" sequence diagram. In addition to hiding the lifeline in the interaction occurrence, UML 2 also specifies that the lifeline must have the same theirBank in its own "Balance Lookup" sequence.\nThere will be times when you model sequence diagrams that an interaction occurrence will overlap lifelines that are not referenced in the interaction occurrence. In such cases the lifeline is shown as a normal lifeline and is not hidden by the overlapping interaction occurrence.\nIn Figure 11, the sequence references the "Balance Lookup" sequence diagram. The "Balance Lookup" sequence diagram is shown in Figure 12. Because the example sequence has parameters and a return value, its label —located in the diagram's namebox—follows a specific pattern:\n\n
  • \n
  • Figure 11 shows a sequence diagram that references the sequence diagrams "Balance Lookup" and "Debit Account."\n The sequence starts at the top left, with the customer sending a message to the teller object. The teller object sends a message to the theirBank object. At that point, the Balance Lookup sequence diagram is called, with the accountNumber passed as a parameter. The Balance Lookup sequence diagram returns the balance variable. Then the option combination fragment's guard condition is checked to verify the balance is greater then the amount variable. In cases where the balance is greater than the amount, the Debit Account sequence diagram is called, passing it the accountNumber and the amount as parameters. After that sequence is complete, the withdrawCash message returns cash to the customer.\nIt is important to notice in Figure 11 that the lifeline of theirBank is hidden by the interaction occurrence Balance Lookup. Because the interaction occurrence hides the lifeline, that means that the theirBank lifeline is referenced in the "Balance Lookup" sequence diagram. In addition to hiding the lifeline in the interaction occurrence, UML 2 also specifies that the lifeline must have the same theirBank in its own "Balance Lookup" sequence.\nThere will be times when you model sequence diagrams that an interaction occurrence will overlap lifelines that are not referenced in the interaction occurrence. In such cases the lifeline is shown as a normal lifeline and is not hidden by the overlapping interaction occurrence.\nIn Figure 11, the sequence references the "Balance Lookup" sequence diagram. The "Balance Lookup" sequence diagram is shown in Figure 12. Because the example sequence has parameters and a return value, its label —located in the diagram's namebox—follows a specific pattern:\n\n
  • Les objets sont représentés par des barres verticales au dessus desquelles figure l’objet et sa classe d’appartenance (même formalisme que dans les diagrammes d’objets). Le nom de la classe ou de l’objet peut être omis.\nLes messages entre objets sont représentés par des flêches partant d’un objet et arrivant à un autre objet.\n
  • Figure 11 shows a sequence diagram that references the sequence diagrams "Balance Lookup" and "Debit Account."\n The sequence starts at the top left, with the customer sending a message to the teller object. The teller object sends a message to the theirBank object. At that point, the Balance Lookup sequence diagram is called, with the accountNumber passed as a parameter. The Balance Lookup sequence diagram returns the balance variable. Then the option combination fragment's guard condition is checked to verify the balance is greater then the amount variable. In cases where the balance is greater than the amount, the Debit Account sequence diagram is called, passing it the accountNumber and the amount as parameters. After that sequence is complete, the withdrawCash message returns cash to the customer.\nIt is important to notice in Figure 11 that the lifeline of theirBank is hidden by the interaction occurrence Balance Lookup. Because the interaction occurrence hides the lifeline, that means that the theirBank lifeline is referenced in the "Balance Lookup" sequence diagram. In addition to hiding the lifeline in the interaction occurrence, UML 2 also specifies that the lifeline must have the same theirBank in its own "Balance Lookup" sequence.\nThere will be times when you model sequence diagrams that an interaction occurrence will overlap lifelines that are not referenced in the interaction occurrence. In such cases the lifeline is shown as a normal lifeline and is not hidden by the overlapping interaction occurrence.\nIn Figure 11, the sequence references the "Balance Lookup" sequence diagram. The "Balance Lookup" sequence diagram is shown in Figure 12. Because the example sequence has parameters and a return value, its label —located in the diagram's namebox—follows a specific pattern:\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • La cardinalité joue un rôle essentiel dans la sémantique de l'relation.\nLa sémantique de l'relation change totalement si la cardinalité évolue.\n
  • \n
  • Navigation means that one object contains a pointer or a reference to the other so that it may invoke the services of the latter\n le nombre d'instances de la classe qui participent à l'association.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Dans ce cas, les rôles sont très importants pour préciser la signification de l'relation.\nDans l'exemple, un HUMAIN peut être à la fois Parent et Enfant.\nUne relation réflexive n’est pas obligatoirement orientée dans les deux sens.\n
  • Une relation de type agrégation a pour objectif d’exprimer qu’un ensemble d’objets fait partie intégrante d’un autre objet. Une agrégation renforce ainsi la sémantique de la notion d’relation.\nLes agrégations peuvent êtres de 2 types : simple ou de composition\nl’agrégation exprime une composition faible, alors que la composition exprime une composition forte. \nComposition : la destruction d’un dossier entraîne la destruction de tous les documents contenus dans le dossier, de même la destruction d’une ville déclenche la destruction de tous les immeubles de la ville. \nAgrégation : même si une équipe de basket est dissoute, les joueurs de cette équipe sont toujours licenciés auprès de la fédération et existent en tant que tels. Il ne s’agit donc pas d’une composition.\n
  • Indicated by a hollow diamond \n Whole-part relationship denotes one object logically or physically contains or has another \n Weaker form of aggregation. Nothing is implied about:\n Navigation\n Ownership\n Lifetimes of participating objects\n
  • \n
  • Composition is a strong form of aggregation in which the owner is explicitly responsible for the creation and destruction of the part objects. \nWe prefer the containent notation because it is more visually distinct.\n\n\n\n \nUne agrégation peut notamment (mais pas nécessairement) exprimer :\n qu'une classe (un "élément") fait partie d'une autre ("l'agrégat"),\n qu'un changement d'état d'une classe, entraîne un changement d'état d'une autre,\n qu'une action sur une classe, entraîne une action sur une autre. \nA un même moment, une instance d'élément agrégé peut être liée à plusieurs instances d'autres classes (l'élément agrégé peut être partagé). \nUne instance d'élément agrégé peut exister sans agrégat (et inversement) : les cycles de vies de l'agrégat et de ses éléments agrégés peuvent être indépendants.\n\n \n  q  Composition\n\nLa composition est une agrégation forte (agrégation par valeur). \nLes cycles de vies des éléments (les "composants") et de l'agrégat sont liés : si l'agrégat est détruit (ou copié), ses composants le sont aussi. \nA un même moment, une instance de composant ne peut être liée qu'à un seul agrégat. \nLes "objets composites" sont des instances de classes composées.\n\n  q  Agrégation et composition : rappel\n\nL'agrégation et la composition sont des vues subjectives. \nLorsqu'on représente (avec UML) qu'une molécule est "composée" d'atomes, on sous-entend que la destruction d'une instance de la classe "Molécule", implique la destruction de ses composants, instances de la classe "Atome" (cf. propriétés de la composition). \nBien qu'elle ne reflète pas la réalité ("rien ne se perd, rien ne se crée, tout se transforme"), cette abstraction de la réalité nous satisfait si l'objet principal de notre modélisation est la molécule... \nEn conclusion, servez vous de l'agrégation et de la composition pour ajouter de la sémantique à vos modèles lorsque cela est pertinent, même si dans la "réalité" de tels liens n'existent pas !\n \n
  • Composition is a strong form of aggregation in which the owner is explicitly responsible for the creation and destruction of the part objects. \nWe prefer the containent notation because it is more visually distinct.\n\n\n\n \nUne agrégation peut notamment (mais pas nécessairement) exprimer :\n qu'une classe (un "élément") fait partie d'une autre ("l'agrégat"),\n qu'un changement d'état d'une classe, entraîne un changement d'état d'une autre,\n qu'une action sur une classe, entraîne une action sur une autre. \nA un même moment, une instance d'élément agrégé peut être liée à plusieurs instances d'autres classes (l'élément agrégé peut être partagé). \nUne instance d'élément agrégé peut exister sans agrégat (et inversement) : les cycles de vies de l'agrégat et de ses éléments agrégés peuvent être indépendants.\n\n \n  q  Composition\n\nLa composition est une agrégation forte (agrégation par valeur). \nLes cycles de vies des éléments (les "composants") et de l'agrégat sont liés : si l'agrégat est détruit (ou copié), ses composants le sont aussi. \nA un même moment, une instance de composant ne peut être liée qu'à un seul agrégat. \nLes "objets composites" sont des instances de classes composées.\n\n  q  Agrégation et composition : rappel\n\nL'agrégation et la composition sont des vues subjectives. \nLorsqu'on représente (avec UML) qu'une molécule est "composée" d'atomes, on sous-entend que la destruction d'une instance de la classe "Molécule", implique la destruction de ses composants, instances de la classe "Atome" (cf. propriétés de la composition). \nBien qu'elle ne reflète pas la réalité ("rien ne se perd, rien ne se crée, tout se transforme"), cette abstraction de la réalité nous satisfait si l'objet principal de notre modélisation est la molécule... \nEn conclusion, servez vous de l'agrégation et de la composition pour ajouter de la sémantique à vos modèles lorsque cela est pertinent, même si dans la "réalité" de tels liens n'existent pas !\n \n
  • Aggregation is also a kind of association. Aggregation is used when one object logically or physically contains another. \n
  • shared part is also known as "catalog aggregation". Example: library card catalog\na book is under author catalog, subject catalog, title catalog\n\nNote that in the figure we are being very explicit about sharing the parts with the {share} constraint. Without that shared parts are not implied because although they aggregate instances of the same classes, this doesn’t mean that they are the same instances. \n
  • A FAIRE EN S3.... L’ an prochain\n
  • Une relation de type agrégation a pour objectif d’exprimer qu’un ensemble d’objets fait partie intégrante d’un autre objet. Une agrégation renforce ainsi la sémantique de la notion d’relation.\nLes agrégations peuvent êtres de 2 types : simple ou de composition\nl’agrégation exprime une composition faible, alors que la composition exprime une composition forte. \nComposition : la destruction d’un dossier entraîne la destruction de tous les documents contenus dans le dossier, de même la destruction d’une ville déclenche la destruction de tous les immeubles de la ville. \nAgrégation : même si une équipe de basket est dissoute, les joueurs de cette équipe sont toujours licenciés auprès de la fédération et existent en tant que tels. Il ne s’agit donc pas d’une composition.\n
  • Composition is a strong form of aggregation in which the owner is explicitly responsible for the creation and destruction of the part objects. We prefer the containent notation because it is more visually distinct.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Most often, subclasses are extended and specialized at the same time\n
  • La factorisation apportée sur la généralisation apparaît graphiquement pour les relations. Imaginons le nombre de relations qui devraient être représentées sans généralisation.\nLes Voitures et les Camions ont tous un ou deux moteurs.\nUn répertoire peut contenir des drivers, des fichiers sources ou des fichiers binaires.\n
  • Composition is a strong form of aggregation in which the owner is explicitly responsible for the creation and destruction of the part objects. We prefer the containent notation because it is more visually distinct.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • La généralisation peut-être simple ou multiple, la généralisation simple signifie qu'une classe hérite d'une seule super-classe alors que dans la généralisation multiple une classe peut hériter de plusieurs super-classes (au moins deux).\n
  • \n
  • \n
  • Les attributs, opérations, relations et généralisations ne suffisent pas à définir avec précision l’ensemble des instances possibles.\nOn appelle invariant d’une classe l’ensemble des conditions et des propositions, appelées contraintes en UML, qui doivent être vérifiées durant la vie d’une instance.\nLes conséquences du non respect de ces contraintes sortent du cadre d’UML .\n
  • \n
  • \n
  • \n
  • \n
  • A Qualified association could be implemented as a balanced tree.\n
  • A Qualified association could be implemented as a balanced tree.\n
  • \n
  • \n
  • \n
  • generalization == "is a"\naggregation == "has a"\nassociation == "uses“\n\nUML has lots of different kinds of relationships. These are by far the most important.\n
  • \n
  • \n
  • Permet d'incorporer des données dans une association\nA n'utiliser qu'en analyse\nPose un problème de représentation pour la conception\n
  • \n
  • Il s'agit d'une configuration déconseillée sur le plan de l'implantation. Généralement, il vient d'un problème mal analysé et conçu\n
  • \nToute relation N-aire peut être transformée en relation binaire, par application de règles systématiques illustrées ici.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • p86 de UML 2 par la pratique\n
  • p86 de UML 2 par la pratique\n
  • \n

Uml classes Par les exemples Uml classes Par les exemples Presentation Transcript

  • Analyse et Conception avec UML Les diagrammes de classes blay@unice.fr www.polytech.unice.fr/~blay IUT Nice-Sophia Antipolis février 2011 Site web du module : http://anubis.polytech.unice.fr/iut/ 1
  • Intro par l’exemple Relations Application Modélisation structurelle Les classes et les objets modélisent les objets matériels ou immatériels qui existent dans le système que l’on essaie de décrire Les relations entre les classes et les objets établissent les connexions entre les divers éléments de modélisation et montrent lagencement architectural Le diagramme de classes et le diagramme d’objets sont les pièces maîtresses de la vue structurale – Dans UML, ils sont répertoriés comme des diagrammes montrant la structure "statique" – Le diagramme d’objets est un exemple du diagramme de classes – Le diagramme d’objets donne une photographie du système dans le temps02/11 2
  • Intro par l’exemple Relations Application Classes  Une classe est une collection (modèle) d’objets avec une structure commune, un comportement commun, des relations identiques et une sémantique identique  On identifie les classes en examinant les objets dans les diagrammes  La représentation graphique d’une classe consiste en un rectangle avec 3 compartiments  Les noms des classes devraient être choisis dans le vocabulaire du domaine – il est bon d’établir des standards pour les nom – i.e., toutes les classes sont des noms communs commençant par une majuscule02/11 3
  • Intro par l’exemple Relations Application Notations UML pour classes et objets02/11 4
  • Concepts du domaine m ple r l’ exe Pa 5
  • Intro par l’exemple Relations Application Détermination des concepts du domaine02/11
  • Intro par l’exemple Relations Application Détermination des concepts du domaine La détermination des concepts s’effectue sur la base des cas d’utilisation par simple analyse grammaticale de la description textuelle. Dune manière générale,02/11
  • Intro par l’exemple Relations Application Détermination des concepts du domaine La détermination des concepts s’effectue sur la base des cas d’utilisation par simple analyse grammaticale de la description textuelle. Dune manière générale, les noms représentent des concepts ou des attributs tandis02/11
  • Intro par l’exemple Relations Application Détermination des concepts du domaine La détermination des concepts s’effectue sur la base des cas d’utilisation par simple analyse grammaticale de la description textuelle. Dune manière générale, les noms représentent des concepts ou des attributs tandis que les verbes représentent des comportements (opérations, méthodes)02/11
  • Intro. Intro. UML De Merise à UML Deux règles utiles  Règle du cartographe : Le modèle conceptuel se construit de la même façon qu’un cartographe dessine une carte :  En utilisant le vocabulaire du domaine étudié.  En excluant les éléments non pertinents.  En n’incluant pas d’éléments inexistants dans le domaine.  Choix entre concept et attribut : Si un élément du domaine étudié est autre chose qu’un nombre ou un simple texte, alors il s’agit probablement d’un concept et non d’un attribut.09/1 0
  • Intro par l’exemple Relations Application Une galerie d’art(1) Nous voulons informatiser une galerie dart, par laquelle noussouhaitons vendre des oeuvres darts à des clients. Les paiementsdoivent être sécurisés en utilisant le système de paiement externe“chaimoinscheir”.(2) Les oeuvres et les artistes sont gérés par les administrateurs via desinterfaces adaptées.(3) Un internaute doit pouvoir sinscrire sur le site pour devenir client.(4) Un internaute peut naviguer sur le site, retrouver un artiste parson nom, visualiser les oeuvres par catégorie.(5) Les clients peuvent voter pour les oeuvres ou les artistes quilspréfèrent.(6) Une fois par jour, un super-administrateur déclenche uneopération de sauvegarde de la galerie.(7) Lidentification des clients fait partie du système de la galerie. 8 /82
  • Intro par l’exemple Relations Application Une galerie d’art 9 /82
  • Diagramme de séquence - Représentez le diagramme de séquence Système correspondant au cas dutilisation Un internaute sinscrit sur le site pour devenir client de la galerie dart1) Linternaute saisit son nom, son prénom, son adresseemail;2) Le système valide ces informations (bien construites);3) Le système enregistre le nouveau client;4) Le système signale au client que tout sest bien passé. 10
  • Intro par l’exemple Relations Application Une galerie d’art 11 /82
  • Diagramme de séquence- Représentez le diagramme de séquence Système correspondant au cas dutilisation Acheter des oeuvres d’art1) Le système propose les oeuvres d’art.2) Le client sélectionne des oeuvres d’art.3) Chaque oeuvre est placée dans le panier par le système3) Le client demande à acheter.4) Le contenu du panier est réservé dans les stocks.5) Le système demande au système de paiement l’encaissementdu panier.6) Le système de paiement valide le paiement et retourne unefacture.7) Le système enregistre le retrait du stock.8) Le système confirme l’achat au client 12
  • Intro par l’exemple Relations Application Des Diagramme de Séquence aux classes Classe Relations? Classe Classe02/11 13
  • Diagramme de séquence 14
  • Intro par l’exemple Relations Application Une galerie d’art 15 /82
  • Intro par l’exemple Relations Application Une galerie d’art (compléments)Sur un artiste nous disposons actuellement des informations suivantes : ■ Date de naissance de l’artiste ■ Nom, prénom, email ■ Son âge ■ Une photo de l’artiste ■ La liste de ses oeuvres en précisant les oeuvres à la vente ou non.Pour chaque « œuvre» nous avons les informations suivantes : ■ l’artiste auquel appartient l’oeuvre ■ Type de l’œuvre (peinture ou sculpture) ■ Texte de description ■ 1 à 3 photos en petit format (150×150 max) par œuvre et leur titre ; ■ Une oeuvre se retrouve dans la galerie à partir dun identifiant donné à loeuvre qui correspond en général à son titre ■ Un artiste de retrouve dans la galerie à partir de son nom dartiste qui est unique. 16 /82
  • Intro par l’exemple Relations Application Une galerie d’art 17 /82
  • Intro par l’exemple Relations Application Une galerie d’art 18 /82
  • Relations entre classes es nd atio s icit tion pl ta «Relations»,Ex no associations, agrégation, généralisation, compléments 19
  • Intro par l’exemple Relations Application Relations Les relations fournissent un chemin de communication entre objets Les diagrammes de séquence sont parcourus pour déterminer quels liens doivent exister pour obtenir le comportement souhaité – si deux objets ont besoin de se parler, il doit exister un lien entre eux Trois types de relations : Association Agrégation Dépendance Une contrainte : Une relation est un lien stable entre deux objets02/11 20
  • Intro par l’exemple Relations Application Relations02/11 21
  • Intro par l’exemple Relations Application Multiplicité : exemple possède 1..* 0..* Voiture Personne gouverne 1 1 Président Pays Nœud * * Un réseau informatique est composé de nœuds inter-connectés Association réflexive02/11 22
  • Intro par l’exemple Relations Application Multiplicité La multiplicité est définie par le nombre d’objets qui participent à une relation La multiplicité est le nombre d’instances d’une classe reliées à UNE instance d’une autre classe Pour chaque association et agrégation, il y a deux multiplicités : une à chaque bout de la relation 1 Classe Exactement une * Classe Plusieurs (0 à n) 0,1 Classe Optionnelle (0 ou 1) 1,2,4 Classe Cardinalité spécifiée 1-1002/11 Classe 23 Intervalle
  • Intro par l’exemple Relations Application Relations  Une association est une connexion bi-directionnelle entre classes – Une association est représentée par une ligne connectant les classes  Une agrégation est une relation plus forte et s’établit entre un tout et ses parties – Une agrégation est représentée par une ligne connectant les classes avec un losange du côté de la classe représentant le tout  Une dépendance est une relation faible établie entre un client et un fournisseur et où le client n’a pas de connaissance sémantique sur le fournisseur – Une dépendance est représentée par une flèche en pointillés allant du client au fournisseur02/11 24
  • Intro par l’exemple Relations Association Application Associations Les associations peuvent indiquer la navigation avec une pointe de flèche ouverte: Pas de flèche => bidirectionnelle La plupart des associations sont unidirectionnelles en fin de conception. Les associations peuvent avoir des étiquettes: Il sagit du nom de lassociation. Les associations peuvent avoir des noms de rôle: un nom de rôle identifie le rôle ou la responsabilité de lobjet dans lassociation. Les associations peuvent indiquer une multiplicité.02/11 25
  • Intro par l’exempleDiagramme de Classes- Relations Relations Association Application Navigation Bien que les associations soit bi-directionnelles par défaut, il peut être bon de limiter la navigation à un seul sens Les objets de Classe2 sont accessibles à partir de ceux de Classe1 et vice-versa Classe1 Classe2 Si la navigation est restreinte, une flèche indique le sens de navigation Les objets de la Classe 1 sont accessibles à la classe 2 Classe1 Classe202/11 26
  • Intro par l’exemple Relations Association Application Nommage des associations• Une association peut être nommée afin de faciliter la compréhension des modèles. Dans ce cas le nom est indiqué au milieu du lien symbolisant l’association nom A B• L’usage recommande de choisir comme nom d’une association une forme verbale active (exemple : travaille pour) ou passive (exemple : est employé par) travaille pour Personne Société est employé par Personne Société02/11 27
  • Intro par l’exemple Relations Association Application Rôles des extrémités d’association On peut attribuer à une extrémité d’une association un nom appelé rôle qui décrit comment une classe source voit une classe destination au travers de l’association Le rôle est placé près de la fin de l’association et à côté de la classe à laquelle il est appliqué L’utilisation des rôles est optionnelle Représentation et exemple A B rôle de B employeur Emploie> Société Personne employé02/11 28
  • Intro par l’exemple Relations Association Application Nommage des associations… Par défaut le sens de lecture du nom d’une association est de gauche à droite Dans le cas où la lecture du nom est ambiguë, on peut ajouter l’un des signes < ou > pour indiquer le sens de lecture • Exemples < travaille pour Société Personne Personne 1 * < est père de02/11 29
  • Intro par l’exemple Relations Association Application Cas particuliers de relations  Relations réflexives encadre chef 1 Personne sous-fifre 1..* Une relation réflexive lie des objets de même classe02/11 30
  • Intro par l’exemple Relations Agrégation Application Composition et Agrégation  Cas particuliers de relations : – Notion de tout et parties 1 transporte passager Voiture Personne moyen_de_transport * 1 1 Composition roulement > Roue 4,6 structure > 1 Agrégation Chassis02/11 31
  • Intro par l’exemple Relations Agrégation Application Agrégation L’agrégation représente une association de type ensemble/élément L’agrégation ne concerne qu’un seul rôle d’une association Représentation L’agrégation permet de modéliser une contrainte d’intégrité et de désigner l’agrégat comme gérant de cette contrainte02/11 32
  • Intro par l’exemple Relations Agrégation Application Agrégation… Exemple 1 – Une personne est dans une foule – Une foule contient plusieurs personnes * Personne Foule Contient > Exemple 2 (Agrégation partagée) – Une personne fait partie de plusieurs équipes – Une équipe contient plusieurs personnes * * Personne Équipe < membre02/11 33
  • Intro par l’exemple Relations Agrégation Application Composition Cycle de vie dépendant : la destruction du système de cours => la destruction des cours 1 seul! Les composants ne peuvent pas être partagés Attention un Point de vue02/11 34
  • Intro par l’exemple Relations Agrégation Application Composition La composition est une agrégation forte (agrégation par valeur). Les cycles de vies des éléments (les "composants") et de lagrégat sont liés : si lagrégat est détruit (ou copié), ses composants le sont aussi. A un même moment, une instance de composant ne peut être liée quà un seul agrégat. Les "objets composites" sont des instances de classes composées.02/11 35
  • Intro par l’exemple Relations Généralisation Application Généralisation C’est une relation de classification entre un élément général et un élément plus spécifique L’élément le plus spécifique est cohérent avec l’élément le plus général et contient plus d’informations Exemple Véhicule Voiture Bus Camion02/11 36
  • Intro par l’exemple Relations Généralisation Application Généralisation Extension par l’ajout d’attributs et d’opérations02/11 37
  • Intro par l’exemple Relations Application Héritage des relations  Les relations sont héritées par les sous classes : VEHICULE motorisation MOTEUR 1..2 VOITURE CAMION lien logique REPERTOIRE FICHIER 1..* * DRIVER FICHIER_TEXTE FICHIER_BINAIRE02/11 38
  • Intro par l’exemple Relations Raffinements Application Association ordonnée Contraintes sur les associations pour exprimer que les objets sont ordonnés (selon la clé, le nom, la date, etc.) Cette contrainte est spécifiée par le stéréotype {Ordonné} du côté de la classe dont les instances sont ordonnés Entreprise 0..* 0..* Produits {Ordonné} Le modèle ne spécifie pas comment les objets sont ordonnés Pour décrire comment les objets sont ordonnés on utilise un commentaire en employant la notation graphique suivante : Ordonné par ...02/11 39
  • Intro par l’exemple Relations Raffinements Application Association « ou-exclusif » Contrat * d’assurance Un contrat d’assurance concerne une entreprise ou une personne mais pas * {XOR} les deux en même temps 1 1 Personne Entreprise02/11 40
  • Intro par l’exemple Relations Raffinements Application Association « sous-ensemble » C’est une contrainte qui indique qu’une collection est incluse dans une autre collection La contrainte est placée à proximité d’une relation de dépendance entre deux associations La flèche de la relation de dépendance indique le sens de la contrainte Exemple 1..* Membre de > 1 Politicien {Sous-ensemble} Partie politique 1 Chef de > 102/11 41
  • Intro par l’exemple Relations Raffinements Application Association Qualifiée Utilisée avec une relation de multiplicité *. Permet de trier la relation en fonction des valeurs d’un attribut. Qualifier02/11 42
  • Intro par l’exemple Relations Raffinements Application Association Qualifiée02/11 43
  • Intro par l’exemple Relations Raffinements Application Classe d’association Il est possible de représenter une association par une classe pour ajouter par exemple des attributs ou des opérations dans l ’association La classe attachée à l’association est appelée une classe d’association ou classe associative La classe d’association possède à la fois les caractéristiques d’une association et celle d’une classe et peut, à ce titre, participer à d’autres relations dans le modèle La classe d’association est attachée à l’association avec une ligne en pointillée02/11 44
  • Intro par l’exemple Relations Application Classe d’association : exemple Une classe d’association est utilisée quand une information semble appartenir aux deux objets ou à aucun objet 1..* Inscrit à > 0..* Étudiant Cours Évaluation02/11 45
  • Application Système de réservation de volApprofondissement Par l’exemple
  • Interview des experts métier1. Des compagnies aériennes proposent différents vols.2. Un vol est ouvert à la réservation et refermé sur ordre de la compagnie.3. Un client peut réserver un ou plusieurs vols, pour des passagers différents.4. Une réservation concerne un seul vol et un seul passager.5. Une réservation peut être annulée ou confirmée.6. Un vol a un aéroport de départ et un aéroport darrivée.7. Un vol a un jour et une heure de départ, et un jour et une heure darrivée.8. Un vol peut comporter des escales dans des aéroports.9. Une escale a une heure darrivée et une heure de départ.10. Chaque aéroport dessert une ou plusieurs villes.
  • Interview des experts métier1. Des compagnies aériennes proposent différents vols.2. Un vol est ouvert à la réservation et refermé sur ordre de la compagnie.3. Un client peut réserver un ou plusieurs vols, pour des passagers différents.4. Une réservation concerne un seul vol et un seul passager.5. Une réservation peut être annulée ou confirmée.6. Un vol a un aéroport de départ et un aéroport darrivée.7. Un vol a un jour et une heure de départ, et un jour et une heure darrivée.8. Un vol peut comporter des escales dans des aéroports.9. Une escale a une heure darrivée et une heure de départ.10. Chaque aéroport dessert une ou plusieurs villes.
  • Étape 1 - Modélisation des phrase 1 et 21. Des compagnies aériennes proposent différents vols.
  • Étape 1 - Modélisation des phrase 1 et 21. Des compagnies aériennes proposent différents vols. 2 concepts importants 1 association du monde réel CompagnieAerienne et Vol Ils ont des propriétés et des comportements. Ce sont donc des classes candidates pour notre modélisation statique. ?La phrase ne donne pas d’indication sur la multiplicité coté CompagnieAerienne.Il faudra poser la question à l’expert métier!
  • Nous partirons du principe quun vol est proposé le plus souventpar une seule compagnie aérienne, mais quil peut égalementêtre partagé entre plusieurs affréteurs.2. Un vol est ouvert à la réservation et refermé sur ordre de lacompagnie.
  • Nous partirons du principe quun vol est proposé le plus souventpar une seule compagnie aérienne, mais quil peut égalementêtre partagé entre plusieurs affréteurs.2. Un vol est ouvert à la réservation et refermé sur ordre de lacompagnie.
  • Étape 2 - Modélisation des phrase 6, 7 et 87. Un vol a un jour et une heure de départ, et un jour et une heuredarrivée.
  • Étape 2 - Modélisation des phrase 6, 7 et 87. Un vol a un jour et une heure de départ, et un jour et une heuredarrivée. Java.util.Date Objet ou attribut? Un objet est un élément plus « important » quun attribut. • si lon ne peut demander à un élément que sa valeur - attribut • si plusieurs questions sy appliquent - objet (qui possède lui-même plusieurs attributs, ainsi que des liens avec dautres objets.)
  • 6. Un vol a un aéroport de départ et un aéroport darrivée.
  • 6. Un vol a un aéroport de départ et un aéroport darrivée.Contrairement aux notions dheure et de date qui sont des types«simples », la notion daéroport est complexe; elle fait partie du«métier». Un aéroport ne possède pas seulement un nom, il aaussi une capacité, dessert des villes, …etc... Cest la raison pourlaquelle nous préférons créer une classe Aéroport plutôt que desimples attributs aeroportDepart et aeroportArrivee dans laclasse Vol.
  • Modélisation de la phrase 10.10. Chaque aéroport dessert une ou plusieurs villes.
  • Modélisation de la phrase 10.10. Chaque aéroport dessert une ou plusieurs villes. ? Si « desservir » consiste simplement 1 à désigner le moyen de transport par les airs le plus proche, toute ville est toujours desservie par un et un seul aéroport. Si « desservir » vaut par exemple pour tout moyen de transport 0..* aérien se trouvant à moins de trente kilomètres, alors une ville peut être desservie par 0 ou plusieurs aéroports.
  • Étape 3 - Modélisation des phrases 8 et 98. Un vol peut comporter des escales dans des aéroports.9. Une escale a une heure darrivée et une heure de départ.
  • Étape 3 - Modélisation des phrases 8 et 98. Un vol peut comporter des escales dans des aéroports.9. Une escale a une heure darrivée et une heure de départ. • Chaque escale a deux propriétés : heure darrivée et heure de départ. • Elle est en relation avec des vols et des aéroports, qui sont eux-mêmes des objets (phrase 8). Il est donc naturel den faire une classe à son tour.
  • ? ? ? ? ?La phrase 8 est imprécise : une escale peut-elle appartenir à plusieurs vols,et quelles sont les multiplicités entre Escale et Aéroport ?De plus, le schéma nindique toujours pas les multiplicités du côté Vol avecAéroport
  • Pour finaliser le diagramme des phrases 8 et 9, il nous suffit dajouter deux précisions :• lassociation entre Vol et Escale est une agrégation (pas une composition, puisquelle est partageable) ;• les escales sont ordonnées par rapport au vol.
  • Classe dassociationOn peut considérer plutôt cette notion descale comme un troisième rôlejoué par un aéroport par rapport à un vol ? Les attributs heureArrivee etheureDepart deviennent alors des attributs dassociation. La classe Escale disparaît alors en tant que telle, et se trouve remplacéepar une classe dassociation InfosEscale.
  • Étape 4 - Modélisation des phrases 3, 4 et 53. Un client peut réserver un ou plusieurs vols, pour des passagers différents.4. Une réservation concerne un seul vol et un seul passager.5. Une réservation peut être annulée ou confirmée.
  • Étape 4 - Modélisation des phrases 3, 4 et 53. Un client peut réserver un ou plusieurs vols, pour des passagers différents.4. Une réservation concerne un seul vol et un seul passager.5. Une réservation peut être annulée ou confirmée.
  • Modélisation alternative des phrases 3, 4 et 53. Un client peut réserver un ou plusieurs vols, pour des passagers différents.4. Une réservation concerne un seul vol et un seul passager.5. Une réservation peut être annulée ou confirmée.
  • Modélisation alternative des phrases 3, 4 et 53. Un client peut réserver un ou plusieurs vols, pour des passagers différents.4. Une réservation concerne un seul vol et un seul passager.5. Une réservation peut être annulée ou confirmée.
  • Modélisation statique
  • Intro par l’exemple Relations Application Conseils pratiques  Réfléchir au problème avant de commencer Soigner le nommage, insister sur le nommage des relations et des rôles Les noms des attributs débutent par une minuscule Les noms des classes débutent par une majuscule et peuvent contenir plusieurs mots concaténés commençant par une majuscule02/11 61
  • Intro par l’exemple Relations Application Conseils pratiques  Réfléchir au problème avant de commencer Soigner le nommage, insister sur le nommage des relations et des rôles  Faire simple! – «Things must be as simple as possible, but no simpler». A. Einstein – éviter toute complication nuisible se dégager de l’implémentation : raisonner objets, classes, messages, relations, attributs, opérations – ne pas s’inquiéter si les possibilités de la notation ne sont pas toutes exploitées02/11 62
  • Intro par l’exemple Relations Application Conseils pratiques (suite)  Approche incrémentale – Itérer – Savoir sarrêter avant d’atteindre la perfection... • prise en compte qualité (niveau de précision), coûts, délais... • asservissement au processus de développement  Faire simple (encore) – Un bon modèle n’est pas un modèle où l’on ne peut plus rien ajouter, mais un modèle où on ne peut plus rien enlever.02/11 (d’après A. de St-Exupéry) 63