Représentation UML des classes de politiques ?

Bonjour,

comment représente-t-on une classe de politique dans un diagramme de classe ?

Par exemple :

J'ai une classe Objet et une classe Gestionnaire qui contient des Objets.

La politique de chargement des Objets par le Gestionnaire est laissé à l'utilisateur via un paramètre template de la fonction Charge().
L'utilisateur peut choisir de charger à partir d'un fichier texte, d'une table de la base, d'un XML, etc.

En C++ cela donne :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

class Gestionnaire { template <class LOADPOLICY> void Charger( string indications ); // indications pour le chemin de fichier, le nom de la table etc. };   struct ChargeObjetDepuisFichierTexte { Objet * Suivant(); };   struct ChargeObjetDepuisTable { Objet * Suivant(); };   struct ChargeObjetDepuisXML { Objet * Suivant(); };

---

Les interfaces de mes politiques sont identiques mais aucun héritage n'entre en jeu, il serait erroné dans un schéma UML de présenter un héritage mais il serait dommage de ne pas montrer un lien évident entre les classes.

Quelles options s'offrent à moi ?

Merci d'avance. 8-)

Salut,

Personnellement, je la ferais plutot apparaitre dans le diagrame d'objet, étant donné qu'elle n'entre réellement en jeu que lors... de l'instanciation de la classe.

*Eventuellement*, dans le diagrame de classes, tu peux les faire apparaitre comme une composition "sélective" ("conditionnelle"), étant donné qu'il faut au minimum une politique pour pouvoir appeler la méthode, mais qu'il est impossible d'envisager de fournir deux politiques sur le meme appel :P

[EDIT]agrégation =/= composition... me suis trompé :aie:[/EDIT]

Il y a plusieurs niveaux dans une approche UML.
Si tu veux simplement décrire ce qui se passe, tu t'affranchir complètement de ce quis e passe au niveau du code en réalité. Plus tu affineras ton schéma, plus il s'approchera de la réalité de code et il utilisera des outils spécifiques à un langage, comme les templates.

Actuellement j'ai ça (voir pièce jointe).

Est-ce choquant ?

En fait, je vais "dérouler" mon raisonnement, qui rejoint fortement celui de miles, mais de manière à te faire comprendre:

Tu pars (correctement) sur le principe qu'il n'y a pas de relation d'héritage entre une classe et ses politiques.

La seule relation possible qu'il te reste est donc une relation de type "a un", qui peut se traduire de deux manières:

• L'agrégation qui fournit une relation transitive, mais "souple" (sans obligation de l'existence de l'un pour que l'autre puisse exister)
• La composition qui fournit une relation plus forte: une classe ne peut pas exister si l'autre n'existe pas et, dans l'autre sens, l'autre classe n'a que peu de sens si ce n'est pas au sein de la classe qui l'utilise

Ainsi, la relation qui unirait une étagère et un/des livre(s) serait une agrégation : une étagère contient un ou plusieurs livres, un (ou plusieurs) livre(s) peu(ven)t etre sur une étagère... voir sur plusieurs (mais pas en meme temps :P) mais tant l'étagère que le livre peuvent très bien exister sans l'autre :D

Par contre, la relation qui unirait le camion au moteur, au chassis et aux roues serait une composition: Si un camion n'a pas de moteur, pas de chassis, ou pas un nombrer minimum de roues, il ne peut pas exister de manières utile, et, de la même manière, un moteur, un chassis ou une roue ne trouve réellement son utilité que parce qu'il/elle se trouve... assemblé(e) avec toutes les pieces qui composent un camion.

Tu te rend donc assez rapidement que la relation qui unit une classe template à ses politiques est plutôt du type composition que du type agrégation ;) (sorry, je m'étais trompé dans le message précédent... je l'édite de suite :oops: :aie:)

Mais, à ce moment là, on atteind une autre contrainte:

Tu peux disposer d'un nombre inconnu de politiques (tu en as donné quatre, mais on pourrait en donner d'autres, pour du texte brut, des fichiers binaires dont les spécifications devraient être fournies, pour une récupération sur le réseau, pour les curseurs sur résultat de requete SQL... :D) MAIS pour chaque instance de ta classe, ne peut y avoir qu'une et une seule politique utilisée (tu ne peux pas commencer par utiliser la politique XML pour passer "à ton bon gré" à une politique "Table" ou à une politique "CSV" :D)

