Discussion :

[slopez]

Bonjour,

Juste pour faire une remarque (encore et toujours lol). Il me semble tous à fait logique que la multiplicité * et le stéréotype List génére un code de type :
==> List<Quelquechose> attrib;

Cependant il m'aurait aussi semblait logique que la multiplicité * sans stéréotype généré quelque chose de la forme (en java par exemple) :
==> char[] attrib;

En ce moment bouml génére quelque chose de la forme de :
==> <char> attrib avec juste la multiplicité renseigné.

De plus je crois que bouml réalisé les choses de cette manière (je sais plus trop) avant.

Merci.

[slopez]

Donc comme je viens de dire j'avais bien vu sa quelque part.


Le reverse de public int[] attr; place [] dans la multiplicité.

Mais est-ce correct ? * Ne serait-il pas plus approprié ?

[bruno_pages]

Bonsoir,

il m'aurait aussi semblait logique que la multiplicité * sans stéréotype généré quelque chose de la forme (en java par exemple) :
==> char[] attrib;

je distingue trois cas (c.f. generation settings onglet "java[2]")

• multiplicity vide ou 1
• multiplicité * ou de la forme a..b
• autre cas

La distinction porte donc sur la seule multiplicité, le stéréotype ne rentre pas en compte. Pour chacun des 3 cas tu peux spécifier la forme par défaut. Dans le cas 2 j'utilise un générique spécifié par le stéréotype, mais libre à toi de produire un vecteur

De plus je crois que bouml réalisé les choses de cette manière (je sais plus trop) avant.

non

Le reverse de public int[] attr; place [] dans la multiplicité.

Mais est-ce correct ? * Ne serait-il pas plus approprié ?

non, car un vecteur est de taille fixe, alors qu'* peut prendre n'importe qu'elle valeur positive ou nulle

j'ai fait aussi cela par cohérence avec C++ ou la taille est spécifiée contrairement à ce pauvre Java, bref pour moi une bonne modélisation de la multiplicité donne le nombre d'éléments, mais le générateur de code produit toujours "[]" en Java pour ${multiplicity} si celle-ci est non vide

Bruno

[slopez]

OK, donc l'ajout de ${multiplicity} permet d'obtenir [] avec 1, *, a...b, x.
Je trouve cela très logique.

Par contre juste une remarque (encore est toujours), le reverse en java ne devrait pas placer à mon avis [] dans multiplicité mais ${multiplicity} avec * par exemple pour un code comme public int[] attr;.

Une autre chose, je n'arrive pas à comprendre pourquoi il n'est pas possible de placer automatiquement les [] avec une multiplicité * sachant qu'avec les stéreotype les <> sont placées. Pourquoi l'un est pas l'autre.

[bruno_pages]

je me demande si tu as vraiment lu ma réponse précédente

Une autre chose, je n'arrive pas à comprendre pourquoi il n'est pas possible de placer automatiquement les [] avec une multiplicité * sachant qu'avec les stéreotype les <> sont placées.

c''est normal que tu ne comprennes par pourquoi "ce n'est pas possible" ... car "c'est possible" !

si tu avais *vraiment* lu ma réponse précédente tu aurais édité les options de génération et via l'onglet "java[2]" aurait vu que dans le cas "*" ou "a..b" la forme est "...${stereotype}<${type}>..." ce qui produit les <> autour du type, tu as juste à la changer par ce qu'il y a pour le troisième cas, c.a.d. "...${type}${multiplicity}..."

tes yeux ou ton cerveau sont en grève aujourd'hui ?

[slopez]

Si j'ai lut la réponse précédente. Mais ce que j'aimerai, c'est d'avoir directement une déclaration qui puisse gérer tous les cas suivant :
==> Un stéréotype + multiplicité * : NomStereotype<NomType> attribut;
==> Sans stéréotype + multiplicité * NomType[] attribut;

Cette déclaration doit gérer les deux cas. Dans les réponses précédentes c'était soit l'un avec <${type}> soit ${type}${multiplicity}. L'idée serait de pourvoir fusionner les deux. Cela est-il possible ? La gestion des deux cas en une déclaration serait beaucoup plus générique que de changer la déclaration en fonction du besoin.

Cela revient au même pour le reverse. Je trouve ça un peu dommage que public int[] attr; ne donne pas une déclaration correct mais tous simplement place [] dans la multiplicité. Au niveau modèle cela n'a pas de sens [] n'est pas une multiplicité.

Merci.

[bruno_pages]

[slopez]

Bon j'insiste plus.

A l'utilisateur de faire un choix.

Par conte je maintient que pour le reverse avoir [] dans la multiplicité, bofbof.

ok, donc j'imagine que ça n'existe pas les conditions dans les déclarations ? Peut être changer le contenut de la génération ? Est-ce possible de modifier la génération de ${quelque chose} ? Créer les nôtres peut être ?

[bruno_pages]

Est-ce possible de modifier la génération de ${quelque chose} ? Créer les nôtres peut être ?

les ${xx} sont des mots clefs builtin, il n'est donc pas possible de changer leur signification sans modifier les sources. Si tu n'es pas d'accord avec ce qu'ils font rien ne t'empêche cependant de modifier le code puisqu'il est disponible

Créer les nôtres peut être ?

c'est la raison d'être des @{xx} qui sont des mots clef utilisateur correspondant à des propriétés (tagged values)

[slopez]

OK, donc c'est mort pour changer les trucs de base (${xx}).

Je connais l'existence des @{xx}, mais je ne trouve pas ça suffisamment évolué pour pourvoir l'utiliser génériquement. De plus la définition d'une propriétés est local (du moins je pense) donc on ne peut pas définir des propriétés de général.

Donc tampi, je placerai ${multiplicity} dans les cas ou j'en ai besoin.


Par contre je reviens sur ce que j'ai dit sur le reverse. La multiplicité [] n'existe pas en UML.

Merci Bruno pour ta patience.