Discussion :

[behess]

Bonjour,

Bruno, tu vas encore me dire que c'est écrit quelque part dans la doc...
mais j'ai deux problèmes :

- avec la génération de code Java : pour une association, le rôle d'une classe template n'est pas correctement définit lors de la génération de code (pas de <T> après le nom de la classe)

- avec les imports Java : une classe définie comme "external" (ex : les classes du package java.util) n'est pas importée lors de la génération de code, même avec une dépendance stéréotypée "import"

[bruno_pages]

- avec la génération de code Java : pour une association, le rôle d'une classe template n'est pas correctement définit lors de la génération de code (pas de <T> après le nom de la classe)

je ne comprends pas, il faudrait un exemple de ce qui est défini sous Bouml et du code attendu

- avec les imports Java : une classe définie comme "external" (ex : les classes du package java.util) n'est pas importée lors de la génération de code, même avec une dépendance stéréotypée "import"

les dépendances import ne s'appliquent pas aux classes externes, pour celles-ci il faudrait que je fasse comme pour C++

pour le moment il suffit de remplacer ${name} dans la définition de la classe externe par java.util.{name}

[behess]

il faudrait un exemple de ce qui est défini sous Bouml et du code attendu

Sous BOUML j'ai créé une Interface<O> avec le stéréotype « interface » et une Maclasse<T> qui implémente l'interface en mettant O->T. Il y a également une agrégation entre Maclasse et Interface avec un rôle "monInterface" en bout.

C'est ce rôle "monInterface" qui ne prend pas le type "Interface<O>".

[bruno_pages]

si j'ai bien compris le code voulut est :

Code :

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

1
2
3
4
5
6
7
interface Interface<O> {
}

class Maclasse<T> implements Interface<T> {
  protected Interface<T> monInterface;
}

(j'ai remplacé Interface<O> par Interface<T> au niveau de l'attribut vu le début de la discussion, et le fait que Interface<O> aurait été invalide)

rien n'impose que l'actual soit T dans la définition de l'attribut, le générateur de code ne peut donc de lui même produire un tel code, il faut le dire explicitement au niveau de la définition de la relation

[behess]

Ok tu as bien compris ce qui devrait être généré.

rien n'impose que l'actual soit T dans la définition de l'attribut, le générateur de code ne peut donc de lui même produire un tel code, il faut le dire explicitement au niveau de la définition de la relation

Comment faire ? Au niveau de la relation on ne peut définir que le rôle, pas le type / actual à utiliser...

[bruno_pages]

Comment faire ? Au niveau de la relation on ne peut définir que le rôle, pas le type / actual à utiliser...

il y a plusieurs possibilités, par exemple dans la définition de la relation remplacer ${type} par ${type}<T> (c'est ce qu'aurait fait le reverse)

[behess]

rien n'impose que l'actual soit T dans la définition de l'attribut, le générateur de code ne peut donc de lui même produire un tel code, il faut le dire explicitement au niveau de la définition de la relation

Comme les génériques sont gérés par ailleurs, je pensais que la non généricité des rôle était un oubli (mais c'est volontaire plutôt si j'ai bien compris).

il y a plusieurs possibilités, par exemple dans la définition de la relation remplacer ${type} par ${type}<T> (c'est ce qu'aurait fait le reverse)

Je vais le définir comme ça donc.

pour le moment il suffit de remplacer ${name} dans la définition de la classe externe par java.util.{name}

donc pas d'import, ok

les dépendances import ne s'appliquent pas aux classes externes, pour celles-ci il faudrait que je fasse comme pour C++

c'est donc au programme ? chouette

[bruno_pages]

Comme les génériques sont gérés par ailleurs, je pensais que la non généricité des rôle était un oubli (mais c'est volontaire plutôt si j'ai bien compris).

encore une fois, comment le générateur pourrait-il deviner qu'il doit produire Interface<T> plutôt que Interface<int> par exemple ?

je n'ai pas mis l'option boule de cristal dans Bouml ...

[behess]

Non mais tu aurais pu proposer une option au niveau du rôle pour définir le type exact... m'enfin

[bruno_pages]

Non mais tu aurais pu proposer une option au niveau du rôle pour définir le type exact... m'enfin

les possibilités sont plus vastes que cela :

• et si on veut seulement produire le nom du type, quelque soit la raison?
• et si on veut séparer les actuals par des espaces, ou des sauts de ligne, ou autre ?
• et s'il y a plusieurs actuals ?

sauf dans de très rares cas où cela aurait rendu les choses difficilement utilisable, le code généré est spécifié explicitement, permettant à l'utilisateur de produire exactement ce qu'il veut au lieu de subir mes choix

[hed62]

"La liberté se monnaie par des responsabilité" (Djensépuki)

C'est une constantes dans les applications. Si l'utilisateur dispose d'une liberté, cela le force à prendre la responsabilité du choix, à s'exprimer pour formuler ce qu'il veut.

Si on automatise la chose, l'utilisateur a moins de responsabilité mais moins de liberté aussi.

Si on désire, après automatisme, de permettre de faire soit ceci, soit cela, alors il faut demander à l'utilisateur de choisir

