Discussion :

[OkDak]

Bonjour,
je suis en projet final de formation et je n'ai pas trouvé de stage
Mais j'ai quand même trouvé un client et j'ai donc un site de vêtements à créer.
Pourriez-vous s'il vous plait me donner votre avis sur mon MCD en sachant bien sur qu'il est bourré d'erreurs et que c'est un premier brouillon. HEUREUSEMENT


Comme je vous l'ai dit ou pas, je suis beaucoup perdu.
Votre avis me sera précieux...
Merci

[escartefigue]

Bonjour OkDak et bienvenue sur ce forum

Avant de présenter votre MCD, il aurait fallu expliquer un peu le contexte et rédiger vos règles de gestion.

Cela étant, on peut quand même formuler quelques remarques.

Type d'entité CLIENT
Avoir mis l'adresse ici signifie que vous gérez une et une seule adresse pour un client. C'est fréquent pour les clients personnes physiques, beaucoup moins pour les clients personne morale qui ont souvent une adresse de facturation, une ou plusieurs adresses de livraison, une adresse du siège, une adresse du service contentieux...
Même remarque pour les téléphones.
Si le besoin est zéro à plusieurs adresses et/ou téléphone, il faut créer des types d'entité [ADRESSE] et [TELEPHONE] (ou [MEDIA]) en lien avec le client


association "passer"
La cardinalité mini zéro coté client signifie qu'un prospect est enregistré au même titre qu'un client, pourquoi pas, mais à confirmer au travers de vos règles de gestion.


association "asso 12"
une commande ne saurait exister sans ligne de commande, il faut donc une cardinalité mini de un coté commande


association "editer"
Associer la facture en relation 1,1 avec la commande revient à ne faire qu'un de l'un et l'autre.
De la même façon, une commande pas encore livrée est déjà facturée, est-ce bien ce qui est souhaité ? (à confirmer au travers de règles de gestion)
Egalement, cette cardinalité 1,1 signifie qu'on ne peut pas facturer plusieurs commandes d'un même client en une seule fois, est-ce là aussi ce qui est souhaité ? (règles de gestion...)
Quoi qu'il en soit, l'édition doit pouvoir être faite plusieurs fois (ex : le client a perdu sa facture). Il faut renommer cette association.


Type d'entité FACTURE
L'attribut "nom facture" me surprend... de quoi s'agit il ?
Dans la facture, il faut le montant HT, le montant TVA, le taux d'escompte pour règlement anticipé, les conditions de paiement (ex : au comptant, 30 J fin de mois...), les conditions de port (franco, départ usine...)


Type d'entité LIGNE COMMANDE
positionner le prix ici est judicieux s'il varie en fonction de la commande, sinon il peut être positionné au niveau article.
Par contre, la TVA ne devrait pas être fonction de la commande. Soit le client est assujetti et le type de TVA dépendra du produit, soit le client n'est pas assujetti.
Si l'unité de mesure de la commande peut être différente de celle du produit, alors il faut ajouter cette unité de mesure dans une nouvelle entité-type en lien avec le produit d'une part et la ligne de commande d'autre part. Il faudra prévoir également une table de conversion d'une unité de mesure vers une autre.


association "asso 11"
Une ligne de commande c'est un et un seul produit, il faut donc mettre 1,1 coté ligne de commande


Type d'entité PRODUIT
Le stock à ce niveau n'a de sens que si les produits ne sont pas stockés par entrepôt, magasin, emplacement. Sinon il faut ajouter les types d'entité correspondants.
La date de création d'un produit n'a pas vraiment de sens. Par exemple, si j'ai 10 pots de peinture de même référence en stock, peut être que 5 d'entre eux ont été fabriqués en février 2020 et les 5 autres en janvier 2021. La date de fabrication est liée au lot de fabrication si géré, à défaut à chaque occurrence de produit.


association "asso 10"
Un seul taux de TVA peut être associé à un produit à un instant "t". Donc, soit il faut ajouter une entité-type DATE en lien avec cette association, soit il faut modifier la cardinalité coté produit en 1,1


association "effectuer"
Selon que la livraison concerne les livraisons en provenance du fournisseur ou à destination du client, il faut rattacher cette association à l'une ou l'autre entité-type.
Ensuite, il faut préciser (encore les règles de gestion) si une livraison ne concerne qu'un et un seul produit (peu probable) ou un assortiment de produits correspondant à une ou plusieurs commandes client ou fournisseur.


Le type d'entité "Prix" et l'association "taxer" sont isolés dans un coin sans doute un oubli ?

[OkDak]

