Discussion :

[djflex68]

Salut,

J'ai une petite question qui me triture l'esprit...
En merise, il est considéré comme une erreur qu'une association dont la cardinalité sur une des pattes est 1-1 soit porteuse de données.
Mais en est-il de même pour une classe d'association en UML ? En effet, comme cela fonctionne sur le même principe, on est en droit de se demander si ça s'applique aussi ...

Mon exemple :
Un commercial est rattaché à une agence pour une période donnée.
J'ai donc une classe d'association "Periode" entre "Commercial" et "Agence" avec une cardinalité 1..1 côté Agence (un commercial travaille dans une et une seule agence), 0..* côté Commercial (une agence contient plusieurs commerciaux). En merise c'est une erreur, mais en UML ?!

Qu'en pensez-vous ?

Merci

[bs606739]

Pour la représentation, la relation entre le commercial et l'agence est toujours présent mais au milieu de l'association, tu as des pointillés qui relie une autre classe qui est période.

Mais pour info.
Un commercial à une période donné travaille pour une agence
Mais Une agence à une période donnée à de 1 à plusieurs commerciaux.
Je me trompe???
Donc tu n'as toujours pas de lien 1-1 mais bien 1 (Agence) -1..* (Commercial)

[djflex68]

Tout d'abord merci pour ta réponse.

Oui la représentation est bien celle que j'ai utilisée.
En fait en Merise, c'est une erreur qu'une association porteuse de données ait une cardinalité 1-1 sur une de ses pattes.
Donc c'est pour ça que moi ça me choquait de modéliser quelque chose de très semblable en UML.

Maintenant on pourrait aussi se dire que, comme on "sort" la période pour la promouvoir en tant que classe, dans ce cas là un commercial peut travailler sur plusieurs agences.
En effet, pour une période donnée (mémorisée dans le commercial lui même), le commercial ne travaille que sur une agence. Par contre, si on "sort" la période, un commercial travaillera sur plusieurs agences (donc 1..*) ce qui résoudrait le "problème".




Mon raisonnement est-il cohérent ?

P.S : je pense que je m'étais mal exprimé lorsque j'ai dit "qu'une association de type 1-1 soir porteuse de données" car j'aurais du dire "qu'une association porteuse de données ait une cardinalité 1-1 sur une de ses pattes."

[Soutou]

En principe une classe assoc est réservée à des multiplicités * des 2 côtés. A partir de là, cette classes assoc peut être reliée à d'autres associations.
Quand tu as une mulltiplicité 1 d'un côté d'une assoc entre C1 et C2, tout attribut est soit dans C1 soit dans C2. Tu ne trouveras jamais un attribut qui dépende des 2. Si c'est le cas alors la multiplicité doit passer à *.

[Médiat]

En merise, il est considéré comme une erreur qu'une association dont la cardinalité sur une des pattes est 1-1 soit porteuse de données.

J'ignorais que Merise fut si précis sur ce point.
Personnellement j'utilise (et je préconise très fortement) cela sans vergogne (PowerAMC l'autorise sans problème), je trouve cette façon de présenter les choses beaucoup plus élégante (cela n'a aucun impact sur le modèle physique), puisque cela permet de regrouper les informations liés à l'association.

[Soutou]

Tu mettrais donc dateachat entre Avion et Compagnie dans la relation Acheter. Tout en sachant que cet attribut ira côté Avion au niveau logique et SQL.

Je trouve que ça perturbe la compréhension. Si tu avais aussi tauxReduc qui donne la réduction que chaque compagnie applique à tout achat, cet attribut serait dans la relation Acheter et irait ensuite côté Compagnie au niveau logique.

Mais bon, c'est pas grave. On est d'accord sur le fond.

[Médiat]

Tu mettrais donc dateachat entre Avion et Compagnie dans la relation Acheter. Tout en sachant que cet attribut ira côté Avion au niveau logique et SQL.

Nous sommes bien d'accord que je parle du niveau conceptuel, il me semble, justement, que dans ton exemple, la DateAchat de l'avion n'est pas intrinsèque à l'avion, mais bien à la relation Acheter, l'avion existe avant qu'il soit acheté, et ses caractéristiques ne sont pas changées par l'achat, conceptuellement, je vois bien deux "choses" différentes.

Si tu avais aussi tauxReduc qui donne la réduction que chaque compagnie applique à tout achat, cet attribut serait dans la relation Acheter et irait ensuite côté Compagnie au niveau logique.

Encore une fois ton exemple est démonstratif : le taux de réduction qu'une compagnie exige pour ses achats n'a rien à voir avec la compagnie en tant que telle (plus définie par ce qu'elle fait que par un taux de réduction)

Mais bon, c'est pas grave. On est d'accord sur le fond ( ).