Discussion :

[bruno_pages]

Bonjour,

je réalise la suite UML Bouml gérant actuellement les langages C++, Java, Idl et Php.

J'ai reçus une demande pour ajouter Python, mais je ne suis pas sure que cela ai un vrai sens :

• Python me semble très (trop) dynamique comparé à la rigidité d'une modélisation,
• le langage est très peu typé et les attributs ne sont pas déclarés (c'est donc d'une certaine façon 'pire' que Php du point de vue UML, ce qui n'enlève rien à l'intérêt du langage )
• je ne suis pas certain que le développeur en Python soit intéressé par un outil Uml gérant Python

Merci de me donner votre avis

[Bayard]

Moi cela m'intéresse.

Par exemple car en python, si quelque chose d'imprévu arrive, l'interpréteur indique via une exception où est le problème. En C++, par exemple, si l'exception n'est pas gérée, il y a un souci.

Je pense que cela peut être intéressant au niveau du marché de l'automatisme sur PC.
Par ailleurs, la compacité et la lisibilité du code python seront apprécié en tant que code généré par UML. Parfois le code généré par un outil automatique est difficile à comprendre.

[Matthieu Brucher]

Je pense que c'est intéressant d'avoir un modeleur qui sort du code Python, même si naturellement tout ne pourra pas être fait. Mais au moins générer le squelette serait intéressant (même si le squelette lui-même est sujet à modification dynamique dans le code).
J'ai une fois cherché cela sans le trouver, donc si Bouml le fait, ce sera l'un des premiers si ce n'est le premier

[Thierry Chappuis]

Bonjour,

je réalise la suite UML Bouml gérant actuellement les langages C++, Java, Idl et Php.

J'ai reçus une demande pour ajouter Python, mais je ne suis pas sure que cela ai un vrai sens :

• Python me semble très (trop) dynamique comparé à la rigidité d'une modélisation,
• le langage est très peu typé et les attributs ne sont pas déclarés (c'est donc d'une certaine façon 'pire' que Php du point de vue UML, ce qui n'enlève rien à l'intérêt du langage )
• je ne suis pas certain que le développeur en Python soit intéressé par un outil Uml gérant Python

Merci de me donner votre avis

Personnellement, je suis favorable au support de Python par Bouml. J'utilise déjà cet outils pour mes projets C++. Pour Python, j'utilise PyUt, mais il n'est pas très stable et son développement est relativement lent. Je pense qu'un outils de modélisation UML avec génération de code me serait autant utile pour développer en Python qu'en C++. Je ne comprends pas ta remarque au sujet du caractère peu typé de Python ni d'ailleurs la comparaison que tu fais avec PHP. Python est un language à typage dynamique, mais fort. Pourrais-tu développer un peu sur ce point?

Thierry

[bruno_pages]

Je ne comprends pas ta remarque au sujet du caractère peu typé de Python ni d'ailleurs la comparaison que tu fais avec PHP. Python est un language à typage dynamique, mais fort. Pourrais-tu développer un peu sur ce point?

Pour moi modéliser veut dire fixer les choses, en particulier la liste des opérations, attributs, les types, la visibilité etc ... ce qui colle bien avec des langages comme C++ (qui est de fait ma référence)

En Php les spécifications de type sont rares, par exemple un attribut n'est pas typé, mais il est possible de typer un paramètre d'opération, et la visibilité existe. La liste des attributs et opérations est également fixe. On modélise donc 'moins' en Php qu'en C++ par exemple.

Avec Python il n'y a pas de spécification de type possible, pas de visibilité (__ n'est qu'un hack), la liste des attributs n'est pas figée etc ... On modélise donc encore moins qu'avec Php d'ou mon 'pire'. Mais je ne dis pas que Python est pire que Php dans l'absolu, ce qui n'aurait aucun sens, c'est juste relatif au niveau de modélisation

[Marmot]

Python me semble très (trop) dynamique comparé à la rigidité d'une modélisation,

Et alors ? Quand tu veux t'assurer de la maintenance d'un projet conséquent tu es bien obligé de passer par la 'rigidité' d'une modélisation.