[bruno_pages]

- avec les imports Java : une classe définie comme "external" (ex : les classes du package java.util) n'est pas importée lors de la génération de code, même avec une dépendance stéréotypée "import"

j'ai finalement étendu les dépendances import aux classes externes dans la version 4.4

[behess]

Comme quoi les rêves les plus fous peuvent se réaliser !

Merci Bruno

[behess]

L'import des classes externe fonctionne bien

J'ai un autre problème que je n'arrive pas à résoudre...

J'ai une agrégation entre une classe stéréotypée « interface » et une classe qui l'implémente (pour info : classe abstraite).

Voici ce qu'on trouve dans définition de la relation :

${comment}${@}${visibility}${static}${final}${transient}${volatile}${type} ${name}${value};
public ${type} get${type}(){
//TODO:customize getter
return ${name};
}
public void set${type}(${type} ${name}){
//TODO:customize setter
this.${name}=${name};
}

génération Java de la relation dans BOUML :

private EventHandlable eventHandler=null;
public EventHandlable getEventHandlable(){
//TODO:customize getter
return eventHandler;
}
public void setEventHandlable(EventHandlable eventHandler){
//TODO:customize setter
this.eventHandler=eventHandler;
}

C'est nickel.

Résultat dans le fichier de la classe qui implémente l'interface :

import org.behess.ClasseMachin;
import org.behess.events.EventHandlable;

[...]

private org.behess.events.EventHandlable eventHandler=null;
public org.behess.events.EventHandlable getorg.behess.events.EventHandlable(){
//TODO:customize getter
return eventHandler;
}
public void setorg.behess.events.EventHandlable(org.behess.events.EventHandlable eventHandler){
//TODO:customize setter
this.eventHandler=eventHandler;
}

Le nom du package s'insère dans le type quand on fait la génération, mais pas dans le code généré directement dans BOUML.

Ce qu'on voudrait c'est avoir la même chose en généré que dans BOUML...

A noter : il existe une dépendance stéréotypée « import » entre la classe qui implémente l'interface et cette dernière.

Est-ce un bug ?
Y a-t-il un moyen de dire à BOUML de ne pas utiliser le type canonique (avec espace de nom) mais le type court (genre ${short_type}) ?

[bruno_pages]

Le nom du package s'insère dans le type quand on fait la génération, mais pas dans le code généré directement dans BOUML.

en fait dans le dialogue sous bouml je ne m'embête pas à préfixer si besoin les noms de classes par leur package

Est-ce un bug ?

non

Y a-t-il un moyen de dire à BOUML de ne pas utiliser le type canonique (avec espace de nom) mais le type court (genre ${short_type}) ?

non plus, il ne faut pas utiliser ${type} dans un nom

pourquoi avoir utilisé get${type} au lieu de get${name} ou get${Name} ?

sinon, pourquoi faire les getter/setter à la main alors qu'on peut demandé à Bouml de le faire ?

[behess]

en fait dans le dialogue sous bouml je ne m'embête pas à préfixer si besoin les noms de classes par leur package

Ok : dans BOUML on a une génération "bridée" par rapport au générateur de code.

Il serait quand même bien d'avoir a sa disposition un outil tel que ${short_type} (ou autre), ça pourrait servir, non ?

pourquoi avoir utilisé get${type} au lieu de get${name} ou get${Name} ?

C'est une bonne question, merci de l'avoir posée.
Au départ je crois l'avoir configuré de cette manière parce que get${name} n'allait pas (il manquait une majuscule après "get") et que ${Name} ne fonctionne pas (il est conservé tel que).

[bruno_pages]

Au départ je crois l'avoir configuré de cette manière parce que get${name} n'allait pas (il manquait une majuscule après "get") et que ${Name} ne fonctionne pas (il est conservé tel que).

c'est vrai, ${Name} est géré au niveau des opérations (et artifacts) mais pas au niveau relation/attribut

reste la question relative a l'utilisation des getter/setter

[behess]

reste la question relative a l'utilisation des getter/setter

sinon, pourquoi faire les getter/setter à la main alors qu'on peut demandé à Bouml de le faire ?

Mais j'ai utilisé les setters/getters par défaut. C'est là le problème : ils ne gèrent pas ${Name} apparemment. C'est pour ça que j'avais mis ${type} dans la définition par défaut...

[bruno_pages]

je parle des getter/setter fabriqués par Bouml via le menu, ceux-ci sont créés en dehors de la définition de la relation et supportent ${Name}

[behess]

D'acccccccccccccccord

Je n'avais pas saisi pardon

Le problème c'est que je défini un rôle dans ma relation et que je ne peux pas définir d'attribut ayant le même nom de rôle dans la classe.

Je comprends donc que je devrais "bidouiller" un faux nom de rôle (ex : anEventHandler), bloquer la génération de la relation et utiliser un attribut comme "véritable" nom : (ex : eventHandler), plus générer des get/setter à partir de cet attribut.

Ok ça peut corriger le problème, mais ce n'est pas vraiment très propre, non ?
ça serait quand même mieux que la relation puisse gérer {$Name}