Discussion :

[abdo.1980]

Bonsoir tout le monde,

Je cherche un tutoriel quiexplique comment exploiter le diagramme de séquence pour générer du code Java ou .net.

et merci d'avance

[Joshua Beharia]

Les outils de génération de code se base principalement sur les diagrammes statiques, et non les diagrammes dynamiques. Esperont que cela évolura vite.

Sinon si tu a sles diag de séquences, tu fais les StateMachine et c'est bon.
J'utilise Rhaspody Developper d'Ilogix pour faire ceci.

[abdo.1980]

vous connaissez pas par hasard un outil qui intégre le diagramme de séquence?!

[Joshua Beharia]

pas à ma connaissance mais ça fait 6 mois qu je ne m'interesse plus à ça (pour l'instant).

[Narvis]

Bonjour

Je ferais les même remarques. Je travail avec AndroMDA 3.2. Bon framework mais toujours pas de prise en charge des diags de séquence. Il faut passer par les diags statiques.

Bye et bon courage

[alex00]

Bonjour,

Il me semble qu'il y a une relation entre diagramme de sequence et code dans Together.

Du genre (avec 4 objets Obj_i, chacun etant d'une classe Class_i) :
Obj_1 -- m1(params) --> Obj_2
Obj_2 -- m2(params') --> Obj_3
Obj_2 -- m3(params") --> Obj_4

on doit avoir en Java pour la classe Class_2 (correspondant a Obj_2) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class Class_2 {
   public void m1(param_type) {
      // possibilite d'ajouter du code avant
      Obj_3.m2(params');
      // possibilite d'ajouter du code au milieu
      Obj_4.m3(params");
      // possibilite d'ajouter du code apres
   }
}

avec un automate, on peut avoir le code complet (tres utile, surtout en info industrielle).

[Joshua Beharia]

oui donc on arrive bien tous au même point, il faut faire sa SM et ses diag de séquences.
Le soft génère le code pour la SM et à toi de mettre les bons appels de méthodes où il faut.

[bruno_pages]

Les outils de génération de code se base principalement sur les diagrammes statiques, et non les diagrammes dynamiques. Esperont que cela évolura vite.

il ne faut tout de meme pas rêver : la génération de code à partir d'un diagramme de séquence est illusoire

• on ne sait pas d'ou viennent les instances,
• ni les arguments des operations,
• et ce qu'on peut mettre dans un tel diagramme ne permet pas de modeliser un 'vrai' comportement ie un 'vrai' code.

D'ailleurs le code présenté montre bien les limites de la chose, et il ne suffira pas d'ajouter du code et avant les lignes générées pour les raisons évoquées ci-dessus.

Il y a par contre beaucoup plus de 'substance' dans un diagramme d'etat et d'activite...

[Joshua Beharia]

Je suis d'accord. Mais de toutes façon, sans passer par l'étape de dynamique des diag de séquences, pas de SMachine.

Par contre pourquoi dis tu que ce que l'on met dans les diag de séquence ne permet pas de réaliser un vrai comportement ???

[bruno_pages]

Mais de toutes façon, sans passer par l'étape de dynamique des diag de séquences, pas de SMachine.

Par contre pourquoi dis tu que ce que l'on met dans les diag de séquence ne permet pas de réaliser un vrai comportement ???

tout ce qui ne correspond pas a un envoie de message ne se voit pas, par exemple tout ce qui est calcul arithmetique. De plus malgrés les fragments les alternatives et boucles ne sont pas très pratiques a indiquer. J'ai peut être tord, mais pour moi les diagrammes de séquences ne sont pas là pour montrer le 'vrai' code et ses détails, mais pour montrer des enchainements 'trop grain'

[Joshua Beharia]

Je suis d'accord, les DS(diag de séquences) sont la pour montrer l'enchaînement (dynamique) entre les objets.
Mais pour moi, les DS sont l'étape fondamentale avant les SM(StateMachine). La SM d'un objet se bâtie à partir de tous les DS que j'ai trouvé (RC->AN->DG).
Ainsi, les trucs fondamentaux se retrouvent dans les SM sous forme d'"action" ou autres joyauseté que UML peut nous proposer, suivant que l'on y adhère ou pas (évolution vers UML 2.0).
Donc pour moi, un jour arrivera où on générera à presque 80% du code à partir de nos modèles Objet. Je dis bien Objet, et pas UML.
Par expérience, j'ai essayé avec Rhapsody pour des applications embarquées en C et le résultat est pas trop mal.

@++

[abdo.1980]

Je tiens à vous remercier pour cette discussion trés enrichissante.
mais Est ce que vous ne touverez pas que l'idée de together de mettre le squelette des messages echangés entre les objets est trés interessante, puisqu il represente un enrichissement du code généré?

[bruno_pages]

mais Est ce que vous ne touverez pas que l'idée de together de mettre le squelette des messages echangés entre les objets est trés interessante, puisqu il represente un enrichissement du code généré?

non, pour moi c'est du 'pipo' : soit on génère un code sans reprise manuelle, soit on ne génère rien. C'est encore pire que la création automatique des diagrammes, tout cela trompe l'utilisateur en lui faisant prendre des vessies pour des lanternes

[Joshua Beharia]

je suis d'accord avec Bruno, le fait de faire des gueguelles de code comme des squelettes et bien ça sert à rien.
Déjà que le gain n'est pas au niveau du code mais si en plus ton cher outil te génère un squelette de méthode avec un cartouche de 15 lignes...L'interêt est vite limité !

@+

[alex00]

je suis d'accord avec Bruno

je suis d'accord