C++ et outils UML : Compatibles ?

"loic.actarus.joly@numericable.fr" <loic.actarus.joly@numericable.fr> writes:

Bonjour,

Une question me turlupine. J'ai plusieurs fois tenté de regarder ce
que donnerait la génération de code depuis un diagramme de classes UML
ou du même style. Avec des langages autres que du C++ (C# en
l'occurrence), je n'ai pas eu de problème spécifique. Avec du C++, ce
n'est pas la même chose.

Je ne parle pas là de problèmes techniques (qui n'auraient pas leur
place ici), mais de problèmes philosophiques. J'ai le sentiment que
les graphes UML ne représentent pas les informations que j'aimerais
voir pour générer du C++. En particulier, les liens entre classe
(agrégation, composition) me semblent très pauvres par rapport à ce
que j'ai l'habitude d'utiliser (une valeur dans la classe, un pointeur
nu, une référence, une variante de pointeur intelligent, un conteneur
bien choisi, un conteneur bien choisi d'une variante de pointeurs
intelligents,...).

Réciproquement, quand je lis un diagramme UML issus de code C++, je le
trouve superficiel. Il rend des services, mais je suis très vite
obligé de me replonger dans le code pour y trouver ce que je cherche.
Je n'ai pas non plus cet effet quand je lis de l'UML issus de C#.

Sans parler des aspects de programmation qu'UML ne gère pas vraiment
(programmation générique, par exemple).

Est-ce que je suis le seul à avoir ce genre de problèmes ? Est-ce que
d'autre utilisent avec succès des outils UML jusqu'à la génération de
code C++ ?

Oui. Mais tu as raison, modéliser en détail du code C++ n'est pas le
point fort d'UML. Ce n'est pas fait pour ça. Mais il faut prendre le
point de vue inverse: C++ laisse rentrer dans des détails qui
n'importent absolument pas quand on développe une application en
orienté objet. Il faut ignorer ces détails. L'outils UML se
configure pour générer les notions UML d'une et d'une seule manière,
et on oublie le code C++, ce ne sont plus que des fichiers
intermédiaires comme les .s parfois générés entre le compilateur et
l'assembleur.

Ceci dit, certains ateliers comme Objecteering permettent d'ajouter
des "étiquettes", des attributs hors de UML aux classes et opérations
pour pourvoir générer du code C++ spécifique. Mais il ne faudrait pas
en abuser.


En C++, on ne peut pas utiliser tout le langage dans un seul projet.
Il faut choisir au début du projet un sous-ensemble cohérent de C++,
augmenté d'une bibliothèque cohérente, et se limiter à ce nouveau
langage, qui peut être trés éloigné de C++.

--
__Pascal Bourguignon__

On Sep 10, 11:57 am, "loic.actarus.j...@numericable.fr"
<loic.actarus.j...@numericable.fr> wrote:

Une question me turlupine. J'ai plusieurs fois tenté de
regarder ce que donnerait la génération de code depuis un
diagramme de classes UML ou du même style. Avec des langages
autres que du C++ (C# en l'occurrence), je n'ai pas eu de
problème spécifique. Avec du C++, ce n'est pas la même chose.

Je me suis servi de Rationale Rose avec C++, sans problèmes
particuliers.

Je ne parle pas là de problèmes techniques (qui n'auraient pas
leur place ici), mais de problèmes philosophiques. J'ai le
sentiment que les graphes UML ne représentent pas les
informations que j'aimerais voir pour générer du C++. En
particulier, les liens entre classe (agrégation, composition)
me semblent très pauvres par rapport à ce que j'ai l'habitude
d'utiliser (une valeur dans la classe, un pointeur nu, une
référence, une variante de pointeur intelligent, un conteneur
bien choisi, un conteneur bien choisi d'une variante de
pointeurs intelligents,...).

