Bonjour ! J'ai besoin d'aide pour mon projet en UML.
 
Bon, voici l'énoncé du problème :

 
Voici une capture d'écran de la modélisation que j'ai réalisé sous ConceptDraw :

 
J'ai plusieurs doutes auxquels j'aimerai particulièrement qu'on m'apporte de l'aide.
 
1) D'abord la relation entre bien d'équipement et produit pose un problème. Je ne sais pas si j'ai le droit de les lier à la fois par héritage et par agrégation. Pourquoi vouloir faire cela ? Je n'ai pas trouvé d'autres manières de représenter le fait que "Les biens d'équipements peuvent être unitaires ou êtres des lots comprenant plusieurs produits".
 
2) Je ne sais pas si la représentation de la facturation est bonne. Cela représente-t-il bien correctement ce qui est demandé dans l'énoncé ?
 
3) Concernant la mémorisation des informations à la livraison d'un bien d'équipement, c'est peut être ce dont je suis le moins sûr. Puis-je réutiliser des attributs déjà utilisés dans la classe Bien d'équipement ? Puis-je lier directement la classe d'association Livraison au Contrat de garantie ?
 
Bien sûr, je suis à l'écoute de toute autre remarque. Merci de votre aide.

edit (mince, j'ai effacé mon message) : donc je disais, pour 1) il n'y a pas d'héritage, seulement une agrégation.

Donc j'enlève juste la relation d'héritage ok. Mais est-ce que je ne devrai pas modéliser une classe Lot ?  
 
Et pour le reste ?
 
Merci de ta réponse.

Oui, une classe lot, pourquoi pas, c'est une classe intermédiaire, ça ne mange pas de pain et c'est plus propre. C'est elle qui modélisera l'agrégation et une instance de cette classe sera incluse dans ta classe bien d'équipement.
 
Sinon, tu peux créer une classe EtatClients, agrégation pour enregistrer les états EtatClient de chaque client (facturé, réglé, livré, en attente de livraison, ayant souscrit un contrat de garantie, etc). Attention cependant à ce que ctte classe ne se transforme pas en fourre-tout. Cette agrégation sera bien entendu modulable (extensible au fur et à mesure des ajouts de nouveaux clients).
 
Pour savoir comment modéliser ton système, il faut bien réfléchir à tous les différents cas d'utilisation (les interactions entre les sous-systèmes et les divers acteurs). Ce sont eux qui déterminent la dynamique du système, et donc l'architecture. Donc je te conseille de les lister pour avoir une vue globale.

juste une remarque, c'est voulu l'absence de multiplicités sur le diagramme des classes ?

Autre remarque, a ta place je ne mettrais pas de relation de composition entre Produit et Commande.
La composition est une relation forte qui en général implique que la suppression du "contenant" entraine également la suppression du "contenu".
Si on supprime une instance de Commande ou de Produit, cela n'implique pas la suppression de l'autre. J'ai bien des commandes de produits qui n'existent plus.
En plus elle semblerait mal orientée.
 
Même remarque entre Contrat de Garantie et Commande, l'agrégation ne me semble pas correcte. Une simple relation avec les bonnes multiplicité doit suffire.

Entre la classe Produit et celle de Bien d'équipement je conserverai à la fois l'héritage et l'agrégation. La classe Lot n'est pas justifiée. Nomme simplement "lot" l'agrégation entre Prduit et Bien d'équipement.
 
Ensuite la classe associative Facturation Mensuelle ne sert à rien. Migre l'attribut date dans la classe Facture et tout ira bien. Par contre il faut que tu rajoutes des attributs à cette classe Facture pour mémoriser le réglement du client (payé : oui,non ; mode de reglement : CB, esp, chèque ; etc)
 
Autre problème, dans ton modèle, on ne peut pas faire le lien entre la facture et ce qui a été acheté ce qui est pour le moins très génant. Je serais toi, je relierai Facture à Commande.
 
Dans ce contexte la classe Magasin est superflue.
 
La classe associative Livraison doit être reliée non pas à Contrat de garantie mais à Bien d'équipement. Cette classe associative n'a pas d'attribut car Bien d'équipement hérite des attributs de Produit.
 
Bon, si tu nous refaisais un diagramme et que tu le postais pour voir ce que ca donne ?

Supprime les association entre Facture d'une part, et Particulier et Société d'autre part, pour n'avoir plus que l'association entre Facture et Client.

Si tu suis ces modifs, tu dois obtenir selon moi un diagramme plus simple et plus juste.

Merci pour toutes ces précieuses indications. Je vais effectuer toutes les modifications et je reposterai le diagramme ici, dès que j'aurai le temps.
 
A+ !

Re !
 
Bon ça y est, j'ai effectué les modifs que tu m'as conseillé pains-aux-raisins. Juste une chose, j'ai décidé de conserver la classe magasin. En effet, même si ça n'a pas vraiment d'utilité comme tu l'as dit, je pense que ça donne tout de même plus de sémantique au diagramme, tu ne crois pas ? Bref, voila le diagramme fraîchement remanié :
 

Bon y a du mieux mais c'est pas encore ça.
 
Concernant la classe Magasin, pourquoi est-elle inutile ? Parce que dans l'énoncé on ne parle que d'un seul magasin.
Une classe n'a vraiment d'intérêt quand plusieurs instances apparaissent. Ce qui n'est pas le cas ici. De plus l'association avec la classe Entrepot est erronée, et pourquoi n'y aurait-il pas alors d'association entre Magasin et Commande ? Le magasin émet bien une commande ?
Pourquoi il n'y aurait-il pas d'association entre Magazin et Contrat de garanti ? Tu te retrouve dans ce cas à une classe en rapport avec tout ce qui est un bon critère pour dire qu'il est inutile de la représenter.
 
Il manque toujours les multiplicités !!!! C'est une chose assez importante pourtant...
 
Il faut supprimer les attributs de la classe Livraison. En effet tu peux déduire la valeur de ces attributs par l'association qui relit Livraison à Bien d'équipements qui possède ces attributs par héritage avec la classe Produit

Un autre petit truc, ajoute "date de règlement" à la classe Facture

Concernant les multiplicités, c'était voulu. Tant que je n'ai pas le diagramme définitif ça ne sert à rien que je les mette. Je vais le refaire avec les quelques nouveaux conseils que tu m'as donné et cette fois je mettrai les cardinalités. A+

Et voici donc, le nouveau diagramme :
 

Ah ! Voilà qui commence à avoir de l'allure
si j'insistais pour que tu mettes les multiplicités c'est parce que je sentais qu'il y avait des zones d'ombre.
En effet, il y a des problèmes à ce niveau.
Je t'en parle à mon retour.
Pendant ce temps, essaie de voir ce qui peut clocher.

pains-aux-raisins tu m'abandonnes ?