Discussion :

[bruno_pages]

Bonsoir,

vous trouverez ici ma proposition de prise en compte de Python dans Bouml. [EDIT] obsolète, la version 2 de la proposition est ici[/EDIT]

de la commenter (le fond, la forme importe peu).

Attention de ne pas prendre pour argent comptant ce que je dis sur Python, gardez à l'esprit que mes connaissances sur Python sont aussi limitées que nouvelles

Bruno

[anthyme]

pour ce qui est des accesseurs (inexistant en python) je ne pense pas que '_' represente bien protected.
Je ne pense pas qu'il soit logique d'acceder aux attributs de la super classe qui commence par '_' je pense pas que cela se fasse dans l'implementation de python.
Cela correspond plutôt à 'private'

vis a vis des docstring, je ne les ai jamais vu decallé apres les """

Code :

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

1
2
3
"""une ligne

---et une autre"""

je les ai toujours vu comme ceci :

Code :

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

1
2
3
"""une ligne

et une autre"""

Voila bonne continuation

[bsadacheng]

Beh ... faut pas chomer par ici ...
donc:
au 2.3
l'operation Class.foo() pour tout Class.__foo (private) dans le reverse ne me
parait pas justifiée.
En python 2.5 pour rendre accessible un __foo on passe par des
properties donnant a l'exec un Class.foo read et/ou write selon le codage
de la property. Pour dire qui si foo() il y a dans le code il se peut, mais ce
n'est pas obligatoire, qu'il soit lié au __foo. La detection du mot clé
property est le seul moyen de prouver un lien explicite. Une autre
routine pourrait retourner __foo sans etre une property. La génération
automatique de foo() peut créer des doublons.
Regarder la doc de __metaclass__ qui permet de traiter une classe comme
un objet au niveau class (génération de classes ou de pré-traitement a
la création de classe. Si il ya un lien avec UML en tenir compte.

2.4
self n'est pas obligatoire mais c'est bien de ne pas permettre de le changer
ça permet de forcer dans les bonnes pratiques des pythonistas

2.5
Qd on a class A(B):
dans le init de A il faudrait rajouter un appel __init__ de la class B
qui n'est pas automatique. Voir le mot-clef super aussi.

dans un module de class (es) il est possible d'avoir des def blabla
non encapsulées dans la class, tout en étant appelable depuis la
classe. C'est le scope module (fichier .py) de python. Si il y a un lien
avec UML, en tenir compte.

2.8
Les chemins relatifs c'est nouveau, je préfererai pas dans un 1er temps
le code est moins clair.

2.10
Un fichier.py peut contenir class A:, class B: etc ... et aussi des def isolées
utilisées dans le module (fichier.py). Si on génère un A.py pour class A
un B.py pour class B, indépendant les uns des autres je vois pas de
probleme. En reverse depuis un existant quid ??

Les chemins de module sont dans python path. Les espaces sont visibles
depuis sys.xxx. Le dict de classe contient ce qui est dans son espace.

Pour le reste c'est joli tout plein
A+

[bruno_pages]

au 2.3
l'operation Class.foo() pour tout Class.__foo (private) dans le reverse ne me parait pas justifiée.

je suis tout à fait d'accord ... sauf sur le fait que j'ai dit cela
j'ai dis qu'une opération reversée appelée __foo dans le source donnerai une opération appelée foo dans le modèle

ce que je propose c'est que le générateur prenne en compte les visibilités pour ajouter un prefixe automatiquement, l'autre avantage etant de cacher les __ 'pas très beau' quand on a un oeil non pythonesque. Bien évidemment le reverse doit alors retirer le prefixe pour retomber sur ses pieds

mais de toute facon la chose est débraillable, je souhaite juste que vous m'indiquiez les 'bonnes' valeurs par défaut de ces settings selon vous

2.5
Qd on a class A(B):
dans le init de A il faudrait rajouter un appel __init__ de la class B
qui n'est pas automatique. Voir le mot-clef super aussi.

ca c'est c'est à l'utilisateur de le faire, comment pourrais-je savoir ce qu'il faut donner en argument s'il y en a ?

dans un module de class (es) il est possible d'avoir des def blabla
non encapsulées dans la class, tout en étant appelable depuis la
classe. C'est le scope module (fichier .py) de python. Si il y a un lien
avec UML, en tenir compte.

ce genre de chose n'est pas modélisable en UML, mais :

• cela n'est pas perdu par le reverse (partie 1 ou 3 cf 2.10)
• c'est possible à générer en le mettant directement dans la définition de l'artifact, ou en l'attachant à la définition d'une classe en le mettant avant ou après. La seule chose c'est que c'est du texte pur et dur

2.10
Un fichier.py peut contenir class A:, class B: etc ... et aussi des def isolées
utilisées dans le module (fichier.py). Si on génère un A.py pour class A
un B.py pour class B, indépendant les uns des autres je vois pas de
probleme. En reverse depuis un existant quid ??

on c'est mal compris, je n'ai peut etre pas été assez clair dans la doc

si les classes A et B sont associée à l'artifact C, alors les classes A et B seront produites dans C.py, le problème n'est pas là

dans Bouml si on veut produire le code de la classe A dans le fichier F.py il faut :

1. creer la classe avec ses membres
2. creer si besoin une vue de deployment
3. creer un artifact dans la vue de deployment et l'appeler F
4. editer l'artifact pour mettre sont stéréotype à "source" et pour demander l'association avec A

c'est donc assez lourd, pour aider on peut demander à Bouml de faire lui-même les étapes 2 à 4 via le menu de la classe, et le plug-out appelé deploy classse le fait pour toutes les classes d'une vue de classes qui n'ont pas d'artifact associé. Le problème est que dans ce cas là les artifacts crées portent le nom de leur classe associée (évidemment il est ensuite possible de les renommer, mais s'il y a 100 artifacts ...)

[bsadacheng]

Citation:
Envoyé par bsadacheng Voir le message
au 2.3
l'operation Class.foo() pour tout Class.__foo (private) dans le reverse ne me parait pas justifiée.
je suis tout à fait d'accord ... sauf sur le fait que j'ai dit cela
j'ai dis qu'une opération reversée appelée __foo dans le source donnerai une opération appelée foo dans le modèle

ce que je propose c'est que le générateur prenne en compte les visibilités pour ajouter un prefixe automatiquement, l'autre avantage etant de cacher les __ 'pas très beau' quand on a un oeil non pythonesque. Bien évidemment le reverse doit alors retirer le prefixe pour retomber sur ses pieds

mais de toute facon la chose est débraillable, je souhaite juste que vous m'indiquiez les 'bonnes' valeurs par défaut de ces settings selon vous
____________
le protected avec _ est une bonne idée, ya pas mal de code comme ça
ou le _ veut bien dire "la c'est moi qui jardine" pas touche.
Les choix me paraissent les bons. Masquer le __ et le _ dans le modèle
oui bien sur puisque les tag potected,private etc sont gérés par bouml
no problem.

Citation:
2.5
Qd on a class A(B):
dans le init de A il faudrait rajouter un appel __init__ de la class B
qui n'est pas automatique. Voir le mot-clef super aussi.

ca c'est c'est à l'utilisateur de le faire, comment pourrais-je savoir ce qu'il faut donner en argument s'il y en a ?
_________
certes les arguments .... et vu le nombre de façons de les passer ....
Mouais ... Ne pas le faire c'est generer du code non fonctionnel.
Pas beau. Par contre bouml connait les parametres de création de la super classe ( il a le init ) donc l'insertion de cette signature doit etre possible.
Si c'est trop compliqué, mettre la signature avec () liste de parametres vide.
Le code va se vautrer lamentablement mais au moins le progrmmeur saura
où et pourquoi (aveugle ??).
Par contre si le reverse ellimine la signature en la vidant
encore pas beau. Le reverse pourrait commenter le code qd il ne peut pas faire ce qu'il lit comme code? Je délire peut-etre ....


Citation:
dans un module de class (es) il est possible d'avoir des def blabla
non encapsulées dans la class, tout en étant appelable depuis la
classe. C'est le scope module (fichier .py) de python. Si il y a un lien
avec UML, en tenir compte.

ce genre de chose n'est pas modélisable en UML, mais :

* cela n'est pas perdu par le reverse (partie 1 ou 3 cf 2.10)
* c'est possible à générer en le mettant directement dans la définition de l'artifact, ou en l'attachant à la définition d'une classe en le mettant avant ou après. La seule chose c'est que c'est du texte pur et dur

Magnifique !!! On est sauvé !!!


Citation:
2.10
Un fichier.py peut contenir class A:, class B: etc ... et aussi des def isolées
utilisées dans le module (fichier.py). Si on génère un A.py pour class A
un B.py pour class B, indépendant les uns des autres je vois pas de
probleme. En reverse depuis un existant quid ??

on c'est mal compris, je n'ai peut etre pas été assez clair dans la doc

si les classes A et B sont associée à l'artifact C, alors les classes A et B seront produites dans C.py, le problème n'est pas là

dans Bouml si on veut produire le code de la classe A dans le fichier F.py il faut :

1. creer la classe avec ses membres
2. creer si besoin une vue de deployment
3. creer un artifact dans la vue de deployment et l'appeler F
4. editer l'artifact pour mettre sont stéréotype à "source" et pour demander l'association avec A


c'est donc assez lourd, pour aider on peut demander à Bouml de faire lui-même les étapes 2 à 4 via le menu de la classe, et le plug-out appelé deploy classse le fait pour toutes les classes d'une vue de classes qui n'ont pas d'artifact associé. Le problème est que dans ce cas là les artifacts crées portent le nom de leur classe associée (évidemment il est ensuite possible de les renommer, mais s'il y a 100 artifacts ...)

J'ai pas compris ... Je connais pas assez bien bouml.

Par contre dans
2.6.1.3 macros


${type} : produit le type de l'attribut, par exemple pour l'utiliser dans un commentaire, éventuellement en plaçant celui-ci directement dans la définition
*

Là ya un truc intéressant a faire. Si c'est posible evidemment.
Le type en python est connu a l'exec soit; Mais il est possible de wrapper
la modif d'un attribut pour verifier le type. On peut faire ça avec un
decorator donc on pourrait avoir dédoublement de ${type} en
${typed} , l'info du type irait dans la doc, et ${typev}${deco} ou deco
serait le decorator de validation des types donc un nom de fonction
et le géné devrait ecrire @deco devant la routine de modif de l'attribut.
On est peut-etre trop loin de UML et trop dans python là ???
Le code du decorator juste pour rire, et pour les codeurs qui
lisent

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
16
17
18
19
20
21
22
23
24
    def require(*types):
    """Return a decorator function that requires specified types.
       types -- tuple each element of which is a type or class or a tuple of
                several types or classes.
       Example to require a string then a numeric argument
       @require(str, (int, long, float))
       will do the trick"""
       def deco(func):
        """Decorator function to be returned from require().  Returns a function
           wrapper that validates argument types."""
        def wrapper (*args):
            """Function wrapper that checks argument types."""
            assert len(args) == len(types), 'Wrong number of arguments.'
            for a, t in zip(args, types):
                if type(t) == type(()):
                    # any of these types are ok
                    msg = """%s is not a valid type. Valid types:\n%s"""
                    assert sum(isinstance(a, tp) for tp in t) > 0, \
                                msg % (a, '\n'.join(str(x) for x in t))
                assert isinstance(a, t), '%s is not a %s type' % (a, t)
            return func(*args)
        return wrapper
    return deco

Bon ben voilou ...
A+

[bruno_pages]

par pitié bsadacheng, ne fait pas les citations à la main, tu dois te rendre compte qu'il y a comme une différence entre l'affichage de ton message et les autres

Citation:
certes les arguments .... et vu le nombre de façons de les passer ....
Mouais ... Ne pas le faire c'est generer du code non fonctionnel.

on c'est mal compris, si tu demandes à Bouml de produite super.__init__(1, ${v2}) il le fera. Par contre il n'a pas de boule de cristal lui permettant de deviner qu'il faut appeler l'__init__ de la classe super avec 1 en premier argument et le troisième paramètre courant en second paramètre

Par contre bouml connait les parametres de création de la super classe ( il a le init ) donc l'insertion de cette signature doit etre possible.
Si c'est trop compliqué, mettre la signature avec () liste de parametres vide.
Le code va se vautrer lamentablement mais au moins le progrmmeur saura
où et pourquoi (aveugle ??).

non, ca c'est de l'algorithmie, c'est à l'utilisateur de faire ce genre de chose, encore une fois Bouml n'est pas extra lucide

Par contre si le reverse ellimine la signature en la vidant
encore pas beau.

mais d'où sortez-vous tout ces trucs ?

Bouml ne vide aucune signature au reverse, ni les corps des opérations etc ...

[bruno_pages]

Là ya un truc intéressant a faire. Si c'est posible evidemment.
Le type en python est connu a l'exec soit; Mais il est possible de wrapper
la modif d'un attribut pour verifier le type. On peut faire ça avec un
decorator donc on pourrait avoir dédoublement de ${type} en
${typed} , l'info du type irait dans la doc, et ${typev}${deco} ou deco
serait le decorator de validation des types donc un nom de fonction
et le géné devrait ecrire @deco devant la routine de modif de l'attribut.
On est peut-etre trop loin de UML et trop dans python là ???

désolé, j'avais raté la fin

inutile de dédoubler ${type} en deux nouvelles macros, tu peux écrire ${type} autant de fois que tu veux, cela ne s'use pas

si tu veux que Bouml produise '@deco' alors mets '@deco' directement là où tu veux, il est inutile de me demander de faire une macro pour cela

petit rappel : les plug-outs sont là pour automatiser ce que vous ne souhaitez pas faire à la main, donc n'hésitez pas à faire des plug-outs modifiant vos modèles comme vous le souhaitez