1 pièce(s) jointe(s)
Association et Collection - Navigation sur plusieurs niveaux
Bonjour,
Après avoir suivi plusieurs tutos sur l'UML aucun code présenté ne répond à ma question :
Soit le diagramme de classe suivant.
Pièce jointe 225441
On pourrait implémenter ces classes et leurs associations suivant le code ci-dessous. La multiplicité * donne lieu à une collection (ici implémentée sous forme de tableau) en faisant abstraction du langage utilisé, seul le principe compte.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
Class Bibliothèque {
private
Livre mesLivres [];
}
Class Livre{
private
Auteur mesAuteurs[];
Bibliothèque maBibliothèque;
}
Class Auteur {
private
Classe_L4 mesClassesL4[];
Livre monLivre;
}
Class Classe_L4 {
private
Auteur monAuteur;
} |
Quel est mon problème !
Si je suis l'implémentation par les classes proposées, la "simple" fenêtre donnant la liste des bibliothèque comportera bien des objets de la classe Bibliothèque. Or celle-ci contient une collection de Livre, eux-même une collection d'Auteurs et ainsi de suite pour les niveaux suivants.
Est-ce normal d'avoir autant de données pour une "simple liste" de bibliothèques ?
Le membres sous forme de collection des différentes classes, en suivant la navigation des associations, peut ainsi retourner une quantité impressionnante de données de la base.
Ai-je tout faux dans mon raisonnement ?
Merci pour vos réponses qui ne manqueront pas de m'éclairer.
Cordialement,
Cela dépend de l'utilisation d'UML que vous faites
Quelques remarques:
- sur la multiplicité: cela dépend de vos besoins. Si vous n'avez à gérer qu'une seule bibliothèque, qu'un seul lieu, alors votre multiplicité à 1 entre livre et bibliothèque peut être OK. Sinon le lien est multiple. Si vous avez plusieurs exemplaires d'un même ouvrage, alors votre relation entre livre et auteur est trop simple là aussi. Tout dépend du problème auquel vous voulez répondre.
- sur l'implémentation des relations entre objets: en faisant l'hypothèse que votre modèle UML est un modèle de conception, une classe UML génère au moins 1 classe en source, en général plusieurs: une classe dans votre langage côté serveur, une autre côté client, une interface, une table dans la base de données, éventuellement un DTD dans XML, etc. Les relations se traduisent suivant les implémentations en pointeurs ou en références, en indexes de tables ou en identifiants uniques. Si vous voulez représenter un objet dans un autre, vous pouvez utiliser la relation d'aggrégation forte (losange noire). Si la multiplicité est simple, cela peut se traduire directement par un objet composant dans son composite. Si la multiplicité est multiple, cela peut éventuellement se traduire par un tableau d'objets. L'implémentation finale dépend des capacités et limitations de votre langage d'implémentation. Si la multiplicité est multiple des deux côtés, alors il est impossible d'avoir une relation de composition correcte.
- sur la modélisation: vous avez intérêt à lire Peter Coad, qui peut vous donner de bonnes indications sur les différents types d'objet dans une modélisation: UML en couleurs.
Cordialement,
Thierry
