Bonjour,
Comment puis-je indiquer que le type retourné par une opération est une liste de génériques ? Est-il possible d'utiliser un stéréotype comme pour les associations "*" ?
Merci d'avance de votre aide.
Version imprimable
Bonjour,
Comment puis-je indiquer que le type retourné par une opération est une liste de génériques ? Est-il possible d'utiliser un stéréotype comme pour les associations "*" ?
Merci d'avance de votre aide.
Bonjour,
non, ce n'est pas une histoire de stereotype
Si le but est d'avoir le type java.util.List<C>, trois solutions :
- dire que l'operation retourne un java.util.List<C> (onglet UML), la definition de l'operation contient donc ${type}
- dire que l'operation retourne un C (onglet UML), et modifier la définition de l'operation en Java pour dire qu'elle retourne un java.util.List<${type}>
- dire que l'opération retourne un list (onglet UML), et modifier la définition de l'operation en Java pour dire qu'elle retourne un ${type}<C>. Je suppose que par ailleurs il est dit que list produit java.util.List en Java
La meilleure solution est la seconde, car si C est une classe et qu'elle est renommée, le renommage est pris en compte
Note : c'est la meme chose pour avoir un parametre dont le type est un generique, sauf que ${type} est remplacé par un ${ti}
Une nouvelle fois je te remercie pour la rapidité de ta réponse.
Comme tu le suggères, je vais mettre en pratique la deuxième solution même si elle ne me satisfait pas pleinement.
En effet, il y a, à mes yeux, au moins deux inconvénients :
- le type retourné par l'opération n'apparaît pas dans le modèle mais uniquement dans le source généré
- me connaissant il y a un risque non négligeable que je perde cette modification en cliquant sur le bouton remettant la définition par défaut :oops:
Serait-il imaginable que dans un futur plus ou moins proche, bouml intègre la gestion des génériques en java ?
Quoiqu'il en soit sache que je trouve que tu mets à notre disposition un excellent outil pour lequel je ne manque pas une occasion de faire de la publicité autour de moi.
si par 'apparaitre dans le modèle' tu parles des diagrammes, alors je ne suis pas d'accord avec toi :Citation:
Envoyé par ptit-lu
- de toute facon en UML list<C> n'existe pas, se serait une indication de type + multiplicite + ordre
- il te suffit de demander un affichage en Java plutot qu'en UML (drawing setting 'drawing language'), et tu verras list<C>
une autre solution serait donc de creer un type list<C>, une sorte de typedef donc, mais je ne sais pas comment faire un équivalent en JavaCitation:
Envoyé par ptit-lu
8O ils sont gérés, que veux-tu dire ?Citation:
Envoyé par ptit-lu
Bonjour,
Disons que mon souhait se rapproche de ce que tu décrit quand tu dis qu'il faudrait spécifier type + multiplicité + ordre et que derrière bouml me génére une liste générique en java.
C'est le problème quand on fournit des outils de qualité aux gens, qu'on est disponible pour répondre à leurs questions, il deviennent encore plus exigeants ;)
Continue comme ça :D
Merci.
j'ai mis les indications type + multiplicité + ordre pour respecter la norme en ce qui concerne pas exemple un activity action pin.
Au niveau d'une operation j'ai trouve cela vraiment trop lourd, et cela date de plus des débuts de Bouml ou j'étais nettement plus interessé par la génération de code que la la modélisation 'pure et dure'. De plus, sauf erreur, cela ne peut pas ce représenter au niveau d'un diagramme de classe ou autre ...
Dans la version 2.30, la gestion de la multiplicité à été ajoutée pour les attributs :
Pourquoi ne pas faire de même pour les opérations ? Ca correspondrait exactement à mon besoin.Citation:
Add management of the multiplicity for the attributes.
The generation settings are modified to be able to set the default definition of an attribute depending on the multiplicity.
When you load a project, the attributes defined by previous releases have an empty multiplicity.
C'est pas si simple, pour moi le stéréotype d'une opération porte sur l'opération elle même et non sur le type de la valeur retournée, et ensuite il y aurait exactement le même problême pour les paramètres.
Il faudrait donc ajouter un couple stereotype + multiplicité sur le type retourné (qui est en fait un paramètre en UML) et chacun des parametres. Cela ferait quelque chose de très lourd car il faudrait aussi faire les 2 generation settings associés (multiplicite '*' et [..]/nombre, le cas de multiplicité 1 existant en fonction du type resterait inchangé) multipliés par les 3 directions (in inout et out). On n'est pas loin de l'usine a gaz :aie:
il faudrait aussi que je renomme les opérations relationAttributeStereotype et set associé de l'API des plug-outs (que je venais juste de renommer !) en relationAttributeParameterStereotype ou valueTypeStereotype ou je ne sais quoi :aie: :aie:
Ma vision est que si on utilise un type complexe, alors il vaut mieux définir un type associe (typedef en C++ et Idl)