Discussion :

[_medi]

Bonjour,

Je dois faire la conception d’un système d’information d’une société, ce système concerne toutes les informations des clients (produits achetés, quantités,…), des produits, et des concurrents (produits, quantités, situation dans le marché, leurs clients, …) mon cahier de charge est cette schéma ci-dessus !

alors je veux savoir comment je vais procéder ! d'un autre termes quels sont les étapes que je dois faire ? et aussi quels sont les diagrammes que je dois faire ?

sinon, Merci

[CinePhil]

Ce schéma est ce qu'on t'a donné ou le fruit de ta première analyse ?

Difficile de te répondre sans connaître le besoin.

[_medi]

Bonjour,

merci pour votre réponse Cinephil

Oui c'est ce qu'on ma donné comme cahier de charge !

j'ai déja exepliquer les besoins !

la conception d’un système d’information d’une société, ce système concerne toutes les informations des clients (produits achetés, quantités,…), des produits, et des concurrents (produits, quantités, situation dans le marché, leurs clients, …)

[CinePhil]

Un cahier des charges, c'est un ensemble de besoins exprimés.
Par exemple, le système doit me permettre de :
- ajouter, modifier un client ;
- ajouter, modifier une usine pour un client ;
- savoir quelles matières premières utilisent les produits ;
- savoir combien de matières premières ont été consommées dans le mois, dasn le trimestre ou dans l'année ;
- savoir combien de clients ont des usines en Chine...

Déjà dans ton schéma, il me semble qu'il y a quelques erreurs (mais je maîtrise mieux le MCD Merise que le diagramme de classe UML alors je peux me tromper) :
- la classe 'Clients_OCP&Pays' n'est reliée qu'à 'Pays' alors qu'elle contient le 'Code_Client' ;
- la classe 'Produits_client&MatièrePremière' devrait, il me semble être reliée à la classe 'Produits_Client' plutôt qu'à la classe associative 'Clients_OCP&Produits'.

Il faut donc commencer par revoir ton schéma et sans doute le compléter des informations manquantes exprimées dans ton texte :
- concurrents et leurs clients (qui ne sont pas forcément les notres mais peuvent être pour nous des prospects) ;
- quantités achetées...

[_medi]

MERCI POUR VOTRE PRECIEUSE AIDE Cinephil.

Mais j’ai un problème avec l’entité concurrent ! Elle sera en relation avec quelles entités ? Aussi pour leurs clients (prospects) !!
Vous pouvez aussi me signalé les erreurs que vous avez remarquez !

[CinePhil]

Puisqu'on est en UML, on peut aussi imaginer une classe 'Entreprises' qui aurait des sous-classes 'Clients', 'Prospects' et 'Concurrents', lesquelles hériteraient de la classe 'Entreprise' et auraient leurs propres propriétés non généralisables dans 'Entreprises'.

'Coordonnées' et 'Contacts' pourraient être reliées à 'Entreprises' et contiendraient donc des coordonnées et des contacts des 3 types d'entreprises.

L'avantage de ce système est les coordonnées et les contatcs d'un prospect devenu client ne changeront pas de table.

