Chapitre 3 Les diagrammes de classes

Présentation au sujet: "Chapitre 3 Les diagrammes de classes"— Transcription de la présentation:

1 Chapitre 3 Les diagrammes de classes
Conception Objet Chapitre 3 Les diagrammes de classes

2 Présentation générale
Point central du développement objet Décrit la structure d’un système Lors de l’analyse et conception Comprendre les objets manipulés Exprimer la manière de satisfaire leur rôle Commence quand les exigences sont arrivées à maturité On continue en // la modélisation des interactions Un diagramme de classes est une collection d'éléments de modélisation statiques (classes, paquetages...), qui montre la structure d'un modèle.   Un diagramme de classes fait abstraction des aspects dynamiques et temporels.   Pour un modèle complexe, plusieurs diagrammes de classes complémentaires doivent être construits. On peut par exemple se focaliser sur : les classes qui participent à un cas d'utilisation (cf. collaboration), les classes associées dans la réalisation d'un scénario précis, les classes qui composent un paquetage, la structure hiérarchique d'un ensemble de classes. Pour représenter un contexte précis, un diagramme de classes peut être instancié en diagrammes d'objets

3 Définitions Classe Objet Un objet est une instance d’une classe
Description abstraite d’un ensemble d’objets aux mêmes caractéristiques (Voiture, Personne) Rectangle compartimenté Objet Entité possédant une identité et encapsulant un état et un comportement (MaTwingo, Dupont) Un objet est une instance d’une classe

4 Définitions Attribut Opération Association
Type d’information contenue dans une classe (couleur, cylindrée, etc) Opération Ce qu’une classe peut faire Spécification d’un service offert par la classe Association Relation sémantique durable entre 2 classes (Personne possède Voiture)

5 Modèle graphique Graphisme général Possède Personne Voiture 1 0..*
IdPersonne Nom Prénom Date de Naissance Immatriculation Marque Modèle Date d’immatriculation

6 Modèle graphique Graphisme classe

7 Modèle graphique

8 Attribut et opération attribut opération
Syntaxe : Visi nom [mult ordre] : type = valinit opération Syntaxe : Visi nom (listePar) : typeRetour Constructeur : opération qui crée un objet Destructeur : opération qui détruit un objet Visi : + publique (accessible hors classe), - privée (accessible que classe), # protégée (accessible depuis les classes qui spécialisent cette classe) Nom : respect règles nommage Mult : nombre de valeurs que peut contenir l’attribut ex [1..*] [1..5] Ordre : par défaut non trié sinon mettre trié Type : booléen, entier, réel, chaîne Valinit : valeur à la création de l’objet ListePar : genre (in out ou inout) nom : type = val-def

9 Visibilité + Attribut public # Attribut protégé - Attribut privé
+ Opération publique() # Opération protégée - Opération privée

10 Relations Relations entre classes Relation de dépendance
Bidirectionnelle ou Unidirectionnelle Relation d’utilisation Correspond à l’envoi d’un message paramétré d’un objet à un autre Les classes ne valent que par les relations qu'elles tissent entre elles. Cette phase est décisive dans l'élaboration du diagramme de classes. Mais c'est à partir des interactions entre les objets que doivent se dessiner les relations entre classes Relation de dépendance.          C'est la relation la moins contraignante entre les classes. Elle est unidirectionnelle et définie une relation d'utilisation.          Dans une collaboration d'objets, cela correspond à l'envoi de message paramétré par un objet d'une autre classe.

11 Relations Une relation porte un nom
Peut être accompagnée d’un sens de lecture Peut être amenée à spécifier le rôle que joue chaque classe (à côté de la classe qui joue le rôle) Peut porter des cardinalités (1, 1..*, 2..5); Lecture inverse des MCD Peut être n-aire (relier plus de 2 classes)        Dans une association, on peut en général naviguer d'une classe à l'autre. Il est parfois nécessaire à certaines étapes de la conception (implémentation) d'indiquer que la navigabilité n'est plus bidirectionnelle. Le parcours de l'association privilégie un sens particulier de navigation. Par exemple dans une gestion de prêts de livre, on peut concevoir que la bibliothèque connaisse ses livres, mais il ne semble pas nécessaire à chaque livre de connaître la bibliothèque. Nous pouvons interpréter ce choix par une navigabilité restreinte. Navigabilité restreinte : de la bibliothèque vers les livres. Remarques : La navigation relève de choix de conception plus que d'analyse. Un modèle d'analyse ne précise pas en général cette notion. La navigabilité restreinte se traduit très souvent par l'absence de référence dans la classe où la navigabilité est restreinte. Par exemple, un objet de la classe Livre ne contiendra pas de référence à un objet de la classe Bibliothèque.

12 Exemples de relations

