Comment modeliser une relation n,m de merise en UML ?

Bonjour,

je cherche à modéliser depuis un modèle conceptuel de données merise une relation n,m avec attributs vers un DC UML.

Pour prendre un exemple, comment disposer les classes article, commande et composee, depuis les entités.
http://sqlpro.developpez.com/cours/m...e=passage#L5.2

http://sqlpro.developpez.com/cours/m...s/merise18.gif

en m'inspirant du modele physique de données, je n'ai aucune referances de la classe commande vers article... ce n'est pas tres pratique d'instancer d'abord un composee pour trouver a quelle numero de commande correspond les references de produits...

En sql, tu n'as pas d'autre choix que de faire une vue entre les trois tables:

• Commande
• Composee
• Article

Du moins, il faut faire un select avec une jointure sur les trois tables.

En revanche, si tu passes au mode objet relationnel, en utilisant une collection de référence Composee dans la classe Commande dont chaque objet fait référence à un objet Article, tu as indirectement une référence d'un article pour une référence de commande au travers de la collection de référence Composee.

merci de ta réponse,

j'avais deja prevu d'effectivement de rajouter une referance de commande a composee, mais ma question était plus general : y a t'il une facon de faire 'automatique' pour representer ce type de relation en UML, car j'aurai tout aussi bien pu utiliser article pour retrouver les commandes, ou renommer l'entitee composee en quelques chose de plus lisible pour l'objet (command_has_article ?).

