Discussion :

[ZeLL]

Salut tout le monde

Voila je suis actuellement en stage et je dois refaire une base de données.
Cette bases a pou but de gerer les contact d'une association, ainsi que ses manifestations.
Mon probleme se situe au niveau de la participation à une manifestation, j'ai fait une entité association "ParticipationManif" entre les entités contact et manifestation. Cette entité est relié par une association 1:1,n avec une entité Qualité. Qualité est le type de participant a la manifestation ( invité, officielle, organisateur, etudiant, participant payant ...), car tout les types de participants ont les meme attributs il n'y a donc pas de raison de faire un heritage.
Le probleme est qu'il y a une exeption (comme toujours!) pour les utilisateurs payant, je dois savoir quand ils payent et comment il payent.
Mon idée étaient de faire un héritage uniquement pour ce type de participants mais deux choses me géne.
*Premierement je ne trouve pas elegant de faire un heritage pour un seul type de participant, surtout que je devrait verifié a chaque fois si le participant payant a pour Qualité participant payant.
*Deuxiemement, il se peut que le participant payant s'inscrive et ne vienne pas; il faudrait alors rajouter dans la spécialisation ParticipantPayant un attribut "estVenue" mais s'il ne vient pas ce n'est plus un participant...
Je n'arrive pas a trouver de solution simple et elegante donc si quelqu'un a une idée, il est le bienvenue.
Merci d'avance

[BizuR]

Salut,

Je dois avouer que c'est pas evident de décrire un diagramme textuellement alors je vais tenter de répéter ce que tu as dit :

Tu veux décrire le comportement d'une participation a une manifestation ... sachant que pour chaque participation d'un contact à une manif ... il y a une qualité (type) ...

Jusque la c'est bon... mais après je ne comprend pas, tu veux dire que l'objet PaticipManif possèdes des attributs differents uniquement pour la qualité "payant" c'est bien ca ? Si ceci est juste... y a t il seulement l'attribut estVenue à ajouter ou bien d'autres ?

Si c'est le seul : rien ne t'empeche de le mettre génériquement pour tous les types de participations, c'est toujours intéressant de savoir qui est venu.

Si il y en a d'autres ... je dois dire que tu n'as pas vraiment le choix ...je ferai un heritage de ParticipManif en deux classes "Payant"/"Invites"... j'ai dejà eu un tel cas avec des reunions dont les attributs etaietn les mm quel que soit le type de reunion sauf pour une ou deux ... c'est ainsi que j'ai fonctionné et ca semblait assez elegant tout de même ...

[ZeLL]

oui tu as bien compris, en fait il y a d'autre attributs pour le participant payant, le prix, la date de payement et le moyen.
Ce qui me gene pour faire un heritage en deux entités comme tu le propose c'est que l'entité invités ne contiendrait aucun attributs, donc dois-je l implementer?
Si cette solution est correcte je devrait verifier a chaque fois (Trigger?)
que la specialisation de participationManif (non payant ou payant) est conforme avec sa relation avec l'entité qualité (invités, officiel, orga, payant...). Est ce une solution correcte en termes de cohérence?

[BizuR]

Bah, je pense même que c'est encore plus coherent pour la comprehension de l'architecture de ton prog ... alors que si tu ne faiait qu'un heritage de Payant, la compehension serait plus dure ....

la bonne idee, je pense , c'est de créer ParticipManif en classe abstraite, puis, deux classes partitions de ParticipManif (Invité et Payant) ... ca monterera bien que toute participation est soti payante, soit par invitation...

Pour le type qualité ... ca reste utile de garder l'association ... puisque, ainsi, ca t'éviteras de vérifier la nature d'un objet... tu auras juste a regarder la qualité. Libre à toi de l'enlever... et dans ce cas, met juste une association entre Invites et Qualité, ca te permettra de ne plus avoir de classes "vides" même si selon moi elle n'aurait pas été vide dans la mesure où elle possèdera surement des méthodes specifiques qui ne serviront pas dans "Payant"

[ZeLL]

Merci pour ton aide, je pense que tu as raison au niveau de la coherence
et surtout de la clareté.
Pour la classe abstraite et les méthodes je suis d'accord mais je fait du merise.
Je travaille avec case studio 2 et je ne sait pas comment indiquer une contrainte d'heritage XT alors si quelqu'un est au courant (une bouteille a la mer).