le langage est très peu typé et les attributs ne sont pas déclarés (c'est donc d'une certaine façon 'pire' que Php du point de vue UML, ce qui n'enlève rien à l'intérêt du langage )

La philosophie est différente des langages à typage statique, c'est au programmeur de s'assurer des tests nécessaires.

je ne suis pas certain que le développeur en Python soit intéressé par un outil Uml gérant Python

A part PyUT et quelques outils en ligne de commande tu serais quasi le seul dispo gratis dans le sens UML->Python.

[anthyme]

Olala tu reçoit les foudre des guru pythoneur alors que ce que tu dis est de bon sens

perso je trouve le python télement rapide rapide a ecrire et que qu'un générateur de code 'vide' me semble peu utile, c'est pas avec ma philosophie de programation dite 'agile'

mais bon courage pour ton projet tout de même

[bruno_pages]

Olala tu reçoit les foudre des guru pythoneur alors que ce que tu dis est de bon sens

je ne pensais pas avoir reçus de coup de foudre, et si j'ai mis cette discussion c'est justement pour recevoir des réponses (tant à faire venant de gourou)

un générateur de code 'vide' me semble peu utile

On est bien d'accord, et je n'ai jamais parlé de faire ce genre de chose. Bouml permet de produire intégralement le code pour les autres langages, il le ferait pour Python.

Si c'est à cause du squelette cité par Miles c'est une erreur de sa part, il pensait sans doute à un autre modeleur ... en supposant que cela puisse alors s'appeler modeleur

P.S. mais de toute façon ce n'est pas très important car la discussion à été vue par 113 personnes mais il n'y a que 5 oui

[zorg724]

Je travaille pour Thales.
La grande tendance des prochaines années est l'approche MDA: la plupart de nos projets (y compris les projets critiques) passent par l'étape de modélisation UML, afin de capitaliser le métier dans des diagrammes UML (de classes, de sequences ...). Ainsi, d'années en années, l'entreprise capitalise en exprimant les relations entre les classes de son domaine : des milliers de classes en relation sont disponibles, indépendamment de tout langage, même de tout modeleur puisque tout est exportable en XMI: l'important est d'avoir une base de données qui décrit les objets, leur comportements, et leur relation : un radar, une procédure d'approche, une balise VOR DME, un missile ... Ainsi, lorsqu'il s'agit de commencer un nouveau projet, il existe vraiment des briques de bases sur étagère pour commencer l'application. La projection du modèle vers le code (qui peut se faire en plusieurs étapes de transformation) est l'étape qui vient qu'au moment de la production, quand les grands choix d'architecture sont faits: vers le C (donc même pas objet), vers ADA 95, JAVA,... Alors Python, certainement, non pas pour en faire du code embarqué (un logiciel de pilotage automatique ou un system de gestion du vol a besoin de plus de sécurité!), mais Python comme langage pour le prototypage, phase essentielle pour tout développement, ou pour la génération de tests. Aussi si Bouml gère Python, ce sera un outil industriel très remarqué. Pour les autres langages, Bouml ne fait pas le poid (malgré ses qualités indéniables) face à des concurrents comme Rhapsody, Objecteering 6...
Salutations.

[bruno_pages]

et bien , si je résume ce que vous dites zorg724, et ce en forçant à peine le trait, cela donne : un modeleur UML pour Python: indispensable ... du moment que c'est Rhapsody, Objecteering ... mais pas Bouml puisque ce n'est un joujou. Je ne comprends donc plus pourquoi vous m'avez envoyé un mail me demandant d'ajouter Python, je ne traite pas les demandes d'évolution de Rhapsody, Objecteering ... ni d'ailleurs de Fujaba ou Visual Paradigm qui étaient vos meilleurs outils de modélisation UML

Pour ne pas polluer cette discussion dédiée à Python je me suis permis d'ouvrir une autre discussion sur les manques de Bouml, qu'il s'agisse du MDA ou autre

