Génération de code or not génération de code ?

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

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 :mrgreen:

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 :mouarf: )

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 !

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

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...

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.

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.

Citation:

---

Envoyé par thybang

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.

---

Avec Bouml le code peut etre integrallement genere, inutile de repasser derriere

Bouml serait donc un super outil :yaisse2:

superbe pub.
^^

enfin, hormis Bouml, il y aurai il d'autr logiciel du meme genre?

sinon, j'ai commencer a le tester, et je le trouve pas mal du tout.
faudrai que je m'y attache un peu plus pour en découvrir tout les mystères.
Sinon, c'est pour savoir. pour Bouml, la génération du code se fait a partir de quel diagramme UML?
celui de séquence? celui de classe? ou d'autre?

Citation:

---

Envoyé par thybang

pour Bouml, la génération du code se fait a partir de quel diagramme UML?
celui de séquence? celui de classe? ou d'autre?

---

Aucun !

la génération ne de fait pas à partir d'un diagramme, elle se fait a partir des infos contenues dans le modèle.

Un diagramme est un dessin exposant certaines informations du modèle en suivant des regles de notation. Ni plus, ni moins, meme s'ils sont egalement un moyen pratique pour rentrer certaines informations dans le modèle.

Sinon, pour répondre plus precisement, dans Bouml la generation se fait a partir des infos attachées aux artifacts (qui sont les support des fichiers sources produits), des classes et de leurs relations, attributs, operations (y compris leur corps) et des extra members (formes libres permettant de produire des formes non UML comme des #ifdef en C++/IDL ou des initialisations en Java via des formes static). Les machines a etat produisent indirectement du code via une fabrication/mise a jour automatique de classes. Ce n'est pas (encore ?) le cas pour les activites.

Citation:

---

Envoyé par thybang

bonjours,
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.

---

Pour une génération de code vraiment efficace, il faut que ce soit le générateur qui s'adapte à ton modèle ET à tes règles de codage et non l'inverse. Toutes les solutions qui t'imposent une façon unique (et généralement très proche du code) de représenter ton appli ET te produisent des squelettes qui ne tiennent pas compte de ton framework ne sont généralement utilisables que de manière marginale.

Les nouveaux outils MDA sont dans cette philosophie : ce sont des moteurs de transformation complètement paramétrables, généralement sous la forme de templates de code créés par copier-coller de ton propre code. Les meilleurs outils fournissent même un environnement dédié qui te permet de mettre au point ces règles de génération.

L'outil le plus utilisé répandu est Mia-Generation de Mia-Software. Cet outil a déjà été mis en oeuvre pour générer du J2EE, C#, C, Ada, Cobol, Natural, ... sur des projets de 200 à 100.000 jours.

Fred

Pour bien connaitre les générateurs embarqués dans certains outils et connaitre un peu Mia-Generation, je ne peux qu'être d'accord avec fmadiot.
D'autre part, la majorité des générateurs que je connais permettent de passer d'un classe à un fichier X ou d'un paquet de classes à un fichier X mais peu de générateur permettent par exemple de générer un fichier pour chaque opération d'une classe. Bref, tout cela pour dire que l'outil Mia-Generation est, lui, très flexible de ce point de vue.