[uml] classe d'association ou pas?

Version imprimable

08/11/2006, 15h13
tridoo

1 pièce(s) jointe(s)

[uml] classe d'association ou pas?

Voila mon problème :
je suis en train de modeliser une application de gestion de ressources dvd.
Chaque dvd est lié à un ou plusieurs réalisateurs, zero ou plusieurs producteurs, un ayant droit et zero ou plusieurs distributeurs.
Comme les attributs pour chacun d'entre eux sont équivalents, je les ai regroupé dans une classe "acteur".
Pour connaître le rôle d'un acteur dans un dvd préçis, j'ai créé une classe d'association "Contexte" entre "acteur" et "dvd". Celle-ci est en relation avec une classe "role" qui définie les différents types de rôlre possible.
Jusque là c'est correct, non?

Mais je souhaiterai aussi pouvoir récupérer pour un "acteur" tous les rôles qu'il a déjà effectué c-a-d sans m'intéresser à un "dvd" préçis.
Je pense relier cette classe "role" à acteur. Est-ce correct?
Merci d'avance
09/11/2006, 08h36
bruno_pages

j'avoue avoir un peu de mal à comprendre ton dessin, ce serait plus clair avec un vrai dessin réalisé grâce à un modeleur UML, ce ne sont pas les gratuits qui manquent (je suis assez bien placé pour le savoir ;) )

Concernant le regroupement des réalisateurs, producteurs etc en une classe acteur pourquoi pas, sans plus d'information il est difficile de juger, une architecture ne se fait pas sur un point précis mais sur une cohérence / pertinence globale.

Pour le dernier point (récupérer pour un "acteur" tous les rôles), la relation entre dvd et acteur est bidirectionelle, donc tu peux le faire sans 'relier' role à acteur (même si je ne sais pas vraiment ce que tu veux dire par 'relier')
09/11/2006, 14h47
Joshua Beharia

Hello,

ben je suis dans la même expectative que Bruno.
J'attends ton schéma et ta réflexion complète !

Mais je trouve ton architecture bancale...

@+
09/11/2006, 23h22
tridoo

2 pièce(s) jointe(s)