Ça dépend de ce que tu veux montrer. À un niveau d'abstraction
assez élevée, tout ça, c'est des détails de l'implémentation,
sans importance. Dès qu'on commence à considérer plusieurs
classes, en fait. Donc, on ne le veut pas trop dans les
diagrammes. Ce genre de détails ont plutôt leur place dans la
déscription de la classe, et Rational Rose, au moins, les
prévoir à ce niveau-là. (Encore que la façon qu'elle les prévoir
pourrait être un peu plus agréable.)

Réciproquement, quand je lis un diagramme UML issus de code
C++, je le trouve superficiel.

Est-ce que par « superficiel », tu ne veux pas dire « d'un
niveau d'abstraction trop élevé » ? C'est là où je ne suis pas
tout à fait d'accord. Au niveau de la conception, ce qui
importe, c'est que la classe A contient une instance de la
classe B (agrégation), et non la technique précise utilisée à
implémenter l'agrégation (qui dépend de la cardinalité et du
« polymorphité » de l'objet ou des objets agrégé(s)).

Il rend des services, mais je suis très vite obligé de me
replonger dans le code pour y trouver ce que je cherche. Je
n'ai pas non plus cet effet quand je lis de l'UML issus de C#.

À un moment ou un autre, il faut bien aller au code. Quelque
soit le langage.

Sans parler des aspects de programmation qu'UML ne gère pas
vraiment (programmation générique, par exemple).

L'UML a bien du support pour des types génériques. Mais si tu
parles de la méta-programmation templatée, non. En revanche,
j'ai des sérieuses doutes sur son utilité au niveau applicatif.

Mais là n'est pas la question. L'UML couvre certains aspects de
la conception. Il ne couvre (et ne peut pas couvrir) tous.
Comment tu fais en UML, par exemple, quand tu génères des
classes avec d'autres programmes (ce qui est arrivé dans prèsque
tous les projets sur lesquels j'ai travaillé) ?

Le problème que j'ai avec les outils UML (mais c'est un problème
indépendant du langage), c'est qu'ils integrent assez mal
d'autres formes d'expression que les diagrammes. Or, il y a
toujours des aspects de la conception qui s'expriment mieux par
d'autres moyens : du texte, des expressions mathématique, ou
d'autres formes de diagrammes.

Est-ce que je suis le seul à avoir ce genre de problèmes ?

Sans doute pas le seul, mais dans l'ensemble, j'ai trouvé que
Rational Rose apportait même plus à C++ qu'à Java (mais c'est
peut-être parce que je m'attaque à des problèmes plus ardus en
C++). Sans résoudre tous les problèmes d'expression.

Est-ce que d'autre utilisent avec succès des outils UML
jusqu'à la génération de code C++ ?

Je m'en suis servi dans au moins deux applications. Dans la
première (il y a assez longtemps -- avant que le C++ supporte
les templates), on ne s'en est servi que pour les fichiers
d'en-tête, mais alors, on s'en servait du code généré
directement, sans en éditer une ligne : les fichiers .hh
étaient des objets générés du point de vue de Clearcase. Dans la
deuxième, on s'en servait et pour les en-têtes et pour les
sources. Sans problèmes.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

loic.actarus.joly@numericable.fr a écrit :

Bonjour,

Une question me turlupine. J'ai plusieurs fois tenté de regarder ce
que donnerait la génération de code depuis un diagramme de classes UML
ou du même style. Avec des langages autres que du C++ (C# en
l'occurrence), je n'ai pas eu de problème spécifique. Avec du C++, ce
n'est pas la même chose.

Je ne parle pas là de problèmes techniques (qui n'auraient pas leur
place ici), mais de problèmes philosophiques. J'ai le sentiment que
les graphes UML ne représentent pas les informations que j'aimerais
voir pour générer du C++. En particulier, les liens entre classe
(agrégation, composition) me semblent très pauvres par rapport à ce
que j'ai l'habitude d'utiliser (une valeur dans la classe, un pointeur
nu, une référence, une variante de pointeur intelligent, un conteneur
bien choisi, un conteneur bien choisi d'une variante de pointeurs
intelligents,...).

