Together est (il me semble) le seul à proposer le round trip engineering, grosso modo la faculté de travailler en meme temps sur l'UML et sur le code source. Et ca change absolument tout !
çà doit être un vrai bonheur ce truc : à la fac on a objecteering, et la génération de code est simplement dégueulasse : il met des accesseurs pour tous les attributs même si on les a déclarés "private", ... Et pour ce qui est de la modification du code généré, c'est encore pire : il insère des tags (plusieurs dizaines de catacères) un peu partout dans le code pour délimiter les zones modifiables (corps des méthodes, javadoc, ...) et celles qui ne le sont pas. Et si on a le malheur de modifier du code qui n'est pas sensé être modifiable (le nom d'une méthode), tout est cassé quand on passe au "reverse engineering" (abus de langage d'ailleurs). J'au aussi utilisé rational rose, mais pas moyen de générer du code : y'avait pas le pluggin adéquat (pour une licence qui coûte pourtant la peau des cou...es).
Mais le principal reproche que je fais aux éditeurs UML que j'ai utilisés, c'est qu'il n'implémentent pas l'intégralité de la norme UML, et de loin (assez frustrant quand on a fait ses petits schémas sur papier (paske quelqu'un d'autre utilisait la rose et qu'on n'a qu'une licence) avec le bouquin d'UML (Muller ro><or) et qu'on veut passer sous rose après).
Pour ce qui est du "round trip engineering" je me demande si les diagrammes UML obtenus ne sont au final pas trop fortement liés au langage utilisé : comment les "inner classes" de java (par exemple) sont elles interprétées ?
[^] # Re: mouais...
Posté par Pierre Tramo . En réponse à la dépêche Eclipse 2.0 est dans les bacs !. Évalué à 0.
çà doit être un vrai bonheur ce truc : à la fac on a objecteering, et la génération de code est simplement dégueulasse : il met des accesseurs pour tous les attributs même si on les a déclarés "private", ... Et pour ce qui est de la modification du code généré, c'est encore pire : il insère des tags (plusieurs dizaines de catacères) un peu partout dans le code pour délimiter les zones modifiables (corps des méthodes, javadoc, ...) et celles qui ne le sont pas. Et si on a le malheur de modifier du code qui n'est pas sensé être modifiable (le nom d'une méthode), tout est cassé quand on passe au "reverse engineering" (abus de langage d'ailleurs). J'au aussi utilisé rational rose, mais pas moyen de générer du code : y'avait pas le pluggin adéquat (pour une licence qui coûte pourtant la peau des cou...es).
Mais le principal reproche que je fais aux éditeurs UML que j'ai utilisés, c'est qu'il n'implémentent pas l'intégralité de la norme UML, et de loin (assez frustrant quand on a fait ses petits schémas sur papier (paske quelqu'un d'autre utilisait la rose et qu'on n'a qu'une licence) avec le bouquin d'UML (Muller ro><or) et qu'on veut passer sous rose après).
Pour ce qui est du "round trip engineering" je me demande si les diagrammes UML obtenus ne sont au final pas trop fortement liés au langage utilisé : comment les "inner classes" de java (par exemple) sont elles interprétées ?