Cédric: Je m'appelle Cédric Brun, je suis le directeur technique de la société Obeo que j'ai rejoint à peu près au début de la société, j'ai participé à de nombreux développements produits de l'entreprise et très vite on a investi dans la communauté Eclipse et dans les développements en Open Source, dans la création de produits en Open Source, donc j'ai pu participer à un certain nombre de ces projets. Par exemple EMF Compare, Acceleo, ATL ou Amalgamation par exemple.
Cédric: Eclipse Modeling, c'est ce qu'on appelle dans le jargon Eclipse un top level project (projet de plus haut niveau). C'est une section qui regroupe un certain nombre de projets au sein de la fondation Eclipse et ces projets ont pour particularité de cibler des technologies de modélisation. Soit pour permettre aux utilisateurs de faire leur propre technologie de modélisation dédiée soit d'utiliser directement ces technologies pour faire par exemple de la modélisation UML), entre autres.
Cédric: Effectivement, c'est là où la plus value commence à apparaître vraiment par l'utilisation des technologies de modélisation. Donc DSL ou DSM pour Domain Specific Modeling ou Domain Specific Model. Donc qui consiste en la définition d'un formalisme dédié à un domaine ou à une problématique ou à un ensemble de tâches, afin d'avoir une définition la plus précise possible pour analyser ou tout simplement capturer des informations. On a une représentation dédiée de la sémantique d'un domaine particulier.
Cédric: Voilà, en général, on va distinguer à la fois le coté conceptuel, c'est à dire comment les concepts s'enchaînent, comment les concepts sont liés entre eux, quelles informations on va mettre sur chaque concept. Par exemple, on va retrouver la notion de modèle métier, tout simplement, on parle d'une personne ou d'un acteur qui peut avoir un nom, qui peut avoir une référence vers un projet. Voilà pour la partie conceptuelle et après on utilise différents types de notations pour représenter ces concepts. Des notations soit graphiques, qu'on connaît par exemple dans les modeleurs UML, donc des diagrammes, qui peuvent ressembler ou pas à de l'UML. Ou des notations plutôt textuelles qui vont correspondre, ressembler à des langages de programmation qu'on utilise en général.
Cédric: Ca peut être une boite, ça peut être un dessin, en fait, techniquement, nous on fait des technologies qui permettent de faire des arbres, de faire des tables. Il y a différents types de notations ou de représentations qui sont plus ou moins pratiques en fonction de ce qu'on cherche à faire avec un modèle.
6. InfoQ: D'où le côté spécifique
Cédric: D'où le côté spécifique et le côté, toujours positionner le modèle par rapport à un objectif, c'est à dire, qu'est ce qu'on cherche à faire, à quelle question on veut répondre avec ce modèle.
Cédric: Donc, EMF c'est un petit peu au centre de tout, c'est le langage qui nous permet de définir ces différents concepts. C'est cette brique logicielle qui a été développée par IBM à l'origine qui fonde toute la façon de décrire les concepts et du coup d'exploiter les instances (des modèles). Pourquoi c'est très important, d'abord cette brique commune fait que différents outils et différents frameworks qui existent dans Eclipse Modeling peuvent interopérer et utilisent les mêmes pratiques, peuvent échanger les données, peuvent s'intégrer beaucoup mieux. Donc EMF, c'est une petite brique sur laquelle beaucoup d'autres choses se sont greffées et qui se sont regroupées dans Eclipse Modeling. EMF a pris une telle importance que dans Eclipse 4, EMF est utilisée au plus bas de la plateforme pour stocker le modèle de workbench, l'atelier Eclipse, pour avoir un modèle et un mode d'accès à ce modèle unifié.
Cédric: Le projet Sirius permet, en ayant défini son formalisme, derrière, de définir un ensemble d'éditeurs et de représentations dédiées. Autrement dit, on a ce côté conceptuel, avec des instances qui peuvent se référencer les unes les autres, et des attributs. En fonction des différentes tâches, des différentes problématiques qu'on a, on veut pouvoir les représenter de manière différente, dans des éditeurs, qui eux aussi peuvent être dédiés. Avec des interactions différentes en fonction du contexte. Est-ce que là je m'attache à définir les aspects sécurités d'un système, est-ce que je m'attache à décrire les échanges entre les systèmes, la volumétrie entre ces échanges. Avec Sirius, on peut définir tout un ensemble d'éditeurs qui vont supporter ces différentes tâches et on peut les définir de manière très rapide.
10. InfoQ: D'accord et quels types de représentations graphiques va-t-on pouvoir obtenir avec Sirius ?
Cédric: Principalement, les utilisateurs de Sirius se tournent vers les diagrammes. On peut définir tout un ensemble de diagrammes, c'est très flexible, on peut définir les différentes couleurs, les différentes formes, est-ce qu'il y a des conteneurs, des listes, des liens entre les éléments. Donc on va pouvoir définir pour une problématique donnée un éditeur qui va exploiter ces différentes formes, et surtout qui va derrière les montrer en gardant la cohérence avec le modèle. On va pouvoir voir dans l'éditeur les informations qui viennent du modèle et tout ça est gardé en cohérence en permanence. Maintenant, Sirius est extensible. On fournit aussi des arbres de base, des éditeurs arborescents et des tables qui sont elles aussi très pratiques pour gérer des masses de données plus importantes. Mais c'est extensible et d'autres types de représentations sont possibles.
Cédric: Tout à fait, donc par exemple, on va modifier dans une table une information, on va mettre une classe qui va devenir abstraite, et le diagramme à coté va lui aussi changer sa représentation, changer la couleur ou changer la forme de la classe qui correspond.
Cédric: Alors tu va pouvoir le faire avec Sirius + EMF, c'est à dire que tu vas commencer par définir ton domaine, ton modèle, c'est à dire tes serveurs et les différentes relations que tu peux avoir et que tu veux garder sur tes serveurs, et derrière avec Sirius, même sans connaître la plateforme Eclipse, sans connaître toutes les technos qu'il y a autour d'Eclipse Modeling, principalement en connaissant ton modèle métier que tu aura défini auparavant, définir un modeleur qui va te représenter ces informations. C'est tout à fait possible. On a largement baissé le coup d'apprentissage des différentes technologies pour faire cela. Pour autant, on n’interdit pas aux power users de le faire. Quelqu'un qui connait bien la plateforme Eclipse peut aussi contribuer du code, des actions spécifiques. On respecte complètement la philosophie d'Eclipse là dessus. Mais on a des utilisateurs qui ont des compétences assez légères en Java et par contre assez fortes d'un point de vue métier qui sont capables de faire des modeleurs eux-mêmes.
Cédric: Une fois que le modèle Ecore et la correspondance avec l'outillage a été faite, l'utilisateur peut directement créer ses instances et les éditer.
14. InfoQ: Tu as mentionné Ecore, peux-tu brièvement dire ce que c'est ?
Cédric: Ecore c'est le langage dans EMF qui permet de définir ces concepts et les relations entre ces concepts. De manière très simple, c'est un langage qui permet de faire l'équivalent d'un diagramme de classe un petit peu enrichi.
Cédric: En fait, on parle de GMF de manière générale, mais il faut savoir qu'il y a deux sous projets dans GMF, une partie runtime qui en fait exploite d'autres technologies Eclipse et permet de construire des modeleurs en écrivant du code Java, de manière plus efficace en offrant tout un tas de services de base comme l'impression, l'arrangement automatique. Donc Sirius utilise GMF Runtime par exemple. Et il y a le projet GMF Tooling, qui permet assez facilement depuis un modèle Ecore de générer un éditeur, donc de générer le code Java qui va correspondre à un éditeur. Un peu à la façon de Sirius. Là où Sirius et GMF Tools se démarquent, déjà Sirius ne passe pas par une phase de génération. L'utilisateur décrit tout simplement son outillage et le runtime va interpréter cette description et l'utilisateur peut directement s'en servir sans passer par une phase de génération. Ca simplifie grandement les choses car la phase de génération nécessite qu'on demande à l'utilisateur de gérer l'étape de compilation, le déploiement, pour pouvoir vraiment tester son modeleur. L'autre changement majeur par rapport à GMF Tools, c'est que le langage qui permet de définir des diagrammes dans Sirius est beaucoup plus flexible. En fait, au départ, on a construit Sirius largement sur notre expérience avec GMF Tools et notre expérience était que souvent il y a des modèles métiers (existants) pour les clients et la structure des modèles pour GMF doit être tweekée pour que GMF puisse vraiment afficher les éléments correctement. Ce qui pose beaucoup de problèmes. C'est à dire que du coup, on est en train de changer les concepts pour qu'ils s'adaptent à l'outil. Avec Sirius, on a fait en sorte d'avoir un maximum de flexibilité. Ce qui fait que Sirius peut afficher n'importe quel type de modèle, de n'importe quelle façon, sans avoir à changer le modèle conceptuel.
Cédric: Graphiti est une technologie plus récente que GMF Runtime mais qui est vraiment au même niveau. C'est une API Java qui permet de faire des modeleurs de façon plus efficace. N'empêche que c'est une API Java qui nécessite de développer pas mal de choses avant d'avoir un modeleur, au même titre que GMF Runtime. Graphiti pourrait être un framework utilisé par Sirius. A l'heure actuelle, nous utilisons le runtime GMF, il remplit bien son rôle. On est satisfait donc on ne voit pas de raison de changer. Mais Graphiti pourrait tout à fait être un candidat. Pour l'utilisateur final de Graphiti, ça ne changerait pas grand-chose. Au final, il définit son modeleur, il obtient un modeleur graphique et quelques soit la technologie en dessous. Avec Graphiti et GMF Runtime, on est vraiment à un niveau plus bas. Sirius est en fait une abstraction de ça.
Cédric: C'est complètement complémentaire. En fait, Xtext permet de définir une syntaxe textuelle pour les modèles (EMF) et comme Sirius utilise EMF, les deux fonctionnent assez bien ensemble. Ca permet d'avoir un éditeur dédié, textuel avec de la complétion, de la couleur, et en même temps, des diagrammes, qui représentent les mêmes informations avec un point de vue différent et de pouvoir éditer les deux de manière concurrente. Donc, ça permet de choisir le meilleur type d'éditeur en fonction de la problématique. Pour certains langages, pour certains DSM, il est beaucoup plus adéquat d'avoir une syntaxe textuelle, quand on commence à définir de la logique opérationnelle par exemple ou quelque chose avec des séquences, on a l'habitude de les définir avec des syntaxes textuelles et c'est beaucoup plus lisible ainsi. Donc, ça permet vraiment d'avoir le choix entre les deux, en fonction de ce qu'on cherche à faire.
18. InfoQ: Pour le moment, Sirius est à l'état de proposition si j'ai bien compris. Ca signifie quoi ?
Cédric: On rentre dans le monde des processus Eclipse. Quand on veut créer un projet dans Eclipse, ça passe par une phase de proposition ou proposal. Cette phase consiste à définir le périmètre du projet, donc le scope, et à trouver ou à identifier les personnes intéressées pour travailler au sein de ce projet. Pour venir et participer à ce projet. Donc, on a fait une proposition pour Sirius qu'on a présenté à la communauté et qui est restée quelques semaines en attente de réactions de la communauté, pour savoir, au regard du projet proposé, Sirius, de son périmètre, qui est intéressé, est-ce que quelqu'un a un problème avec ça. Avec la par exemple la relation entre Sirius et GMF ou Graphiti que l'on documente dans cette proposition. Et les gens derrière, dans la communauté Eclipse, on réagit sur les forums. Et je dois avouer que les réactions étaient plutôt positives.
Cédric: Effectivement, Sirius ne vient pas de nulle part, en fait, c'est une brique, une technologie qu'on développe depuis 5 ans. Tout a démarré effectivement avec Thalès qui avait un besoin, Thalès qui voulait pousser les ingénieries de spécialité à utiliser des outils de modélisation, donc tout ce qui est ingénierie système, de leur faire utiliser des outils de modélisation car Thalès voyait une plus value importante à leur faire utiliser les outils de modélisation. Pour faire de l'analyse multi critères, pour faire tout le travail d'ingénierie chez Thalès. Il se trouve que pour faire ça, la meilleure façon, pour Thalès, était d'avoir un modèle spécifique. On retombe sur ce dont je parlais au débit, la notion de précision de ce qu'on veut capturer comme information, de ce qu'on veut en ressortir. Donc Thalès a fait le choix des modèles spécifiques assez tôt. Et donc se pose après la question du fait qu'il faut bien des outils pour pouvoir éditer ces modèles spécifiques, donc comment faire pour que définir ces outils, ce soit peu couteux et assez flexible pour qu'éventuellement, des business units au sein de Thalès puisse le faire elles-mêmes ou adapter les outils elles-mêmes. Donc on a commencé à travailler avec Thalès et ils nous ont soumis d'abord un périmètre plus petit que ça bien sûr, plus autour de l'analyse multi critères. On a commencé à répondre à leur besoin avec des prototypes et assez vite, les prototypes se sont montrés assez convaincants pour que la volonté de Thalès soit beaucoup plus forte et pour Obeo derrière assez convaincant pour qu'on se dise qu'on a quelque chose avec lequel on peut faire un produit. Et donc c'est apparu dans Obeo Designer.
Cédric: Oui j'étais dès le départ à récolter le besoin de Thalès, à concevoir la technologie, à concevoir les premiers prototypes. D'ailleurs, la première version, la première livraison, était très bien pour faire de la visualisation, mais on se disait que jamais on ne pourrait faire de l'édition. On en est bien loin maintenant.
Cédric: Donc, effectivement, c'est une base de code assez large sur laquelle on développe depuis un moment, et sur laquelle on développe encore à l'heure actuelle. C'est un des aspects forts de la proposition qu'on fait à la fondation Eclipse. Sirius représente à peu près 10 personnes à temps plein, qui travaillent dessus en permanence. Donc les difficultés dernières sont en fait assez limitées pour nous, on travaille déjà beaucoup avec Eclipse, on a intégré à peu près tous les process Eclipse dans nos méthodes de développement et on était déjà dans un processus où toutes les dépendances étaient déjà très contrôlées et très limitées. Donc le travail de préparation de la soumission de code qui consiste principalement à vérifier les copyrights, les dépendances, pour pouvoir donner ça à l'équipe IP (Propriété Intellectuelle) d'Eclipse, c'est quelque chose que nous on faisait au fur et à mesure. Je dis pas qu'il n'y a pas de travail, on fait le travail de repasser sur tous les fichiers pour vraiment s'assurer que vraiment tout est correct mais c'est finalement assez peu. Donc, on est dans ce processus là. D'ici quelques jours, normalement la semaine prochaine, le premier lot sera prêt pour qu'on l'envoie à l'équipe IP de la fondation Eclipse. L'équipe IP va réceptionner ce code, vérifier effectivement que les dépendances que l'on annonce sont bien celles dans les faits dans le code, que les copyrights sont correctement mis et qu'il n'y a pas de problèmes de brevets ou de plagiats dans le code qu'on fournit. C'est un processus qui peut prendre un certain temps, voir un temps certain, on a pas beaucoup de visibilité là dessus. On suppose, on espère, après avoir échangé avec la fondation Eclipse, avoir vérifié tout le code et intégré le code sur le repository GIT d'ici à la fin de l'été. Derrière, nous, on est aussi pas mal habitués à l'infrastructure Eclipse donc on espère avoir nos premiers builds qui tournent en septembre et la première release pour EclipseCON Europe, donc, autour de novembre.
Cédric: In fine, on veut effectivement que Sirius soit adopté et pour qu'il soit adopté au sein d'autres projets Eclipse, il faut qu'il sorte assez vite d'incubation, il faut qu'il soit dans le release train donc on cherche à atteindre un niveau de release très vite pour pouvoir faire partie du release train, donc de la prochaine release qui est Eclipse Luna. Ca devrait pas poser de problème à proprement parler au sens où les APIs existent déjà depuis longtemps. C'est quelque chose qu'on distribue via Obeo Designer depuis un moment, c'est quelque chose qui est largement déployé chez des clients d'Obeo et chez Thalès sur des projets assez critiques. Donc, c'est quelque chose qui est déjà assez mature donc le coté API, sortie d'incubation et rejoindre le release train rapidement devrait pas poser de problème. Après il y a un autre aspect, sur la bonne connaissance des commiteurs d'un projet de tous les process Eclipse. Je parlais de l'IP tout à l'heure mais il y aussi toutes les informations qu'on doit fournir pour faire une release par exemple et là encore, on participe largement à Eclipse depuis des années donc on est rodés à tout ça. Ca devrait bien se passer, il n'empêche qu'on va être un peu dépendant du travail qui est fait par l'équipe IP, donc on essaie que ça se passe le plus tranquillement possible.
Cédric: Bien sûr, il y a effectivement ce qu'on appelle maintenant Sirius qui existe dans Obeo Designer et qui est disponible. On peut se rendre sur le site Obeo Designer et tout simplement acheter le produit et on a accès à Sirius en avant première je dirais. On va prévoir des chemins pour migrer ensuite de cette version vers la nouvelle version de Sirius. Obeo Designer reste, et restera un produit commercial. Et Obeo Designer va dès que possible remplacer sa version actuelle de Sirius par la version qui vient d'Eclipse et puis il y a la version d'évaluation, pour ceux qui souhaiteraient avoir un aperçu de ce à quoi ça ressemble.
/filters:no_upscale()/sponsorship/topic/15eb7fc8-c345-4739-bb9b-7a19e0814106/JavaDay-1652355094338.png)
Commentaires de la Communauté