Ce genre de relation se rencontre par exemple ici lorsque une remise depend a la fois d'une commande et d'un article, ou de concerver un historique (ex : un employé est dans une entreprise a une peridode donnée, concerver un historique de l'employer avec les dates debut et date de fin).

Apres avoir regarde plusieurs livres UML, un representation qui me semble convernir est la relation n-aire entre classes (deux classes reliée, et une troisieme 'classe assosiation' avec un trait pointillé sur la relation).

Par contre je n'ai pas trouve comment implémenter avec ce type de relation...

Au final, tes données sont stockées dans un SGBDR, il faudra bien faire la glue entre ton modèle objet et tes requêtes SQL, c'est pour cela qu'il y a une floppée d'outils Mapping O/R et de framework pour faire cette glue, donc en fonction de ces mappeurs tu auras des modèles objets différents.

Autrement, tu as le modèle navigationnel classe association qui va induire l'existence d'un classe ayant la référence de commande et celle de l'article.

d'accord, je me suis renseigné entre temps et une relation ternaire reste de la conception et peut etre implémenté de différentes façon.
J'ai notamment lu ce poste http://www.developpez.net/forums/d17...ion-impl-ment/
qui m'a confirmé ceci. Pour tout de même essayer de fournir une implémentation d'exemple (je n'en ai pas trouve sur le net!) de ce type

Citation:

---

avec la navigabilité dans les deux sens, et les cardinalité n et p :
C1 <-p-- CA --n-> C2
peut être traduit en design :
C1 <-1-- CA
CA --1-> C2

---

en reprenant le modele physique de donnée de l'exemple (au fait, le merise ne m'intéresse que peu (bon, un peu quand même), cétait plutôt un exemple pour comparer ce que je voulais pour l'UML, je ne connaissait pas les classes associations au début de ce topic).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116

//Code minimaliste, sans accesseurs ni vérification ! #include <string> #include <iostream> /* Soit article *________________________________* commande * <____________1 client | | commande_has_article */ using namespace std; enum mode_payement {ESPECE, VISA, EN_NATURE, EN_MONNAIE_DE_SINGE}; class client { public: string nom; int age; }; class article { public: string designation; float prix; }; class commande { public: commande(client& ref_client):o_client(ref_client){} client &o_client; short mode_payement; long int timestamp; }; class commande_has_article { public: commande_has_article(article& ref_article, commande& ref_commande):o_article(ref_article), o_commande(ref_commande){} article &o_article; commande &o_commande; float remise; int quantite; }; int main(void) { //Création de 3 article article v_article[3]; v_article[0].designation = "cafe"; v_article[1].designation = "stylo"; v_article[2].designation = "bouillotte"; v_article[0].prix = 2.80; v_article[1].prix = 1.20; v_article[2].prix = 15.95; //un client client o_client; o_client.nom = "Dave Null"; //Nouvelle facturation commande o_commande_1(o_client); o_commande_1.mode_payement = VISA; //Je n'ai pas de lien (referance) vers les articles de la commande, car j'ai choisis //l'approche avec une classe d'association, je doit l'instancier pour creer le liens commande_has_article o_fha_1(v_article[1], o_commande_1); o_fha_1.quantite = 42; o_fha_1.remise = 30; //J'ajoute un article a ma commande commande_has_article o_fha_2(v_article[2], o_commande_1); o_fha_2.quantite = 1; o_fha_2.remise = 0; //Je ne ferai jamais de remise pour une bouillotte, c'est un choix //////////////////////////////////// // module de facturation 2.0 (juste un peu d'affichage pour voir) float total=0; float remise; float prix_avec_remise; cout << "Nom du client : " << o_commande_1.o_client.nom << endl; cout << "Code payement : " << o_commande_1.mode_payement << endl; cout << "A commande : " << endl; //utiliser un tableau ou un vecteur normalement //Pour toutes les liaisons entre commande et article... cout << o_fha_1.o_article.designation << " X " << o_fha_1.quantite << endl; remise = (o_fha_1.o_article.prix * o_fha_1.quantite) * (o_fha_1.remise / 100); prix_avec_remise = o_fha_1.o_article.prix * o_fha_1.quantite - remise; cout << "Avec une remise de " << o_fha_1.remise << "% soit un sous total de " << prix_avec_remise << endl; total += prix_avec_remise; cout << o_fha_2.o_article.designation << " X " << o_fha_2.quantite << endl; remise = (o_fha_2.o_article.prix * o_fha_2.quantite) * (o_fha_2.remise / 100); prix_avec_remise = o_fha_2.o_article.prix * o_fha_2.quantite - remise; cout << "Avec une remise de " << o_fha_2.remise << "% soit un sous total de " << prix_avec_remise << endl; total += prix_avec_remise; cout << "Soit un total de " << total << endl; return 0; }

---

Voila l'utilisation des classes associative en C++ (j aurai pu prendre n'importe quel langage objet) quelque peut il confirmer que c'est la bonne chose a faire, en fait c'est la notion de durée de vie d'une relation qui ne m'es pas familière, mais l'exemple montre que l'on a bien une remise pour chaque article de la commande comme dans l'exemple en merise, apres l'idée de déporter dans la classe cote 1 dans une relation 1:n et d'utiliser une map me semble aussi très pratique... c'est surtout la gestion de la vie des instances de la classe associative que me pose probleme, cela n'est il pas en finale tres lourd a gérer ?

Je suis pas un spécialiste du C++, mais les étapes sont corrects.

En disant cela:

Citation:

---

c'est surtout la gestion de la vie des instances de la classe associative que me pose probleme, cela n'est il pas en finale tres lourd a gérer ?

---

Tu lances un débat, c'est ce qui explique la pléthore d'outils ORM.
De toute façon, pour chaque ligne de commande tu devras instancier les objets ad hoc. Pourquoi, c'est lié au fait que les données sont stockées dans un SGBDR (en général) et qu'il faut faire la correspondance des objets écris dans un langage objet avec le monde SQL.

Soit tu trouves un framework qui se charge de faire l'interfaçage autrement dit traduit les objets en code SQL et vice versa, soit tu le fais toi même.

Y a t il une façon élégante de le faire ?

Si le framework peut attaquer des SGBDR de différents éditeurs, il va induire une couche d'abstraction supplémentaire pour s'adapter aux spécifités du SGBDR, donc le faire soi-même suppose de coder les spécifités pour chaque SGBDR. Dans le framework ADO.NET, ils utilisent le desing pattern abstract factory comme solution d'interfacage entre les différents SGBDR, ce qu'on appelle plus généralement la couche d'accès aux données, en anglais DAL( Data Access Layer).

Je t'ai donné un exemple, d'autres frameworks vont être plus complexes comme Spring qui va s'appuyer sur une fabrique d'objet pour la connectivité aux bases, mais d'autres couches se rajoutent.
Hibernate utilises aussi le design pattern abstract factory mais l'architecture est différente de celle d'ADO.NET.

Le mieux, c'est que tu en prennes un et que tu l'étudies en détail pour comprendre la mécanique derrière.

Merci pour toutes ces réponses, cela me semble quand même plus claire. Dans mes recherche je suis tombé sur un tuto de hibernate qui explique comment il gère les relations many to many. Finalement, avoir une classe association en UML a du bon pour la modelisation, mais le mieux et d'essayer une implémentation au plus tôt pour ne pas avoir de surprises.

C'est par l'exemple, qu'on apprend le mieux. Mais d'avoir une trame de reflexion, c'est quand même mieux. Autant dire, que j'ai mis du temps pour avoir les idées un peu plus clair sur le sujet.