13 Multiplicité d’associations
Multiplicité des associations (cardinalités) 1 Un et un seul 0..1 Zéro ou un M..N De M à N (entiers) * De zéro à plusieurs 0..* 1..* De un à plusieurs

14 Classes associatives Pour associer des attributs et/ou des méthodes aux associations => classes associatives Les classes associatives sont des associations mais aussi des classes. Elles ont donc les mêmes propriétés et peuvent par exemple être liées par des associations.

15 Exemple de classe associative
Revue « pour savoir » semaine « 52 » au point de vente « Wimille » vendu à 15 exemplaires Revue « pour savoir » semaine « 51 » au point de vente « Wimille » vendu à 12 exemplaires Revue « Géo » semaine « 52 » au point de vente « Wimille » vendu à 30 exemplaires…

16 Exemple de classe associative
employé employeur Personne Société 1 0..2 Emploi salaire augmenter ()

17 Exemple de classe associative
employé employeur Personne Société 1 0..2 Emploi salaire Fichedepaie 1..* 1 augmenter ()

18 Agrégation Agrégation
Cas d’association particulière non symétrique. Exprime une relation de contenance (contient). Pas de concensus sur la signification exacte de l'aggrégation Utiliser avec précautions (ou ne pas utiliser...) Une relation exprime une forme de couplage entre abstractions. La force de ce couplage dépend de la nature de la relation dans le domaine du problème. Par défaut, l’association représente un couplage faible, les classes associées restant relativement indépendantes l’une de l’autre. L’agrégation est une forme particulière d’association qui exprime un couplage plus fort entre classes. Une des classes joue un rôle plus important que l’autre dans la relation. L’agrégation permet de représenter des relations de type maître et esclaves, tout et parties ou composés et composants. Agrégat Elément 1..* 0..*

19

20 Composition Agrégation plus forte. Composition tout ou partie
Contraintes liées à la composition : 1. Un objet composant ne peut être que dans 1 seul objet composite 2. Un objet composant n’existe pas sans son objet composite 3. Si un objet composite est détruit, ses composants aussi On peut emboîter les classes pour une composition (classes et associations incluses dans la classe) La composition est une forme d’agrégation avec un couplage plus important. Ce couplage de composition indique que les composants ne sont pas partageables et que la destruction de l’agrégat entraîne la destruction des composants agrégés. La valeur maximale de multiplicité du côté du conteneur ne doit pas excéder 1 puisque les objets, instances de la classe des composants, doivent tous appartenir au même objet conteneur. Une agrégation se fait par référence du ou des « enfant(s) » dans le contexte du « parent » By reference Une composition se fait par valeur, c’est-à-dire copie du ou des « enfant(s) » dans le contexte du « parent » By value Composite Elément 1 0..*

21 Exemple de composition

22 Plusieurs modélisation de la composition
Différentes manière de représenter la composition

23 Exemple de composition

24 Qualifieur Un qualifieur est un attribut ou un ensemble d'attributs dont la valeur sert à déterminer l'ensemble des instances associées à une instance via une association. Les attributs du qualifieur sont des attributs de l'association.

25 Exemple de qualifieur

26 Exemples de qualifieur

27 Exemples de qualifieur

28 Résumé du diagramme de classes

29 Premiers exercices Photocopie TD1

30 Interfaces Peut contenir des opérations, pas d’attributs, pas d’associations ni de méthodes Définit un service ou un contrat Collection d’opérations publiques Lors analyse et conception : identifier les services qu’offrent les classes et leurs objets Une interface est un ensemble d’opérations qui définissent la fonction d’une classe ou d’un composant. Par conséquent, une interface définit le comportement apparent de cet élément. Elle peut représenter totalement ou partiellement le comportement d’une classe ou d’un composant et définit les spécifications des opérations (c’est-à-dire leur signature), mais jamais leur implémentation. Une classe fille ne peut hériter que d’une seule classe: Java n’admet que l’héritage simple, à la différence d’autres langages, comme C++ qui autorisent l’héritage multiple. Les concepteurs du langage Java ont fait ce choix pour éviter la complexité de gestion de l’héritage multiple qui, dans certains cas, peut amener une classe à hériter plusieurs fois d’une même superclasse. Comme Smalltalk, Java n’admet que l’héritage simple. Cependant , pour répondre à certaines situations, Java admet une forme d’héritage multiple avec des classes très particulières, que l’on appelle des interfaces. Une classe abstraite • ne peut pas être instanciée • utile pour définir un comportement abstrait • peut contenir des méthodes abstraites Un méthode abstraite • doit être définie dans une sous classe • est dans un classe abstraite IGestionnaireProjet