Dés lors, si tu veux exposer les différentes politiques possibles, cela doit se faire dans le diagrame qui permet de montrer les différentes instances de ta classe: le diagrame d'objets.

Tu pourras alors te "contenter" d'une instance utilisant une politique "particulière" (vraissemblablement la plus couremment utilisée) et d'une note indiquant les autres politiques existantes, par exemple ;), voire, décider de représenter une instance de la classe composée avec chaque politique existante (mais cela allourdira le shéma, et je ne me prononcerai pas sur la plus value appportée ;))

Si tu tiens absolument à représenter les politiques dans le diagrame de classes, tu as deux solutions:

Soit tu indique la composition avec une représentation "générique" Politique et, éventuellement une note informative exipliquant que c'est à choisir parmis les différentes politiques

Soit tu indiques la composition en représentant toutes les politiques envisagées, mais la note explicative doit alors clairement indiquer qu'une seule politique ne peut être utilisé à la fois (ce qui finira par allourdir le shéma, sans *forcément* apporter de plus value).

La dépendance n'est pas choquante non plus, mais, j'indiquerais peut etre clairement l'unicité de la dépendance, et je me demande s'il est opportun de faire apparaitre tout l'arbre d'héritage dans ce contexte...

Il faut voir ce que tu va placer autour de cette relation, mais, si déjà, tu sais que ta classe gestionnaire dépend d'une classe dérivée de ILoadPolicy, tu sais, a priori, tout ce qu'il faut à son sujet ;) :P

De plus, je me demande si tu n'a pas tendance à déjà trop t'impliquer dans le langage qui sera utilisé :P

Je comprends ce que tu veux dire.

Par contre, il existe différentes façons d'utiliser les classes de politiques :

• On peut en hériter pour proposer l'interface de la politique à l'utilisateur directement (assez courant).
• On peut la composer pourquoi pas (jamais vu).
• On peut, sans utiliser les techniques ci-dessus, l'utiliser via une instanciation ou des méthodes statiques.

Pour ma part, si tu regardes bien, j'utilise la troisième solution, avec même une autre particularité : ce n'est pas ma classe qui est paramétrable, mais la fonction Charger().

Donc pour le coup ce que tu dis là :

Citation:

---

Envoyé par koala01

MAIS pour chaque instance de ta classe, ne peut y avoir qu'une et une seule politique utilisée (tu ne peux pas commencer par utiliser la politique XML pour passer "à ton bon gré" à une politique "Table" ou à une politique "CSV" :D)

---

est faux dans mon cas, puisque pour une instance de ma classe, je peux très bien commencer par utiliser une politique de chargement via un fichier txt, puis rajouter des données tirées d'un xml, le Gestionnaire saura les charger sans soucis sans faire de distinction entre les différents objets.

Donc, dans mon cas, la composition, moyen...

Dans ce cas, le template, il est bien adapté ?

Citation:

---

Envoyé par NiamorH

Je comprends ce que tu veux dire.

Par contre, il existe différentes façons d'utiliser les classes de politiques :

• On peut en hériter pour proposer l'interface de la politique à l'utilisateur directement (assez courant).
• On peut la composer pourquoi pas (jamais vu).
• On peut, sans utiliser les techniques ci-dessus, l'utiliser via une instanciation ou des méthodes statiques.

Pour ma part, si tu regardes bien, j'utilise la troisième solution, avec même une autre particularité : ce n'est pas ma classe qui est paramétrable, mais la fonction Charger().

Donc pour le coup ce que tu dis là :

Citation:

---

Envoyé par koala01

Tu peux disposer d'un nombre inconnu de politiques (tu en as donné quatre, mais on pourrait en donner d'autres, pour du texte brut, des fichiers binaires dont les spécifications devraient être fournies, pour une récupération sur le réseau, pour les curseurs sur résultat de requete SQL... :D) MAIS pour chaque instance de ta classe, ne peut y avoir qu'une et une seule politique utilisée (tu ne peux pas commencer par utiliser la politique XML pour passer "à ton bon gré" à une politique "Table" ou à une politique "CSV" :D)

---

