Discussion :

[runn2]

Afin d'augmenter mes capacité à produire des applications rapidement, je voudrai savoir ce que peut m'apporter un générateur de code à partir des diagrammes UML ?

Actuellement, je fais une conception logiciel à base d'un mix de diagramme UML fait avec Visio et avec un texte descriptif fait en Word.
Au moment de passer à l'implémentation, j'écris mes classes en ajouter des méthodes et attributs par-ci par-là en fonction de mes besoins pour les besoins d'implémentation détaillé, le gros des appels de méthode ont été définie dans la phase de conception.

J'utilise un développement en spirale en implémentant une partie du code avant d'avoir écrit la spec complete.

Je m'interroge principalement sur :
- l'investissement en temps que je vais devoir consacrer à l'apprentissage de l'outil avant d'accelérer mon développement : est ce 1 mois ? 3 mois ? 6 mois ? un an ?
- la qualité du code produit par l'outil
- la possibilité de faire du développement en spirale avec l'outil

Et je m'interroge accessoirement sur :
- la diversité des cibles possibles sur les plateformes et langage : j'utilise du VB .NET sous windows XP, du C++ Embedded pour Windows CE, du Visual C++ 6

[bruno_pages]

Vaste sujet !

Désolé de répondre si tard, mais je mets rarement les pieds sur cette partie du forum car je n'apprécie par particulièrement Rose sachant que j'ai utilisé Rose et RoseRT au travail.

Cela va sans doute te sembler étrange que je dise cela puisque je développe Bouml sur mon temps libre, mais UML n'est pas quelque chose de magique grace à quoi tout les temps de développement ont été divisés par 10 et les bugs une espèce en voie de disparition

L'avantage d'UML, même s'il n'est sans doute pas le seul dans ce cas, est de te permettre de prendre en peu de hauteur par rapport à ton code, bref de ne pas être enfoui dans le camboui et de réflechir un peu plus, et surtout de le faire avant la phase de codage proprement dite. Ce que tu peux espérer y gagner c'est :

• une spec plus claire et précise, l'inverse ne pouvant aboutir à la réalisation de bons programmes
• faciliter la maintenabilité de la chose
• une doc en adéquation avec le code, ce qui n'est pas négligeable
• une doc lisible utilisant des dessins comprehensibles par tous (quand on connait UML evidemment)

On peut evidemment faire de l'UML sans outils, mais c'est quand même pas le pied !
Avec un outil tu fais à la fois la specif, la doc, et le code, le tout étant plus facilement cohérent. Evidemment si tu fais n'importe quoi tu arrives a n'importe quoi même avec un outil

Ensuite, si tu utilises un outil, le gain/perte apporté par la chose est évidemment très lié à l'outil, et des outils catastrophique aboutissant à une perte de temps considérable ou à un quasi echec du développement il y en a, et les plus chers ne sont pas les meilleurs loin de là (mais cela n'engage que moi évidemment )

Quelque soit l'outil que tu utilises il y aura forcément un temps d'adaptation, surtout qu'il y a peu de chance que tu puisse considéré l'outil indépendamment du reste, il y a un lien avec la gestion de conf, de doc, la manière de gérer un developpement à plusieurs etc etc. Par contre je ne peux pas te donner de chiffre sur ce temps, il dépend de trop de facteurs et d'abord de toi

Pour tout dire, j'utilise UML dans un cadre prof ou je ne suis pas seul ou parce que le soft sera à priori repris plus tard par d'autres, mais je n'utilise pas UML pour des développements perso : cela fait plus de 20 ans que je code et j'ai acquis d'autres habitudes de développement que j'ai la prétention de croire pas trop mauvaises

Bonnes modélisations !

[ftrifiro]

A voir si tu ne perds pas plus de temps qu'autre chose. A voir si tu ne perds pas de la clarté, de la mainmise... Pour finalement du code ultra simple... Perso et c'est mon côté ringard, je me méfie de la génération de code qui est l'arbre qui cache la forêt. Ce qui est long, c'est de réfléchir avant de commencer, mettre au point du code, pas de faire des squelettes et des boîtes vides...

A voir enfin si la génération peut s'intégrer à ton architecture applicative, tes choix de frameworks. Pour que ce soit opérationnel, il faut que ton diagramme de classes soit tout à fait un diagramme d'implémentation. Je ne suis jamais allé aussi loin en modélisation car j'ai toujours trouvé que j'alourdissais trop les schémas pour pas grand chose.

C'est pê un tort mais ma philosophie est qu'UML est une boîte à outils, on puise ce qui peut nous aider. Après, faire passer toute la conception du logiciel dans le moule UML, faut voir si ça apporte qqc... Fameux pragmatisme !!

A+, Fred

[runn2]

Merci de cette réponse, je suis finalement un peu dans la même position que toi.

En l'absence de réponse positive, je n'ai pas envi d'essayer sans être payé pour cela...
L'investissement en temps est trop lourd...

[ego]

Je ne connais pas Bouml de Bruno mais perso, avec des outils comme Together (Borland) ou RSA (IBM), on peut tout à fait passer d'UML au code et inversement sans problème.
Le gain est à la fois que l'outil écrit le squelette sur la base du modèle (ok, c'est pas le plus dur mais c'est gratuit une fois que le modèle est fait) et surtout, le lien bi-directionnel entre code et modèle assure que le modèle, tout au moins celui de "conception", est fidèle au code.
Oui, je dis que le modèle est fidèle au code car on sait que bien souvent, le code diverge rapidemment du modèle. Dans le cas de la génération de code, on a au moins l'assurance que le modèle servira aux successeurs pour avoir une vision high-level du code et donc que le modèle restera utile.

UML ça sert d'abord à réfléchir et ensuite à documenter ce que l'on a codé et/ou l'inverse.

[thybang]

bonjours,

moi cela serai pour avoir uen autre question portant aussi sur la génération de code.
On parle souvent de génération de code.
Je voudrai savoir si tous les code générés par les outils de conception UML étaient uniquement le squelette ou s"il existait des super outils qui nous offre plus que cela.