Discussion :

[zorg724]

Pour le reste je suis assez perplexe, contrairement à vous ce qui m'importe le plus n'est finalement pas la sémantique mais la syntaxe...

=> La grammaire du langage Python est disponible là:
http://docs.python.org/ref/grammar.txt
z.

[bruno_pages]

La grammaire du langage Python est disponible là:
http://docs.python.org/ref/grammar.txt

oui, je l'avais trouvé et utiliser pour faire la proposition, merci quand même

J'avais laissé la question ouverte dans la proposition 2, j'ai choisi le plus pratique pour les utilisateurs : je gère un flag "2.2" pour que l'héritage d'object reste implicite et soit produit pas le générateur si besoin.

J'ai fini les modifs coté modeleur, je continue ...

[Thierry Chappuis]

la version 2 de la proposition est ici

J'ai rien à rajouter!

Thierry

[bsadacheng]

Merci champion !!!!!!!!!!
Franchement avec tout ça on devrait faire du bon boulot.

[bruno_pages]

La version 4.0 est disponible sur le site ou sur sourceforge

Cette version permet de générer du code Python mais pas de faire des reverses ni d'atteindre les définitions Python via un plug-out utilisateur, il faudra pour cela attendre une prochaine version

Attention, il y a quand eu pas mal de changements, c'est donc une version beta, accrochez-vous à vos octets

[Thierry Chappuis]

La version 4.0 est disponible sur le site ou sur sourceforge

Cette version permet de générer du code Python mais pas de faire des reverses ni d'atteindre les définitions Python via un plug-out utilisateur, il faudra pour cela attendre une prochaine version

Attention, il y a quand eu pas mal de changements, c'est donc une version beta, accrochez-vous à vos octets

Merci, je vais tester ça!

Thierry

[zorg724]

Bonjour,
Félicitions, Monsieur Bruno Pages,
j'ai réalisé une petite modélisation "bâteau" en 20 minutes:

-la prise en main est immédiate.

-la qualité du code généré est remarquable : gestion de l'héritage, des compositions de liste, dictionnaire, ensemble....

-Je n'ai pas très bien compris comment on fait pour générer les paramètres d'une méthode, car j'ai beau avoir défini 2 paramètres dans l'onglet 'UML', ceux-ci ne s'ajoutent pas à au code généré: j'ai dû modifier à la main le template "Definition" dans l'onglet "Python" :
${@}${static}${abstract}def ${name}${(}${p1},${p0}${)}:
mais peut-être qu'il y a plus simple?

-J'ai créé une classe de stéréoptype énuméré (Color, en ajoutant 2 attributs de classe). Cependant un constructeur est généré: est-ce normal?
-Je continue les tests.

Salutations.

[bruno_pages]

-Je n'ai pas très bien compris comment on fait pour générer les paramètres d'une méthode, car j'ai beau avoir défini 2 paramètres dans l'onglet 'UML', ceux-ci ne s'ajoutent pas à au code généré: j'ai dû modifier à la main le template "Definition" dans l'onglet "Python" :
${@}${static}${abstract}def ${name}${(}${p1},${p0}${)}:
mais peut-être qu'il y a plus simple?

il y a beaucoup plus simple : appuyer sur le bouton default definition qui prend la définition donnée par les generation settings en y ajoutant gentiment les paramètres

il est également possible d'ajouter/retirer/modifier des paramètres via edit parameters, mais ce sera sans doute moins utilisé en Python qu'en C++ par exemple

-J'ai créé une classe de stéréoptype énuméré (Color, en ajoutant 2 attributs de classe). Cependant un constructeur est généré: est-ce normal?

actuellement je force l'existance d'__init__ même si c'est inutile (cf la doc : The operation __init__ is automatically added by the code generation, even if they are no instance attribute or relation.)

[zorg724]

default definition

Par contre les valeurs par défaut ne sont pas utilisées dans la définition de la méthode:

Si j'ai bien compris, je vais sur la très judicieuse boite de dialogue "generaton settings dialog", et là je peux modifier les templates: dans l'onglet 'Python 2' je vois "operations template definition":

${@}${static}${abstract}def ${name}${(}${)}:
${docstring}${body}