Réciproquement, quand je lis un diagramme UML issus de code C++, je le
trouve superficiel. Il rend des services, mais je suis très vite
obligé de me replonger dans le code pour y trouver ce que je cherche.
Je n'ai pas non plus cet effet quand je lis de l'UML issus de C#.

Sans parler des aspects de programmation qu'UML ne gère pas vraiment
(programmation générique, par exemple).

Est-ce que je suis le seul à avoir ce genre de problèmes ? Est-ce que
d'autre utilisent avec succès des outils UML jusqu'à la génération de
code C++ ?

A+

--
Loïc

Je suis dans le même cas que James Kanze. Je n'ai jamais eu de problème
de génération de code à partir de Rational Rose, ni, d'ailleurs, avec
Objecteering de Softeam.

je pense qu'il s'agit d'un problème de niveau d'abstraction.
La conception globale NE DOIT PAS entrer dans les détails d'implémentation.

C'est un peu la même chose entre la conception UML et la programmation
objet qu'entre un langage de haut niveau et l'assembleur :
- Dans un langage de haut niveau, on ne se préoccupe pas de la gestion
des registres
- Dans une conception objet, on ne se préoccupe pas de la "cuisine" sur
les pointeurs (il faut d'ailleurs relire, à propos des pointeurs en
conception, ce que disait James Rumbaugh à l'origine sur le sujet : "pas
de pointeur en conception")

Une question Loïc, mais c'est peut-être difficile de répondre en
quelques lignes : qu'est-ce qui te fait dire qu'en C# tu n'as pas de
problème spécifique vis-à-vis de UML ?

Wykaaa

On 11 sep, 17:03, Wykaaa <wyk...@yahoo.fr> wrote:

Je suis dans le même cas que James Kanze. Je n'ai jamais eu de problè me
de génération de code à partir de Rational Rose, ni, d'ailleurs, av ec
Objecteering de Softeam.

je pense qu'il s'agit d'un problème de niveau d'abstraction.
La conception globale NE DOIT PAS entrer dans les détails d'implément ation.

La conception globale, non, bien entendu. Mais là, je parle d'aller
jusqu'à la génération de code, et là, je n'ai plus l'impression d' être
au niveau global. Peut-être voulais-je aller trop loin avec ces
outils ?

- Dans une conception objet, on ne se préoccupe pas de la "cuisine" sur
les pointeurs (il faut d'ailleurs relire, à propos des pointeurs en
conception, ce que disait James Rumbaugh à l'origine sur le sujet : "pa s
de pointeur en conception")

Mais à ce niveau là, est-ce encore de la conception ? Ce que je
cherchais, c'était justement le chaînon manquant qui me permettrait de
rapprocher conception et réalisation.

Une question Loïc, mais c'est peut-être difficile de répondre en
quelques lignes : qu'est-ce qui te fait dire qu'en C# tu n'as pas de
problème spécifique vis-à-vis de UML ?

Ce n'est pas facile à exprimer...

Le fait d'avoir utilisé un outil qui me permettait des round-trips
instantanées entre vision code et vision graphique (le seul que j'ai
vu faire ça en C++ était together, mais payant, donc j'ai pas essayé
longtemps, et très lourd en perfs et donc peu agréable à utiliser sur
la durée).

Le fait que le code que je faisais en C# était moins critique que
celui en C++, et donc que j'acceptais peut-être plus d'avoir un
contrôle moins fort.

Le fait que le projet où j'ai mis ça en œuvre en C# était assez pet it,
donc plus aisément gérable.

Le fait qu'il y ait moins de choix à effectuer en C# qu'en C++, et
donc moins de chose à spécifier sur les schémas.

D'autres points sûrement. Je serais curieux de travailler pendant
quelque temps dans une équipe où ces pratiques sont mises en œuvre,
afin de pouvoir élargir mon point de vue sur ce sujet.

--
Loïc

On Sep 12, 8:43 pm, "loic.actarus.j...@numericable.fr"
<loic.actarus.j...@numericable.fr> wrote:

On 11 sep, 17:03, Wykaaa <wyk...@yahoo.fr> wrote:

> Je suis dans le même cas que James Kanze. Je n'ai jamais eu
> de problème de génération de code à partir de Rational Rose,
> ni, d'ailleurs, avec Objecteering de Softeam.

> je pense qu'il s'agit d'un problème de niveau d'abstraction.
> La conception globale NE DOIT PAS entrer dans les détails
> d'implémentation.

La conception globale, non, bien entendu. Mais là, je parle
d'aller jusqu'à la génération de code, et là, je n'ai plus
l'impression d'être au niveau global. Peut-être voulais-je
aller trop loin avec ces outils ?

Oui et non. En ce qui concerne l'UML proprement dit, il ne
s'adresse pas trop à la réalisation, et un diagramme UML ne doit
pas contenir des détails de la réalisation. L'outil que je
connais, en revanche (Rational Rose, mais j'imagine que c'est
vrai des autres aussi), à des mechansimes supplémentaires ; si
tu clickes sur une classe, dans un diagramme, il ouvre une boîte
de dialogue où tu peux donner beaucoup de détails de
l'implémentation. Assez pour qu'il puisse générer le code. Ce
n'est pas vraiment parfait, mais c'est utilisable, dans
l'ensemble, et ça a quand même certains avantages.

> - Dans une conception objet, on ne se préoccupe pas de la
> "cuisine" sur les pointeurs (il faut d'ailleurs relire, à
> propos des pointeurs en conception, ce que disait James
> Rumbaugh à l'origine sur le sujet : "pas de pointeur en
> conception")

Mais à ce niveau là, est-ce encore de la conception ?

À quel niveau ? Le niveau dont tu parles, ou celui dont parle
Rumgaugh ? C'est certain (à mon avis, en tout cas) que le choix
entre T*, boost::shared_ptr<T> ou un autre pointeur intelligent
est un détail de l'implémentation, et non partie de la
conception. Encore que... est-ce que l'interface ou le contrat
font partie de la conception ? Le fait que j'utilise
std::auto_ptr dans l'interface de ma queue de messages, par
exemple, dit beaucoup sur la gestion des messages entre les
threads.

Ce que je cherchais, c'était justement le chaînon manquant qui
me permettrait de rapprocher conception et réalisation.

> Une question Loïc, mais c'est peut-être difficile de
> répondre en quelques lignes : qu'est-ce qui te fait dire
> qu'en C# tu n'as pas de problème spécifique vis-à-vis de UML
> ?

Ce n'est pas facile à exprimer...

Le fait d'avoir utilisé un outil qui me permettait des
round-trips instantanées entre vision code et vision graphique
(le seul que j'ai vu faire ça en C++ était together, mais
payant, donc j'ai pas essayé longtemps, et très lourd en perfs
et donc peu agréable à utiliser sur la durée).

J'ai d'assez bonnes expériences avec Rational Rose. Mais pour
être payant, c'est payant. Si ce n'est pas le client qui
l'achète, c'est hors question.

Le fait que le code que je faisais en C# était moins critique
que celui en C++, et donc que j'acceptais peut-être plus
d'avoir un contrôle moins fort.

Le fait que le projet où j'ai mis ça en œuvre en C# était
assez petit, donc plus aisément gérable.

Le fait qu'il y ait moins de choix à effectuer en C# qu'en
C++, et donc moins de chose à spécifier sur les schémas.

C'est certainement le cas pour Java.

D'autres points sûrement. Je serais curieux de travailler
pendant quelque temps dans une équipe où ces pratiques sont
mises en œuvre, afin de pouvoir élargir mon point de vue sur
ce sujet.

C'est en effet fort intéressant. Actuellement, je n'en est pas
accès, mais les projets où je me suis servi de Rational Rose
m'ont bien plu.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34