© Éditions Eyrolles
167
chapitre n° 2
Le niveau logique : du relationnel à l’objet
Agrégations UML
Une agrégation peut être modélisée de plusieurs manières :
●
par des collections ou des structures dans la classe composite ;
●
par une classe composite reliée aux différentes classes composantes par des références ;
●
une combinaison de ces deux approches.
La première solution convient si aucune autre classe que la classe composite n’est reliée à des
objets des structures de la classe composite. La seconde solution semble mieux adaptée au
partage d’objets de classes composantes entre différentes classes composites. La dernière
solution permet de mélanger à la demande les deux premières approches.
Figure 2-83 Solution universelle
Logiciel[ codelogi , nomlogi ]
Achat[@refLogi, @refDept, dateAchat ]
Departement[codept , nomdept]
Serveur[ nomserv , typeserv ]
Installation[@refAch , @refServ, dateInstall ]
L’exemple 2-84 met en œuvre des collections. Le tableau 2.10 décrit les contraintes avec les
mêmes multiplicités.
Figure 2-84 Solution basée sur les collections
Logiciel[ codelogi,nomlogi,achats{dateAchat, @refDept1 }]
Departement [ codept , nomdept ]
Serveur[nomserv ,typeserv ,install s{ dateInstall ,@refLogi, @refDept2 }]
Tableau 2.10 Contraintes à respecter pour la solution avec collections
m1
m2
Contraintes
*
1
Inclusion : pour tous les éléments de la collection installs, la référence refLogi
pointe un objet Logiciel qui possède une référence refDept1 sur un objet
Département d’OID x, et la référence refDept2 pointe l’objet d’OID x.
Unicité : pour tous les éléments de la collection installs, les couples de références
(refLogi, refDept2) sont distincts deux à deux.