permettre le roundtrip body dans la définition des classes

[johanjof]

Bonjour,

J'ai remarqué que de temps à autre je lance un roundtrip un peu fâcheux plutôt qu'un roundtrip body.
En effet, dans un diagramme de classe avec une très longue liste de classes, je ne vois plus les artefacts qui sont beaucoup plus bas. Je les ignore d'ailleurs généralement une fois qu'ils sont crée (sauf si j'ai besoin d'y mettre une directive) et je travaille plutôt avec les diagrammes. Hors l'option roundtrip body ne se trouve QUE dans les artefacts.
Serait-il possible d'avoir l'option roundtrip body dans la partie définition ?

[Bruno Pagès]

Bonjour,

En effet, dans un diagramme de classe avec une très longue liste de classes, je ne vois plus les artefacts qui sont beaucoup plus bas.

Je suppose que vous vouliez dire dans une vue de classes et non un diagramme de classe

A noter qu'il n'est pas nécessaire de chercher à la main l'artefact associé à une classe, le menu d'une classe dans l'explorateur permet d'aller directement sur l’artefact via select associated artefact

l'option roundtrip body ne se trouve QUE dans les artefacts.
Serait-il possible d'avoir l'option roundtrip body dans la partie définition ?

Situation actuelle

Aujourd'hui le roundtrip body est proposé

• au niveau d'un artefact, et dans ce cas il s'applique à toutes les opérations définies dans le fichier source correspondant
• au niveau d'un vue de déploiement, et dans ce cas il s'applique à toutes les opérations définies dans les fichiers sources des artefact de la vue
• au niveau d'un paquetage, et dans ce cas il s'applique à toutes les opérations définies dans les fichiers sources des artefact des sous vues de déploiement, avec une recherche récursive

Il ne peut donc pas être lancé au niveau d'une classe ou d'une vue de classes, et s'il est lancé dans un paquetage ne contenant que des sous classes mais pas de sous artefact il ne se passe rien.

Réflexion 'à voix haute'

Il y a deux façons de le proposer au niveau d'une classe :

1. c'est un raccourcis pour qu'il s'applique à l'artefact correspondant et donc à toutes les opérations de toutes les classes associées à l'artefact, et non de la seule classe d'où il est lancé
2. il s'applique aux seules opérations de la classe et de ses sous classes, et donc pas aux opérations des autres classes dans le cas ou l'artefact est associé à plusieurs classes

Le choix entre ces deux possibilités est loin d'être anodin.

Le 1er cas est le plus simple car il n'est pas discriminant. Si on peut faire le roundtrip body au niveau d'une classe il faut pouvoir le faire au niveau d'une vue de classes, et dans ce cas il s'applique à l'ensemble des artefacts associés aux classes. En remontant encore d'un niveau, appliqué à un paquetage il s'applique à l'ensemble des sous artefact trouvés directement ou via au moins une de leurs classes.

Dans le second cas c'est plus compliqué car à chaque fois qu'on tombe sur une opération il faut se demander s'il faut ou non la mettre à jour. Au niveau d'une vue de classes il faudra balayer plusieurs fois les sources d'un même artefact associé à plusieurs classes présentes dans la vue, et quand on remonte au niveau paquetage et peut être même projet ces cas vont explosés car à priori on va trouver les classes avant leur artefacts lors du balayage de l'arbre des éléments. Mais n'est-ce pas se compliquer la vie pour rien ? Est-il bien utile de faire cette discrimination et de ne pas suivre le 1er cas ?

[johanjof]

Personnellement étant un adept de Slackware qui cherche à tout maîtriser j'aurais tendance à vouloir descendre au plus bas donc au niveau classe, qui aussi permet de ne pas regénerer inutilement un paquet d'éléments d'un artefact qu'on n'a pas modifié.

Mais il faut être plutôt pragmatique :
- aujourd'hui il existe quand on clique sur une classe l'option "roundtrip", il faut utiliser la même logique que sur cette option pour roundtrip body, sinon ça va perturber l'utilisateur

Il me semble qu'à bien y réfléchir il faut se poser la question fondamentale de ce que l'on veut faire faire au concept des artefacts, ou autrement dit qu'est ce qu'on veut leur laisser comme fonctionnalités qui leur soient propres, sinon ils vont finir par perdre leur sens si toutes leurs fonctionnalités sont dupliquées.

