Discussion :

[Sojiro0]

Bonjour à toutes et à tous !

Actuellement en train de modéliser un système lié au domaine commercial, je me retrouve coincé lors de la modélisation d'un cas qui, à mon avis, à largement du être couvert d'une manière ou d'une autre par quelqu'un. Malheureusement, je ne trouve aucun exemple publié concernant ce cas (soit je cherche mal, soit l'information est bien cachée voir jalousement gardée )

Dans le cas de figure que je vais vous présenter, je vais restreindre le nombre d"information à l'essentiel pour que l'on puisse se concentrer sur le problème qui motive ma présence.

Description du cas -> Nous modélisons deux classes : Article et Fournisseur. Un article peut être vendu par 0 ou plusieurs fournisseur (un article vendu un jour par un fournisseur peut ne plus être vendu le lendemain, mais toujours exister) et un fournisseur quand à lui, peut vendre 0 à plusieurs articles.
Chaque article dispose d'un certain nombre d'attribut, dont un qui nous intéresse tout particulièrement : le prix de vente. Le cas standard voudrait qu'un article ait un prix définit. OR, en fonction du fournisseur, de l'article, et de la quantité désiré, le prix peut être amené à varier ! (sur une base de tarifs définis)

Ex: pour l'achat d'un stylo bleu chez le fournisseur 1:
Quantité souhaité :1x => Prix 1€ l'unité
Quantité souhaité > 10x => Prix 0,9€ l'unité
Quantité souhaité > 100x => Prix 0,85€ l'unité

Pour le même style mais chez le fournisseur 2:
Quantité souhaité :1x => Prix 1€ l'unité
Quantité souhaité > 10x => Prix 0,95€ l'unité
Quantité souhaité > 100x => Prix 0,8€ l'unité

Là, je bloque. Ici il m'est nécessaire de définir un attribut avec une ou plusieurs listes à double entrées (quantité, prix) pour chaque article, mais:

• Je ne sais pas si c'est faisable - sachant que cela est possible pour une liste à entrée unique - et après de nombreuses recherches je n'ai toujours pas la réponse,
• Si ce n'est pas faisable, quel doit être mon angle d'attaque ? Dois-je considérer une nouvelle classe "listePrix" qui disposera de deux attributs définit par des listes simples ?

PS: en parallèle, je vais continuer de me pencher sur la question et vous tiendrais au courant lors d'éventuelle trouvaille

PS2: il semblerait que j'ai posté ce message dans la mauvaise section, si un modérateur pouvais déplacer le sujet dans la section appropriée (diagramme de classe), je lui en serais gré.

Je vous remercie par avance pour avoir pris le temps de me lire,
Sojiro0

[Sojiro0]

Je vois bien cette solution, même si je ne suis pas totalement convaincu...

[bruno_pages]

Bonjour,

...
Là, je bloque. Ici il m'est nécessaire de définir un attribut avec une ou plusieurs listes à double entrées (quantité, prix) pour chaque article, mais:

• Je ne sais pas si c'est faisable - sachant que cela est possible pour une liste à entrée unique - et après de nombreuses recherches je n'ai toujours pas la réponse,
• ...

Ce que vous décrivez n'est pas une liste mais est une table d'association (map) dont la clé est un type ayant deux attributs (quantité, prix), c'est tout à fait faisable

Mais le problème risque d'être encore plus complexe car le prix risque aussi de varier dans le temps, ce qui rajoute un attribut (i.e. quantité, prix, date)
Le fait que vous vous posiez des questions à ce propos doit vous inciter à vous demander si vous n'êtes pas en train de vous fourvoyer en voulant associer le prix du produit au produit lui même

PS2: il semblerait que j'ai posté ce message dans la mauvaise section, si un modérateur pouvais déplacer le sujet dans la section appropriée (diagramme de classe), je lui en serais gré.

sujet déplacé

[Sojiro0]

Ce que vous décrivez n'est pas une liste mais est une table d'association (map) dont la clé est un type ayant deux attributs (quantité, prix), c'est tout à fait faisable

Mais le problème risque d'être encore plus complexe car le prix risque aussi de varier dans le temps, ce qui rajoute un attribut (i.e. quantité, prix, date)
Le fait que vous vous posiez des questions à ce propos doit vous inciter à vous demander si vous n'êtes pas en train de vous fourvoyer en voulant associer le prix du produit au produit lui même

Effectivement, j'ai complètement oublié la notion de "temps de validité" sur le prix (alors que je l'ai intégré à d'autres endroits...je fatigue il semblerait )

Si j'applique l'idée de la classe association, je devrais transformer le diagramme de la sorte (sauf erreur de ma part) :

Cependant, quelque chose me gêne ici : sur une classe association, il n'y a aucune notion de cardinalité (normal me direz-vous). Cependant, ce modèle ne représente pas la possibilité d'avoir plusieurs listes de prix pour un même produit chez un même fournisseur. Le problème devient d'autant plus flagrant quand on imagine un produit vendu non pas par un mais plusieurs fournisseurs.

J'aurai donc imaginé quelque chose de la sorte :

Là encore, j'ai un souci, car rien ne "lie" la liste de prix à un fournisseur. Un article peut être vendu chez le fournisseur 1 et 2 et posséder une liste de prix A et B, cependant, savoir que la liste A est liée au fournisseur 1 n'est pas évident.

Enfin, dernière chose à laquelle j'ai pensé, mais que j'aurais voulu éviter : l'association N-aires.

Je ne suis pas certain des cardinalités sur cette dernière, je ne suis pas habitué au N-aires je vous avoue

PS: en ce qui concerne les dates, ne tenez pas compte du type d’attribut affiché dans chaque image...qui doit évidement être "date"

Qu'en pensez vous ?

[bruno_pages]

Une relation N-aire n'est qu'une représentation simplifiées de plusieurs relations, autant mettre les 'vraies' relations (c'est pour cela que je ne les ai pas mises dans Bouml)

Est-il bien utile qu'un article connaisse son prix d'achat (effectué ou potentiel) et ses fournisseurs (utilisés ou potentiels) ? je ne pense pas

Par contre votre classe fournisseur doit avoir une relation (unidirectionnelle) vers les produits disponibles, une autre (bidirectionnelle) vers des devis et une autre (bidirectionnelle) vers des factures

[Sojiro0]

Est-il bien utile qu'un article connaisse son prix d'achat (effectué ou potentiel) et ses fournisseurs (utilisés ou potentiels) ? je ne pense pas

En l’occurrence, c'est le cas

Pour expliquer plus précisément la situation, nous recevons chaque début d'année, et pour chaque fournisseur, un catalogue de prix sur leurs articles, valable pour l'année sauf exception. Entre chaque catalogue, nous retrouvons souvent des produits identiques (qualité inclue). Bien souvent les tarifs diffèrent entre chacun des fournisseurs en fonction de certains critères (quantité, surface commandée, ect...). L'idée est de pouvoir faire un comparatif entre chaque tarif proposé en fonction des volumes à commander, et cela, sur tous les articles.

Nous ne sommes pas le client final, l'article acheté chez un fournisseur est transformé chez nous pour être revendu par la suite.

Enfin, je comprends le diagramme décrit précédemment. Étant donné que le devis porte la notion de tarification sur l'article, il est alors inutile d'avoir l'information sur ce dernier. Cependant dans notre cas, l'information doit être accessible avant même l'opération de devisage, d'où mon instance sur ce point-là

Si vous pensez que je suis dans l'erreur, n'hésitez pas à me le dire

[bruno_pages]

ah oui votre cas est particulier, je me mettais dans le cas 'standard' d'un acheteur

si j'ai bien compris en entrée vous avez (éventuellement itérativement) un article et une quantité (ou information équivalente comme une surface pour par exemple du carrelage) et vous voulez trouver le fournisseur le moins cher

votre question renvoie à l’éternelle dilemme taille des données versus temps d'exécution. Une solution intermédiaire peut être que chaque article connaisse ses fournisseurs et rien de plus directement, ensuite chaque fournisseur connait les articles vendus et les conditions de prix, la classe fournisseur ayant l'opération prix prenant un article et une quantité et retournant le prix d'achat pour ces 2 critères, la classe article ayant une opération meilleurPrix prenant une quantité et retournant le cout et fournisseur calculés en itérant sur ses fournisseurs et comparant les prix retournés par l'opération du fournisseur

je n'ai pas mis le diagramme de classes mais il se déduit facilement, n'utilisez des relations bidirectionnelles que lorsque cela est vraiment justifier, car elles prennent de la place et sont plus difficile à gérer que les relations unidirectionnelles

[Sojiro0]

si j'ai bien compris en entrée vous avez (éventuellement itérativement) un article et une quantité (ou information équivalente comme une surface pour par exemple du carrelage) et vous voulez trouver le fournisseur le moins cher

Exactement !

votre question renvoie à l’éternelle dilemme taille des données versus temps d'exécution.

En effet, une problématique rencontré dans tous les projets de taille respectable sur lesquels j'ai eu l'occasion de travailler

Une solution intermédiaire peut être que chaque article connaisse ses fournisseurs et rien de plus directement, ensuite chaque fournisseur connait les articles vendus et les conditions de prix, la classe fournisseur ayant l'opération prix prenant un article et une quantité et retournant le prix d'achat pour ces 2 critères, la classe article ayant une opération meilleurPrix prenant une quantité et retournant le cout et fournisseur calculés en itérant sur ses fournisseurs et comparant les prix retournés par l'opération du fournisseur

Intéressant comme solution, je pense même me diriger vers celle-ci. L'idée que l'article ne soit pas chargé d'une tonne de données me plait bien, sachant que ce dernier est déjà associé à un certain nombre d'autres classes. Pour le diagramme associé, effectivement, au vu des explications données il est assez simple à déduire.

Concernant les relations bidirectionnelles, merci pour l'information. Il est vrai que je n'ai pas réellement fait attention et ai abusé de ces dernières .

Merci en tout cas pour le temps que vous m'avez accordé. Tout cela aura eu le mérite de me faire avancer sur le sujet !