Tags

, , , , , ,

Je viens de découvrir Actifsource, un environnement commercial de modélisation et de génération de code. Les captures d’écran sur le site de l’outil ont immédiatement attiré mon attention car elles montrent l’éditeur positionné sur un template de génération de code Java avec coloration syntaxique des mots clefs du langage !

Hors, le saint graal de la génération de code, du point de vue de l’auteur de templates, c’est justement de pouvoir éditer un template de génération de code de la même manière qu’il écrirait le code avec son éditeur moderne favori (le JDT par exemple). Avec un éditeur de template traditionnel moderne comme Acceleo, on bénéficie de la complétion des éléments du méta-modèle d’entrée mais les mots clefs du langage cible sont de simples caractères ASCII, ce ne sont pas des éléments de modèle reconnus par l’éditeur.

J’ai donc suivi le tutorial de création d’un service simple. Le premier point remarquable est que l’environnement permet d’éditer le méta-modèle ET le modèle dans le même diagramme:

actifsource-modeling

Cette possibilité offre une grande souplesse, cela permet d’instancier le modèle et de vérifier le méta-modèle au fur et à mesure que le méta-modèle est conçu.

Par contre, comme EMF (le framework de méta-modélisation de prédilection de l’écosystème Eclipse Modeling) ne permet pas de travailler simultanément au niveau méta-modèle et modèle, j’ai tout de suite eu la grande crainte que ce produit n’utilise pas EMF. C’est malheureusement le cas: les modèles ne sont pas basés sur EMF. C’est un gros problème pour l’interopérabilité de cet environnement avec le reste des outils de l’écosytème Eclipse Modeling. En voici la preuve :

actifsource-features

Passons là dessus pour le moment, et voyons le plus intéressant: l’éditeur de templates. Le test apporte la confirmation tant attendue: l’éditeur fourni bien la coloration syntaxique du langage cible, ici Java, en rouge:

actifsource-syntaxhighlighting

Les éléments du méta-modèle d’entrée apparaissent soulignés en bleu. Tout le reste appartient à la syntaxe du langage cible, ici Java.

Malheureusement, en ce qui concerne le support du langage cible, l’outillage s’arrête là. Il n’y a pas de complétion de code Java. Cela fera peut-être l’objet d’une évolution future.

actifsource-javacompletion1

Par contre, il y a bien la complétion du modèle d’entrée, pas d’inquiétude de ce coté là.

L’absence de complétion de code peut s’expliquer par le fait que les parties du template qui sont conformes à la syntaxe cible ne sont pas interprétées comme un modèle à part entière. Voici le template ouvert avec l’éditeur de modèle Actifsource. Les apparences sont trompeuses: le code source cible est stocké en texte plein, et non sous forme de modèle:

actifsource-template-model

Le code “public class” (en rouge) est hélas considéré comme une simple chaîne de caractères. La coloration syntaxique semble se baser uniquement sur des informations lexicales de la syntaxe du langage cible et ne semble pas aller plus loin. C’est dommage, pendant un moment, j’ai cru qu’Actifsource ne se contentait pas de faire de la “simple” génération de texte et qu’il passait par une représentation intermédiaire propre au langage cible, à savoir, un PSM.

Parenthèse: Cette approche hybride aurait un potentiel très intéressant car tout en permettant de créer facilement des templates de génération de code, elle permettrait de considérer le code généré comme un modèle qui pourrait ensuite subir de nouvelles manipulations. Cela pourrait être utilisé, par exemple, pour ajouter des annotations JDK5 JPA par dessus des POJOs générés par ailleurs. Ce qui permet de séparer les templates de génération des POJOs de la problématique de génération des annotations JPA. Ces mêmes templates pourraient également être réutilisés pour générer des mappings au format HBM XML par exemple. Dommage, j’attends toujours une solution de transformation modèle à modèle qui utilise une syntaxe textuelle propre au langage cible pour écrire les templates.

Un point très positif est que la génération de code se déclenche en temps réel dès que le méta-modèle, le modèle ou le template est modifié. C’est très pratique au quotidien. C’est sans doute de cette fonctionnalité remarquable que l’environnement tire sans nom: Actifsource.

Un autre point essentiel est que l’environnement supporte le refactoring “rename” sur les éléments du modèle et du méta-modèle ! Je suis un maniaque du refactoring automatisé, c’est selon moi une fonctionnalité essentielle en ingénierie logicielle. C’est donc un point très positif, à fortiori car on trouve très rarement cette fonctionnalité dans les environnements MDSD.

En conclusion, cet environnement permet d’unifier et de fluidifier tout le processus de modélisation et de génération de code et brille par sa simplicité et son efficacité. Par contre, l’environnement semble complètement fermé et n’offre pas d’interopérabilité avec le reste de l’écosystème Eclipse Modeling basé sur EMF, ce qui est selon moi une sérieuse erreur stratégique pour un environnement de génération de code pourtant basé sur la plateforme Eclipse.

L’écosystème Eclipse est selon moi aujourd’hui incontournable dans le monde du Model-Driven et de la génération de code. Ce produit ne pourra donc attirer que les utilisateurs intéressés uniquement par la génération de code comme une fin en soit et ne s’inscrivant pas dans une démarche plus globale d’ingénierie des modèles. De plus, ce produit étant commercial et le format de stockage des modèles et templates étant opaques, les utilisateurs devront se poser la question d’investir dans des modèles et templates qu’ils auront des difficultés à migrer par la suite.

Edit: Je n’ai pas encore testé mais il semblerait qu’Actifsource supporte l’import/export de modèles EMF Ecore à partir de la version 4.2.0.

Advertisements