Discussion :

[Pierre8r]

Bonjour,

Peut-on générer l'ensemble du code d'un projet Java depuis Bouml ?

Merci,

Tintin92

[bruno_pages]

oui !

qu'est ce qui pourrait te faire penser que cela n'est pas le cas ?

[Pierre8r]

oui !

qu'est ce qui pourrait te faire penser que cela n'est pas le cas ?

Peux-tu me donner quelques pistes pour ce programme sophistiqué ?

Code :

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

1
2
3
4
5
public class PremProg                                            //genes\PremProg.java
{ public static void main (String[] args)
  { System.out.println ("Mon premier programme Java") ;
  }
}

Non, non, ce n'est pas une blague, je suis vraiment nul.

Tintin92

[bruno_pages]

facile : tu as juste à reverser le répertoire genes (puisque d'après le commentaire c'est là qu'est placé PremProg.java), puis à regarder la définition de la classe PremProg (onglets Uml et Java) et de son opération Main (onglets Uml et Java), et l'artifact PremProg (onglets Uml et Java et associated classes).

Note : fais cancel lorsque le reverse t'affiche le premier explorateur de fichiers puis indiques genes avec le second

il faut vraiment que tu lises les deux premiers tutoriels, puis la doc de reference ... à moins que tu veuilles resté nul

[Pierre8r]

J'ai fait un Reverse Java puis un Generate Java.
La seule différence c'est que le Generate ajoute un
import java.lang.*;
qui ajoute un warning.

Code écrit :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
package src;

public class PremProg {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		System.out.println("Premier programme.");
	}

}

Après un Reverse + Generate :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
package src;

import java.lang.*;
public class PremProg {
  /**
   * @param args
   */
  public static void main(String[] args)
  {
  
  		System.out.println("Premier programme.");
  }

}

Tintin92

[Pierre8r]

Bonjour,

Je souhaiterai prolonger ma question.
Je sais maintenant que l'on peux écrire la totalité du code Java d'une application à partir de Bouml.
Mais est-ce réelement applicable avec une vraie application ?
Est-ce souhaitable ?
Celà depand-t-il de ta taille du projet ?

Merci,

Tintin92

[bruno_pages]

bonsoir,

Je ne pense pas être le mieux placé pour répondre à cette question, mais je vais quand même essayer de répondre aussi objectivement que possible.

Pour cela il faudrait s'accorder sur ce qui fait qu'un outil est ou non compatible avec ce que tu appelles une 'vraie' application.

Je suppose qu'une 'vraie' application correspond d'abord un 'gros' modèle. Si tu vas voir du coté des benchmarks tu auras une partie de la réponse : Bouml permet de part sa très faible consommation mémoire et CPU de manipuler de très gros modèles. Ces comparaisons ne couvrent qu'une faible part de l'utilisation 'normale' d'un modeleur, mais je pense qu'ils sont malgré tout représentatifs et surtout chacun peut les refaire à sa guise avec les modeleurs testés ou d'autres.

Une 'vraie' application a de forte chance d'etre réalisée à plusieurs.

