Discussion :

[artatnas]

Bonjour a tous

Voici mon probleme

Je dois modeliser une interface de commandes de voitures

Alors un client peut choisir un package et une couleur lors de sa commande.

Les couleurs disponibles dependent du package choisi ,
et une couleur peut etre disponible pour plusieurs packages.
Ainsi, une relation n,n existe entre couleurs et packages.

Mais un vehicle appartient a un package et un package peut contenir pls vehicles.
Donc il y a aussi une relation 1,n entre vehicules et packages

Un vehicule a une couleur choisie en fonction de son package, mais une couleur peut etre possedee par plusieurs vehicules.
Il y a une relation 1,n entre couleurs et vehicules selon le package du vehicule.

Comment modeliser tout ca : MCD et MPD svp.

[hed62]

Le mieux est de faire une proposition et nous en discuterons

[artatnas]

J ai pense a un MPD dans ce genre
Une table COULEURS
Une table PACKAGES
Une table VEHICULES

Les tables COULEURS et PACKAGES seraient reliees par une relation 1,n a VEHICULES.

Dans ce cas un vehicule aurait une couleur et un package mais je ne trouve pas le moyen d exprimer le fait que cette couleur est disponible en fomction du package.

Merci de me repondre au plus vite svp.

[hed62]

J ai pense a un MPD dans ce genre

Démarre depuis le MCD : moins d'erreurs, gain de temps, le MPD est généré depuis le MCD.

Dans ce cas un vehicule aurait une couleur et un package mais je ne trouve pas le moyen d exprimer le fait que cette couleur est disponible en fomction du package.

Eh bien un package est en relation avec des couleurs. Une voiture n'a qu'une couleur et qu'un package sélectionné parmi les choix possibles.

Merci de me repondre au plus vite svp

Ca c'est bien inutile, et a même tendance à facher

[artatnas]

Au debut g bien commence avec un MCD : Le couleurs etaient associes aux packages genre n,n , et les voitures aux packages 1,n.

Ainsi une voiture appartenait bien a un packge, mais le hic est que le package est diponible sous plusieurs couleurs, alors que le vehicule lui ne doit avoir qu une couleur : comment faire?

[hed62]

voiture -1..1--------------0..n- couleur
voiture -1..1--------------0..n- package
couleur -1..n--------------1..n- package

[artatnas]

Mci

Mais dans ce cas comment savoir que les couleurs pour une voiture sont disponibles en fonction du package auquel il appartient

[hed62]

Il faut ajouter une contrainte sur les deux relations il me semble, mais je ne suis pas suffisamemnt dur de moi pour affirmer. Mieux vaut attendre un expert.

[artatnas]

G une iD

couleur et Packages sont reliees par une table packages-couleurs
vehicule sera reliee a cette derniere

Merci bcp pour toutes les reponses

[hed62]

Je ne suis pas convaincu par cette idée..

Attention au SMS !

[JPhi33]

Bonjour,

J'ai suivi votre débat avec intérêt. Je résume les deux propositions qui s'en dégagent :

1) Proposition de hed62

(Je nomme "Offre" l'association entre Package et Couleur)

[ Couleur ]--1,n----( Offre )----1,n--[ Package ]
[ Véhicule ]--1,1----( a-un )----1,n->[ Couleur ]
[ Véhicule ]--1,1----( a-un )----1,n->[ Package ]

Dans cette modélisation, comme l'a très justement souligné hed62, il faut ajouter une contrainte... mais laquelle ?


2) Proposition de artatnas

La table Véhicule est reliée à une table "packages-couleurs" (artatnas se garde de préciser comment) dont on peut supposer qu'il s'agit de la relation n,n entre Packages et Couleurs dont il parle dans son premier message.

Traduit en modèle EA, toujours avec l'association Offre, cela donne :

[ Couleur ]--1,n----( Offre )----1,n--[ Package ]
[ Véhicule ]--1,1----( a-un )----0,n->( Offre )

Dans cette modélisation, je matérialise une association entre Véhicule et Offre.



Revenons à la proposition 1. La contrainte qu'il faut modéliser est une contrainte d'inclusion des deux association "a-un" dans l'association "Offre", exprimant le fait que :
un Véhicule se trouvant dans un Package ne peut être que d'une des Couleurs autorisées dans le Package
et que
un Véhicule d'une certaine Couleur ne peut se trouver que dans un Package proposant cette Couleur

