Générer du code python dans des packages

[cedrix57]

Bonjour,

Je suis en train d'utiliser Bouml (que je trouve génial au passage) pour créer un diagramme de classe, et générer du code python.

J'ai presque réussit à faire tout ce que je souhaite.
Il me reste à trouver comment faire pour que le code soit généré au sein de package.

Vous pouvez voir sur l'image suivante les classes que j'ai commencé à créer.



Pour le moment j'arrive à générer deux fichiers params.py et process.py dans un dossier codePythonGenere.
J'ai essayé d'indiquer les dossiers des packages de plusieurs manière (il y en a une visible sur l'image).
Mais dans tous les cas cela n'a aucun effet. Quelqu'un sait comment je devrais m'y prendre ?


Sinon par la suite, je vais également décrire les classes de l'interface graphique dans un package gui. Je vais utiliser de nombreuses classes de PyQt que je vais écrire dans les Packages PyQt4.QtGui et PyQt4.QtCore.
Sera-t-il possible de faire comprendre à bouml que ce sont des bibliothèques externe et qu'il faudra simplement faire des import ?

Merci d'avance,

Cédric

Edit : mise à jour du lien de l'image

[bruno_pages]

Bonjour,

Envoyé par cedrix57

Il me reste à trouver comment faire pour que le code soit généré au sein de package.

(remarque initiale : je ne connais pas Python et j'ai oublié le peu que je j'ai su lorsque j'ai ajouté Python dans Bouml)

qu'est ce que cela signifie au niveau du code généré, qu'est-ce qui devrait être généré de particulier et qui manque ?

Envoyé par cedrix57

Mais dans tous les cas cela n'a aucun effet. Quelqu'un sait comment je devrais m'y prendre ?

lorsqu'une classe est placée dans un package Python son nom est préfixé par le package suivit d'un '.' que ce soit dans une forme import ou autre référence à celle -ci

Envoyé par cedrix57

Sera-t-il possible de faire comprendre à bouml que ce sont des bibliothèques externe et qu'il faudra simplement faire des import ?

il est possible de dire qu'une classe est externe en l'éditant et en cochant external dans l'onglet dédié à Python. Par défaut la définition d'une casse externe est ${name} qui spécifie le nom utilisé pour cette classe à la génération, mais vous pouvez changer cette ligne par exemple en pa.${name} afin de placer cette classe dans le package pa. Il est également possible de donner d'autres lignes à la définition, normalement il s'agit juste d'une seconde ligne supposée être une forme import même si le générateur de vérifie rien et produit les lignes telles qu'elles sans se poser de question là où une forme import doit être produite. Je rappelle que la production des imports est liée à l'utilisation des dépendances stéréotypées import ou from

[cedrix57]

Merci pour votre réponse. J'ai mis à jour le lien qui montre mon image.

qu'est-ce qui devrait être généré de particulier et qui manque ?

Peut être qu'il ne manque rien et que j'ai simplement pas réussit à faire la bonne manipulation =) En fait en python, les packages sont représenté comme en java par des dossiers. Si un classe appartient au package metier, elle sera dans un dossier metier. En plus dans ce dossier un fichier __init__.py sera ajouté.

lorsqu'une classe est placée dans un package Python son nom est préfixé par le package suivit d'un '.' que ce soit dans une forme import ou autre référence à celle -ci

La placer dans un package ne suffit pas ?

il est possible de dire qu'une classe est externe en l'éditant et en cochant external dans l'onglet dédié à Python

Merci ça va m'être utile. Par contre pour les classes externes pour lesquelles j'ai choisi de ne pas générer du code Python, je n'arrive plus à accéder à l'intercalaire Python qui est grisé.

Je rappelle que la production des imports est liée à l'utilisation des dépendances stéréotypées import ou from

Je n'ai pas très bien compris comment cela fonctionne. Voici ce que j'ai essayé de faire. J'aimerai bien dans ce cas pouvoir obtenir le code Python suivant :

Code :

from PyQt4.QtGui import QMainWindow

[bruno_pages]

Envoyé par cedrix57

les packages sont représenté comme en java par des dossiers. Si un classe appartient au package metier, elle sera dans un dossier metier.

tout comme pour la génération Java il est de votre responsabilité de demander à la fois la production du fichier dans le bon dossier d'une façon ou d'une autre *et* de renseigner le champ package pour Python en éditant le paquetage contenant la vue de déploiement contenant l'artéfact produisant le code de la classe. A noté que c'est ce que vous aviez fait vu la première version de l'image montrant l'onglet Python de l'édition d'un paquetage

Envoyé par cedrix57

En plus dans ce dossier un fichier __init__.py sera ajouté.

sa production et son contenu est aussi de votre responsabilité, pour cela utilisez un artéfact stéréotypé text (c.f. doc )

Envoyé par cedrix57

La placer dans un package ne suffit pas ?

au niveau graphique non, car que faudrait-t-il faire si graphiquement vous mettiez une classes dans deux paquetages différents ?

Envoyé par cedrix57

Par contre pour les classes externes pour lesquelles j'ai choisi de ne pas générer du code Python, je n'arrive plus à accéder à l'intercalaire Python qui est grisé.

je ne comprends pas, soit une classe n'est pas externe et son code est produit par l'artéfact associé, soit une classe est externe et il n'y a pas de production de code car c'est justement le but cherché

vous parlez de l'onglet de quel éditeur (classe, artéfact ...) ?

Envoyé par cedrix57

Je n'ai pas très bien compris comment cela fonctionne. Voici ce que j'ai essayé de faire.

cf la doc seules les dépendances entre classes et artéfacts sont prises en compte pour la production *explicite* des formes import (les dépendances entre paquetages ne signifient rien au niveau génération de code)

le générateur produit implicitement des formes import pour les classes référencées par les classes qu'il génère, c.a.d. que si l'artéfact A produit le code de la classe C1 qui elle même référence la classe C2 (via une relation, attribut ou une opération) alors le fichier A.py contiendra une forme import pour C2. Si C2 est déclarée externe la forme import doit être indiquée via la seconde ligne de sa définition, pas de seconde ligne implique pas de forme import produite.

spécifier explicitement un import ne sert donc que lorsque qu'on veut produire une forme from .. import en remplacement de la forme import produite implicitement, ou parce que la classe à importer n'est pas référencée

Envoyé par cedrix57

J'aimerai bien dans ce cas pouvoir obtenir le code Python suivant :

Code :

from PyQt4.QtGui import QMainWindow

avez-vous lu ma réponse d'hier ?

vous éditez QMainWindow, cochez external puis modifiez sa définition en ajoutant une seconde ligne contenant from PyQt4.QtGui import QMainWindow

merci de lire les différents chapitres de la doc associés à la génération de code Python (générateur python, paquetage, artéfact, classe, opération, relation et attribut) et de faire des essais

[cedrix57]

A noté que c'est ce que vous aviez fait vu la première version de l'image montrant l'onglet Python de l'édition d'un paquetage

En fait cela ne marchait pas car je n'avais pas placé les déploiyement view dans les packages =)

avez-vous lu ma réponse d'hier ?

vous éditez QMainWindow, cochez external puis modifiez sa définition en ajoutant une seconde ligne contenant from PyQt4.QtGui import QMainWindow

Oui désolé j'avais cru comprendre qu'il était possible de le faire deux manières en fait.

sa production et son contenu est aussi de votre responsabilité, pour cela utilisez un artéfact stéréotypé text

Ok par contre j'ai ajouté un commentaire dans ce fichier car je n'arrive pas à lancer la génération de ce fichier si celui-ci est vide.

le générateur produit implicitement des formes import pour les classes référencées par les classes qu'il génère, c.a.d. que si l'artéfact A produit le code de la classe C1 qui elle même référence la classe C2 (via une relation, attribut ou une opération) alors le fichier A.py contiendra une forme import pour C2.

Apparemment chez moi ça ne le fait que si j'ajoute une dépendance avec le stéréotype import. Mais finalement j'ajoute les import en ajoutant une ligne dans la définition car j'aime bien faire des import de cette manière from package.module import *.

Merci pour vos réponses en tout cas, cela va beaucoup m'aider pour le logiciel que je vais développer.

[bruno_pages]

Envoyé par cedrix57

Oui désolé j'avais cru comprendre qu'il était possible de le faire deux manières en fait.

les classes déclarées externes sont particulières, 1) n'ayant pas d’artefact associé il n'y a pas non plus de paquetage contenant via une vue de déploiement l’artefact associé et spécifiant le package, 2) cela permet de donner explicitement la façon dont l'import sera fait

Envoyé par cedrix57

Ok par contre j'ai ajouté un commentaire dans ce fichier car je n'arrive pas à lancer la génération de ce fichier si celui-ci est vide.

oui, une définition vide veut dire pas de définition et donc pas de génération, de façon générale produire un fichier vide semble peut utile