Discussion :

[tridoo]

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

[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')

[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...

@+

[tridoo]

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... ) à 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é... ) 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!
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).

[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 :


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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 non ?

[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 .