Vous êtes ici : Accueil Diagrammes Diagramme UML Diagramme de classe

Diagramme de classe

Le site de Laurent Audibert :

http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML016.html

http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML017.html

Diagrammes de classes (cf. Class diagram)

Il représente les classes intervenant dans le système. Le diagramme de classe est une représentation statique des éléments qui composent un système et de leurs relations.

Chaque application qui va mettre en œuvre le système sera une instance des différentes classes qui le compose.

A ce titre il faudra bien garder à l'esprit qu'une classe est un modèle et l'objet sa réalisation.

L'exemple le plus classique est de considérer la classe « EtreHumain » qui sert à instancier les objets « pierre:EtreHumain », « georgette:EtreHumain », etc...

Enfin, l'erreur la plus courante est de créer une classe pour chaque cas d'utilisation d'un système alors que se seront des ensembles de classes qui vont permettre la réalisation d'un cas d'utilisation.

Le fonctionnement dynamique d'une classe pourra être modélisé à travers des diagrammes d'état ou d'activité.

Important : Les classes et les associations utilisées dans le diagramme de classe pouvant servir de base à la génération du code de l'application, il faut respecter au maximum les chartes de nommage ainsi que les bases de syntaxe des langages informatiques.

Le concept de classe

La classe est un concept abstrait qui permet de représenter toutes les entités d'un système. Une classe peut donc représenter une voiture, un bouton cliquable,  un devis, un utilisateur connecté, une structure de donnée ou tout autre élément devant être modélisé et donnant généralement lieu à la génération d'un code informatique.

La classe est définie par son nom, ses attributs et ses opérations comme ci-dessous.
Étant donné que les classes vont être utilisées pour générer le code il est souhaitable d'utiliser une règle de nommage qui respecte les syntaxes des langages informatiques comme par exemple celle proposée par Java qui consiste à :

  • Commencer les noms des classes par des majuscules et tous les autres éléments par des minuscules.
  • Séparer les mots composés par des majuscules.
  • Ne pas utiliser de caractères spéciaux ou accentués qui pourraient ne pas être acceptés dans les langages informatiques.
ConceptDeClasse.png

 

Les attributs de la classe

Nous verrons plus bas que les associations entre classes sont aussi des attributs.

La syntaxe d'un attribut est la suivante :

<visibilite> [/] <nomAttribut> : <type> [ '['<multiplicite>']' [{<contrainte>}] ] [ = <valeurParDefaut> ]

  • visibilite : + public / # protected / - private
  • / : signal un attribut dérivé. C'est à dire calculé à partir d'autres attributs.
  • nomAttribut : nom de l'attribut
  • type : type de l'attribut
  • [multiplicite] : multiplicité pour définir des tableaux, des listes de valeurs
  • {<contrainte>} : pour donner des contraintes OCL quand la multiplicité est supérieure à 1
  • valeurParDefaut : valeur d'initialisation

Les opérations de la classe

La syntaxe des opérations est la suivante :

  • <visibilite> <nomOperation> ([<param1>, ... , <paramN>]) : [<typeRetour>] [{<proprietes>}]
  • visibilite : + public / # protected / - private
  • nomOperataion : nom de l'opération
  • [<param1>, ... , <paramN>] : liste des paramètres respectant la syntaxe ci-dessous.
  • typeRetour : type de retour de l'opération
  • {<propriete>} : contraintes OCL, indications ou mots clé comme « abstract »

La syntaxe des paramètres (<paramX>) est la même que celle d'un attribut à la « direction » près  :

[<direction>] <nomParam> : <type> [ '[' <multiplicite> ']' ] [ = <valeurParDefaut> ]

  • direction  <in> : Valeur par défaut qui définit que l'appelant fournit une valeur et n'accède pas aux modifications de cette dernière.
  • direction <out> : Paramètre utilisé uniquement pour fournir une valeur en lecture à l'appelant.
  • direction <inout> : Paramètre utilisé par l'appelant pour fournir une valeur qu'il peut aussi lire après modification.

Nous considérons aussi souvent qu'il existe des opérations implicites qui sont les opérations d'accès aux attributs appelées « Accessor » et « Mutator » puisque le concept de base des langages objets consiste à encapsuler les attributs dans les classes en les rendant privées ou protégées et à ne permettre leur accès qu'à travers des méthodes publiques.

Classes actives et passives

UML définit les classes par défaut comme passives.