est faux dans mon cas, puisque pour une instance de ma classe, je peux très bien commencer par utiliser une politique de chargement via un fichier txt, puis rajouter des données tirées d'un xml, le Gestionnaire saura les charger sans soucis sans faire de distinction entre les différents objets.

Donc, dans mon cas, la composition, moyen...

---

Ah, non...

Au pire, tu ajoutera des éléments en choisissant une politique différentes, mais, si tu commence ton chargement sous la forme d'un fichier XML, tu dois, en tout état de cause, terminer le chargement du fichier avant de pouvoir envisager d'y ajouter des données récupérées d'une table ou d'un fichier CSV...

En fait, tu vas commencer par gérer la première partie (chargée au départ de ton fichier XML, dans mon exemple) puis tu va rajouter la liste des éléments créée, de manière "temporaire" en utilisant ton fichier CSV à la liste existante ;)

Cela pourrait se faire sous une forme proche de

Code:

---

1 2 3 4 5 6 7 8

/*....*/ legestionnaire->Load<ChargeObjetDepuisXML>("fichier.xml"); /*...*/ legestionnaire->AddItems(legestionnaire->Load<ChargeObjetDepuisFichierTexte>("fich2.csv")); /*...*/ legestionnaire->AddItems(legestionnaire->Load<ChargeObjetDepuisTable>(larequeteSQL)); /*...*/

---

Citation:

---

Envoyé par Miles

Dans ce cas, le template, il est bien adapté ?

---

Ah, ca, la question mérite d'être posée :D

Citation:

---

Envoyé par koala01

De plus, je me demande si tu n'a pas tendance à déjà trop t'impliquer dans le langage qui sera utilisé :P

---

En fait le code est déjà écrit, C++ évidement, avec les techniques que j'ai trouvé appropriées (templates + policies).
J'essaye juste de représenter au plus juste mon travail pour que, lorsque quelqu'un voudra y mettre le nez en vue d'ajouter une extension, cela soit simple et compréhensible pour lui.

Citation:

---

Envoyé par Miles

Dans ce cas, le template, il est bien adapté ?

---

Et bien, pour décrire un peu plus ma situation, on a besoin, dans notre programme, d'utiliser (en lecture seulement) des objets dont la structure est la suivante :

• Code alphanum
• Libellé réduit
• Libellé complet
• Taux

Comme exemple d'utilisation, on va éventuellement rattacher une rubrique métier à un de ces objets. Lors de l'impression de la rubrique, on va utiliser le libellé complet de l'objet et se servir du taux pour faire un calcul. C'est à peu près tout ce qu'on est sencé faire avec... Jamais de modif des objets pour réinjection en tout cas.

Ces objets, on ne les invente pas, il nous sont fournis par différents organismes sous différents formats (word, excel etc.) et les formats utilisés pour nous transmettre les données sont susceptibles d'évoluer.

On a par exemple un vieux fichier texte qui contient des données qui ne changent jamais (donc pas réactualisées ni renvoyées par les organismes). Ce fichier est très pratique car il respecte l'ordre des données de la structure en séparant par des tabulations.

A côté de ça, d'autres fichiers nous sont régulièrement envoyés pour compléter le premier. Mais ils utilisent cette fois un tableau word et la présentation n'est plus la même (ordre différent, données en plus et inutiles pour nous, code alphanumérique non construit - à nous de le faire). On peut facilement exporter le contenu du tableau word vers un fichier texte où les données sont séparées par des tab, mais reste que la structure n'est toujours pas la même.

J'ai donc à peu près ça :

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

