génération forward declaration en C++

[johanjof]

Bonjour,

Je rencontre quelques soucis avec la generation de forward declaration. Ne sachant comment la modéliser en UML, j'ai écris un code en C++ et demandé à Bouml de générer l'UML ce qu'il a fait notamment à l'aide d'une liaison de dépendance récursive. Le code était le suivant :

Code: Select all

typedef struct machin machin;
class truc
{
 machin *variable;
};

En regénérant le code UML issu du modèle, je retrouve le bon code.
Malheureusement, en reproduisant la même modélisation UML pour de nouveaux éléments (cf "nouveautype" ci-dessous), la forward déclaration dans le code généré en C++ se retrouve systématiquement APRES la déclaration de la classe, ce qui produira une erreur de compilation. Y a t-il une solution ?

Code: Select all

typedef struct machin machin;
class truc
{
 machin *variable;
 void fonction(nouveautype** var);
};
typedef struct nouveautype nouveautype;

Par ailleurs, la génération inverse du code ci-dessus (avec la nouvelle déclaration placée correctement au dessus de la classe), ne produit aucun lien entre nouveautype et la classe truc. Comment faut-il procéder pour que cela soit le cas ?

Merci beaucoup

[Bruno Pagès]

Bonjour,

Ne sachant comment la modéliser en UML, j'ai écris un code en C++ et demandé à Bouml de générer l'UML

utiliser le reverse est la bonne méthode quand on ne sait pas comment faire, même si le reverse a des limites et qu'il peut y avoir d'autres solutions que celle fournie par lui

Code: Select all

typedef struct machin machin;
class truc
{
 machin *variable;
};

Le typedef est valide mais bien inutile en C++ ou "struct machin;" est suffisant

Malheureusement, en reproduisant la même modélisation UML pour de nouveaux éléments (cf "nouveautype" ci-dessous), la forward déclaration dans le code généré en C++ se retrouve systématiquement APRES la déclaration de la classe, ce qui produira une erreur de compilation. Y a t-il une solution ?

Code: Select all

typedef struct machin machin;
class truc
{
 machin *variable;
 void fonction(nouveautype** var);
};
typedef struct nouveautype nouveautype;

L'ordre de génération ne fait que suivre l'ordre indiqué dans le modèle, si un même artéfact génère le tout vous devez déplacer la classe supportant votre typedef nouveautype avant celle pour truc dans la liste des classes associées à l'artéfact, en éditant ce dernier

Par ailleurs, la génération inverse du code ci-dessus (avec la nouvelle déclaration placée correctement au dessus de la classe), ne produit aucun lien entre nouveautype et la classe truc. Comment faut-il procéder pour que cela soit le cas ?

Le reverse ne crée pas de dépendance à chaque fois qu'un type référencé par un autre, sinon cela aboutirait à un sacré plat de nouille, donc rien d'anormal

Notez que si vous avez modélisé toutes les classes (ici truc machin et nouveautype) et que chacune est supportée pas un artéfact propre alors il est inutile de définir les typedefs associés, la génération de code produira toute seule les forward déclarations

[johanjof]

utiliser le reverse est la bonne méthode quand on ne sait pas comment faire, même si le reverse a des limites et qu'il peut y avoir d'autres solutions que celle fournie par lui

A priori, je n'ai pas trouvé d'autre représentation. Par exemple Enterprise Architect ne diffère que en utilisant une liaison récursive de généralisation à la place de la dépendance. Bouml refuse la liaison récursive type généralisation.

utiliser le reverse est la bonne méthode quand on ne sait pas comment faire, même si le reverse a des limites et qu'il peut y avoir d'autres solutions que celle fournie par lui

Pour tout vous dire, ce code est un exemple pour une utilisation d'un type de libusb, et sa déclaration est faite comme cela. Je me contente de recopier seulement cette déclaration et d'ajouter le header qui va bien dans l'artefact, dans la rubrique C++ source, afin de pouvoir utiliser des types non connus/modélisés dans Bouml.

L'ordre de génération ne fait que suivre l'ordre indiqué dans le modèle

.
Voilà ! C'est ça que j'ai raté ! Je ne savais pas que l'ordre comptais dans la vue des classes, ni qu'on pouvait les "glisser". Merci

Notez que si vous avez modélisé toutes les classes (ici truc machin et nouveautype) et que chacune est supportée pas un artéfact propre alors il est inutile de définir les typedefs associés, la génération de code produira toute seule les forward déclarations

Dans mon cas, machin et nouveautype ne sont pas modélisés et leur définition est contenue dans le header que j'ajoute à l'artefact comme indiqué ci-dessus, et tous ces types sont donc dans le même artefact. En reverse, le type apparaît bien, mais l'include du cpp "libusb.h" est ignoré et donc le nouveau code généré ne compilera pas.

[Bruno Pagès]

Dans mon cas, machin et nouveautype ne sont pas modélisés et leur définition est contenue dans le header que j'ajoute à l'artefact comme indiqué ci-dessus, et tous ces types sont donc dans le même artefact.

Une façon propre de gérer les classes/types externes (au sens ou bouml n'en connait pas la définition) est d'en faire des classes ... "externes", cela vous permet de les utiliser comme d'autres classes/types afin de typer des attributs ou de les utiliser pour des relations etc. Cependant il y a un revers, le générateur ne sait rien les concernant, il est donc incapable de produire une déclaration pour elles, et donc il produit directement l'#include dés que c'est nécessaire. Les list ou autres template de la stl sont des candidats tout désignés pour les classe externes, même si ceux-ci peuvent aussi être gérés autrement via les options de génération (onglet C++[5] lorsque vous éditez les options de génération).

En reverse, le type apparaît bien, mais l'include du cpp "libusb.h" est ignoré et donc le nouveau code généré ne compilera pas.

c'est un exemple de ce qui est perdu lors du reverse/roundtrip et donc ensuite à la génération

[johanjof]

En d'autres termes, si je veux pouvoir travailler de façon fluide c++/model et vice-versa sans perdre de code (notamment avec la méthode de roundtrip body que vous m'avez proposé dans un autre ticket que j'avais ouvert), la seule méthode possible est de disposer du code entier d'une bibliothèque par exemple et de le reverse dans Bouml ?
(avec le risque très probable de problèmes lors du reverse, sur de si grandes quantités de code à absorber)

[Bruno Pagès]

Je me répète mais pour moi

• soit vous faites tout dans Bouml (sauf peut être la saisie/modification du corps des opérations via l'iotion de preservation de corps), et vous utilisez donc le générateur mais pas le reverse ni le roundtrip
• soit vous créez/modifiez vos classes en dehors de Bouml et vous utilisez le reverse (une fois) puis le roundtrip pour mettre à jour votre modèle à partir de vos sources modifiés typiquement à des fins de documentation, et vous n'utilisez donc pas le générateur

Si vous mixez génération et roundtrip (le 'vrai', pas 'roundtrip body') vous risquez des problème pour des applications en C++