Discussion :

[slopez]

Je sais que la question à déjà était posée mais est-il possible qu'une agrégation, spécialisation... ne génère pas le code suivant :

package testA;

class A extends testB.B {
...
}

Mais plutôt :

package testA;

import testB.B;

class A extends B {
...
}

[bruno_pages]

a question à déjà était posée

... et la réponse a également déjà été donnée

à moins que ce soit une demande d'évolution, genre :

• ajout d'une option de génération globale force package prefix generation mise à oui par défaut (compatibilité avec l'existant)
• non génération du préfixe s'il y a une dépendance stéréotypée import vers la classe en cause ou/et une dépendance stéréotypée import vers le package en question

[slopez]

Je trouve que l'évolution peut être très utile pour les génération de code en java. Les imports à mon gout permettent de garder une plus grande visibilité dans le code (longueur des lignes). En plus je pense que c'est à la personne de gérer dans son modèle les collisions de nom, elle est sensée savoir ce qu'elle fait (peut être une boite de dialogue pour prévenir d'un conflit de nom).

Le conflit de nom pourrait-être réglée à l'aide d'un choix local à l'agrégation, méthode, composition... du choix de préfixage ou nom (import ou totalité du package).

Après cela reste peut être spécifique au java, je ne sait pas trop si l'on peut l'étendre à d'autre langage (C++ ).

Cela pourrait aussi rentrée en compte dans la création des méthodes et des héritages, je m'explique. Par exemple B hérite de A. Cela implique l'import de A dans B. Ce qui évite par exemple de faire un import si j'ai besoinde la déclaration de A dans B. Et oui je pense quand uml une relation de type héritage, composition, réalisation... implique une relation d'utilisation (import en java et include en c++ par exempe).

[bruno_pages]

peut être une boite de dialogue pour prévenir d'un conflit de nom

non, de plus ne pas oublier que le but des espaces de noms est justement de permettre les homonymies, et non de les interdire !

Le conflit de nom pourrait-être réglée à l'aide d'un choix local à l'agrégation, méthode, composition... du choix de préfixage ou nom (import ou totalité du package).

en supposant force package prefix generation existant et valant no, la résolution d'une homonymie peut être résolue par l'utilisateur par exemple en remplaçant une forme ${type} par aze.qsd.${type}, c'est toute la force de la génération par substitution que j'ai choisi d'utiliser

Après cela reste peut être spécifique au java

cela n'est pas un problème, de toute façon un générateur de code ne peut pas ne pas avoir de règles lié au langages cible qu'il gère

pour info il y a déjà un force namespace prefix generation pour C++

Par exemple B hérite de A. Cela implique l'import de A dans B.

pas d'accord, si tel était le cas alors import n'existerait tout simplement pas en Java, il serait implicite et non explicite

je pense quand uml une relation de type héritage, composition, réalisation... implique une relation d'utilisation.

mais une relation d'utilisation n'implique pas un import, de toute façon UML ne connait pas Java ou autre langages

import en java et include en c++ par exempe

gros mélange, l'import de Java et l'#include de C++ n'ont pas le même but. Ne pas confondre #include (qui ne fait pas parti du langage, et n'est qu'une directive de pré-processing permettant d'inclure n'importe quoi n'importe où) et using

[slopez]

- L'idée de la boite de dialogue c'était dans le cas ou on enlevé le pré-fixage des classes et on m'était des imports, pour prévenir d'un conflit de nom (à titre informationnelle). Dsl je m'explique peut être un peu mal.

- Je ne savait pas que force "namespace prefix generation" existait en C++. PK pas la même chose en Java.

- Désoler me suit un peu embrouiller avec les dépendances en UML. Par exemple une relation de dépendances en C++ se traduit pas un #include. En java pas besoin, il suffit de reprendre le chemin du package + le nom de la classe. Donc dans BOUML une relation de dépendance est implicite dans une agrégation, héritage... Don par exemple si je rajoute une relation de dépendance stéréotypé import en plus d'une relation d'héritage,composition... cela pourrait faire disparaitre le pré-fixage. Cela pourrait être une alternative à la case à coché.

En espérant que mes idées soit clair.

[bruno_pages]

PK pas la même chose en Java.

c'est justement je propose de faire dans ma première réponse (point 1)