class Objet;   class Gestionnaire { ~Gestionnaire() { // for_each + Delete() }   template <class LOADPOLICY> void Charger( string indics ) { LOADPOLICY load( indics ); Objet* obj = NULL; while ( obj = load.GetObjet() ) set_.insert( obj ); // set car les objets doivent être triés par code }   Objet const * GetPremier(); Objet const * GetSuivant(); };   template <UNSCRAMBLEPOLICY> class ChargeurFichierTexte { ChargeurFichierTexte( string const & filename ) : ifstream_( filename ) { }   ~ChargeurFichierTexte() { if ( ifstream_ ) ifstream_.close(); }   Objet * GetObject() { Objet * obj = NULL; string str; std::getline( ifstream_, str ); if ( !str.empty() ) { UNSCRAMBLEPOLICY::Process( str ); obj = new Object( str.substr(...), str.substr ... ) } return obj; } };   class DecodeurAucun { static void Process( string const & str ) { // rien } };   class DecodeurLigneOrganisme1 { static void Process( string const & str ) { str = ... // modif de la chaine pour présenter les données comme voulu } };

---

Je n'avais jusqu'à présent pas parlé de la politique de décodage pour simplifier mais puisque je suis lancé...

Je peux donc charger tous mes objets très simplement au démarrage de l'appli comme ça :

Code:

---

1 2 3 4 5 6

Gestionnaire & gest = Singleton::Instance(); gest.Load<ChargeurFichierTexte<DecodeurAucun> >( "Commun.txt" ); if ( region == "alsace moselle" ) gest.Load<ChargeurFichierTexte<DecodeurOrganisme2> >( "AM.txt" ); else gest.Load<ChargeurFichierTexte<DecodeurOrganisme1> >( "General.txt" );

---

Si une autre région nous envoie un fichier xml dans le futur, j'aurai juste à écrire un autre Chargeur. Vous voyez le truc ?

Au passage, à quoi bon ces curieux AddItems() koala01 ??

Allez j'en rajoute une couche.

Une fois tous mes objets chargés, j'ai plusieurs endroits dans l'appli où ils apparaissent, et je ne dois pas afficher les mêmes partout. En effet ils possèdent un type qui découle de leur code (tous les objets dont le code commence par "1A" jusqu'à "1Z" sont de type bidule et je dois les afficher dans cette fenêtre là et pas celle là.

J'ai donc ajouté une notion de filtre (un prédicat) qui, une fois en place, permet de ne renvoyer que les bons objets.

Code:

---

1 2 3 4 5 6 7

class FiltreAucun : public Filtre { virtual bool Filtrer( string const & str ) { return true; } };

---

Code:

---

1 2 3 4 5 6 7 8 9

gest.SetFiltre( filtreBidule );   Objet * obj = NULL; obj = gest.GetPremier(); // Teste le prédicat et renvoie le premier qui y répond while ( obj ) { // affichage de obj obj = gest.GetSuivant(); // Teste le prédicat }

---

Seulement voilà, ça me turlupinait de devoir passer par une méthode virtuelle alors qu'il existe un moyen pour ne pas avoir à le faire :

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

class Gestionnaire { (...)   template <class FILTERPOLICY> Objet const * GetPremier();   template <class FILTERPOLICY> Objet const * GetSuivant() { ++iter_; while ( iter_ != set_.end() && !FILTERPOLICY::Filtrer( iter->GetCode() ) ) ++iter_; return ( iter_ != set_.end() ? *iter : NULL ); } };   class FiltreTypeBidule { static bool Filtrer( string const & str ) { return str[0] == '1' && str[0] >= 'A' && str[0] <= 'Z'; } };

---

Code:

---

1 2 3 4 5 6 7

Objet * obj = NULL; obj = gest.GetPremier<FiltreBidule>(); while ( obj ) { // affichage de obj obj = gest.GetSuivant<FiltreBidule>(); }

---

C'est pas forcément un choix évident pour toutes les situations (on perd quand même la possibilité d'utiliser le polymorphisme du filtre si l'on avait voulu rassembler en un seul endroit l'affichage de toutes les fenêtres) mais dans mon cas ça colle bien.
Je suis sur que cette solution peut faire gagner en perf face à la version polymorphique, et vu l'existant, un peu de perfs gagnées ici et là, ça n'est vraiment pas du luxe.

Donc avec mon mécanisme, je suis tout de même prêt à écrire de nouveaux filtres, de nouveaux chargeurs, de nouveaux décodeurs, sans avoir à toucher le code du gestionnaire.

Il n'y a qu'un changement de l'objet qui pourrait impliquer pas mal de réécriture, mais c'est un peu normal, c'est la base du système non ?

Maintenant que tout est dit, comment je représente ça dans un diagramme de classe ? :lol:

Heu...

On ne te l'a peut etre jamais dit, mais, idéalement, l'UML est fait avant de commencer à code, quitte à y revenir si un problème auquel on n'a pas réfléchi apparait :D

Sinon, l'idée de mon addItems était que j'avais envisagé ton gestionnaire comme un gestionnaire de tes objets...

L'idée aurait donc été d'avoir un comportement "charger au départ du fichier <format du fichier>" qui renvoie... une liste d'objet ainsi qu'un comportement "ajouter (liste d') éléments, que j'ai traduit par "addItems".

L'initialisation se fait donc en remplissant une première fois la liste des objet avec... la liste d'objet renvoyée par "charger au depart du fichier", et de faire l'ajout en utilisant "ajoute elements" et en lui passant comme parametre... la liste des éléments renvoyée par... "charger au départ du fichier" ;):D

En fait ma fonction Load ne vide pas le std::set sousjacent donc je ne pense pas avoir besoin d'une telle fonction.

UML est bien gentil, mais je ne l'ai jamais trouvé très approprié pour représenter correctement les familles de points communs et les points de variabilité que le C++ nous permet d'exploiter.

Ne te prend pas trop le choux. UML est un outil, non une finalité. Il ne sert qu'à préciser avec des zolis dessins le résultat de ton analyse/design. (et le diagramme UML qui tombe bon avant la première ligne de code, je n'y crois pas)
(Maintenant, je connais mal UML2)

Quelque part, on rejoint un peu le même principe qu'avec les concepts. Et je n'ai pas souvenir d'avoir croisé beaucoup de diagrammes UML pour dire que std::list raffine les concepts de séquence bi-directionnelle itérable, objet valeur, ...

Bien qu'ayant moi aussi une expérience limitée d'UML, et pour cause, je suis d'un avis semblable à celui de Luc. Ils ont été conçus pour représenter un code objet, et c'est tout. L'objet n'est qu'un des paradigmes du C++.

A chaque fois que je tenté d'avoir un peu de niveau de détail dans des diagrammes UML, je me suis retrouvé incapable de représenter ce qui pour moi était important dans mon code C++.

En pratique, donc, je fais mes propres schémas (non normalisés) adaptés au cas en question, et accompagnés du texte qui va bien.

Je ne disconviens absolument pas du problème ;)

Il est vrai que, le but de l'UML est, finalement, de fournir un langage "commun" pour la conception...

Il a le gros avantage, effectivement, de fournir de beaux petits dessins parce que le principe du "un petit dessin vaut mieux qu'un grand discours" reste toujours vrai :D

Et, comme tout le monde le sait, il existe le même fossé entre la conception et la réalisation que celui qui existe entre la théorie et la pratique :D

Le problème vient, souvent, de ce que l'on se rende compte pendant la phase de réalisation que des problèmes (quelconques, pouvant parfois venir de mauvaise conception) qui n'étaient pas prévus font leur apparition.

"Dans un monde parfais", chaque fois qu'un problème apparait, il fautdrait adapter la conception à ce problème (en commençant par le début de solution trouvée), et la reprendre "entièrement" (ou peu s'en faut) à partir de ce point... mais cela devient rapidement ingérable :P (surtout quand on est déjà en retard :P)