C'est à dire qu'elle fournissent des structures de données et des comportements.

Les classes définies comme actives sont les classes qui contrôlent le système aussi appelé « main ».

Elles sont représentées par une double barre sur le coté.

L'association

L'association est le premier niveau de relation entre 2 classes.

Elle spécifie tout simplement qu'une classe peut en utiliser une autre.

L'association est habituellement traduite dans le code par un pointeur ou un tableau de pointeurs.

Dans l'exemple ci-dessous nous avons en haut la représentation graphique et en bas la représentation sous forme d'attributs de la même association.

Cet exemple montre bien que l'association utilisée graphiquement se matérialisera réellement comme un attribut avec la multiplicité et le rôle défini sur l'association.

Une association est donc définie par ses 2 terminaisons qui ont chacune :

  • Un rôle : C'est le nom que prendra l'attribut de la classe.
  • Une multiplicité : Comme pour les attributs
  • Une navigabilité : Pour rendre l'association bidirectionnelle ou monodirectionnelle.
  • Une visibilité : Comme tous les attributs.
AssociationClasse.png

 

 

Multiplicité d'une terminaison.

Chaque terminaison d'association peut définir les multiplicités suivantes :

  • 1 : C'est la valeur par défaut de toute terminaison qui précise qu'il y a un et un seul élément.
  • 0..1 : Possibilité d'avoir 0 ou 1 élément.
  • 1..*  : Possibilité d'avoir 1 à n éléments. Cette structure de dimension inconnue devra être gérée par une structure de de dimension variable (listes chainées, etc...)
  • 0..* : Possibilité d'avoir 0 à n éléments. Cette structure de dimension inconnue devra être gérée par une structure de dimension variable (listes chainées, etc...)
  • n : Définit un nombre précis d'éléments.
  • n..m : Définit une fourchette précise d'éléments.
  • * : équivalent de 0..*

Les agrégations

 

Contrairement à l'association

l'agrégation représente un objet instancié et pas simplement un pointeur.

Les compositions

 

Tout comme l'agrégation la composition représente un objet instancié et pas simplement un pointeur.

En plus cet objet ne peut être créé et détruit que par l'objet qui le compose.

On dit que la durée de vie de l'objet composé est le même que celui de l'objet qui le compose.

L'héritage

 

Le concept d'héritage tel qu'il est définit dans tous les langages objets est représenté en UML par une flèche d'héritage comme ci-dessous.

Heritage.png

Schémas extraits du cours de Laurent Audibert et reproduits avec son autorisation.
http://laurent-audibert.developpez.com/Cours-UML/html/index.html

3.3.2  Terminaison d’association


Propriétaire d’une terminaison d’association

La possession d’une terminaison d’association par le classeur situé à l’autre extrémité de l’association peut être spécifié graphiquement par l’adjonction d’un petit cercle plein (point) entre la terminaison d’association et la classe (cf. figure 3.4). Il n’est pas indispensable de préciser la possession des terminaisons d’associations. Dans ce cas, la possession est ambiguë. Par contre, si l’on indique des possessions de terminaisons d’associations, toutes les terminaisons d’associations sont non ambiguë : la présence d’un point implique que la terminaison d’association appartient à la classe située à l’autre extrémité, l’absence du point implique que la terminaison d’association appartient à l’association.


Figure 3.4: Utilisation d’un petit cercle plein pour préciser le propriétaire d’une terminaison d’association.

Par exemple, le diagramme de la figure 3.4 précise que la terminaison d’association sommet (i.e. la propriété sommet) appartient à la classe Polygone tandis que la terminaison d’association polygone (i.e. la propriété polygone) appartient à l’association Défini par.

Une terminaison d’association est une propriété

Une propriété est une caractéristique structurelle. Dans le cas d’une classe, les propriétés sont constituées par les attributs et les éventuelles terminaisons d’association que possède la classe. Dans le cas d’une association, les propriétés sont constituées par les terminaisons d’association que possède l’association. Attention, une association ne possède pas forcément toutes ses terminaisons d’association !

Une propriété peut être paramétrée par les éléments suivant (on s’intéresse ici essentiellement aux terminaisons d’associations puisque les attributs ont été largement traités section 3.2) :