La modélisation de cette contrainte conduit obligatoirement au modèle EA issu de la proposition 2.
La proposition 2 est donc une conclusion logique à la proposition 1 ou, dit autrement, une manière plus élégante et plus concise de modéliser la proposition 1. Evidemment, pour aboutir au modèle 2, il faut connaître et accepter le concept d'association entre associations.


JPhi33

[hed62]

La contrainte qu'il faut modéliser est une contrainte d'inclusion des deux association "a-un" dans l'association "Offre"

Merci pour la précision, mes notions de contraintes sont limitées

La proposition 2 est donc une conclusion logique à la proposition 1

Ca je crois que je ne l'aurais jamais soupçoné...

Evidemment, pour aboutir au modèle 2, il faut connaître et accepter le concept d'association entre associations.

Aurais tu le temps de détailler s'il te plait ? Y a t il un rapport entre la modélisation 2 et les classes d'association d'un diagramme de classes UML ?

[JPhi33]

Y a t il un rapport entre la modélisation 2 et les classes d'association d'un diagramme de classes UML ?

Pour l'équivalence des concepts, on pourrait dire, avec les réserves qui conviennent, 1 classe d'association UML = 1 association EA

Etant donné qu'une classe d'association "est une" (au sens de la généralisation) classe, on peut définir une classe d'association entre une classe d'association et une classe (ou une autre classe d'association).

Les mêmes possibilités existent dans les 2 modèles mais je ne dirais pas que pour modéliser la même réalité on aboutisse obligatoirement à une équivalence classe = entité et classe d'association = association. Avec le modèle EA on raisonne uniquement sur l'aspect statique du SI alors qu'avec UML on se doit d'envisager des objets englobant a la fois les aspects statique et dynamique du SI.

La modélisation d'un même sujet devrait normalement aboutir à des disparités (même légères) entre les deux types de modèles... ou alors c'est que la conception objet a été pilotée par les données et qu'on n'a pas vraiment cherché à définir les objets car on a laissé l'aspect dynamique de côté pour ne le "raccrocher" qu'à la fin.

Je termine avec un bémol : la définition de vraies classes d'objets (non pilotée par le statique) est une tâche qui semble intellectuellement difficile, voire complexe, et concernant cette démarche UML ne dit rien !


JPhi33

[hed62]

et concernant cette démarche UML ne dit rien !

Juste pour clore l'explication : UML ne préconise rien en ce sens car UML est un simple langage. Pour obtenir des "conseils"/"démarche" il faut se tourner vers les méthodes. Toutefois je ne sais pas si ces méthodes définissent réelement "comment faire de vrais objets sans se laisser piloter par les données"

[JPhi33]

UML ne préconise rien en ce sens car UML est un simple langage.

Oui, bien entendu. Ce n'est évidemment pas ce que je voulais dire. Je rectifie : à ma connaissance, aucune démarche de modélisation orientée objet, ne dit quoi que ce soit à ce sujet.
Les xUP, les méthodes agiles et les autres méthodes orientées objet sont beaucoup plus centrées sur l'organisation du développement du logiciel que sur l'abstraction du réel en objets. Le concepteur ne peut s'appuyer sur rien d'autre que "ses connaissances du domaine de l'application" pour "énumérer les classes d'objets susceptibles d'exister" (cf. OMT, par exemple).

Sinon, j'espère que tu as trouvé quelque intérêt au reste de ma réponse sur les associations et les classes d'associations...

[hed62]

On est d'accord

Sinon, j'espère que tu as trouvé quelque intérêt au reste de ma réponse sur les associations et les classes d'associations...

Tout à fait, oui, merci ! J'aurai du mal la prochaine fois que je rencontre le cas de passer de l'un à l'autre car cela ne m'est pas naturel, mauis j'essaierai d'y penser

Le concepteur ne peut s'appuyer sur rien d'autre que "ses connaissances du domaine de l'application"

Effectivement, et ici on voit une dérive assez génante : les concepteurs sont des experts métiers, qui ne connaissent pas forcément l'implication de tout ce qu'ils modélisent