P.S. Heureusement que Bouml ne rivalise pas totalement avec Rhapsody, Objecteering et autres monstres, ce serait plus que gênant pour leur équipe de développement car je suis seul sur Bouml que je développe chez moi, lorsque je ne suis pas au travail. Par contre, même s'il n'y a pas que cela qui compte, les performances lamentables de ces outils me laissent pantois. Malgré tout, tout le monde n'est pas de votre avis, et il y a pas mal d'utilisateurs de Rhapsody, Objecteering et autre Rose qui, malgré le coût d'achat de leurs licences, sont passés à Bouml. Mais tout le monde n'a pas la même utilisation d'un modeleur ... y compris dans Thales où Bouml est utilisé

[zorg724]

Bonjour,
Bouml ne fait pas le poids malgré ces indéniables qualités techniques, parce que:
Vous êtes seuls sur son développement.
Ce n'est pas un reproche, mais c'est la réalité.

Nous sommes 350 ingénieurs sur un projet , avec plus de 150 utilisateurs d'un modeleur cher et moins performants que le votre sur certains aspects, mais:

- Pour un projet qui a une durée de vie de plus de 10 ans; il nous faut un outil fait par une entreprise qui a les reins solides: un homme seul sur un projet n'est pas une garantie de pérennité: Quand est-il de la disponibilité de l'outil demain? Quel type de support peut-on espérer? Quelles collaborations pour faire évoluer ensemble le produit?

