Une association n-aire connecte n entités/classes. Une association n-aire peut également posséder ou non des attributs.
Détaillons à présent les interprétations des cardinalités d’une association n-aire, qui varient selon les formalismes entité-association. Ces approches se différencient selon le sens de lecture des cardinalités au niveau des entités concernées par l’association n-aire.
Dans le modèle américain de P. Chen, les contraintes de cardinalités d’une entité donnée sont lues à partir des autres entités (du sens entités connectées→entité concernée) alors qu’avec Merise, elles sont lues du sens entité concernée→entités connectées.
Figure 1-23 Classe-association avec attribut sous UML
Departement codedept nomdept budget
Logiciel
Achat dateachat prix
Classe-association 1..*
1..*
nomlogi editeur
Bien que l’exemple qui nous servira de fil conducteur fasse intervenir une association de degré 3 (3-aire), il est aisé de transposer notre propos à des associations de degré supérieur.
MCD Merise
Le schéma conceptuel 1-24 modélise le fait que des logiciels sont installés sur des serveurs sur l’initiative de départements. On désire savoir la date à laquelle un département a procédé à l’installation d’un logiciel sur un serveur.
Le formalisme de type Merise impose la lecture des cardinalités suivantes :
● du côté Logiciel, combien de couples (Département, Serveur) peuvent être associés à un logiciel ? Réponse : (0,N), car un logiciel peut ne pas être installé ou au contraire être installé sur plusieurs serveurs par différents départements ;
● du côté Serveur, combien de couples (Département, Logiciel) peuvent être associés à un serveur ? Réponse : (1,N), car un serveur doit au moins héberger un logiciel installé par un département et un serveur peut héberger plusieurs logiciels sur l’initiative de différents départements ;
● du côté Departement, combien de couples (Serveur, Logiciel) peuvent être associés à un département ? Réponse : (0,N), car un département peut ne pas être impliqué dans une installation de logiciel. En revanche, il peut être l’instigateur de plusieurs installations mettant en jeu différents logiciels et serveurs.
Par ailleurs, ce diagramme ne laisse apparaître aucune autre contrainte. En d’autres termes, n’importe quel logiciel peut être installé sur l’initiative de n’importe quel département sur n’importe quel serveur. (Transposons ce schéma dans le modèle relationnel : la table Installation va être définie avec sa clé primaire composée des identifiants des trois entités. Il est alors possible d’insérer n’importe quel triplet (nomlogi, nomserv, codedept, dans cette table.) Est-ce la réalité à modéliser ? Probablement pas !
La majorité des associations n-aires sans contrainte additionnelle ne permettent pas de repré-senter convenablement le monde réel. Nous consacrons par la suite un paragraphe à la mise en
Figure 1-24 Association 3-aire Merise
Logiciel
œuvre de contraintes additionnelles sur une association n-aire. Pour raisonner avec des asso-ciations de degré supérieur, il suffit de considérer des triplets (pour une association de degré 4) au lieu des couples (comme c’est le cas dans notre exemple), etc.
La notion de cardinalité est insuffisante pour intégrer la contrainte suivante : un logiciel d’un département ne doit être installé que sur un seul serveur. La solution consiste à définir une contrainte d’unicité que Merise appelle CIF (contrainte d’intégrité fonctionnelle). Nous détaillerons par la suite le schéma qu’il convient d’élaborer à cet effet.
Formalisme de Chen
Décrivons l’exemple 1-25 d’association 3-aire Installation dans le formalisme de P. Chen.
Ce formalisme impose la lecture des cardinalités suivantes :
● du côté Logiciel, combien de logiciels peuvent être associés à un couple (Département, Serveur) ? Réponse : (0,N), car un logiciel peut ne pas être installé, en revanche plusieurs logiciels peuvent être installés sur le même serveur par un département ;
● du côté Serveur, combien de serveurs peuvent être associés à un couple (Département, Logiciel) ? Réponse : (1,1), car nous représentons directement la contrainte qu’un logiciel d’un département ne doit être installé que sur un seul serveur ;
● du côté Departement, combien de départements peuvent être associés à un couple (Serveur, Logiciel) ? Réponse : (0,N), car un département peut ne pas être impliqué dans une installation de logiciel et en revanche plusieurs départements peuvent utiliser le même logiciel sur un serveur donné (on parle alors d’installation de licence).
On constate que ce formalisme permet de représenter intrinsèquement les contraintes d’unicité (appelées aussi CIF dans Merise) que nous détaillerons plus loin.
Ce qu’en disait la littérature
Les associations n-aires ont toujours été très peu mises en avant dans la littérature consacrée à UML. Les exemples sont rares, les explications encore plus ! Les premières versions des
Figure 1-25 Association 3-aire (formalisme de Chen)
Logiciel
principaux outils anglo-saxons (comme Rational Rose) ne les géraient pas (le chapitre 4 fait le point sur cet aspect des choses). Seul Rumbaugh [RUM95] avec OMT abordait explicitement cet aspect (en le limitant aux ternaires et en niant quasiment les dimensions supérieures). Il y est dit : « La notation symbole de multiplicité (celle d’OMT) fonctionne bien quand il s’agit d’associations binaires… Cependant cette notation est ambiguë pour les associations n-aires (n > 2). La meilleure approche est de préciser les clés candidates. Une clé candidate est un ensemble minimum d’attributs qui identifie uniquement un objet… ». Ce dernier conseillait de promouvoir l’association ternaire comme une classe. Si UML avait poursuivi cette voie :
● il ne devrait pas y avoir de multiplicité notée sur les ternaires !
● on devrait introduire la notion d’identifiant ou de clé candidate sur les associations !
● l’interprétation se ferait ensuite au niveau logique ! Notation UML
On lit désormais dans la spécification (Unified Modeling Language : Superstructure - version 2.0 - formal/05-07-04) que la lecture des multiplicités doit se faire selon le mode de lecture du formalisme de Chen (exemple de la figure 1-25).
« For n-ary associations, the lower multiplicity of an end is typically 0. The lower multiplicity for an end of an n-ary association of 1 (or more) implies that one link (or more) must exist for every possible combination of values for the other ends ».
On apprend dans cette même spécification que toute association binaire pourrait être représentée à l’aide du symbole losange.
« Any association may be drawn as a diamond (larger than a terminator on a line) with a solid line for each association end connecting the diamond to the classifier that is the end’s type. An association with more than two ends can only be drawn this way ».
Cette notation n’est pas très utilisée en pratique (seul l’outil Together de Borland l’a adoptée).
De plus, ce formalisme peut porter à confusion car il ressemble au symbole de l’agrégation partagée.
Une association n-aire sans contrainte se représente avec UML soit par un losange (symbole de l’association) qui connecte les n classes et une classe-association, soit par une classe stéréo-typée reliée aux n classes.
Une association n-aire avec contrainte se représente plus facilement avec UML par une ou plusieurs classes-associations reliant les n classes.
Association en losange
Le diagramme de classes 1-26 modélise l’association Installation précédente à l’aide du symbole de l’association n-aire. La contrainte d’unicité apparaît explicitement (multiplicité 1 du côté Serveur).
Classe stéréotypée
L’exemple 1-27 décrit la même association à l’aide d’une classe stéréotypée <<Association ternaire>>. La contrainte d’unicité n’apparaît plus explicitement.
Cette notation n’est pas conseillée à moins d’utiliser un outil qui ne prend pas en compte le symbole losange de l’association et de vouloir toutefois modéliser une association n-aire sans contrainte.
Figure 1-26 Association 3-aire UML avec un losange
Figure 1-27 Association 3-aire UML avec stéréotype Departement
Utilisation d’une classe-association
Cette solution va nous permettre de prendre en compte explicitement la contrainte d’unicité qui concerne l’installation des logiciels : un logiciel d’un département n’est installé que sur un seul serveur.
Le diagramme 1-28 met en œuvre la classe-association Installation en liaison avec la classe Serveur. Il met en évidence qu’une installation (constituée d’un logiciel et d’un départe-ment à une date donnée) est associée à un seul serveur (multiplicité 1 du côté Serveur).