Ce qui peut être gênant il me semble, (encore une fois je ne suis pas expert en UML), c'est qu'un concurrent peut aussi être un client ou même un fournisseur (on n'en a pas parlé de ceux-là !) quand il y a de la sous-traitance sur un même métier. C'est très fréquent dans les entreprises de bâtiment par exemple. Dans ce cas, je ne sais pas si un même objet 'Entreprise X' peut à la fois figurer dans 'Clients' et 'Concurrents'.

[_medi]

MERCI encore une fois pour votre précieuse aide Cinphil

Si si vous êtes expert en UML d’après vos réponses (en tout cas par rapport à moi) !

Alors à votre à vis qui ce que je dois faire dans le cas ou un concurrent peut aussi être un client ou même un fournisseur’ ??

d’après la structure que vous avez proposer ‘'Entreprises' qui aurait des sous-classes 'Clients', 'Prospects' et 'Concurrents', lesquelles hériteraient de la classe 'Entreprise' et auraient leurs propres propriétés non généralisables dans 'Entreprises'.’ L’entité produit sera en relation avec l’entité client ! Mais pour les produits des concurrents comment je vais faire ?? aussi les clients des concurrents ??


Aussi vous pouvez me donné une schéma globale avec toute les entités possible ??

[_medi]

Bonjour,

Alors pour être encore plus claire dans ma question, en plus de la structure de la base j'ai rédigé les besoins des système

Besoins du système :

1- Pour un client, en plus de ses cordonnées, il faut avoir des informations sur les produits qui achètent, la quantité, les usines ou ses produits sont utilisés, ville (ou pays) de l’usine, nationalité du client.

2- Pour un concurrent il faut savoir les produits qui produisent avec les quantités, ses clients et les informations sur ces clients. (un concurrent peut être un de nos client)

3- Les différents produits que nous produisant avec les quantités !

Pour en plus de la gestion (ajout, suppression, modification,..) faire des graphes et des camembert monteront la production et les consommations !!

Je pense maintenant que je suis assez claire et que j’aurai plus des réponses !
ma question encore une fois qu'ils sont les différent entités ?

[CinePhil]

A la réflexion, mon système d'héritage doit marcher même avec un concurrent client.
La classe Entreprises peut être identifiée par un identifiant et son nom (+ d'autres informations selon le besoin), la classe Clients peut comporter le numéro de client (le compte client dans la comptabilité pourquoi pas), la classe Concurrent peut comporter la part de marché... Rien n'empêche à mon avis qu'une Entreprise soit aussi un Client et un Concurrent.

Pour maîtriser les quatités des produits, tu auras besoin de relier d'une manière ou d'une autre ton système à celui des commandes clients et des achats fournisseurs. A moins que ton service marketing ne travaille que sur des ordres de grandeurs qu'ils pompent d'ailleurs et qu'ils ressaisissent directement dans leur système. Dans ce cas, tu peux facilement faire la relation entre Produits et Clients et entre Produits et Concurrents...

Voilà encore quelques pistes mais ton besoin reste à préciser.
Si tu dois vraiement reprendre le système existant pour le compléter ou l'améliorer, interroge les utilisateurs sur la manière dont ils travaillent actuellement, ce qu'ils utilisent réellement (y compris les formulaires papier), ce dont ils ont besoin, ce qui ne leur plaît pas dans le système actuel...

[_medi]

Bonjour,

Oui je suis tout a fais d’accord avec vous Cinephil, mais je ne crois pas que j’aurai besoin d’une classe ‘fournisseur’ (pourquoi faire ? puisque notre société elle fais vendre ses produits et elle ne fais pas appelle à des fournisseurs !)

Aussi je veux savoir comment je vais faire pour identifier les clients et les produits de nos concurrents ?

[CinePhil]

Les produits peuvent être ceux de l'entreprise ou ceux des clients ou ceux des concurrents, dans une même table.

Un produit peut être (ou pas) vendu par un ou plusieurs concurrents tout comme il peut être (ou pas) acheté par un ou plusieurs clients.
De même, un concurrent peut vendre (ou pas) un ou plusieurs des produits et un client peut acheter (ou pas) un ou plusieurs des produits. C'est une relation * / * qui se traduit par une classe associative à chaque fois.

Si j'ai bien compris l'autre partie de la dernière phrase (désolé de vous dire ça mais votre français est quelque peu approximatif ; faites attention, ça peut être pénalisant dans les relations commerciales et professionnelles), il s'agit d'identifier les clients de vos concurrents ? Dans ce cas je pense que les clients de vos concurrents peuvent aussi être vos clients ou bien des prospects. Vous avez bien l'intention d'aller leur piquer un peu de part de marché à vos concurrents non ? Dans les deux cas, ces clients de vos concurrents sont des entreprises. Il faudra sans doute faire une association particulière entre Entreprises et Concurrents pour exprimer qu'une entreprise peut être (ou pas) cliente d'un ou plusieurs concurrents et qu'un concurrent peut est avoir (ou pas) pour client une ou plusieurs entreprises. Attention ! Il faudra interdire qu'une entreprise soit cliente ou fournisseur d'elle-même par un malicieux retour d'héritage !

Terminons avec les fournisseurs...
Votre société fabrique des produits avec de la matière première qu'elle extrait du sol ? Elle n'achète pas de composants du produit qu'elle fabrique ? Elle ne peut pas se retrouver cliente d'un de ses client ou d'un de ses prospects ou d'un de ses concurrents ?

[_medi]

Bonjour

Cinephil si vous trouvez mon francais un peu approximatif c'est par ce que tout simplement je ne suis pas francais ! et que c'est ma 3éme langue !!

mais je veux savoir ce que vous vouliez dire par 'faire une association particulière entre Entreprises et Concurrents' !!

notre société n'a pas besoin de fourniseur par ce que elle même fabrique les produits à partir de la matiers premier qui n'a pas n'ont plus besoin de l'acheté et vend les produits fabriqués et même parfois la matier premier !

Merci infiniment pour vos réponses.

[CinePhil]

Bonjour

Cinephil si vous trouvez mon francais un peu approximatif c'est par ce que tout simplement je ne suis pas francais ! et que c'est ma 3éme langue !!

Je m'en doutais un peu !

mais je veux savoir ce que vous vouliez dire par 'faire une association particulière entre Entreprises et Concurrents' !!

Il y a déjà une relation d'héritage entre Entreprises et Concurrents, un concurrent étant un type particulier d'entreprise. Il faudra faire une autre association entre ces deux classes pour gérer les clients de vos concurrents, en interdisant comme je l'ai déjà dit qu'une entreprise puisse être cliente d'elle-même. J'espère que la logique UML n'interdit pas ce genre d'association entre une classe mère et une classe fille.
Sinon on peut aussi, en considérant que les clients des concurrents sont soit des clients soit des prospects de votre entreprise, faire deux associations :
- entre Concurrents et Clients ;
- entre Concurrents et Prospects.
Là encore, un de vos client pouvant être aussi un de vos concurrents, il faudra interdire que l'un de vos Concurrents puisse être Client de lui-même.

notre société n'a pas besoin de fourniseur par ce que elle même fabrique les produits à partir de la matiers premier qui n'a pas n'ont plus besoin de l'acheté et vend les produits fabriqués et même parfois la matier premier !

Merci infiniment pour vos réponses.

Ok, c'est ce que j'avais cru comprendre à propos des fournisseurs. C'est rare mais ça arrive.

[_medi]

Bonjour,

Il faudra faire une autre association entre ces deux classes pour gérer les clients de vos concurrents, en interdisant comme je l'ai déjà dit qu'une entreprise puisse être cliente d'elle-même. J'espère que la logique UML n'interdit pas ce genre d'association entre une classe mère et une classe fille.

D’après la réponse de Hed, qui je remercie d’ailleurs par ce que il n’a pas supprimé la discussion !
Il dis que ‘La classe mère n'est pas censée connaître les filles. Par contre, une des filles peut avoir une relation vers la classe mère. C'est notamment le cas du design pattern composite.’

Alors en suivant vos conseil Cinephil, je vous présente le diagramme de classes que j’ai fais

Et je vous remercie pour vos réponses

[hed62]

Tu confonds les diagrammes de classes et les MCD.

En effet, toutes tes classes d'associations sont inutiles. La relation entre les classes, oui, mais les classes qui en découlent (reliées à la relation par des pointillés) sont incorrectes.

D'autre part, tu peux être plus précis dans les relations :

Produit -*-------*-> MatièrePremière

devient donc

Produit <x>-*-------*-> MatièrePremière

<x> étant un losange plein. Ce type de relation s'appelle une composition, et signifie qu'un produit est composé de matières premières. Il faut utiliser une composition quand il y a un lien entre les lignes de vie des objets. La composition indique que la matière première qui compose un produit ne peut exister dans ton application sans produit associé. Si ce n'est pas le cas, préfère l'usage d'une agrégation, donc un losange blanc.

Si tu tiens à préciser la nature de la relation, il convient de spécifier le(s) rôle(s) de(s) classe(s) entrant dans la relation, et non pas de nommer la relation elle meme :

Produit <x>-*-composants------------*-> MatièrePremière

Suivant cette remarque : les relation entre commande, ligne de commande et client devraient être des agrégations.

Selon ta modélisation , une commande est passée par un client, mais un Client ne peut passer qu'une commande unique... Un peu restrictif :p

Tes cardinalités sont généralement inversées :

A<x>-1-------------------*->B

signifie :

A est composé de plusieurs B,
B ne porte qu'une référence de A.

Bon courage pour la suite !

[CinePhil]

Quelques remarques à chaud sur le diagramme...

Normalement, on ne mentionne pas, dans un diagramme de classes, les propriétés mères dans une classe fille mais seulement les propriétés spécifiques à la fille (le n° de client dans la classe Client par exemple).

Je ne vois pas l'intérêt de l'association (Clientèle - d'ailleurs écrite Clientèe). S'il s'agit de représenter les clients des concurrents, c'est le rôle de l'Association_9. Dans cette association, une entreprise, qu'elle soit prospect ou cliente de votre entreprise, est cliente d'un concurrent.

Je crois que vous avez inversé les multiplicités. En UML, on lit l'association en mettant la multiplicité à la fin :
- Un contact appartient à une seulle entreprise donne
Contact -----------1..1 -> Entreprise
- Une entreprise a ou pas des contacts donne
Entreprise----------*-> Contact
Donc l'association complète donne :
Entreprise -1..1----------------*- Contact

En Merise c'est le contraire, on s'arrête au milieu de la relation et on pose la cardinalité du côté de l'entité traitée en ignorant superbement la seconde.

Edit : hed62 a écrit plus vite que moi mais il confirme ce que je dit ci-dessus à propos des multiplicités.

[_medi]

Bonjour,

Merci à vos deux cinephil et hed

Tu confonds les diagrammes de classes et les MCD.

Mais je ne confonds pas le diagramme de classes et le MCD, ils sont trés proches c 'est pour ça !

En effet, toutes tes classes d'associations sont inutiles.

Vous êtes sur ?

un losange plein. Ce type de relation s'appelle une composition, et signifie qu'un produit est composé de matières premières. Il faut utiliser une composition quand il y a un lien entre les lignes de vie des objets. La composition indique que la matière première qui compose un produit ne peut exister dans ton application sans produit associé. Si ce n'est pas le cas, préfère l'usage d'une agrégation, donc un losange blanc.

je sais ce que signifie une composition et une agrégation ! mais j'ai de male à savoir comment les utilisée !! Merci pour cette explication

Je crois que vous avez inversé les multiplicités.

Oui, c'est vrai vous avez raison Cinephil ! comme toujour quoi !

j'ai refais le diagramme mais il manque toujour d'autre classe concernant les usines et les pays de nos clients !
Mais je veux savoir est ce que avec cette modélisation je n'aura pas de probléme pour différencier les clients et les produits de nos concurrents au notre ! ??
A plus tard.

[Invité]

Coucou !

Donc, nous abandonnons la discussion :

http://www.developpez.net/forums/sho...d.php?t=488570

D'après ta nouvelle proposition de diagramme, je constate que ton entité "Coordonnées" n'est plus liée à "Clients_OCP" mais à "Entreprises". De toutes façons, pour moi, il n'existe pas d'entité "Coordonnées". Adresse", "Téléphone", "Fax", "Email" sont des attributs, soit de "Clients_OCP", soit de "Entreprises", soit des deux.

J'avais un doute sur l'entité que tu appelais "Usines". D'après ton premier diagramme, j'avais interprété que tes clients étaient en fait des usines. Il y a pourtant une information "Effectif" dans tes entités "Clients", "Prospects" et "Concurrent".

J'avais compris que "Concurrents" était un produit. Pourquoi les attributs de "Prospects" et ceux de "Concurrents" sont-ils identiques ? Ainsi que je te l'avais dit, pour moi, "Prospects" devrait être une entité comportant des attributs spécifiques et liée à la fois à "Clients", "Entreprises", voire à "Concurrents".

J'avais un autre doute concernant l'entité "Contacts". Il semble désormais qu'il peut y avoir plusieurs contacts pour une même entreprise.

"Association_?", ça sert à quelque chose ?

En fait, tu avances au feeling en fonction de ce que nous te proposons d'après ce que nous interprétons...

Désolé ! Je ne parle pas "UML"...

[CinePhil]

Sur ce nouveau diagramme :

Il y a toujours une association inutile entre Entreprise et Client. Client hérite d'Entreprise mais je ne vois pas quelle association tu veux ajouter entre ces deux classes.

En pur UML, la classe d'association Clientée est inutile. Remplace la par le rôle "Client" sur le trait de l'association. Idem pour la classe associative Marché. Sauf si tu veux stocker par exemple la part de marché de tes concurrents dans les Entreprises ou pour les Produits. Dans ce cas, tu fais comme pour la classe Ligne de commande.

Côté multiplicités :
- je dirais qu'une commande comprend au moins une ligne de commande donc 1..*
- je dirais qu'une ligne de commande est composée au plus d'un seul produit (elle peut aussi comporter un service, des frais annexes du genre transport...) et qu'un produit peut ou pas faire partie d'une ou plusieurs lignes de commande, donc Ligne de commande -*--------------------0..1-- Produits
- ton association entre Entreprise et Coordonnées a des multiplicités 1..1 des deux côtés donc on peut inclure les coordonnées dans Entreprise. Mais peut-être considères-tu, comme je l'avais compris au départ, qu'une entreprise peut avoir plusieurs coordonnées (plusieurs sites ou une adresse de livraison et une adresse de facturation...). Dans ce cas il faut changer les multiplicités.

Mais je veux savoir est ce que avec cette modélisation je n'aura pas de probléme pour différencier les clients et les produits de nos concurrents au notre ! ??

Tu pourras interroger tes produits via les lignes de commande pour les produits que tu vends à tes clients et tu pourras interroger différemment les produits vendus par tes concurrents.
L'avantage de ce système est qu'un produit aujourd'hui vendu par un concurrent mais pas par ton entreprise existera déjà dans ta base le jour où ton entreprise décidera d'attaquer ce marché.

[hed62]

Clientèe et Marché ne sont pas simplement inutiles : elles sont redondantes. J'ai presque envie de dire qu'elles sont fausses, car en plus de reprendre strictement les mêmes informations que la relation entre les classes, elles ajoutent un ID technique.

D'autre part, inutile de suffixer toutes les propriétés par le nom de la classe, et les ID techniques ne sont pas à mentionner.

Dans la classe Contact, tu précise ID_entreprise. Cela relève du même problème que tes classes d'associations ! Cela vient en redondance avec la relation.
Tu dis que DC et MCD sont très proches, peut être justement parceque tu ne connais pas vraiment les différences majeures existant entre ces deux schémas ? Enfin, dernière précision, les clefs étrangères n'apparaîtraient pas dans un MCD, mais dans un MLD, voire MPD.