• Pour cela il faut d'abord que les structures internes soient compatibles avec des modifications en parallèle, une partie visible destinée à résoudre ce problème est le BOUML_ID qui permettent aux identificateurs internes de ne pas se télescoper, ce qui ne serait pas de bon gout !
• Lorsque l'on travaille à plusieurs on peut vouloir se répartir le travail sur des parties séparées pour éviter de devoir merger les fichiers du modèle, pour cela Bouml offre project control et project synchro.
• Mais ce choix ne peut être imposé, il est donc nécessaire de pouvoir faire des merges. Comme je n'offre pas d'outils de merge spécifique il faut que cela soit réalisable avec des outils 'classique'. Pour cela les fichiers du modèle sont des fichiers texte, et non des fichiers binaires que Bouml pourait produire et lire plus rapidement. De plus, pour aider les utilisateurs ces fichiers sont indentés, utilisent des identificateurs 'verbeux', et contiennent des commentaires. Les informations ne sont pas non plus mises n'importe comment dans les fichiers, y compris pour les diagrammes : le résultat est cohérent d'une sauvegarde à une autre (je connais des modeleurs pourtant très chers pour lesquels cela n'est pas vrai !). Bien évidemment il serait préférable d'avoir un outil de merge dédié a Bouml et connaissant la structure des ficheirs, mais je connais des utilisateurs travaillant à plusieurs et faisant leur merge sans problème ... alors que le format des fichiers n'est pas documenté.

Une 'vraie' application a de forte chance d'etre en gestion de configuration. Pour cela il y a file control. Le fait que les fichiers du modèle soit des fichiers texte non produits de facon 'aléatoire' réponds également à ce besoin, il est par exemple possible de regarder les différences entre deux versions. D'autre part cela est très bien vu des gestionnaires dont le mode de mémorisation repose sur les differences, souvent réduites, afin de ne pas avoir a stoker l'ensemble des versions des fichiers ce qui est consomateur au niveau disque.

On peut difficilement se contenter seulement de ce qu'offre un outil, surtout dans un cadre professionel, ainsi chacun a ses besoins propres. L'ouverture avec Bouml se fait via les "plug-outs", ceux-ci permettent d'ajouter de nouvelles fonctionalites, et cela au choix en C++ ou Java via le modeleur comme n'importe qu'elle autre appli, et non via un pseudo langage (visual basic pour ne pas le citer). On ne peut pas tout faire via les plug-outs, en particulier la partie purement graphique des diagrammes n'est pas encore accessible (hors production d'un png ou svg), mais on peu quand meme faire beaucoup. En particulier les generateurs de code/XMI/documentation & reverse sont des plug-outs, meme si certains sont fait 'à la main' (ce qui résoud le problème de l'oeuf et de la poule pour le generateur C++ !).

Un peu dans le meme veine il y a l'integration avec d'autres outils, comme par exemple Eclipse dans le monde Java pour lequel je n'ai rien fait de particulier. XMI peut etre utilise comme une passerelle, mais je n'ai pas beaucoup de recul sur le sujet.

Après il y a tout ce qui a un rapport avec l'etat courant du développement de l'outil.

• Cela concerne bien-sur la complétude vis à vis d'UML, qui n'est donc pas à 100%, mais le principale est bien là
• Cela concerne aussi certaines facilités qui peuvent être considérées comme manquantes, par exemple le roundtrip

En dehors de ce que j'ai sans doute oublié, il reste tout ce qui se rapproche des gouts et des couleurs ... et là chacun a sa réponse propre.

Pour finir, etant donné son utilisation en entreprise ou pour l'enseignement il est peu probable que Bouml ne soit qu'un 'jouet'

Bonnes modélisations

[pomauguet]

Je sais maintenant que l'on peux écrire la totalité du code Java d'une application à partir de Bouml.
Mais est-ce réelement applicable avec une vraie application ?

Ca, c'est LA vraie question. Qui ne s'applique pas qu'à Bouml mais à tous les outils de modélisations UML.

Personnellement, je n'utilise Bouml que pour la partie rétroconception, ce qu'il fait très bien. Ca me permet d'avoir mon modèle toujours à jour. Bon, je m'en sers aussi ponctuellement comme outil graphique pour insérer dans un rapport, mais ça ne rentre pas dans le cadre de "construction de modèle".

Bouml peut générer du code, mais dans ce cas, on se passe de la puissance des éditeurs nouvelle génération qui font très bien le formatage, les imports, la complétion, etc..

Un autre axe, c'est la gestion de version, du modèle et du code. Si je renomme ma classe Toto en Toto2, comment la rétroconception peut savoir qu'il s'agit d'un renommage, et qu'il doit changer toutes les références à Toto en Toto2. Si une annotation permettait à un gestionnaire de version (style CVS) de savoir que Toto est Toto2 c'est la même chose, et bien on aurait mis à jour parfaitement le modèle.

Pour moi, le graal serait d'avoir une combinaison parfaite Modélisateur-Editeur-Gestionnaire de version.

[bruno_pages]

Personnellement, je n'utilise Bouml que pour la partie rétroconception, ce qu'il fait très bien. Ca me permet d'avoir mon modèle toujours à jour. Bon, je m'en sers aussi ponctuellement comme outil graphique pour insérer dans un rapport, mais ça ne rentre pas dans le cadre de "construction de modèle".

ce que tu dis me désole, et cela illustre bien les craintes que l'exprimais ici. Tout le monde ne fait pas comme toi, sinon j'arreterai ...

[pomauguet]

ce que tu dis me désole, et cela illustre bien les craintes que l'exprimais ici. Tout le monde ne fait pas comme toi, sinon j'arreterai ...

Déja, y a pas d'offense Bruno.

Mais j'ai du mal à croire en la génération de code, que ce soit par un outil ou par du MDA. Ca me semble un peu trop magique, et pour simuler la magie en informatique, il faut toujours un paquet de lignes de code...

Maintenant, si j'essaye quand même d'utiliser un modélisateur pour générer du code, je me passe du confort d'un éditeur à la Eclipse, qui fait de l'auto-complétion, de la coloration syntaxique, de la vérification à la volée de syntaxe, de l'ajout d'import spécifique... Eclipse et consorts a changé la vie des développeurs , et ce serait bien audacieux de faire comme si ces mêmes développeurs accepteraient de revenir en arrière...

Donc voila, mon post était juste pour exprimer ce qui marche pour moi. Et même si ça te parait limité Bruno, moi je trouve ça déja pas mal...

Pour faire plus, c'est juste que je ne sais pas faire autrement, d'une manière qui me convienne. Comment faire travailler en collaboration l'outil de modélisation et l'éditeur, c'est toute la question. Comment synchroniser de l'un vers l'autre, du modéle vers le code et réciproquement.