EMF : Eclipse Modeling Framework

Java, Models, Patterns 10 Minutes

Introduction

Nous avions parlé des notions de modèles et de méta-modèles dans les articles sur l’IDM [1] ou sur le pattern AOM [2]. Le premier nous a permit de survoler un peu les aspects théoriques du sujet tandis que le second, nous a emmené dans ses aspects bien concrets et ses problématiques d’implémentation.

UML

Pourtant, entre ces deux extrêmes, se situe ce que les gens connaissent a priori le mieux ou du moins ce qu’ils ont le plus en tête lorsqu’on leur parle de modèle: une représentation graphique souvent en UML d’un ensemble de concepts formant ce que l’on peut appeler un DSL lorsque celui-ci a la prétention d’être un méta-modèle.

Nous avions prévu de traiter UML, un article avait un peu initier cela [3] en 2017, mais d’autres priorités sont venues se placer devant. Il est évident que bien sur UML est un langage qui se prête très bien a la modélisation, et heureusement puisque celui-ci est fait pour cela, cependant UML a ce défaut d’être très générique et couvrir essentiellement des préoccupations propres au monde du développement logiciel.

Bien sur UML est extensible, bien sur il existe des profils UML permettant de sortir de ce « carcan » mais il n’empêche que UML reste un outil pour des gens ayant la connaissance (complexe il faut aussi le noter) et la maitrise de ce langage. Et même, souvent face a cela, la modélisation des systèmes, au lieux de se voir formelle et exploiter au mieux les spécificités du langage, se voit réduite a une caricature de modélisation où se battent en duel diverses boites et flèches de façon à « singer » un diagramme de classe…

En réalité, cet état de fait, n’est pas forcement un problème tant qu’il permet aux individus d’échanger et de se comprendre sur les différents aspects ou points de vue sur le système. Cependant, cela illustre bien la limite du langage dans sa pratique qui, il faut l’avouer, si elle s’en est retrouvé réduite a cela est probablement du surtout a, certes, permettre un certain degré de communication « technique » entre les gens, mais aussi son inaptitude a rendre opérationnel les modèles créés et donc un effort moindre dans une formalisation qui serait alors inutile.

Du MDA a l’IDM

Pourtant, c’est bien ce qui nous avait été vendu avec le MDA [4]. La convergence des modèles spécifiques a la plateformes (PSM) et ceux indépendants de celle ci (PIM), devait nous permettre la fameuse générations de code qui nous épargnerait des heures d’écritures sur des aspects non fondamentaux du système tant que les modèles (UML?) seront correctement décrit est raffinés. Pourtant, dans la pratique, si le MDA fourni un cadre de réflexion pour penser les modèles, les rendre opérationnels est une taches vraiment ardues.

Le MDA a été abandonné au profit de l’IDM ou MDE, afin d’offrir un cadre d’une part plus générique a la mise en œuvre de processus utilisant des modèles (ce qui, accessoirement, a été le cœur de ma thèse) mais aussi d’autre part, des moyens et outils permettant de faciliter cette opérationnalisation.

Nous aborderons le premier point dans un autre article, nous allons plutôt nous concentrer sur le second, la mise a disposition d’outils permettant justement cette opérationnalisation et entre autre comme l’indique le titre: EMF [5] et GMF [6], les deux faisant partis du projet Eclipse Modeling [7] qu’il faudra compléter avec l’éditeur GMF [8] (ajouter l’outil via l’url [8] dans « Help > Install new software »)

EMF

EMF ou Eclipse Modeling Framework est comme son nom l’indique un framework de modélisation. Bon ok…. C’est bien sur plus que ça! Bien sur Eclipse a perdu en vitesse ces dernières années surtout face a IntelliJ qui se veut un outil plus efficace et opérationnel pour le monde pro mais ca serait oublié les années d’avancées technologiques que la plateforme Eclipse a permit de faire. Grace a son framework basé sur OSGI (oui je sais je kiffe OSGI), Eclipse est un formidable bac a sable pour construire des applications diverses et variées [9]. Et bien si OSGI est le moteur d’exécution de Eclipse, EMF en est son cœur ou plutôt son modèle ou devrais je dire même son DSL.