Mais où se trouve la doc qui explique comment je peux ajouter les valeurs par défaut?
Au final, au lieu d'avoir
def demarer(vitesse, position):
pass

il faudrait
def demarer(vitesse =10, position=100):
pass

Merci d'avance.

[bruno_pages]

Au final, au lieu d'avoir
def demarer(vitesse, position):
pass

il faudrait
def demarer(vitesse =10, position=100):
pass

Ce ne sont pas les generation settings qui permettent de traiter ce cas particulier car ils définissent effectivement des templates.

Donc, default definition produit à priori

Code :

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

1
2
${@}${static}${abstract}def ${name}${(}${p0}, ${p1}${)}:
${docstring}${body}

il faut ensuite directement modifier la définition de demarer pour avoir

Code :

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

1
2
${@}${static}${abstract}def ${name}${(}${p0} = 10, ${p1} = 100${)}:
${docstring}${body}

la partie devant "Definition:" est éditable et peut être modifiée comme on veut (contrairement a la partie devant "Result after substitution:" qui ne l'est évidemment pas). D'ailleurs il y a un curseur qui clignote, placé avant le premier caractère

Edit parameters est un moyen 'moins manuel' pour modifier les paramètres, mais actuellement cela ne permet pas de spécifier une valeur par défaut. Cependant je peux très bien ajouter une colonne pour cela dans ce dialogue et modifier le parsing associé : j'avais oublié que l'on pouvait spécifier une valeur par défaut pour les paramètres

[zorg724]

Justement,
dans l'onglet "UML", "parameters:", je peux définir la direction, le nom, le type,
et surtout " Default Value".
C'est les valeurs renseignées dans ce tableau que je souhaite récupérer dans l'onglet "Python", "definition:": Est-ce qu'il existe un moyen systématique (en cliquant sur "default definition") pour générer un template du type:

${@}${static}${abstract}def ${name}${(}${p0}={tabParam[0]}, ${p1}{tabParam[1]}${)}:
${docstring}${body}

Car sinon, on renseigne pour rien les paramètres par défaut dans "UML", "parameters:", puisqu'il faut les retaper dans l'onglet "Python".

M.Zorgi

[bruno_pages]

on renseigne pour rien les paramètres par défaut dans "UML", "parameters:", puisqu'il faut les retaper dans l'onglet "Python".

oui, actuellement le renseignement de la partie "default value" au niveau uml n'est pas utilisée par la génération de code, et ce pour tout les langages, il manque un ${vi}

[bsadacheng]

Dans la def d'une classe on défini un champ private dans l'onglet UML
et les __ ne sont pas ajoutez automatiquement dans le code. Pour protected
on pourrait mettre _ . Ya buggie ou j'ai pas fait comme y faut ??

[bruno_pages]

Dans la def d'une classe on défini un champ private dans l'onglet UML
et les __ ne sont pas ajoutez automatiquement dans le code.

ca c'était dans la proposition 1

ce n'est plus d'actualité comme je l'ai dis dans une réponse plus haut et dans la proposition 2

[bsadacheng]

Qui donc a pu suggerer de supprimer une fonctionnalité essentielle
du langage? Peu importe. C'est une annerie à mon avis. ça doit
etre des 'tits gars qui ont pas encore digéré la conception objet.
Et puis le modèle UML sert à quoi? si il n'est pas cohérent avec la génération?
D'ailleurs le reverse va lui maintenir la cohérence en marquant les private.
ça vous gène pas aux entournures? ça me fait cet effet la à moi:

Oh !!!! Cruelle désillusion .....

[bruno_pages]

je ne comprends pas ces remarques

Qui donc a pu suggerer de supprimer une fonctionnalité essentielle du langage?

la visibilité n'existe pas en Python, comment pourrait-elle être une fonctionnalité essentielle ?

Et puis le modèle UML sert à quoi? si il n'est pas cohérent avec la génération?

où y-a-t-il incohérence ?
si vous appeler quelque chose __xx dans le modèle alors __xx sera bien produit à la génération

D'ailleurs le reverse va lui maintenir la cohérence en marquant les private.

rien ne vous empêche de dire que des éléments sont privés en dehors du reverse

y aurait-il un quiproquo ?

[bsadacheng]

[QUOTE=bruno_pages;2914948]je ne comprends pas ces remarques

ATTENTION ne prenez pas la suite pour une agression ou des propos désobligeants, je cherche simplement a faire comprendre mon point de vue
et d'arriver à un outil UML qui soit le plus puissant possible.

[QUOTE=bruno_pages;2914948]la visibilité n'existe pas en Python, comment pourrait-elle être une fonctionnalité essentielle ?

Stricto sensu la visibilité n'existe pas en Python. On peut acceder au champs
en connaissant ce que fait python. Mais c'est pareil dans les autres langages
sauf que vous ne savez pas ce que fait l'interpreteur/compilateur et/ou que vous ne cherchez pas à biaiser avec les outils. On pourrait
supprimer de la doc python ces explications et hop plus personne ne
pourrait dire la visibilité n'existe pas en Python. Serait il possible de rester
tout simplement à ce que permet la syntaxe de python. Ne serait il pas plus
simple et prudent de suivre la syntaxe.


[QUOTE=bruno_pages;2914948]où y-a-t-il incohérence ?
si vous appeler quelque chose __xx dans le modèle alors __xx sera bien produit à la génération.

Il y a incohérence dans la mesure ou en Java vous mettez le mot clef private
la ou un champ private existe dans le modele UML, ce que vous ne faites pas
pour python, __ est le mot clef private. BOUML a-t-il le droit de supprimer de la syntaxe ?
La 2eme incohérence vient de ce que un futur reverse marquerait private en UML la ou une classe python contiendrait __ . Dans un sens BOUML suivrait la syntaxe et pas dans l'autre .... Si ça c'est pas incohérent .....

rien ne vous empêche de dire que des éléments sont privés en dehors du reverse

Pas compris ....

y aurait-il un quiproquo ?

Oui j'ai l'impression que Python ne vous semble pas un langage du niveau
de Java ou C++. Ayant pratiquer professionellement les trois plus d'autres comme Haskell ou Erlang, je peux vous affirmer que python a de grandes qualités.
Et puis sans polémiquer sur les langages, peu importe. Suivez simplement
la syntaxe. C'est le coeur de votre logiciel. Ce que fait python APRES
la génération du code ne regarde pas BOUML. Certes la syntaxe est riche
dans python et beaucoup de mécanismes de python sont puissants et pas
immédiat, je vous conseil de coder en python et vous en prendrez conscience
comme j'ai pu le constater moi-meme jour apres jour. Seul Haskell me
parait encore plus puissant que python.

Cordialement et en espérant avoir été constructif

[bruno_pages]

ATTENTION ne prenez pas la suite pour une agression ou des propos désobligeants, je cherche simplement a faire comprendre mon point de vue

pas de problème : on est sur la même longueur d'onde

pour python, __ est le mot clef private

c'est absolument faux, __ fait parti du nom :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class C:
  def __init__(self):
    self.__v = 123
  
  def f1(self):
    print self.__v
  
  def f2(self):
    print self.v

c = C()
c.f1()    # affiche 123
c.f2()    # AttributeError: C instance has no attribute 'v'

[hed62]

Ce qu'il voulait signifier, je pense, est plus ceci :

def __init__(self):
self.__v = 123 // Privé
self.v = 123 // Public


En effet, j'ai toujours préfixé de "__" les attributs privés de mes classes.

[zorg724]

Bonjour,
J'ai pu utiliser maintenant Bouml avec Python, sur un projet de 100 classes environ. L'ensemble est particulièrement stable et rapide. Aussi se pose le problème du reverse, car sur des projets qui grossissent cela devient indispensable. J'ai essayé de faire du reverse et cela ne semble pas fonctionner:
"can't start the plug-ot 'python-reverse' perhaps you must specify its absolute path or set the environment varaible PATH?"

Est-ce normal ? Dans la documentation, cela parait possible:
http://bouml.fr/doc/index_pythongenerator.html:

'When you start the Python code reverse, it ask for a directory, then it reads all the sources placed under the selected directory and sub-directories. The sources read by the Python code reverse are the ones having the extension specified in the generation settings.... '

Est-ce qu'on peut vous aider à faire le moteur de reverse, ou bien est-ce en cours de développement?
Cordialement,
M.zorgi