Relations UML et C++

Version imprimable

Bonjour � tous,

J'ai une question concernant la traduction de relations UML en C++: si on consid�re que j'ai deux classes A et B avec une relation plusieurs � plusieurs entre ces classes. J'aimerai pouvoir � partir d'un object A lister l'ensemble des objets B qui lui sont li�s et � partir d'un objet B lister l'ensemble des objets A qui lui sont li�s. Donc ma question : comment g�rez vous ce type de relation dans vos codes? personnellement, je suis parti sur un truc du genre:
d�finition des classes:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
class A;
class B;
 
class A
{
private:
    set<B*> _lstpB;
public:
    ~A();
    void addRelB(B* const ptB);
    void removeRelB(B * const ptB);
};
 
class B
{
private:
    set<A*> _lstpA;
public:
    ~B();
    void addRelA(A* const ptA);
    void removeRelA(A* const ptA);
};

et pour le code:

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
 
#include "head.h"
#include <iostream>
 
A::~A()
{
    cout << "destructeur de A" << endl;
    set<B*>::iterator it = _lstpB.begin();
    while (it != _lstpB.end())
    {
        (*it)->removeRelA(this);
        it = _lstpB.begin();
    }
}
 
void A::addRelB(B* const ptB)
{
    cout << "ajout d'une relation A->B" << endl;
    if (ptB != NULL)
    {
        if (_lstpB.insert(ptB).second)
        {
            cout << "demande d'ajout d'une relation B->A" << endl;
            ptB->addRelA(this);
        }
        else
            cout << "la relation A->B existe deja" << endl;
    }
}
 
void A::removeRelB(B * const ptB)
{
    cout << "suppression d'une relation A->B" << endl;
    if (ptB != NULL)
    {
        if (_lstpB.erase(ptB) != 0)
        {
            cout << "demande de suppression d'une relation B->A" << endl;
            ptB->removeRelA(this);
        }
        else
            cout << "la relation A->B est deja supprimee" << endl;
    }
}
 
 
B::~B()
{
    cout << "destructeur de B" << endl;
    set<A*>::iterator it = _lstpA.begin();
    while (it != _lstpA.end())
    {
        (*it)->removeRelB(this);
        it = _lstpA.begin();
    }
}
 
void B::addRelA(A* const ptA)
{
    cout << "ajout d'une relation B->A" << endl;
    if (ptA != NULL)
    {
        if (_lstpA.insert(ptA).second)
        {
            cout << "demande d'ajout d'une relation A->B" << endl;
            ptA->addRelB(this);
        }
        else
            cout << "la relation B->A existe deja" << endl;
    }
}
 
void B::removeRelA(A* const ptA)
{
    cout << "suppression d'une relation B->A" << endl;
    if (ptA != NULL)
    {
        if (_lstpA.erase(ptA) != 0)
        {
            cout << "demande de suppression d'une relation A->B" << endl;
            ptA->removeRelB(this);
        }
        else
            cout << "la relation B->A est deja supprimee" << endl;
    }
}

Je me demande si c'est la bonne approche, elle me permet d'�tre s�r que mes donn�es sont correctement reli�es (lorsqu'on ajoute ou retire une relation ou lorsqu'un des objets est d�truit) mais je trouve �a un peu "lourd" c'est pour �a que je me demande comment vous g�rez les relations notamment les n-n dans vos codes C++

06/05/2008, 10h48
JolyLoic

Une solution est d'utiliser les boost::bimap.
06/05/2008, 12h52
koala01

Salut,

Je sais que ma proposition peut n�cessiter un am�nagement de ton diagramme de classes, mais, j'ai pris l'habitude, � cause des bases de donn�es, d'�viter les relation n-n et d'intercaler un m�canisme (pour rester g�n�rique :D) qui me permette de ne g�rer que des relations un � plusieurs.

L'id�e est donc, peut �tre, de cr�er une classe que nous nommerons, par exemple ABMediator, qui serait (qui s'en doute :question:) adapt� sur base du DP... m�diateur, et � qui les �l�ments de type A et les �l�ments de type B se reporteraient pour la gestion des relations.

Cette classe interm�diaire disposerait de "tous les A" et de "tous les B", chaque A et chaque B auraient une r�f�rence unique sur le m�diateur, et ce serait ce serait � ce dernier de g�rer les relations de multiplicit� ;)