Cela en fait donc une plateforme de prototypage idéal moyennant l’effort de rentrer dedans et de comprendre EMF.

Heureusement même sans connaitre vraiment EMF, on peut quand même jouer avec, car l’outil intégrer en son sein un outil de modélisation compatible avec lui-même: le langage Ecore.

Encore un langage? Oui mais celui ci est simple et dérivé pour l’essentiel de ce qui se fait dans UML. Sauf qu’il a l’intérêt de fournir une implémentation qui va nous servir de M3 comme nous en avions parlé dans l’article [14].

Avec EMF on va donc disposer d’un langage de niveau M3 permettant de mettre en œuvre des DSL au travers de modèles de niveau M2. Ces DSL pourront alors être employés pour construire nos modèles qui représenteront les systèmes étudiés.

Je n’aborderai pas ici la question des transformations de modèles qui sera le sujet d’un autre article mais sachez qu’en définissant des fonctions entre les éléments des méta-modèles, il est possible d’appliquer ces fonctions sur les modèles afin de les traduire dans les différents contextes de modélisations que sont les méta-modèles. Pour ce faire on utilisera aussi un DSL de transformation comme ATL (transformation de modèle a modèle) ou Xtext (transformation de modèle a représentation textuelle)

Le hic dans cette histoire c’est que si EMF est un framework outillé d’une syntaxe graphique pour la modélisation de nos méta-modèles, ces méta-modèles ne sont pas en soit exploitable et ne sont que des représentations du DSL que l’on souhaite obtenir.

Face a cela, du coup, soit on implémente soit même au travers d’un outil le DSL (comme avec le pattern AOM) soit on exploite les outils Eclipse qui permettent d’en générer une implémentation compatible avec Eclipse lui même.

Exemple

Pour illustrer cela, on va prendre un exemple en reprenant un cas simple les automates a état finis. Mais avant on récupère Eclipse Modeling [7] comme cité plus haut et on se construit un projet Ecore Modeling Project nommé FSM (oui FSM car les FSM c’est bien). On obtient:

La on a un éditeur graphique pour composer notre modèle de FSM, on va donc le faire:

Une fois cela fait, il nous reste plus qu’a générer les outils et plugin qui permettront a éclipse de déployer ce méta-modèle comme d’un outil au sein d’éclipse pour produire des FSM [10]. Pour cela, on ouvre le fichier genmodel et on click droit sur la racine du document xml > on choisit Generate All. Différents projets vont alors être ajoutés au workspace.

Ces projets, nommés edit et editor, ne sont rien de moins que des plugins OSGI eclipse pouvant être intégrés dans un Eclipse RCP (une plateforme Eclipse vierge). De même, ça vous l’avez peut être pas vu mais des sources ont été ajoutées dans notre projet. Ces sources sont une implémentation de notre méta-modèle afin de pouvoir créer des modèles via les deux autres projets. Mais trêve de bavardage, testons cela!

Pour tester notre méta-modèle, comme eclipse s’est charger de générer le plus gros des plugins, il nous reste qu’a lancer celui ci dans un Eclipse Application. Cela va lancer un nouvel eclipse dans un autre workspace mais avec notre plugin dedans. En tout logique, on va donc se créer un projet vierge et créer un fichier du type de notre modèle:

Notre projet ressemble alors a ceci:

enfin si on ouvre le fichier alors on est face a un fichier xml pour lequel l’éditeur permet de construire des éléments de modèles conforment a notre méta-modèle des FSM:

Les éléments étant ici a plat car nous n’avons pas défini de structure englobante pour nos différents types d’objets.

Bon pour certain, ça va manquer un peu de substance tout ça, car on veut faire des automates pas de l’XML.

Et bien c’est la que va intervenir GMF [6] en nous fournissant le moyen de définir un modèle de représentation comme nous en avions parlé dans [15].

GMF

GMF ou Graphical Modeling Framework est comme son nom l’indique un framework de modélisation graphique. Youhou! Cet outil, directement intégré a Eclipse, permet la définition d’interface graphique pour Eclipse. Ainsi grâce a celui ci, il va être possible de définir un modèle de représentation que l’on pourra mapper sur les concepts du méta-modèle et ainsi lui donner une représentation graphique.