Voici juste ma vision schématisée de comment je considère les artefacts:
- architecture physique (fichiers) à dissocier de l'architecture de concepts qui eux sont dans les vues, j'aurais tendance à vouloir me rendre dans la partie artefacts que si j'ai besoin de créer de nouveaux fichiers (je préfèrerais d'ailleurs lors de la création d'une nouvelle classe avoir un bouton droit qui me permette de choisir l'artefact associé s'il existe déjà, mais ça c'est une autre nouvelle fonctionnalité pour un autre topic )
- en +, je me rend dans les artefacts uniquement si je veux faire des trucs "experts", c-a-d des choses pour lesquelles il est difficile de trouver une solution dans la partie conception comme faire passer des directives de preprocessing (car je préfère idéalement que tout passe dans les vues, car ce qui est dans les artefacts n'est pas tout reversible que ce soit en reverse ou en roundtrip).

Bref, il faudrait bien détailler les contours de ces artefacts... Mais ça c'est à vous de voir où vous souhaitez les emmener.

[Bruno Pagès]

Personnellement étant un adept de Slackware qui cherche à tout maîtriser j'aurais tendance à vouloir descendre au plus bas donc au niveau classe, qui aussi permet de ne pas regénerer inutilement un paquet d'éléments d'un artefact qu'on n'a pas modifié.

Je ne suis pas certain de vous suivre, mais les générateurs de code ne modifient pas les fichiers inutilement, la génération se fait d'abord en mémoire et les fichiers ne sont écrasés que si le contenu a changé

Mais il faut être plutôt pragmatique :
- aujourd'hui il existe quand on clique sur une classe l'option "roundtrip", il faut utiliser la même logique que sur cette option pour roundtrip body, sinon ça va perturber l'utilisateur

Cela veut dire qu'il faut suivre l'option 2 : si vous avez deux classes associées à un artefact et qu'il y a eu des modifications pour ces deux classes dans les sources alors un roundtrip au niveau artefact mettra à jour les deux classes, par contre si vous lancez le roundtrip au niveau d'une des deux classes alors seule celle-ci est mise à jour et pas l'autre.

La règle par défaut c'est que l'application d'une commande ou d'un plug-out à un élément donné n'impacte que cet élément et éventuellement ses sous éléments et éléments liés, c'est donc ce que fera le roundtrip body. La génération de code est un contre exemple, mais cela à un sens puisque le but est quand même de produire un/des sources, donc le faire pour toutes les classes associées à un artéfact et non pour la seule classe ou la génération est appliquée est raisonnable. Le verrou sera un autre contre exemple.

Je suis d'accord avec vous et je vais donc suivre l'option 2 pour le roundtrip body, même si cela alourdit celui-ci au niveau implémentation et donc exécution

Il me semble qu'à bien y réfléchir il faut se poser la question fondamentale de ce que l'on veut faire faire au concept des artefacts...

En ce qui me concerne c'est clair, mon interrogation n'était pas véritablement liée au cas des artéfacts mais portait sur les effets collatéraux et aurait été la même pour un autre type d’élément dans un cas semblable.

... (je préfèrerais d'ailleurs lors de la création d'une nouvelle classe avoir un bouton droit qui me permette de choisir l'artefact associé s'il existe déjà, mais ça c'est une autre nouvelle fonctionnalité pour un autre topic )

j'ai répondu, et là nous ne sommes pas d'accord

- en +, je me rend dans les artefacts uniquement si je veux faire des trucs "experts", c-a-d des choses pour lesquelles il est difficile de trouver une solution dans la partie conception comme faire passer des directives de preprocessing (car je préfère idéalement que tout passe dans les vues, ...).

Je fais de même

car ce qui est dans les artefacts n'est pas tout reversible que ce soit en reverse ou en roundtrip.

Oui en ce qui concerne C++ car je saute toujours ce qui n'est pas modélisable en UML (les friends dans les classes ne sont cependant pas perdus et sont supportés par les extra class members)

Par contre les reverse/roundtrip Php ne perdent plus aucune forme non modélisable en UML et les mémorisent via les extra artifact definitions que j'ai ajouté dans la version 7.1

Je pourrais donc faire de même lors des reverse/roundtrip C++ et mémoriser les parties non modélisables via des extra artifact definitions ou des extra class members, mais le reverse/roundtrip est déjà une sacrée usine à gaz

[johanjof]

Cool merci

[Bruno Pagès]

Bouml 7.4 est disponible et ajoute la possibilité de faire un roundtrip body au niveau d'une classe (sans affecter les autres classes affectées au même artefact), ou d'une vue de classe, et toujours au niveau d'un artefact ou d'une vue de déploiement ou d'un paquetage

Plus de détails sur l'historique