Tout d'abord, merci de vos réponses.
Pour ce qui est de mon problème, j'en suis à cette solution (inspiré du conseil de Bruno Pagès) : entre "ressource" (ex-"dvd") et "contact" (ex-"acteur") une classe d'association que j'ai nommé "contexte", elle-même liée (désolé pour la formulation...:oops: ) à une classe "role".
Le plus simple est que vous regardiez mon diagramme de classe (modélisé avec un outil développé en c++ trés léger et rapide que certains d'entre vous connaissent bien...;) ).
Vous vous apercevrez que je ne vous avez pas donné toutes les données de mon problème...
- En gros, on veut archiver des documents reçus (maison d'édition indépendante) qui peuvent être soit audiovisuels ou audio.
- De plus, ces documents arrivent souvent au sein de compilation.
- En tout cas, il faut pouvoir récupérer des informations sur realisateur(s), ayant droit, et eventuellement producteur(s), distributeur(s).
- Ceux-ci peuvent être des personnes ou bien des structures (collectif, maison d'édition, ...).
- Il faut aussi arriver à marquer (désolé... :oops: ) le(s) contact(s) privilégié(s) pour un document donné (oeuvre ou compil).

Je vais arrêter là.... Cependant, si mon projet vous passionne ou que vous trouvez quelque chose de bizarre, n'hésitez pas à me le faire savoir! :lol:
Quoi qu'il en soit merci d'avance à tous ceux qui prendront un peu de leur temps et de leur énergie pour se pencher sur ce problème.

[Edit] J'avais oublié de préciser que, si j'ai tout bien compris (ce qui n'est pas forcément gagné...), la classe d'association devient une classe à part entière en phase de conception (voir image pour les cardinalités).
10/11/2006, 13h07
bruno_pages
[Remplace ma réponse précédente]

Oui, la classe d'association devient une vraie classe, mais ce n'est pas pour cela que tu dois modifier ton diagramme, ou tout au moins sont aspect.

Je ne suis pas certain que tu puisses le faire avec un autre modeleur, mais avec Bouml tu peux très bien garder ton diagramme initial et générer un code prennant en compte la classe d'association.

Je m'explique sur un exemple plus simple, on veut cela :
http://bouml.fr/cl_assoc1.png

Si on ne fait rien de plus (les classes d'association ne sont pas traitées de façon particulière par Bouml), on obtient en C++ :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 class A { protected: B * b; }; class B { protected: A * a; }; class R { };
et en Java :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class A { protected B b; } class B { protected A a; } class R { }
Mais ce n'est pas ce que l'on veut au niveau attributs, ce serait plutôt du genre:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 class A { protected: R * r; }; class B { protected: R * r; }; class R { protected: A * a; B * b; };
et en Java :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class A { protected R r; } class B { protected R r; } class R { protected A a; protected B b; }
Et bien c'est possible, en faisant par exemple :
- tu édites la relation bidir et tu indiques qu'elle ne doit pas être générée en C++ et en Java, elle est donc seulement là pour le dessin
- tu ajoutes l'attribut 'r' de type R dans les classes A et B, en C++ tu dis de plus que c'est un pointeur (${type} * ${name})
- tu ajoutes l'attribut 'a' dans R de type A, en C++ tu dis que c'est un pointeur
- tu ajoutes l'attribut 'b' dans R de type B, en C++ tu dis que c'est un pointeur
- via les drawing settings tu caches l'attribut 'r' pour les classes A et B, et les attributs 'a' et 'b' pour la classe R
Note : j'utilise des attributs au lieu de relations car on peut plus facilement les cacher dans les diagrammes.

Le diagramme reste alors tel qu'il est, avec la classe d'association bien visible, et le code généré est celui désiré.

Note : la chose pourait être automatisée via un plug-out, sauf en ce qui concerne la modification des drawing settings car le contenu des diagrammes (au sens dessin) n'est pas (encore) accessible et modifiable via les plug-outs

C'est 8-) non ?
10/11/2006, 15h59
Nip

Je n'ai pas grand chose a rajouter sur les commentaires de Bruno concernant la classe d'association, qui est effectivement une classe a part entiere. Par contre je suis beaucoup plus mesure quand aux choix que tu as fait concernant ton diagramme de classe:
-Prenons le cas de l'heritage pour la classe contact. Je ne pense pas que ce soit la meilleure chose a faire sous le simple pretexte que une structure et une personne partage 3 attributs communs. Deja parce que une personne ou une structure N'EST PAS un type de contact. Ensuite creer des classes sans attribut ou juste avec un seul traduit plus un probleme de conception que une pseudo facilite d'utilisation ou de concision (pense a la maniere dont tu vas declarer ta classe personne!!). Une classe personne et une classe structure me paraissent indispensable; tu peux ensuite passer, si necessaire, les infos communes dans une classe coordonnees liee aux precedentes par une relation de composition (suppression de l'objet en cas de suppression du contenant).
-Les heritages en cascade! Fait tres attention, c'est vraiment le genre de conception qui peut amener a se tirer des balles. Tu es TOUJOURS amene a faire des modifications sur tes classes, toujours tout simplement parce que tout ne se prevoit pas; si tu modifies la classe mere tu vas modifier le comportement de 5 classes, autant te dire que c'est loin d'etre evident.
"Ressource et oeuvre" sont a passer dans la meme classe avec une relation d'agregation sur elle meme pour traduire la notion de compilation.
Tu peux conserver l'heritage pour audiovisuelle et audio.
-L'heritage pour morceau ne se justifie pas: une classe morceau{titre, compositeur, interprete} est suffisante.
-N'y a t'il pas de notion d'appartenance entre utilisateur et commentaire (je pense a une agregation plus qu'a la composition).
Quelques questions parce que je ne comprends pas tout: quelle est la difference entre audio et morceau? entre album (attribut de existant) et compilation? La difference entre une personne et un utilisateur? Un compositeur ou un interprete ne sont pas des personnes?
-Enfin inutile aussi de preciser le role des associations quand c'est evident: preciser "contient" ou "ecrit par" n'apporte rien, ca tombe sous le sens, et alourdit inutilement le diagramme.

Toutes mes propositions ne sont que des ...propositions et donc parfaitement discutables. Reste qu'il me parait indispensable de modifier la conception de ton appli :D.
12/11/2006, 18h21
tridoo
Désolé pour le temps de réaction, j'étais sur d'autres projets.

Citation:

Prenons le cas de l'heritage pour la classe contact. Je ne pense pas que ce soit la meilleure chose a faire sous le simple pretexte que une structure et une personne partage 3 attributs communs. Deja parce que une personne ou une structure N'EST PAS un type de contact. Ensuite creer des classes sans attribut ou juste avec un seul traduit plus un probleme de conception que une pseudo facilite d'utilisation ou de concision (pense a la maniere dont tu vas declarer ta classe personne!!). Une classe personne et une classe structure me paraissent indispensable; tu peux ensuite passer, si necessaire, les infos communes dans une classe coordonnees liee aux precedentes par une relation de composition (suppression de l'objet en cas de suppression du contenant).

Ce choix vient du fait que les "contacts" pour une ressource peuvent être des personnes, ou des structures, ou encore des personnes et des structures...
Il faut alors que la classe d'association "Contexte" soit associée aux deux associations reliant "Ressource" à "Personne" d'une part, et "Structure" d'autre part. Est-ce à cela que tu pensais?
Pour éviter l'héritage, je pencherais plutôt pour une association reflexive sur la classe "Contact" de type agrégation avec pour rôle personne et structure.
Qu'en pensez-vous?

Citation:

Les heritages en cascade! Fait tres attention, c'est vraiment le genre de conception qui peut amener a se tirer des balles. Tu es TOUJOURS amene a faire des modifications sur tes classes, toujours tout simplement parce que tout ne se prevoit pas; si tu modifies la classe mere tu vas modifier le comportement de 5 classes, autant te dire que c'est loin d'etre evident.
"Ressource et oeuvre" sont a passer dans la meme classe avec une relation d'agregation sur elle meme pour traduire la notion de compilation.
Tu peux conserver l'heritage pour audiovisuelle et audio.

Il y a peu de chance que je le remodifie souvent par la suite car c'est dans le cadre de ma formation. Pour cette raison, je reste trés attaché à la dimension sémantique du modèle.

Citation:

L'heritage pour morceau ne se justifie pas: une classe morceau{titre, compositeur, interprete} est suffisante.

Tu as raison. Une classe unique avec un booléen qui indique si c'est un morceau original ou non devrait suffire.

Citation:

N'y a t'il pas de notion d'appartenance entre utilisateur et commentaire (je pense a une agregation plus qu'a la composition).

Tu as encore raison. Un oubli de ma part.

Citation:

Enfin inutile aussi de preciser le role des associations quand c'est evident: preciser "contient" ou "ecrit par" n'apporte rien, ca tombe sous le sens, et alourdit inutilement le diagramme.

Tout à fait d'accord avec toi mais c'est la façon de faire qu'on m'a enseigné...

Citation:

Quelques questions parce que je ne comprends pas tout: quelle est la difference entre audio et morceau? entre album (attribut de existant) et compilation? La difference entre une personne et un utilisateur? Un compositeur ou un interprete ne sont pas des personnes?

"
- Audio" concerne des documents audio reçus (documentaire, interview, ...) par l'asso alors que "Morceau" concerne les morceaux inclus dans une oeuvre (audio ou audiovisuellle).
- "album" est tout simplement une reference à un album dans lequel se trouve le morceau en question. "Compilation" concerne les oeuvres. Les court-métrages sortent souvent au sein de compilations produites par des maisons d'édition. Il faut donc qu'on recense comme une "Ressource" celles-ci afin de pouvoir gérer notamment les dates de reception, de réponse, les coordonnées du producteur(s), etc....
- la classe Utilisateur ne sert qu'à gérer les identifiants de connexion.
- on ne veut pas stocker d'info sur les interprètes, les compositeurs, ....
  Je ne voie donc quel intérêt j'aurais à les inclure dans la classe "personne".
  De plus, si j'allais dans ce sens, il faudrait le faire pour tous les techniciens (pour l'instant un simple attribut dans les classes Oeuvre et Audiovisuelle).
  Voilou