31 Généralisation et spécialisation
Classe plus générale reliée à 1 ou plusieurs autres classes spécialisées (sous-classes) par généralisation. Les sous-classes héritent des propriétés des super-classes et peuvent comporter des propriétés spécifiques. Exemples : Voiture, Bateau, Avions sont des Moyens de transport (Marque, Modèle, Vitesse) Bateau est le seul à avoir un tirant d’eau Les hiérarchies de classes ou classifications permettent de gérer la complexité en ordonnant les objets au sein d’arborescences de classes d’abstraction croissante. [KETT-98] La généralisation: il s’agit de prendre des classes existantes (déjà mises en évidence) et de créer de nouvelles classes qui regroupent leurs parties communes; il faut aller du plus spécifique vers le plus général. [KETT-98] La spécialisation: il s’agit de sélectionner des classes existantes (déjà identifiées) et d’en dériver de nouvelles classes plus spécialisées, en spécifiant simplement les différences La généralisation consiste à factoriser les éléments communs d’un ensemble de classes dans une classe plus générale appelée super-classe. Les classes sont ordonnées selon une hiérarchie; une super-classe est une abstraction de ses sous-classes. La généralisation est une démarche assez difficile car elle demande une bonne capacité d’abstraction. La mise au point d’une hiérarchie est délicate et itérative. Les arbres de classes ne poussent pas à partir de leur racine. Au contraire, ils se déterminent en partant des feuilles car les feuilles appartiennent au monde réel alors que les niveaux supérieurs sont des abstractions construites pour ordonner et comprendre. La généralisation ne porte ni nom particulier ni valeur de multiplicité. La généralisation est une relation non réflexive: une classe ne peut pas dériver d’elle-même. La généralisation est une relation non symétrique: si une classe B dérive d’une classe A, alors la classe A ne peut pas dériver de la classe B. La généralisation est par contre une relation transitive: si C dérive d’une classe B qui dérive elle-même d’une classe A, alors C dérive également de A.

32 Exemple de généralisation
En Italique : classe abstraite

33 Exemple de généralisation

34 Classe abstraite Classe qui ne s’instancie pas directement
Représente une pure abstraction afin de factoriser des propriétés communes Exemple : Moyen de transport (noté en italique)

35 Réalisation La source prend en charge les opérations de l’élément cible

36 Exemple de réalisation

37 Dépendance La source utilise la cible
Si la cible change, la source risque d’être affectée

38 Exemple de dépendance

39 Exercices Photocopie TD2

40 Réaliser un diagramme de classes
Comment identifier les classes ? Entités autonomes reliées entre elles par des relations Autonomie essentielle pour réutilisabilité Technique ascendante permet d’utiliser les composants existants

41 Réaliser un diagramme de classes
Les principes de la conception reposent sur quatre principes essentiels : réification ou comment faire un objet de quelque chose. L'autonomie et la localité, ou comment penser dans les propres termes de l'objet. La composition et l'affinage, ou comment structurer les objets. La généricité, ou comment développer des applications de manière abstraites. Ainsi, concevoir par objets c'est répondre à la question : "De quoi parle t-on?". Définition : La réification est l'opération essentielle du paradigme objet par lequel quelque chose (physique, relation, évène-ment) est représentée informatiquement sous la forme d'objets. Concevoir un programme par une méthode objets, c'est : r Décomposer le logiciel en unités indépendantes. r Chaque unité disposant de sa propre mémoire locale et des opérations qu'elle sait effectuer. Chaque objet est une cellule, une "brique" de base pour la conception d'un objet (classe) complexe. autonomie : les objets sont considérés comme entité à part entière. r localité : par opposition au global, où l'on précise tout d'un point de vue individu. composition : constituer des entités à part entière. r affinage : décrire un logiciel en terme de logiciels déjà existants, on utilise les héritages des objets génériques. Au début, on définit les classes les plus spécifiques et au fur et à mesure que l'on remonte dans la hiérarchie, on généralise les entités : Par exemple :

42 Réaliser un diagramme de classes
Un cycle de conception s'effectue en cinq étapes : Identifier les entités du domaine. Structurer le domaine en analysant les propriétés des entités et des relations Identifier les opérations que savent effectuer ces entités. Décrire précisément ces opérations en les reliant à des messages. Décrire le lancement du programme.

