Les associations représentent des relations entre des
objets de classes différentes ; elles représentent des connexions entre des instances de deux ou plusieurs classes qui
existent pour une certaine durée. Elles sont différentes des liens transitoires, par exemple, qui n'existent que le
temps d'une opération. Ces dernières situations peuvent au contraire être modélisées à l'aide des collaborations, dans
lesquelles les liens n'existent que dans un contexte particulier et limité.
Vous pouvez
utiliser les associations pour montrer que des objets connaissent d'autres objets. Parfois, des objets doivent garder
contact avec d'autres objets pour pouvoir interagir et s'envoyer des messages par exemple. Dans certains cas, les
associations peuvent venir à la suite de patterns d'interaction dans des diagrammes de séquence ou des diagrammes
d'interaction.
La plupart des associations sont binaires (elles existent seulement entre deux classe), et sont conçues comme des
chemins solides connectant des paires de symboles de classes. Une association a un nom. L'association rôles peut en avoir plusieurs. Des noms de rôle sont préférables car ils donnent plus d'informations.
Dans les cas où un seul des rôles peut avoir un nom, les rôles sont toutefois préférables aux noms d'associations. Ces
derniers sont en effet très longs, l'association étant supposée être unidirectionnelle, partant de l'objet auquel le
nom de rôle est associé.
Les associations sont le plus souvent nommées pendant l'analyse, avant qu'il existe assez d'informations pour nommer
les rôles correctement. Quand ils sont utilisés, les noms d'associations doivent être une phrase verbale et refléter le
but de la relation. Le nom de l'association est placé sur le chemin d'association ou à côté.
Exemple
Dans un guichet automatique, le tiroir-caisse fournit l'argent que le distributeur de billets distribue.
Pour que le distributeur de billets puisse distribuer des billets, il doit rester en contact avec l'objet
tiroir-caisse ; de la même façon, si le tiroir-caisse est à court d'argent, l'objet distributeur de
billets doit en être informé, le tiroir-caisse doit donc rester en contact avec le distributeur de
billets. Une association modélise cette référence.
Association entre le distributeur de billets et le tiroir-caisse, appelée fournit la valeur.
Les noms d'association, s'ils sont mal choisis, peuvent être déroutants et trompeurs. L'exemple suivant illustre des
noms bien et mal choisis. Dans le premier diagramme, des noms d'associations sont utilisés ; mais s'ils sont
syntaxiquement corrects (ils utilisent des phrases verbales), ils ne donnent pas beaucoup d'informations sur la
relation. Dans le deuxième diagramme, des noms de rôles sont utilisés, ils renseignent beaucoup plus sur la nature de
la participation dans l'association.
Exemples de bonne et de mauvaise utilisation de noms d'association et de noms de rôle.
Chaque fin d'association est un rôle indiquant le rôle joué par une classe dans une association. Chaque
rôle doit avoir un nom, et l'opposé des noms de rôle doit être unique. Un nom de rôle doit être un nom indiquant le
rôle de l'objet associé en relation avec l'objet associant. Un nom de rôle pertinent pour un professeur en
association avec un cours serait, par exemple, chargé de cours ; éviter les noms comme "a" et
"contient", car ils n'apportent aucune information sur la relation entre les classes.
Notez que le fait d'utiliser des noms d'association ou des noms de rôle est exclusif : on ne peut pas utiliser un nom
d'association et un nom de rôle. Les noms de rôle sont préférables aux noms d'associations excepté dans les cas
où il n'existe pas assez d'informations pour nommer le rôle de façon appropriée (comme c'est souvent le cas lors de
l'analyse ; lors de la conception, en revanche, il faut toujours utiliser des noms de rôle). Un manque de bons noms de
rôle peut signifier que le modèle est incomplet ou mal conçu.
Le nom de rôle est placé à côté de la fin de la ligne d'association.
Exemple
Prenez l'exemple d'une relation entre les classes dans un système de saisie de demande. Un client peut avoir deux types
d'adresses : une adresse à laquelle les factures sont envoyées, et plusieurs adresses où les commandes sont envoyée.
Nous avons donc deux associations entre l'objet Client et l'objet Adresse, comme illustré ci-dessous. Les
associations sont marquées par le rôle que l'adresse associée joue pour le client.
Associations entre le Client, l'Adresse, et la Commande, indiquant les noms de rôle et les
multiplicités
Pour chaque rôle, vous pouvez définir la multiplicité de sa classe, c'est à dire le nombre d'objets de la classe
pouvant être associés à un objet de l'autre classe. La multiplicité est indiquée par une expression de texte sur le
rôle. L'expression est une liste séparée par des virgules de plages de nombres entiers. Une plage est indiquée par un
entier (la valeur la plus basse), deux points, et un entier (la valeur la plus haute) ; un entier seul est une plage
valide, et le symbole '*' indique "plusieurs", c'est à dire un nombre illimité d'objets. Le symbole '*' seul équivaut à
'0..*', c'est à dire à n'importe quel chiffre, même à aucun ; c'est la valeur par défaut. Un rôle scalaire en option a
la multiplicité 0..1.
Exemple
Dans l'exemple précédent, les multiplicités étaient expliquées pour les associations entre Commande et Client, et entre
Client et Adresse. Le diagramme indique qu'une commande doit être associée à un Client (la multiplicité est de 1..1 à
la fin de Client), mais un Client peut n'avoir aucune Commande (la multiplicité est de 0...* à la fin de Commande). De
plus, un Client a une seule adresse de facturation mais peut avoir plusieurs adresses de livraison. Pour éviter d'avoir
une codification trop complexe, si les multiplicités sont omises, on peut supposer qu'elles sont de 1..1.
La propriété navigabilité d'un rôle indique qu'il est possible de naviguer d'une classe associante vers une
classe cible en utilisant l'association. Cela peut être mis en oeuvre de plusieurs façons : par des références d'objets
directes, des tableaux associatifs, des tables de hachage ou par toute autre moyen permettant à un objet de se référer
à un autre. La navigabilité est indiquée par une flèche ouverte, placée sur la fin ciblée de la ligne de l'association
qui se trouve à côté de la classe visée (celle vers laquelle on navigue). La valeur par défaut de la propriété
navigabilité est vérifiée.
Exemple
Dans l'exemple de saisie de demande, l'association entre la Commande et le Client est navigable dans les
deux directions: une Commande doit savoir quel Client a passé la Commande, et le
Client doit savoir quelles Commandes il a passé. Lorsqu'il n'y pas de pointe de flèche, l'association est
sensée être navigable dans les deux sens.
Dans le cas des associations entre le Client et l'Adresse, le Client doit connaître ses
Adresses, mais les Adresses ne savent pas quels Clients (ou une autre classe, beaucoup de choses
ayant des adresses) sont associés aux adresses. En conséquences, la fin de l'association de la propriété de
navigabilité du Client est supprimée, donnant le diagramme suivant :
Classes du système des saisies de demande mises à jour, indiquant la navigabilité des associations.
Parfois, une classe peut être associée à elle même. Cela ne signifie pas forcément qu'une instance de cette classe est
associée à elle-même ; généralement, cela signifie qu'une instance de la classe est associée à d'autres instances de la
même classe. Dans le cas d'auto-associations, les noms de rôles sont essentiels pour distinguer le but de
l'association.
Exemple
Examinez l'auto-association suivante impliquant la classe Employé :
Dans cet exemple, un employé peut être associé à d'autres employés ; si c'est le cas, il est directeur, et les autres
employés sont des membres de son personnel. L'association est navigable dans les deux sens car les employés connaissent
leur directeur et que le directeur connaît ses employés.
Créer deux associations entre des classes implique que les objets sont liés deux fois ; un objet donné peut être lié à
différents objets grâce à chaque association. Chaque association est indépendante, et est caractérisée par son nom de
rôle. Comme dans l'exemple ci-dessus, un Client peut être associé à différentes instances de la même classe, chacune
avec un nom de rôle différent.
Lorsque la multiplicité d'une association est supérieure à un, les instances associées peuvent être classées. La
caractéristique classement d'un rôle indique que les instances participant à l'association sont classées ; par
défaut, c'est un ensemble non ordonné. Le modèle ne définit pas comment l'ordre est maintenu ; les opérations
qui mettent à jours et ordonnent l'association doivent spécifier où les éléments mis à jour sont insérés.
Les instances individuelles d'une association sont appelées liens ; un lien est donc une relation entre des
instances. Des messages peuvent être envoyés par des liens, et les liens indiquer des références et des agrégations
entre les objets. Voir aussi Technique
: diagramme de communication pour plus d'informations.
Une classe d'association est une classe qui a aussi des propriétés de classe (comme des attributs, des
opérations et des associations). On la crée en traçant une ligne tiretée entre le chemin d'association et le symbole
d'une classe qui maintient les attributs, les opérations et les associations pour l'association. Les attributs, les
opérations et les associations s'appliquent à l'association originale elle-même. Chaque lien de l'association a les
propriétés indiquées. L'utilisation la plus courante des classes d'association est la synchronisation de relations
multiples (voir exemple ci-dessous). En principe, la classe et l'association devraient avoir le même nom, mais des noms
différents sont autorisés si nécessaire. Une classe d'association dégénérée contient des attributs seulement pour
l'association ; dans ce cas, vous pouvez omettre le nom de la classe d'association pour atténuer son isolation.
Exemple
Pour reprendre l'exemple de l'Employé utilisé plus tôt, prenez le cas d'un Employé (un membre du personnel) travaillant
pour un autre Employé (le directeur). Le directeur évalue régulièrement son personnel pour voir ses performances sur
une période donnée.
L'évaluation ne peut pas être un attribut soit du directeur, soit du personnel, mais on peut associer l'information et
l'association elle-même, comme le montre l'exemple ci-dessous :
La classe d'association Evaluation enregistre les informations se rapportant à l'association elle-même.
Des qualificatifs sont utilisés pour diminuer et définir plus précisément l'ensemble des instances associées à une
autre instance ; un objet et une valeur qualificative définissent un ensemble unique d'objets dans l'association,
formant une clé composée. La qualification réduit en général la multiplicité du rôle opposé ; la multiplicité
réseau affiche le nombre d'instances de la classe associée liées à la première classe et une valeur de qualificatif
donnée. Les qualificatifs sont représentés par des petites cases à la fin de l'association liée à la classe
qualifiante. Ils appartiennent à l'association, pas à la classe. La case d'un qualificatif peut contenir plusieurs
valeurs de qualificatifs ; la qualification est basée sur la liste entière des valeurs. Une association
qualifiée est une variante de l'attribut association.
Exemple
Prenons l'exemple suivant d'amélioration de l'association entre la Ligne article et le Produit : une
ligne article est associée au Produit qui est commandé. Chaque ligne article se réfère à un seul produit,
alors qu'un produit peut être commandé sur de nombreuses lignes article. En qualifiant l'association avec le
qualificatif Codeproduit, on indique en plus que chaque produit a un code produit unique et que les Lignes
articles sont associées aux Produits utilisant ce code produit.
L'association entre la Ligne article et le Produit a pour qualificatif le Codeproduit.
Une association n-aire est une association entre trois classes ou plus, où une classe unique peut apparaître plus d'une
fois. Les associations n-aire sont représentées par de grands losanges avec des chemins de participation pour chaque
classe participante. C'est le symbole traditionnel pour le modèle relation-entité d'une association. Pour être plus
compact, la forme binaire est représentée sans le losange puisque c'est l'association la plus courante dans le modèle
réel. Les associations n-aires sont assez rares et peuvent être modélisées sous forme de classes. Les associations
n-aires peuvent aussi avoir une classe d'association ; on l'indique en traçant une ligne tiretée du losange vers le
symbole de la classe. Les rôles peuvent avoir des noms de rôle mais la multiplicité est plus compliquée et mieux
définie en faisant la liste des clés candidates. Si elle est indiquée, la multiplicité représente le nombre d'instances
correspondant à un bloc de données spécifique des autres objets N-1. La plupart des associations n-aire peuvent être
remplacées par des associations qualifiées ou des classes d'association. Elle peuvent aussi être remplacées par des
classes ordinaires, bien que cela supprime la contrainte qu'un seul lien peut avoir lieu pour un bloc de données
spécifique d'objets participants.
|