Pueblo2708 a écrit 9 commentaires

Tout le monde parle de OOo et on oublie LibreOffice. Perso, dès l'annonce du fork, j'ai viré OOo pour le remplacer par LibreOffice. J'installe, je lance, je constate le clônage plus que le fork et j'utilise pour faire ma présentation d'équipe. Après une demi-journée de boulot à faire mes slides, je suis content, j'enregistre et je ferme. J'arrive avec mon ordi dans la salle de réunion où sont présent tous mes collègues, pour la plupart pro-M$. Je branche l'ordi au rétro, je lance ma présentation et là...la cacatastrophe: impossible d'ouvrir le document et une demi-journée de boulot de perdu. Pour le coup, mes collègues pro-M$ se sont bien foutu de mon activisme libriste. Je m'en tiendrais bien à mon vieux latex beamer si ce n'était le problème de productivité. Conclusion, j'ai complétement désinstallé LibreOffice pour remettre OOo.

Cette fonctionnalité supporte-t'elle une vue logique du modèle qui permet d'assurer l'intégrité du modèle en cas d'édition concurrente sur plusieurs fichiers associés à un même modèle ?

Oui.

Papyrus propose t'il une interface de fusion de modèle UML équivalente à RSA (merge 3 contributeurs et combined merge)

Non.

Est-'il prévu d'intégrer les diagrammes dans le même fichier que celui du modèle car le fait qu'il soit séparé par défaut est assez pénalisant ?

Non. Mais le fait de sérialiser le modèle et les diagrammes dans des fichiers différents n'est pas plus pénalisant que si ils étaient dans le même fichier. Dans un cas, on a plusieurs fichiers à racine unique et dans l'autre un seul fichier avec plusieurs racines. Quand les modèles sont chargés, il n'y a plus que des objets.

Si toutes ces conditions ne sont pas réunies ne sommes nous pas encore à assez loin d'une utilisation industrielle pour modéliser en équipe ?

Non, nous n'en sommes pas si loin. À la rigueur, à ce niveau là, le problème est essentiellement méthodologique. On peut réaliser des projets de taille raisonnable en confiant la réalisation des sous-systèmes à différentes équipes. Si les spécifications systèmes ont été correctement définies, l'intégration ne devrait alors pas poser de gros problèmes.

Quoiqu'il en soit, le but premier de cette dépêche était de pousser les développeurs à utiliser Papyrus de manière à identifier et remonter tous ces problèmes. Comme, je le disais, les équipes de développement sont très réactives et plus elles disposeront de retours, plus elles seront à même de proposer des solutions efficaces.

Tres franchement, je suis un peu surpris de voir autant d'applomb à décrire un projet dont vous n'êtes pas membre...

Je suis ingénieur de recherche dans l'équipe du CEA qui développe Papyrus. Je travaille en amont de ce projet (et non de Topcased), j'interviens comme consultant pour mon expertise sur GMF et je participe au debug quand j'en ai le temps. Certes, je ne suis pas au courant de toutes les tractations entre les projets: la politique m'ennuie énormément. En revanche, je connais bien mes travaux de recherche et quand je dis: les équipes de développement réfléchissent à l'intégration de papyrus avec Eclipse CDO pour fournir des fonctionnalités équivalentes à celles fournies par jazz de IBM, il s'agit en fait d'une proposition que j'ai faite avec d'autres ingénieurs de recherche de mon laboratoire et dont je continue à étudier la faisabilité. L'expression "réfléchir à" n'engage absolument à rien contractuellement, isn't it ? Peut-être aurais-je vous contacter pour avoir la permission d'avoir des idées pour améliorer Papyrus.

Pour ce qui est du rapprochement Papyrus / Topcased, ça fait des lustres que cela aurait du être fait. Qu'est-ce qu'il l'en empêche dans le fond ? Primo, comme vous l'avez mentionnez, ils ne poursuivent pas le même objectif et secundo, il y a la mise en concurrence des pôles de compétitivité.

Ah oui, et si je met autant d'aplomb à écrire sur ce sujet, c'est peut-être aussi parce que des personnes "plus au courant" ne le font pas comme elles le devraient. Et je trouve ça dommage qu'un tel projet reste cloitré dans des labos de recherche, qu'ils soient industriels ou académiques. Bien à vous.

