Discussion :

[shimomura22]

Bonjour

Voici mon problème
Un client est une personne
Un client peut devenir proprio
un proprio est une personne

Voici mon diagramme d'utilisation



Merci à tous

[bruno_pages]

à part acquéreur qui sort de nulle part les généralisation sont correctes ... si elles ont un sens

Acteur2 ---|> Acteur1 n'a de sens que si Acteur2 peut prendre le rôle d'Acteur1 pour tout les cas d'utilisation où Acteur1 intervient

[shimomura22]

Bonjour et merci de ton post..
La présence d'acquéreur s'explique par le fait qu'un client peut devenir un acquéreur si il achète où loue un bien.
C'est justement sur ce point que je me demandais si mon schéma était correcte

Merci

[bruno_pages]

L'acteur acquéreur a un sens s'il a des UC qui lui sont propre, s'il n'y en a pas il ne sert a rien et "client" suffit

Notez que si le garage ne fait que de la vente le seul moyen de devenir un client est d'acheter une voiture = être un acquéreur.

[shimomura22]

Salut je reviens avec mon problème d’acquéreur.
Donc un client deviens acquéreur que si il a acheté ou loué un bien....
L'acquéreur a les mêmes attributs que le client c'est à dire nom prenom adresse etc ....
Je vous propose ce schéma E-A ???
Est-il correct de mettre les attributs dans l'association ???
Merci ...

[tonton16]

Bonjour,

Dans ton cas, c'est une grosse erreur de mettre des propriétés dans l'association. Ces propriétés caractérisent justement un client ou un acquéreur, il faut qu'elles soient dans une entité.
Un acquéreur est un client particulier et les 2 sont des personnes, donc tu peux faire une entité Personne et tu y mets les propriétés qui sont dans ton association. Et par exemple, tu crées une entité Profil pour dire qu'il est soit client soit acquéreur. Il existe probablement d'autres solutions, tout dépends du reste de ta modélisation (par exemple transformer l'entité Profil en une propriété de Personne).

Note toutefois que je suis d'accord avec Bruno Pages sur son dernier message, ça permettrait de se passer de toute cette complexité.