Discussion :

[three minute hero]

Bonjour,

Malgré mes recherches, je ne trouve aucun moyen d'indiquer à BOUML comment générer une liste d'initialisation pour le constructeur d'une classe (pour initialiser la classe mère et les différents champs).

Un exemple si sait-on jamais je me fais mal comprendre :

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
EditableListCtrl::EditableListCtrl(wxWindow* parent, wxWindowID id): wxPanel(parent), listCtrl(this, -1)
{
	// Bouml preserved body begin 00020682
	// Bouml preserved body end 00020682
 
}

wxPanel est la classe mère et listCtrl un champ privé.

Est-il possible de faire générer ceci à BOUML et si oui comment ?

Merci beaucoup et bravo pour ce bien sympathique logiciel !

[bruno_pages]

Bonjour,

ll faut modifier la définition du constructeur dans l'onglet C++.

Petit truc : quand on ne sait pas comment configurer Bouml pour produire un code donné, écrire un exemple de ce code, passer le reverse dessus et regarder les définitions ainsi créées. Cela ne donne par forcément le meilleur résultat dans 100% des cas, mais dans beaucoup de cas.

Donc, je creer un répertoire, et je mets dans celui-ci un fichier contenant :

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class wxPanel {
};
 
class listCtrl {
};
 
 
class EditableListCtrl : public wxPanel, public listCtrl {
  public:
    EditableListCtrl(wxWindow* parent, wxWindowID id);
};
 
EditableListCtrl::EditableListCtrl(wxWindow* parent, wxWindowID id): wxPanel(parent), listCtrl(this, -1)
{
}

puis je reverse ce répertoire, j'édite le constructeur et dans l'onglet C++ on voit (il serait mieux de remplacer wxPanel(parent) par wxPanel(${p0})) :

[three minute hero]

Tout d'abord merci beaucoup pour votre réponse.

La solution que vous décrivez est justement celle que j'emploie actuellement, en espérant qu'il existait une solution plus automatisée (avec une variable «$initialization_list» reliée à des champs de formulaire, par exemple). J'ai par ailleurs un instant pensé que le champ «initial value» des «Relation dialog» jouerai ce r̂ole.

Ne pensez-vous pas qu'il serait intéressant de proposer par défaut une telle fonctionnalité, étant donné qu'il est obligatoire, sinon recommandé, d'indiquer dans cette liste les valeurs par défaut des objets (n'étant pas des pointeurs) dont les classes ne possèdent pas de constructeur par défaut ? Et je ne parle même pas des classes mères…

[bruno_pages]

Les valeurs par défaut des attributs/relations ne sont pris en compte que pour les variables de classes (static). Elles ne sont pas prises pour les initialisations dans les constructeurs car il y a peu de chance que la même valeur soit utilisée dans tout les cas.

Sinon, il ne faut surtout pas avoir 'peur' d'adapter les déclarations/définitions comme cela est fait dans le cas présent : c'est ainsi que le code généré est spécifié. Ce mode de spécification permet à l'utiilsateur d'être maitre du code généré et non de subir les choix de l'outil sans rien pouvoir faire contre.

Bonnes modélisations

[three minute hero]

Il est vrai qu'à partir d'une certaine mesure, il devient nécessaire d'adapter manuellement. Mais plus que d'en avoir peur, j'étais intéressé par le fait de pousser jusqu'au bout (tout du moins jusqu'aux limites du coeur de l'implémentation) le concept de programmation graphique… et il se trouve qu'avec votre outil je ne m'en sens vraiment pas loin !

Enfin… ceci est une toute autre question, nous sortons légèrement du domaine de l'UML !

Merci encore pour ce support technique optimal, et bravo pour cette réactivité record !

[bruno_pages]

j'étais intéressé par le fait de pousser jusqu'au bout le concept de programmation graphique

En résumé il faudrait un bouton 'edit initializations' actif pour un constructeur et qui afficherait une table permettant de spécifier la forme placée entre '( )' pour les classes héritées et pour les attributs/relations de la classe courante. Evidemment la chose lirait & modifierait la forme modifiée actuellement à la main, de façon semblable à ce que fait 'edit parameters'.

Je vais essayé de mettre cela quelque part dans les TODOs, il y a peu de chance que ce soit dans la prochaine version que je voudrais livrer dimanche car actuellement je (re)travaille sur les instances de classes afin qu'elles existent au niveau browser et ne soient plus des elements purement graphique des diagrammes de sequence, collaboration et objet

Merci encore pour ce support technique optimal, et bravo pour cette réactivité record !

you welcome

[three minute hero]

Magnifique !

[three minute hero]

Bonjour,

Je déterre le topic pour vous annoncer que j'ai trouvé une solution plus flexible pour gérer les listes d'initialisation :

Il suffit d'ajouter une balise body comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
${comment}${inline}${class}::${name}${(}const ${t0} & ${p0}${)}${volatile}${throw}:
	${body}
{
	${body}
}

Le problème, c'est que la génération de code ne fonctionne plus dés qu'un des deux body est rempli. En effet, les deux balises partagent le même identifiant :

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
Area::Area(const string & name):
	// Bouml preserved body begin 00024302
	name(name),
	selected(false)
	// Bouml preserved body end 00024302
 
{
	// Bouml preserved body begin 00024302
	// Bouml preserved body end 00024302
 
}

Pourrait-on imaginer un bouton dans le formulaire «  Operation dialog» qui ajouterait les «: ${body}» avec un identifiant différent ? Vachement moins fatigant qu'une gestion complète de liste d'initialisation, avouez (même si ça serait mieux ).