Il ne faut donc surtout pas croire que je reproche en quoi que ce soit la manière de travailler de NiamorH (en plus, je suis pas son patron ;):D), et même, je me doute fort qu'il n'aura sans doute pas eu énormément le choix :P

Ceci dit, as tu déjà passé ton projet dans certains outils tels que doxygene, voire, l'avoir importé dans BOUML pour voir comment ces outils te représenteraient les différentes classes :question:

Cela pourrait, peut être, te mettre sur la voie pour terminer cette "retro ingénieurie" :D

C'est une idée.

La documentation, ce n'est pas dans les habitudes de la maison... donc je n'ai pas accès à doxygene. Je ferai ça chez moi si j'en trouve le temps.

En fait j'ai fait un petit diagramme à ma sauce, non formalisé UML, qui me va.

Pour appuyer les arguments de Luc et Loïc, j'ajouterais que l'UML est quasi parfait pour "imager" un code Java, par exemple.

Pour ce qui est du C++, dès qu'on avance un peu et qu'on en vient par exemple à utiliser des templates, c'est cuit.

Le peu de fois que j'ai eu à bosser sur un projet (loisir) avec d'autres personnes, j'ai toujours préféré l'établissement d'une "norme" pour nos schémas qui nous serait propre.

Donc ne te prends pas trop la tête sur la réprésentation car à mon avis tu auras du mal à trouver (si c'est possible) la représentation qui colle parfaitement.