nom :
Comme un attribut, une terminaison d’association peut être nommée. Le nom est situé à proximité de la terminaison, mais contrairement à un attribut, ce nom est facultatif. Le nom d’une terminaison d’association est appelée nom du rôle. Une association peut donc posséder autant de noms de rôle que de terminaisons (deux pour une association binaire et n pour une association n-aire).
visibilité :
Comme un attribut, une terminaison d’association possède une visibilité (cf. section 3.2.4). La visibilité est mentionnée à proximité de la terminaison, et plus précisément, le cas échéant, devant le nom de la terminaison.
multiplicité :
Comme un attribut, une terminaison d’association peut posséder une multiplicité. Elle est mentionnée à proximité de la terminaison. Il n’est pas impératif de la préciser, mais, contrairement à un attribut dont la multiplicité par défaut est 1, la multiplicité par défaut d’une terminaison d’association est non spécifiée. L’interprétation de la multiplicité pour une terminaison d’association est moins évidente que pour un attributs (cf. section 3.3.4).
navigabilité :
Pour un attribut, la navigabilité est implicite, navigable, et toujours depuis la classe vers l’attribut. Pour une terminaison d’association, la navigabilité peut être précisée (cf. section 3.3.5).

3.3.3  Association binaire et n-aire

Association binaire


Figure 3.5: Exemple d’association binaire.

Une association binaire est matérialisée par un trait plein entre les classes associées (cf. figure 3.5). Elle peut être ornée d’un nom, avec éventuellement une précision du sens de lecture (▸ ou ◂).

Quand les deux extrémités de l’association pointent vers la même classe, l’association est dite réflexive.

Association n-aire


Figure 3.6: Exemple d’association n-aire.

Une association n-aire lie plus de deux classes. La section 3.3.4 détaille comment interpréter les multiplicités d’une association n-aire. La ligne pointillé d’une classe-association (cf. section 3.3.7) peut être reliée au losange par une ligne discontinue pour représenter une association n-aire dotée d’attributs, d’opérations ou d’associations.

On représente une association n-aire par un grand losange avec un chemin partant vers chaque classe participante (cf. figure 3.6). Le nom de l’association, le cas échéant, apparaît à proximité du losange.

3.3.4  Multiplicité ou cardinalité

La multiplicité associée à une terminaison d’association, d’agrégation ou de composition déclare le nombre d’objets susceptibles d’occuper la position définie par la terminaison d’association. Voici quelques exemples de multiplicité :

  • exactement un : 1 ou 1..1
  • plusieurs : * ou 0..*
  • au moins un : 1..*
  • de un à six : 1..6

Dans une association binaire (cf. figure 3.5), la multiplicité sur la terminaison cible contraint le nombre d’objets de la classe cible pouvant être associés à un seul objet donné de la classe source (la classe de l’autre terminaison de l’association).

Dans une association n-aire, la multiplicité apparaissant sur le lien de chaque classe s’applique sur une instance de chacune des classes, à l’exclusion de la classe-association et de la classe considérée. Par exemple, si on prend une association ternaire entre les classes (A, B, C), la multiplicité de la terminaison C indique le nombre d’objets C qui peuvent apparaître dans l’association (définie section 3.3.7) avec une paire particulière d’objets A et B.

Remarque 1 :

Pour une association n-aire, la multiplicité minimale doit en principe, mais pas nécessairement, être 0. En effet, une multiplicité minimale de 1 (ou plus) sur une extrémité implique qu’il doit exister un lien (ou plus) pour TOUTES les combinaisons possibles des instances des classes situées aux autres extrémités de l’association n-aire !

Remarque 2 :

Il faut noter que, pour les habitués du modèle entité/relation, les multiplicités sont en UML « à l’envers » (par référence à Merise) pour les associations binaires et « à l’endroit » pour les n-aires avec n>2.

3.3.5  Navigabilité


Figure 3.7: Navigabilité.

La navigabilité indique s’il est possible de traverser une association. On représente graphiquement la navigabilité par une flèche du côté de la terminaison navigable et on empêche la navigabilité par une croix du côté de la terminaison non navigable (cf. figure 3.7). Par défaut, une association est navigable dans les deux sens.

Par exemple, sur la figure 3.7, la terminaison du côté de la classe Commande n’est pas navigable : cela signifie que les instances de la classe Produit ne stockent pas de liste d’objets du type Commande. Inversement, la terminaison du côté de la classe Produit est navigable : chaque objet commande contient une liste de produits.



 

 
Figure 3.8: Implicitement, ces trois notations ont la même sémantique.