Pour ma part, je dirais que c'est un mixte des deux: les modèles sont complétement sérialisés dans des bases de données et la gestion de version est supportée depuis la version 3.0 (d'après Cédric). Il supporte effectivement le verrouillage exclusif et il est compatible avec tous les modeleurs EMF based moyennant l'application d'un genmodel spécifique.

D'après mon expérience, Topcased est moins abouti en termes d'intégration. Il évolue également beaucoup moins vite que papyrus. Je pense que c'est un problème de ressources et de financement. En effet, Papyrus a l'avantage de vivre en marge de plusieurs projets alors que Topcased était un projet à part entière financé sur fonds privés / publiques dont la date de fin est passée il y a un peu plus de un an. J'ai cru comprendre d'ailleurs qu'il y aurait une suite (Topcased 2) en cours de montage...à voir. Quoiqu'il en soit, la fusion avec Topcased n'est à ma connaissance pas pour demain. Heureusement, la plupart des briques logicielles développées pour Topcased (transformations de modèles, outils d'analyse) peuvent parfaitement être utilisées dans Papyrus. Pour ce qui est de CDO, je l'ai utilisé dans un projet d'outillage d'un méta-modèle ad-hoc pour la boîte qui m'emploie. Cela nécessite l'utilisation d'un genmodel dédié pour la génération de l'implantation du méta-modèle. Du coup, cette approche ne peut pour le moment pas être appliquée à l'implantation de UML car son genmodel ne peut-être modifié. Mais j'ai ouïe dire que le concepteur de CDO travaillait sur ce problème actuellement...à vérifier également.

Je ne connais peut-être pas assez bien SART pour répondre précisément. Je dirais que MARTE "englobe" SART dans le sens où il permet de représenter une décomposition fonctionnelle du système avec des contraintes temps-réel. MARTE est davantage basé sur la séparation des préoccupations, à savoir modélisation du système d'un côté et modélisation de la plateforme de l'autre. Ensuite, des modèles d'allocation permettent de spécifier comment le système doit être implanté. Les modèles issus des modèles d'allocation permettent de mener différents types d'analyses d'ordonnancement, de performances, etc. En plus des contraintes temps-réel, MARTE permet de spécifier toutes sortes de propriétés non-fonctionnelles (poids, consommation, encombrement, etc.) utilisées dans les scénarios d'analyse servant à valider le système. En revanche, contrairement à SART, MARTE ne spécifie aucune méthodologie de conception / analyse. Des informations détaillées peuvent être trouvées sur le site http://www.omgmarte.org/

Tout à fait. CDO est une piste à envisager dans le cadre de développements autour de EMF et GMF car il s'appuie sur la notion de modification concurrente d'objets à travers des transactions. Je m'avance peut-être un peu, mais je pense que cela peut améliorer les choses dans la mesure ou l'unité de configuration dans cette approche est l'objet alors que dans l'approche CVS l'unité de configuration est le fichier. J'ai personnellement fait des essais sur cette technologie et j'ai pu constater que cela fonctionne plutôt bien. On peut par exemple poser des verrous sur certaines parties du modèle et voir le modèle se synchroniser automatiquement quand une autre personne a fait un commit. La contre-partie est de devoir mettre en place un système de base de données, ce qui peut-être perçu comme une contrainte forte par les utilisateurs mais peut-être nécessaire pour le passage à l'échelle.

Autant pour moi. Le changement de technologie correspond effectivement un alignement avec GMF pour les représentations graphiques, Modisco pour la vue "Model" et Xtext pour la syntaxe textuelle. La question du merge avec Topcased n'est à priori plus d'actualité. Les apports de cette version par rapport à la précédente réside principalement dans la provision de nombreux points d'extension permettant de customiser les vues afin de créer des outils sur mesure pour une organisation ou un domaine particulier. En parallèle de la version release, la version en développement (0.7.1) fait l'objet de très nombreux commit pour la correction de bugs et pour l'ajout de nouvelles fonctionnalités. Les futurs développement de Papyrus ont pour objectif de fournir aux utilisateurs un moteur d'exécution de modèles UML et des outils de validation formelle. Pour ce qui est du travail collaboratif, ce n'est malheureusement pas encore à l'ordre du jour; cependant, les équipes de développement réfléchissent à l'intégration de papyrus avec Eclipse CDO pour fournir des fonctionnalités équivalentes à celles fournies par jazz de IBM.

Ouais, c'est pas mal mais je préfére MDWorkbench de Sodius qui est encore plus user-friendly, également basé sur eclipse et qui offre beaucoup de connecteurs vers d'autres outils.