Merci pour ces r�ponses,
@JolyLoic, ce n'est pas pour un projet perso et je ne peut pas utiliser boost
@koala01, c'est une bonne id�e que j'utilisai d�j�. Ca permet effectivement d'�tre tr�s proche du mod�le de donn�es stock� dans une BD mais �a a l'inconv�nient de multiplier les classes
J'ai pens� � utiliser un truc du genre:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #include <set> template<typename classe, typename objet, typename conteneur = std::set<objet*> > class Relation { private: conteneur _lstpObj; public: ~Relation(); void addRel(objet* const obj); void removeRel(objet* const obj); }; #include "head.tpp"
avec
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 template<typename classe, typename objet, typename conteneur> Relation<classe, objet, conteneur>::~Relation() { conteneur::iterator it = _lstpObj.begin(); while (it != _lstpObj.end()) { (*it)->removeRel(static_cast<classe*>(this)); it = _lstpObj.begin(); } } template<typename classe, typename objet, typename conteneur> void Relation<classe, objet, conteneur>::addRel(objet* const obj) { if (_lstpObj.insert(obj).second) obj->addRel(static_cast<classe*>(this)); } template<typename classe, typename objet, typename conteneur> void Relation<classe, objet, conteneur>::removeRel(objet* const obj) { if (_lstpObj.erase(obj) != 0) obj->removeRel(static_cast<classe*>(this)); }
et donc je peux l'utiliser comme �a:
Code:

1 2 3 4 5 class A : public Relation<A, B> {}; class B : public Relation<B, A> {};
Qu'en pensez-vous sachant que je sp�cialiserai ma classe Relation pour les diff�rents types de conteneur et que je g�rerai les erreurs par exception (notamment dans le cas de param�tres NULL)

06/05/2008, 15h48
koala01

Le transtypage dans les diff�rentes m�thodes ne me semblent m�me pas n�cessaire...

En effet, un A va travailler avec un B* et invers�ment (un B avec un A*).

Comme A et B h�ritent d'une sp�cialisation de Relation, quand tu fais
obj->remove(this), tu lui passe automatiquement le bon type (du moins, il me semble :P)

Ben dans le principe je suis d'accord avec toi, mais si je ne met pas le static_cast, le compilateur me mets:

Citation:

error C2664: 'Relation<classe,objet>::removeRel' : impossible de convertir le param�tre 1 de 'Relation<classe,objet> *const ' en 'A *const '
with
[
classe=B,
objet=A
]
and
[
classe=A,
objet=B
]
Les types point�s n'ont aucun rapport entre eux ; conversion n�cessitant reinterpret_cast, cast de style C ou cast de style fonction

(j'utilise Visual 2003) de plus j'ai un autre probl�me, si par exemple j'ai les classes A, B et C avec A<-->B<-->C chaque relation est de type n-n mon id�e est de faire un truc du genre:
Code:

1 2 3 4 class A : public Relation<A, B> {}; class B : public Relation<B, A>, public Relation<B, C> {}; class C: public Relation<C, B> {};
Mais l� le compilateur r�le encore:

Citation:

error C2385: acc�s ambigu de 'removeRel' dans 'B'
est peut-�tre le 'removeRel' en base 'Relation<B,A>::removeRel'
ou le 'removeRel' en base 'Relation<B,C>::removeRel'
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\xtree(267)*: lors de la compilation de la fonction membre du mod�le de classe 'Relation<classe,objet>::~Relation(void)'
with
[
classe=A,
objet=B
]

Il faut donc que je mette le nom complet: par exemple pour la m�thode removeRel:
Code:

1 2 3 4 5 6 7 template<typename classe, typename objet>//, typename conteneur> void Relation<classe, objet>::removeRel(objet* const obj) { if (_lstpObj.erase(obj) != 0) obj->Relation<objet, classe>::removeRel(static_cast<classe*>(this)); }
Ce qui jusque l� n'est pas tr�s pratique mais passe encore, le dernier probl�me que j'ai c'est que lorsque pour un �lement de la classe B, j'appelle addRel, le compilateur ne sais pas diff�rencier entre la m�thode provenant du premier h�ritage (Relation<B,A>) de celle provenant du second (Relation<B,C>). Hors le prototype de addRel est dans un cas: void addRel(A* const) et dans l'autre: void addRel(C* const). Donc le compilateur devrait pouvoir les diff�rencier (en tout cas �a me semble logique). Je testerai ce soir avec VS2005.