Lorsque l’on représente la navigabilité uniquement sur l’une des extrémités d’une association, il faut remarquer que, implicitement, les trois associations représentées sur la figure 3.8 ont la même signification : l’association ne peut être traversée que dans un sens.



 
Figure 3.9: Deux modélisations équivalentes.

Dans la section 3.3.1, nous avons dit que :

« Un attribut est une association dégénérée dans laquelle une terminaison d’association est détenue par un classeur (généralement une classe). Le classeur détenant cette terminaison d’association devrait théoriquement se trouver à l’autre terminaison, non modélisée, de l’association. Un attribut n’est donc rien d’autre qu’une terminaison d’un cas particulier d’association. »

La figure 3.9 illustre parfaitement cette situation. Attention toutefois, si vous avez une classe Point dans votre diagramme de classe, il est extrêmement maladroit de représenter des classes (comme la classe Polygone) avec un ou plusieurs attributs de type Point. Il faut, dans ce cas, matérialiser cette propriété de la classe en question par une ou plusieurs associations avec la classe Point.

3.3.6  Qualification


                     
 
                     
Figure 3.10: En haut, un diagramme représentant l’association entre une banque et ses clients (à gauche), et un diagramme représentant l’association entre un échiquier et les cases qui le composent (à droite). En bas, les diagrammes équivalents utilisant des associations qualifiées.

Généralement, une classe peut être décomposée en sous-classes ou posséder plusieurs propriétés. Une telle classe rassemble un ensemble d’éléments (d’objets). Quand une classe est liée à une autre classe par une association, il est parfois préférable de restreindre la portée de l’association à quelques éléments ciblés (comme un ou plusieurs attributs) de la classe. Ces éléments ciblés sont appelés un qualificatif. Un qualificatif permet donc de sélectionner un ou des objets dans le jeu des objets d’un objet (appelé objet qualifié) relié par une association à un autre objet. L’objet sélectionné par la valeur du qualificatif est appelé objet cible. L’association est appelée association qualifiée. Un qualificatif agit toujours sur une association dont la multiplicité est plusieurs (avant que l’association ne soit qualifiée) du côté cible.

Un objet qualifié et une valeur de qualificatif génèrent un objet cible lié unique. En considérant un objet qualifié, chaque valeur de qualificatif désigne un objet cible unique.

Par exemple, le diagramme de gauche de la figure 3.10 nous dit que :

  • Un compte dans une banque appartient à au plus deux personnes. Autrement dit, une instance du couple {Banque , compte} est en association avec zéro à deux instances de la classe Personne.
  • Mais une personne peut posséder plusieurs comptes dans plusieurs banques. C’est-à-dire qu’une instance de la classe Personne peut être associée à plusieurs (zéro compris) instances du couple {Banque , compte}.
  • Bien entendu, et dans tous les cas, un instance du couple {Personne , compte} est en association avec une instance unique de la classe Banque.

Le diagramme de droite de cette même figure nous dit que :

  • Une instance du triplet {Echiquier, rangée, colonne} est en association avec une instance unique de la classe Case.
  • Inversement, une instance de la classe Case est en association avec une instance unique du triplet {Echiquier, rangée, colonne}.

3.3.7  Classe-association

Définition et représentation


Figure 3.11: Exemple de classe-association.

Parfois, une association doit posséder des propriétés. Par exemple, l’association Emploie entre une société et une personne possède comme propriétés le salaire et la date d’embauche. En effet, ces deux propriétés n’appartiennent ni à la société, qui peut employer plusieurs personnes, ni aux personnes, qui peuvent avoir plusieurs emplois. Il s’agit donc bien de propriétés de l’association Emploie. Les associations ne pouvant posséder de propriété, il faut introduire un nouveau concept pour modéliser cette situation : celui de classe-association.

Une classe-association possède les caractéristiques des associations et des classes : elle se connecte à deux ou plusieurs classes et possède également des attributs et des opérations.

Une classe-association est caractérisée par un trait discontinu entre la classe et l’association qu’elle représente (figure 3.11).

Classe-association pour plusieurs associations

Il n’est pas possible de rattacher une classe-association à plus d’une association puisque la classe-association constitue elle-même l’association. Dans le cas où plusieurs classe-associations doivent disposer des mêmes caractéristiques, elles doivent hériter d’une même classe possédant ces caractéristiques, ou l’utiliser en tant qu’attribut.

