Discussion :

[wiss0507]

Pourquoi il faut pas faire un boucle entre trois ou quatre classes?
Lorsqu'on a par exemple des relations:
Marchandise_Fournisseur
Fournisseur_Facture
Facture_Client
Client_Marchandise
MERCI D'AVANCE

[ego]

Qui a dit ça ?
Pas moi en tout cas

[enamorada]

Est-ce que c'est logique de faire une boucle entre 3 ou 4 classes ?
svp j'aurais besoin d'une réponse.

[bruno_pages]

ego a déjà répondu pour dire qu'avoir des relations en boucle entre des classes est bien évidemment permis

par contre cela n'est pas forcément 'logique', ce qui est possible dans le cas général n'est pas nécessairement un bon choix pour un cas particulier donné.

sans plus d'information sur votre cas il ne nous est pas possible d'en dire plus et de dépasser le cadre des généralités, publiez votre diagramme et nous pourrons être plus précis

[fsmrel]

Bonjour,

Pourquoi il ne faut pas faire une boucle entre trois ou quatre classes?
Lorsqu'on a par exemple des relations:
Marchandise_Fournisseur
Fournisseur_Facture
Facture_Client
Client_Marchandise

L’exemple que vous donnez est conceptuellement mauvais si on le prend au pied de la lettre. En effet, vous mettez manifestement en oeuvre une seule classe FACTURE et mélangez donc les factures des clients et celles des fournisseurs. Etant donné qu’une facture fournisseur fait nécessairement référence à un fournisseur et qu’une facture client fait nécessairement référence à un client, une facture donnée doit par conséquent faire référence à la fois à un client et à un fournisseur, ce qui constitue une anomalie : pour corriger le tir, il faut donc une classe pour les factures des clients et une classe pour les factures des fournisseurs, ce qui rompt la boucle dont vous faites mention.


Cela dit, pour confirmer ce qu’ont répondu ego et Bruno, il existe des situations où les boucles sont justifiées (graphiquement parlant). Par exemple, certaines personnes de l’entreprise sont habilitées à utiliser des cartes bancaires de l’entreprise : on modélise donc l’habilitation des personnes à utiliser ces cartes. Maintenant, une de ces personnes passe une commande en utilisant une de ces cartes : si on veut savoir qui a passé telle commande et avec quelle carte, il y aura introduction d’une boucle dans la représentation graphique. La situation que l’on peut rencontrer est alors celle-ci :

La commande CD1 a été réglée par Raoul ;
La commande CD1 a été réglée avec la carte CB3 ;
Mais Raoul ne fait pas partie des utilisateurs de la carte CB3.

Si dans le règlement de l’entreprise ceci est interdit, il y a donc une contrainte à mettre en œuvre pour éviter l’infraction.

[fsmrel]

Dans la suite de mon message, voici des exemples pour illustrer (à faire valider par Bruno et ego ! Il m'arrive d'être distrait... )


1) Exemple de boucle fautive :




2) Elimination de la boucle :




3) Exemple de boucle légitime (et légale) :

Certaines personnes de l’entreprise ont l’autorisation d’utiliser telle ou telle carte pour passer des commandes.

[bmoraut]

Est-ce que c'est logique de faire une boucle entre 3 ou 4 classes ?
svp j'aurais besoin d'une réponse.

En effet, je vois ce que tu veux faire:
C'est établir que la Marchandise qui a été achetée à un fournisseur, puis facturée au Client,
est une marchandise "achetée" par ce même client.

Cette boucle est logique, mais je te conseil de créer une relation que l'on appel de type "Log":
Liste des Marchandises achetée par chaque client.
Car la marchandise ne sera peut être pas achetée par un seul client.

Donc une mono-boucle est illogique.

Révise tes modèles de conceptions

[escartefigue]

bmoraut, vous répondez à un sujet qui date de 2014... il est assez peu probable que l'intéressé vous réponde !

Cela étant dit, votre raisonnement est incomplet.
Non seulement il est rare que toutes les marchandises facturées par un fournisseur sur une facture F1 aillent chez un et un seul client comme vous le mentionnez justement, mais aussi, il est encore plus rare que les deux actions soient simultanées.
De plus, certains achats fournisseurs ne partent jamais chez les clients (ex : les factures d'énergie, les consommables, les composants servant à la fabrication…)
Bref client et fournisseurs sont deux types d'entité différents (ou classes d'entités en UML) et par conséquent, les associations les concernant sont également distinctes.