Nombre de classes ou utilisation de contraintes?

Bonjour,

J'ai joins deux diagrammes UML. Il y a deux types de données : TypeA et TypeB. J'aimerais pouvoir représenter les 4 associations suivantes:

• un élément simple TypeA avec un élément simple TypeB
• un élément simple TypeA avec un groupe d’éléments TypeB
• un groupe d’éléments TypeA avec un élément simple TypeB
• un groupe d’éléments TypeA avec un groupe d’éléments TypeB

Dans la version 1, je représente un élément simple générique et un groupe d’éléments générique. Dans ce cas, les types A et B héritent de l’élément simple générique. Mais puisqu'un groupe doit contenir des éléments du même type, je dois ajouter une contrainte. Dans la version 2, je représente un élément simple pour chaque type, et un groupe d’éléments pour chaque type.

La différence que je vois entre ces deux versions est l'utilisation de contrainte et le nombre de classes utilisées.
Est-ce qu'il y a ici une décision importante de conception? Est-ce qu'il vaut mieux éviter d'utiliser des contraintes, si on en a la possibilité?

Merci d'avance

vos diagramme ne répondent pas à votre besoin, le rôle de la classe Association est obscur, pour ne pas dire 'magique'. ;)

[quote=Miko95;6542611]
un élément simple TypeA avec un élément simple TypeB
[QUOTE]
TypeA 1---------------1 TypeB

Citation:

---

Envoyé par Miko95

un élément simple TypeA avec un groupe d’éléments TypeB

---

TypeA 1---------------* TypeB

Citation:

---

Envoyé par Miko95

un groupe d’éléments TypeA avec un élément simple TypeB

---

TypeA *-------------1 TypeB

Citation:

---

Envoyé par Miko95

un groupe d’éléments TypeA avec un groupe d’éléments TypeB

---

TypeA *--------------* TypeB

Vous voulez dire que je n'ai pas besoin de dédier une classe pour le regroupement d’éléments de chaque type et que c'est implicite par la cardinalité *?

Il suffirait donc que chacun de mes types héritent de ElementAssociable et de créer une association n-aire réflexive sur ElementAssociable avec des cardinalités *?

au niveau du diagramme de classe, c'est à dire au niveau statique, oui

au delà je ne peux rien dire car je ne sais toujours pas si vous comptez générer du code c.f. autre discussion sur le même sujet

Pour ce qui est de la suite, j'essaye d'abord de représenter de manière conceptuelle le domaine concerne, ensuite je vais devoir choisir comment représenter de manière logique ce modèle (SGBDR, BDD a base de graphes...), puis je choisirai une implémentation adéquate en fonction du modèle logique.
Par rapport au code, oui, je devrai écrire du code pour la communication avec la base de données (DAO avec JDBC, Hibernate, peut être autre chose...).

Sinon, ce qui me dérange un peu c'est le fait de ne pas dédier de classe pour définir un groupe d’éléments. Même si c'est implicite, j"imagine que déjà au niveau conceptuel, cette question se pose. Il est vrai que pour ce qui est de la nature de ce qui doit être représenté, le diagramme dit tout. Mais, est ce une raison pour ne pas définir un groupe d’éléments ici?