Nous n’allons pas rentrer dans le détails technique et plutôt poursuivre notre exemple des FSM.

Exemple

Tout d’abord nous allons activer le dashboard GMF qui va nous permettre de mettre en œuvre le processus de déclaration des éléments du modèle de représentation, celui des éléments de la palette graphique ainsi que les éléments de mapping entre les concepts du méta-modèle des FSM et les éléments du modèle de représentation que nous venons de décrire.

Pour activer le dashboard, il faut aller dans le menu Winndow>Show View et choisir « GMF Dashboard ». Cela va ouvrir un onglet du type:

Dans cet onglet, on va retrouver un wizard pour construire les différents éléments de notre modèle. On y retrouve notre modèle de domaine que nous venions de faire en Ecore ainsi que le Genmodel qui nous avait servi a generer les projets « edit », « editor » et « tests ».

Les éléments qui nous manques sont des éléments qui derivent du modèle Ecore (au dessous et dessous).

Au dessus donc on va définir les éléments graphiques permettant la représentation. On lance le wizard en cliquant sur Derive. On choisi le nom de notre fichier et le root élément (dans notre cas FSM) et on finalise en sélectionnant les éléments qui doivent être représentés par des Entités, par des relations ou par des attributs.

On valide et on obtient un fichier xml gmfgraph.

On fait de même pour définir la palette de l’éditeur graphique en cliquant sur Derive mais en dessous du modèle de domaine.

Et la même combat on obtient alors un modèle xml gmftools représentant les éléments de la palette.

Enfin dernière étape, il reste le mapping a définir avant de pouvoir générer l’éditeur graphique. Pour le mapping, même démarche, on clic sur combine pour lancer le wizard. On valide les différents modèles que nous venons de déclaré et nous arrivons finalement sur une interface de configuration des nœuds et des relations du modèle:

Par défaut, le wizard propose de définir comme des nœuds les classes du modèle du domaine et d’utiliser les relations de la classe que nous avions sélectionnée comme relation pour construire les relations. Ce n’est pas cela que l’on veut sauf si nous avez gardé tous les précédents wizards avec les valeurs par défaut.

Donc nous allons un peu changer cela de manière a déclarer les Event et les States comme des nœuds et utiliser la classe Transition comme Links

et en cliquant sur Change on va pouvoir affiner le mapping entre modèle du domaine, palette et représentation.

Voila le modèle est prêt, il reste a générer le projet « diagramme » en cliquant sur Transform puis sur « generate diagram editor ».

Il nous reste donc plus qu’a lancer l’application comme nous l’avions déjà fait précédemment dans un Eclipse Application.

La on retrouve notre modèle de tout a l’heure. Du coup deux choix s’offre a nous soit on génère un graphique a partir du modèle existant en faisant un clique droit sur le fichier et en choisissant « Initialize fsm_diagram » nous fournissant (après re-agencement des éléments):

Soit on crée un nouveau modèle en créant un diagramme FSM en allant dans New>Example>FSM Diagram. La on retrouve notre palette que nous avions déclaré

qui va nous permettre de définir notre FSM

Bon on identifie assez vite certaines limites a l’exercice, ici pas de flèches ni l’identification de l’événement sur les transitions. Mais pour la défense de l’outil, il faut garder a l’esprit, qu’ici, nous n’avons rien coder du tout.

En effet tout a été généré sous la forme de projet java plugin pour eclipse, que ce soit pour notre modèle ou les éditeurs. Ainsi rien n’empêche, une fois un modèle de poser d’aller affiner l’implémentation des plugins afin que l’outil de modélisation convienne mieux aux usages du domaine.

Enfin dernier point non traité ici et qui restera a la charge du développeur, concerne la définition et l’implémentation de la sémantique opérationnelle des modèles ou comment ceux ci doivent fonctionner.

La question de la sémantique opérationnelle des modèle étant un sujet en soit qui recoupe a la fois syntaxe abstraite/concrète mais aussi transformation de modèle, nous reviendrons sur ce point dans un article dédié.

Références

Publié par Thomas Collonvillé

Publié

Laisser un commentaire