Merci beaucoup pour toutes vos infos, elles me sont d'une grande aide.
Je poste le screen une fois modifié...
Merci encore

[escartefigue]

J'avais oublié : l'association "commander" entre "client" et "produit" n'a pas lieu d'être, car elle autorise de commander sans passer par une commande

[OkDak]

Bonjour et merci encore pour vos infos.
Voilà ce que ça donne :


Qu'en pensez-vous ?

[escartefigue]

Bonjour,

Tout d'abord, je ne suis pas habitué à la représentation UML à laquelle je préfère nettement le modèle entité-association.

Ensuite, vous n'avez toujours pas rédigé les règles de gestion, or, c'est une étape essentielle sans laquelle aucune validation du MCD n'est possible.
Elle se présentent sous la forme d'un identifiant de règle et d'un libellé, par exemple :
[...]
R005a : un client peut passer zéro à plusieurs commandes
R005b : une commande est passée par un seul client
[...]
R012a : une commande contient au moins une ligne de commande
R012b : une ligne de commande est contenue dans une seule commande
etc.

Attention à vos cardinalités qui sont souvent erronées ou inversées. Par exemple, il faut 1 coté client et * coté adresse, de même 1 coté client et * coté commande, idem pour produit et catégorie etc.

Le fait d'avoir rattaché la livraison à la commande et non à la ligne de commande (au travers de lignes de livraison) signifie que la livraison est toujours strictement conforme à la commande. S'il manque une partie de la commande, pas de livraison...
Je doute que ça corresponde à la réalité. À confirmer par les règles de gestion.
C'est quoi le "nom" d'une livraison ?

Pour la gestion des adresses françaises, il est recommandé de suivre la norme postale. Cette norme est accessible gratuitement sur le web.
La ville doit être sortie de l'entité-type adresse, il faut créer une nouvelle entité-type ville, associée à l'adresse.

Pour les téléphones, l'attribut "nom" est inapproprié, "numero" est plus adapté

"rôle" et "token" n'étant pas expliqués, je suis incapable d'être critique à leur sujet

"facture" est associée à "commande" et vous facturez dès la commande avec éventuellement plusieurs factures pour une commande. C'est plutôt curieux.
En effet, comme vu plus haut, la livraison concerne la totalité de la commande, on peut donc supposer qu'une seule facture par commande suffit.
Reste à savoir si vous facturez vraiment dès la commande (c'est ce qu'indique votre modèle) ou si vous ne facturez qu'après avoir livré.
Ca aussi il faut l'écrire sous forme de règles de gestion.
Si vos règles de gestion stipuleront qu'une commande fait l'objet d'une et une seule facture établie dès la commande, alors on pourra n'avoir qu'une seule entité-type pour les deux.

[Paprick]

Bonjour,

Attention à vos cardinalités qui sont souvent erronées ou inversées. Par exemple, il faut 1 coté client et * coté adresse, de même 1 coté client et * coté commande, idem pour produit et catégorie etc.

Et oui, attention aux sens des cardinalités qui sont inversées en UML par rapport à un schéma entité-association.
D'ailleurs, je rejoints escartefigue pour sa préférence pour les schémas E/A qui sont, à mon sens, bien plus clairs et expressifs que les diagrammes de classes UML.

[OkDak]

Bonjour,
je comprends bien votre point de vu sauf qu'on nous impose cette façon de travailler...
Pour le reste, je me repenche dessus.
Merci encore...

[escartefigue]

Si par "façon de travailler" il faut comprendre "produire un diagramme UML" alors, avec certains outils de modélisation (comme Looping), vous pouvez basculer d'un modèle E/A vers un modèle IML et inversement par un simple clic.
Du coup, rien de plus facile que de faire valider vos propositions ici sous forme E/A et de basculer en mode UML pour votre soutenance
Et si vous positionnez correctement les cardinalités du modèle E/A elles seront automatiquement inversées par le logiciel de modélisation lors de la bascule en modèle UML

[OkDak]

Si par "façon de travailler" il faut comprendre "produire un diagramme UML" alors, avec certains outils de modélisation (comme Looping), vous pouvez basculer d'un modèle E/A vers un modèle IML et inversement par un simple clic.
Du coup, rien de plus facile que de faire valider vos propositions ici sous forme E/A et de basculer en mode UML pour votre soutenance
Et si vous positionnez correctement les cardinalités du modèle E/A elles seront automatiquement inversées par le logiciel de modélisation lors de la bascule en modèle UML

Ils ne veulent pas...
On doit le jour du titre présenter un diagramme de classe, de séquence et tout ce qui va avec et malheureusement dans ce format mais je vais regarder ça.
Merci à tous...