- La richesse fonctionnelle des outils chers est incomparables, tout simplement parce qu'un grand nombre d'experts collaborent à son élaboration (algorithme de layout de diagrammes de classes, gestion de OCL , outil de transformation de modèle, automation, mapping automatique d'un modèle vers une base de donnée... ). Le plus grand génie ne peut pas tout faire...

BOUML est EXCELLENT, mais il ne peut être utilisé que pour des petits projets, où pour des phases moins critiques du développement.

BOUML a une carte à jouer avec PYTHON, car BOUML peut s'imposer dans des niches techniques comme par exemple modeleur PHP et PYTHON. Ces langages sont délaissés par les autres produits. C'est l'occasion inespéré d'étendre l'usage de BOUML.

Cordialement,
Mr Zorgi

[Matthieu Brucher]

- Pour un projet qui a une durée de vie de plus de 10 ans; il nous faut un outil fait par une entreprise qui a les reins solides: un homme seul sur un projet n'est pas une garantie de pérennité: Quand est-il de la disponibilité de l'outil demain? Quel type de support peut-on espérer? Quelles collaborations pour faire évoluer ensemble le produit?

Désolé, mais en ce qui concerne la pérennité d'un produit à terme, je ne fais pas confiance à une entreprise, je fais confiance à un logiciel Open Source. Au moins, si l'équipe de développement arrête, il y a moyen de continuer, ce n'est pas le cas d'un développement fermé par une boîte externe.
Et puis Bruno peut aussi ajouter des contributions externes, c'est ça l'avantage de son système

[bruno_pages]

Décidément on ne se comprend pas

Quand est-il de la disponibilité de l'outil demain?

Mais les outils payants sont tout sauf pérennes !

Combien d'outils commerciaux ont déjà disparus. J'ai des utilisateurs qui ont dut abandonner leur modeleur habituel car le distributeur ayant disparut ils ne pouvait même plus mettre à jour leur licence alors que cela devait être fait chaque année. J'en ai d'autres qui ont abandonné Rhapsody suite à des rumeurs de rachat par l'un de leur concurrent

Seuls les produits dont vous pouvez avoir les sources sont pérennes, quand les autres meurent, ce qui est inévitable, vous ne pouvez même pas réinstaller/utiliser les versions déjà acquises quand vous changer de machine à cause des différentes protections ou parce que vous n'avez pas le moyen de le faire

Et cela n'a rien à voir avec la taille du distributeur. Comment vous faites maintenant que Microsoft ne maintient plus ni ne distribue Visual Basic pour forcer le passage à C# ?

Quel type de support peut-on espérer? Quelles collaborations pour faire évoluer ensemble le produit?

C'est assez amusant, car des ex utilisateurs de objecteering sont passés à Bouml car, je site : ils n'en sont pas content (problèmes de stabilité, de réactivité du support)

Et cela n'a rien à voir avec le prix du produit. Vous aviez beau avoir acheter à prix d'or une suite Scade, la version majeure suivante n'est pas compatible ascendant, les outils de migration 'oublient' les fonctionnalités ayant disparues et n'ayant pas de correspondance

C'est l'occasion inespéré d'étendre l'usage de BOUML.

Incroyable, à vous entendre le cas de Bouml est désespéré. Lorsque j'ai arrêté de comptabiliser les téléchargements à partir du site de Free en Juillet 2007 il y avait eu plus de 150000, avec une croissance non linéaire

Si j'ajoute Python dans Bouml ce ne sera pas le dernier spasme d'un soft moribond cherchant désespérément à survivre en cherchant sa niche

[bsadacheng]

Faites le asap svp. Je developpe en python tout le temps dans un centre de recherche. Je reve d'un modeleur uml crachant du code python. Faites le, je vous en supplie Je connais Bouml mais manquait mon langage. Python est tres puissant, faire du typage strict est facile avec les decorators. L'introspection du langage est fabuleuse. Je code les acces hard en C, une lib d'interface et hop, je pilote n'importe quoi. les UI graphique avec PyQt
et le dev integré avec Eric4. Avec Bouml j'aurais une plateforme complete.
C'est qd la 1ere version??? Demain???

[bruno_pages]

c'est bizarre quand même comme l'impact d'un message peut varier de l'un à l'autre ...

Bon, je vais re-réfléchir à une prise en compte dans Bouml et produire une proposition, ces derniers jours je n'avais pas le cœur à l'ouvrage.
Pendant que vous aurez la gentillesse de lire la proposition cela me laissera le temps de faire la 3.5 que je compte faire avant d'attaquer la 4.0

C'est qd la 1ere version??? Demain???

si c'est un jour mercurien cela laisse une certaine marge

Pour Php cela m'avait pris deux WEs et les 5 soirées entre pour tout faire (en jours terrestres), c'est à dire modifier le modeleur, l'API avec les plug-outs, plug-out upgrade (), faire le générateur et le reverse () ... sans oublier l'introduction de deux 'jolis' bugs

Mais j'avais bénéficier de pas mal de copier-coller à partir de ce qui était fait pour gérer Java. Là je ne sais pas trop ce que cela va donner, alors disons entre 2 et 4 jours Neptuniens, suivant ma disponibilité

[bsadacheng]

Et beh , chapeau bas
Je connais pas php mais bon qd meme.
J'attends avec impatience.
Vous developpez en C++ je crois. Je me suis jamais fait à
ce langage. Je préfère ..... python.
J'ai fait du Java aussi .... je préfère .... python.

[bruno_pages]

deux jours ... euh de qu'elle planète .. bigre, qu'elle idée j'ai eu là
Donc, 4 jours (2 WEs) + 5 soirées, je ne suis pas overkloqué, et j'ai une gentille chatte qui mérite une attention de type NMI

Oui c'est en C++, comme quoi il n'y a pas qu'en Python qu'on peut aller vite
Java je considère que je ne connais pas trop, juste de quoi faire l'API et quelques plug-outs dans ce langage
De Php je ne connais que la syntaxe/sémantique liée aux classes, et j'avoue qu'il en sera au moins au début de même pour Python ... une sorte de service minimum pour une prise en compte dans Bouml

[Matthieu Brucher]

De Php je ne connais que la syntaxe/sémantique liée aux classes, et j'avoue qu'il en sera au moins au début de même pour Python ... une sorte de service minimum pour une prise en compte dans Bouml

A nous de regarder tes tutoriels et d'améliorer la prise en charge

[bruno_pages]

A nous de regarder tes tutoriels

diantre, mais je n'ai pas dis que le ferai un tutoriel pour Python ... mais c'est bien essayé

blague à part que ceux qui n'ont pas peur de rédiger ne se gênent pas, d'ailleurs j'en discutait hier in English (sauter le début de la discussion)

en ce qui me concerne rédiger est à la limite des mes capacités, je viens de commencer la proposition pour Python mais cela avance péniblement ... dommage qu'on ne puisse pas tout écrire en C++

[Matthieu Brucher]

diantre, mais je n'ai pas dis que le ferai un tutoriel pour Python ... mais c'est bien essayé

Pardon, je me suis mal exprimé A l'aide de tes tutoriels publiés ici sur les extension pour Bouml, on devrait pouvoir t'aider à améliorer le support de Python