Don par exemple si je rajoute une relation de dépendance stéréotypé import en plus d'une relation d'héritage,composition... cela pourrait faire disparaitre le pré-fixage

c'est aussi ce que je propose de faire dans ma première réponse (point 2)

[slopez]

Je voulais savoir si c'était possible dans le code suivant :

public class A {
public interface X {
}
}

De pourvoir avoir l'import A.X;

Actuellement je n'arrive pas à remonter jusqu'à X. Quand je fait ma fléche sur dépendance + import le code généré est import A;.
Il y a moyen de contourné le problème ? Est-ce normal ? Sachant que je ne veut pas d'un fichier java par classe.

[bruno_pages]

Quand je fait ma fléche sur dépendance + import le code généré est import A;
...
Est-ce normal ?

c'est non seulement normal, mais aussi heureux, à moins que le but soit de générer un code faux ?

dans une forme import A.X il faut que A soit un package

[slopez]

Dans une forme import A.X; A n'est pas nécessairement un package. Du moins j'arrive à compiler du code utilisant X avec l'import de ci-dessus. A étant une classe contenant la définition de l'interface X par exemple.
Ce que je n'arrive pas à faire sur le modeleur c'est obtenir le fameux import. J'arrive à inclure la définition d'une classe dans une autre classe avec une génération correct. J'arrive à tracer la dépendance stéréotypé import. Mais le code générer est import A

Me suis-je me fait comprendre ? Merci et encore dsl pour mes explications pas très clair.

[bruno_pages]

Dans une forme import A.X; A n'est pas nécessairement un package. Du moins j'arrive à compiler du code utilisant X avec l'import de ci-dessus.

bizarre car le miens refuse la chose (javac 1.5.0_16)

• ajout d'une option de génération globale force package prefix generation mise à oui par défaut (compatibilité avec l'existant)
• non génération du préfixe s'il y a une dépendance stéréotypée import vers la classe en cause ou/et une dépendance stéréotypée import vers le package en question

disponible avec la version 4.5

note : prends également en compte les imports directement écrit à la main au niveau de la définition des artifacts

[slopez]

C'est cool pour l'ajout de la fonction "force package prefix generation" dans la nouvelle version de bouml. Très pratique pour la lisibilité du code.

Pour le truc des imports voici un exemple plus complet mais compiler avec javac 1.6.0_04, c'est peut être ce qui fait tous.

/**************/
package testA;

import testB.B;

public class A {
private B b = null;

public class X {

}
}
/**************/
package testB;

import testA.A.X;

public class B {
public X x = null;
}

Pas de problème de compilation par contre un petit truc que je remarque c'est un fichier A$X.class avec A.class. Mais ça compile. Peut être une nouveauté de java 1.6 (ou plutôt du compilateur).

Sinon encore merci pour l'ajout de la fonctionnalité la génération de java a être encore mieux comme ca.

Cordialement, Sébastien.

[slopez]

Bonjour, je me permet de relancer le sujet sur la définition des classes dans un autres classes.

Prenons l'exemple de l'interface Entry définit dans java.util.Map. La classe Map permet diverse forme de parcours dont celui représenté par entrySet() (Entry<Key, Value>). Cependant comme dit précédemment dans le sujet, actuellement l'import d'une classe définit dans une autre classe (ici une interface dans une interface) ne généré un import que de la classe englobante (Map). Donc pour accéder à la classe Entry par la flèche de dépendance sur la classe génère un import java.util.Map;, alors que je désire java.util.Map.Entry;. Je tiens à souligner qu'actuellement je bosse en java 5 donc cette possibilité ne proviens pas de la version 6.

Cordialement, LOPEZ Sébastien.

[bruno_pages]

toujours avec javac 1.5.0_16 j'ai refais un test d'import d'une sous classe et cette fois-ci cela c'est bien passé

j'ai changé sans doute changer la façon de compiler, en supposant que testA et testB sont deux sous répertoires du répertoire courant cette fois-ci j'ai fait javac */*.java

l'import des sous classes sera donc disponible dans la prochaine version, avec bien-sûr leur prise en compte pour savoir si le "chemin d'accès" à une classe doit ou non préfixer son nom

[slopez]

OK, impécable. Merci.

[bruno_pages]

modification effectuée dans la version 4.9 disponible.

Bruno

[slopez]

OK merci Bruno.