De même, il n’est pas possible de rattacher une instance de la classe d’une classe-association à plusieurs instances de l’association de la classe-association. En effet, la représentation graphique (association reliée par une ligne pointillé à une classe déportée) est trompeuse : une classe-associaiton est une entité sémantique atomique et non composite qui s’intancie donc en bloc. Ce problème et à nouveau abordé et illustré section 3.5.2.

Auto-association sur classe-association


Figure 3.12: Exemple d’auto-association sur classe-association.

Imaginons que nous voulions ajouter une association Supérieur de dans le diagramme 3.11 pour préciser qu’une personne est le supérieur d’une autre personne. On ne peut simplement ajouter une association réflexive sur la classe Personne. En effet, une personne n’est pas le supérieur d’une autre dans l’absolu. Une personne est, en tant qu’employé d’une entreprise donné, le supérieur d’une autre personne dans le cadre de son emploi pour une entreprise donné (généralement, mais pas nécessairement, la même). Il s’agit donc d’une association réflexive, non pas sur la classe Personne mais sur la classe-association Emploie (cf. figure 3.12).

Liens multiples


Figure 3.13: Exemple de classe-association avec liens multiples.

Plusieurs instances d’une même association ne peuvent lier les mêmes objets. Cependant, si l’on s’intéresse à l’exemple de la figure 3.13, on voit bien qu’il doit pouvoir y avoir plusieurs instances de la classe-association Actions liant une même personne à une même société : une même personne peut acheter à des moments différents des actions d’une même société.

C’est justement la raison de la contrainte {bag} qui, placée sur les terminaisons d’association de la classe-association Actions, indique qu’il peut y avoir des liens multiples impliquant les mêmes paires d’objets.

Équivalences

Parfois, l’information véhiculée par une classe-association peut être véhiculée sans perte d’une autre manière (cf. figure 3.14 et 3.15).


Figure 3.14: Deux modélisations modélisant la même information.


Figure 3.15: Deux modélisations modélisant la même information.

Classe-association, association n-aire ou association qualifiée ?

Il n’est souvent pas simple trancher entre l’utilisation d’une classe-association, d’une association n-aire ou encore d’une association qualifiée. Lorsque l’on utilise l’un de ces trois types d’association, il peut être utile ou instructif de se demander si l’un des deux autres types ne serait pas plus pertinent. Dans tous les cas, il faut garder à l’esprit qu’une classe-association est d’abord et avant tout une association et que, dans une classe-association, la classe est indissociable de l’association.


                   
Figure 3.16: Pour couvrir le cas des comptes joints, il faut utiliser le modèle de droite.

Ainsi, le cas d’un compte joint ne peut être représenté correctement par le diagramme de gauche dans figure 3.16 : mieux vaut utiliser une association qualifiée (diagramme de droite dans la figure 3.16). Ce problème et à nouveau abordé et illustré section 3.5.2.


                   
Figure 3.17: Si un cours doit pouvoir exister indépendamment d’un lien entre un enseignant et un groupe, il faut utiliser le modèle de droite.

Dans le diagramme de gauche de la figure 3.17, un cours ne peut exister que s’il existe un lien entre un objet Enseignant et un objet Groupe. Quand le lien est rompu (effacé), le cours l’est également. Si un cours doit pouvoir exister indépendamment de l’existence d’un lien (on a pas encore trouvé d’enseignant pour ce cours, le cours n’est pas enseigné cette année mais le sera probablement l’année prochaine, …) il faut opter pour une association ternaire (modèle de droite dans figure 3.17).


Figure 3.18: Si un même cours doit concerner plusieurs couples Enseignant/Etudiant, il ne faut pas utiliser une classe-association, mais une association ternaire comme sur le modèle de droite.

Le cas de figure est encore pire si l’on remplace Groupe par Etudiant (cf. modèle à gauche sur la figure 3.18). En effet, le cas général décrit par ce modèle ne correspond pas du tout au diagramme d’objet (cf. section 3.5) situé au centre. Nous reviendrons sur ce problème dans la section 3.5.2 avec l’illustration 3.24. Dans cette situation, il faut opter pour une association ternaire comme sur le modèle de droite.

3.3.8  Agrégation et composition

Agrégation


Figure 3.19: Exemple de relation d’agrégation et de composition.

Une association simple entre deux classes représente une relation structurelle entre pairs, c’est à dire entre deux classes de même niveau conceptuel : aucune des deux n’est plus importante que l’autre. Lorsque l’on souhaite modéliser une relation tout/partie où une classe constitue un élément plus grand (tout) composé d’éléments plus petit (partie), il faut utiliser une agrégation.