43 Réaliser un diagramme de classes
A partir d’un cahier des charges (ou document de spécification) Mot clé Ne pas choisir comme nom le rôle Les classes peuvent évoluer (incrémental) Attention à la surabondance de classes Classes d’objets du monde modélisé Plus difficile pour une appli abstraite (SE) qu’une appli qui gère des objets physiques (livres, CD, etc). Le talent et l'expérience sont des parties inévitables du succès de la conception. Nous pouvons toutefois donner des principes généraux. La critique est aisée mais l'art est difficile : r En analysant les conceptions existantes, on peut apprendre à concevoir. r Notamment, s'il existe des classes on peut les analyser en examinant les principes de modularités : classes autonomes, cohérentes, classes pures, abstractions des méthodes descendantes. La règle "critiquez et améliorez des conceptions existantes" n'est pas en soi une solution aux problèmes, mais permet l'analyse et l'apprentissage par expérience. Des classes réutilisables Une façon naïve mais efficace de trouver des classes est de regarder simplement ce qui est disponible. Un "bon" environnement à objets offre un certain nombre de classes pré définies qui implémentent des abstractions importantes. Des objets externes Beaucoup de classes décrivent simplement (avec habitude) le comportement d'objets externes de la réalité concrète ou abstraite à modéliser : r Missiles et radars, livres et auteurs, figures et polygones, fenêtres et souris, etc…. Cette idée fournit les classes fondamentales d'un système : r Considérer la construction de logiciel comme une modélisation opérationnelle et utiliser les classes d'objets du monde modélisé comme base pour les classes du système logiciel.

44 Réaliser un diagramme de classes
Comment identifier les attributs ? A partir d’un cahier des charges Propriétés des objets Pour l’analyse ne retenir que les importants

45 Réaliser un diagramme de classes
Comment identifier les relations ? A partir d’un cahier des charges Verbes Dépendances entre classes modélisées par des relations et non des attributs

46 Réaliser un diagramme de classes
Identifier les entités Classes principales (principaux concept du domaine) Difficulté : les bonnes classes Noyau minimal qu’on enrichira Liste exhaustive sur la fin de la conception

47 Réaliser un diagramme de classes
Structurer le domaine Organiser et relier les classes Relations taxonomiques Relation méronomiques (même hiérarchie ou hiérarchie différente)

48 Réaliser un diagramme de classes
identifier les opérations Aspects dynamiques Identifier ce qu’on peut effectuer avec les objets S’intéresser aux messages

49 Exercice de conception
Selon le modèle que l’on vient de voir Gestion des examens à l’IUT : réservation des salles, établissement du planning, mise en place de la surveillance, saisie et diffusion des notes

50 Paquetage et sous-système
Organisation du système qui possède beaucoup d’objets Prendre en compte Les compromis techniques Les éléments à développer en // Les éléments à acheter Les éléments à réutiliser

51 Package Élément de groupement et d’organisation dans lequel se trouvent des éléments qui doivent être nommés de façon unique Représenté par un dossier (proche répertoire SE) Un paquetage peut en inclure d’autres

52 Package Viser la cohérence et l’indépendance
S’efforcer de minimiser les relations entre packages Principalement utilisé lors des phases d’analyse et conception [PAM-97 p90] Un paquetage est un regroupement d’éléments de modélisation, mais aussi une encapsulation de ces éléments. A l’image des classes, les paquetages possèdent une interface et une réalisation. Chaque élément contenu par un paquetage possède un paramètre qui signale si l’élément est visible ou non à l’extérieur du paquetage. Les valeurs prises par le paramètre sont : public ou implémentation (privé).

53 Package

54 Package Une modification du package Interface entraîne des modifications du package Utilitaire

55 Package Relation de dépendance entre paquetages
Au moins 1 classe du paquetage client utilise les services offert par une classe du paquetage fournisseur Toutes les classe ne sont pas forcément visibles

56 Exemple

57 Sous-système Collection organisée d’éléments que l’on peut composer en systèmes plus petits et finalement en éléments primitifs non décomposables : classes Éléments qui ensemble offrent des services Le package n’est qu’un groupement logique Le système offre des services Les dépendances entre systèmes se basent sur ces services Décomposition du système en sous-systèmes : regrouper les parties du système qui ont des fonctionnalités similaires (package de classes) Vu de l’exterieur, le système est un ensemble de services qu’il rend au travers de son interface Le sous-système doit être le plus modulaire possible (interface avec le système limitée) Les relations entre sous-systèmes : - client-serveur : le client doit connaître l’interface du serveur pour demander un service et obtenir une réponse - égal à égal : chaque sous-système doit connaître les interfaces des autres. La décomposition du système en couches : Une couche (cliente) connaît les interfaces des couches en dessous (serveur) mais pas des couches au dessus l’architecture en couches peut être - ouverte : si une couche connaît toutes les couches du dessous. un changement dans une couche a des conséquences sur les autres le code est plus compact (services accessibles sans redefinition) - fermée : une couche ne connaît que celle du dessous Décomposition du système en partitions : -chaque partition est indépendante des autres Découpage classique : 3 sous-systèmes - interface homme-machine - les objets métiers (ensemble des objets découverts lors de l’analyse) - l’infrastructure : couche basse (BD, gestion des architectures à objets distribués, etc)