Une agrégation est une association qui représente une relation d’inclusion structurelle ou comportementale d’un élément dans un ensemble. Graphiquement, on ajoute un losange vide (♦) du côté de l’agrégat (cf. figure 3.19). Contrairement à une association simple, l’agrégation est transitive.

La signification de cette forme simple d’agrégation est uniquement conceptuelle. Elle ne contraint pas la navigabilité ou les multiplicités de l’association. Elle n’entraîne pas non plus de contrainte sur la durée de vie des parties par rapport au tout.

Composition

La composition, également appelée agrégation composite, décrit une contenance structurelle entre instances. Ainsi, la destruction de l’objet composite implique la destruction de ses composants. Une instance de la partie appartient toujours à au plus une instance de l’élément composite : la multiplicité du côté composite ne doit pas être supérieure à 1 (i.e. 1 ou 0..1). Graphiquement, on ajoute un losange plein (✦) du côté de l’agrégat (cf. figure 3.19).

Remarque

Les notions d’agrégation et surtout de composition posent de nombreux problèmes en modélisation et sont souvent le sujet de querelles d’experts et sources de confusions. Ce que dit la norme UML Superstructure version 2.1.1 reflète d’ailleur très bien le flou qui entoure ces notions :

Precise semantics of shared aggregation varies by application area and modeler. The order and way in which part instances are created is not defined.

3.3.9  Généralisation et Héritage


Figure 3.20: Partie du règne animal décrit avec l’héritage multiple.

La généralisation décrit une relation entre une classe générale (classe de base ou classe parent) et une classe spécialisée (sous-classe). La classe spécialisée est intégralement cohérente avec la classe de base, mais comporte des informations supplémentaires (attributs, opérations, associations). Un objet de la classe spécialisée peut être utilisé partout où un objet de la classe de base est autorisé.

Dans le langage UML, ainsi que dans la plupart des langages objet, cette relation de généralisation se traduit par le concept d’héritage. On parle également de relation d’héritage. Ainsi, l’héritage permet la classification des objets (cf. figure 3.20).

Le symbole utilisé pour la relation d’héritage ou de généralisation est une flèche avec un trait plein dont la pointe est un triangle fermé désignant le cas le plus général (cf. figure 3.20).

Les propriétés principales de l’héritage sont :

  • La classe enfant possède toutes les caractéristiques des ses classes parents, mais elle ne peut accéder aux caractéristiques privées de cette dernière.
  • Une classe enfant peut redéfinir (même signature) une ou plusieurs méthodes de la classe parent. Sauf indication contraire, un objet utilise les opérations les plus spécialisées dans la hiérarchie des classes.
  • Toutes les associations de la classe parent s’appliquent aux classes dérivées.
  • Une instance d’une classe peut être utilisée partout où une instance de sa classe parent est attendue. Par exemple, en se basant sur le diagramme de la figure 3.20, toute opération acceptant un objet d’une classe Animal doit accepter un objet de la classe Chat.
  • Une classe peut avoir plusieurs parents, on parle alors d’héritage multiple (cf. la classe Ornithorynque de la figure 3.20). Le langage C++ est un des langages objet permettant son implémentation effective, le langage Java ne le permet pas.

En UML, la relation d’héritage n’est pas propre aux classes. Elle s’applique à d’autre éléments du langage comme les paquetages, les acteurs (cf. section 2.3.3) ou les cas d’utilisation (cf. section 2.3.2).

3.3.10  Dépendance


Figure 3.21: Exemple de relation de dépendance.

Une dépendance est une relation unidirectionnelle exprimant une dépendance sémantique entre des éléments du modèle. Elle est représentée par un trait discontinu orienté (cf. figure 3.21). Elle indique que la modification de la cible peut impliquer une modification de la source. La dépendance est souvent stéréotypée pour mieux expliciter le lien sémantique entre les éléments du modèle (cf. figure 3.21 ou 3.25).

On utilise souvent une dépendance quand une classe en utilise une autre comme argument dans la signature d’une opération. Par exemple, le diagramme de la figure 3.21 montre que la classe Confrontation utilise la classe Stratégie car la classe Confrontation possède une méthode confronter dont deux paramètre sont du type Stratégie. Si la classe Stratégie, notamment son interface, change, alors des modifications devront également être apportées à la classe Confrontation.

 
Actions sur le document
Références
 
Site réalisé et hébergé par www.optragroup.fr