Markus Völter, un des auteurs de "Model-Driven Software Development", a publié un nouveau livre dans le domaine du Model-Driven Software Design (MDSD). "DSL Engineering" se concentre sur la conception et l'implémentation de domain specific languages (DSL).
Un DSL est un langage au vocabulaire optimisé pour décrire de façon efficiente les problèmes et solutions d'un domaine donné. En contraste, les general purpose languages (GPL) comme Java pourront peut-être décrire les mêmes problèmes et solutions, mais ils nécessitent typiquement des programmes plus verbeux, sont difficile à analyser par les outils et difficiles à comprendre pour les experts du domaine.
Par conséquent, les DSL bien conçus sont utilisable par des non-programmeurs pour définir de façon formelle les modèles liés au métier. Habituellement, ces modèles sont ensuite transformés en artefacts comme par exemple du code source plus général (GPL) ou des documents.
InfoQ a eu la chance de pouvoir rencontrer Markus Völter, l'auteur principal du livre, et Christrian Dietrich, l'un des coauteurs:
InfoQ: Pourriez-vous s'il vous plait décrire votre expérience dans le champ des DSL ?
Markus Völter: J'ai travaillé avec les modèles et la génération de code depuis environ dix ans maintenant. J'ai démarré avec des langages et générateurs basés sur UML, mais j'ai rapidement changé de camp pour celui des DSL. En particulier lorsqu'on travaille avec des ateliers de conception de langages modernes, l'approche DSL est tellement plus puissante et productive qu'UML.
Dans tous les cas, j'ai passé ces dix dernières années à construire des langages, des analyseurs et des générateurs par moi-même, et à aider des clients à faire de même. Comme projets on trouve par exemple le POC (proof of concept) du standard AUTOSTAR, plusieurs DSL pour la définition d'architecture, des DSL pour configurer des prothèses auditives ou des réfrigérateurs, mais aussi des DSL qui sont utilisés dans les métiers d'assurance et dans l'ingénierie des spécifications. En termes d'outillage, j'ai principalement travaillé avec ce bon vieil openArchitectureWare, Eclipse EMF/GMF/Xtext et plus récemment, JetBrains MPS. Ces deux dernières années, j'ai passé la plupart de mon temps à développer le système mbeddr, qui est un environnement de développement de DSL basé sur JetBrains MPS pour logiciel embarqué.
Christian Dietrich: Je travaille sur des projets de modélisation depuis plus de six ans. Mon premier contact avec le MDSD était lors d'un projet avec de l'UML et un gros générateur de code propriétaire. Depuis, j'ai beaucoup utilisé openArchitectureWare avec des modèles aussi bien basés sur UML qu'EMF. En 2008 j'ai découvert oAW Xtext et j'étais super excité: créer des langages textuels avec un outillage raisonnable était devenu tellement simple comparé à l'époque de lex, yacc ou antlr. J'ai commencé à creuser le framework et depuis qu'il est passé chez Eclipse je l'ai beaucoup utilisé — pour mon travail, mais aussi en participant au forum XText d'Eclipse sur mon temps libre. J'ai travaillé avec d'autres technologies dans le domaine du MDSD et des DSL comme MPS par exemple mais je me suis concentré sur Xtext.
InfoQ: Votre livre couvre le cycle complet de conception, implémentation et application d'un domain specific language. Dans quel cadre l'utilisation de DSL ou de model driven software development (MDSD) s'applique le mieux ?
Markus: Je ne pense pas qu'il y ait un cadre en particulier, c'est pourquoi le livre a six champs d'application différents dans la quatrième partie. Ces champs incluent les spécifications, l'architecture logicielle, les logiques applicatives très spécifiques, l'implémentation logicielle, l'utilisation de DSL en tant qu'utilitaire pour développeur et l'utilisation dans le contexte d'une gamme de produits logiciels. J'ai vu de très bonnes utilisations de DSL dans chacun de ces champs d'application. Voici quelques indicateurs qui déterminent probablement si l'utilisation d'un DSL dans n'importe lequel de ces champs sera couronnée de succès — en plus d'avoir des développeurs compétents bien entendu: il faut vraiment comprendre le domaine pour lequel on construit le DSL, ou au moins avoir les moyens de forger cette compréhension de manière itérative. Aussi, le domaine a besoin de suffisamment d'abstractions ou notations spécifiques pour garantir la construction d'un DSL plutôt que d'utiliser un GPL avec une bibliothèque ou un framework. Une autre bonne raison pour utiliser un DSL est le besoin de pouvoir faire des analyses avancées, lesquelles nécessiteraient une sémantique statique (i.e. au moment de la compilation) au niveau du domaine. Une autre bonne raison est la volonté d'avoir des non-programmeurs qui développeraient des applications du domaine — remarquez comme je n'utilise pas le mot "programme" ici — qui nécessite typiquement de supprimer tout le bruit induit par un GPL dans le code. Enfin, plus vous utiliserez souvent un DSL pour construire des systèmes, plus l'effort nécessaire à la création du DSL diminuera (c'est ici que les ateliers de conception de langages entrent en jeu), et plus il sera facile de justifier le développement d'un DSL.
InfoQ: D'un autre côté, pourrais-tu aussi donner quelques indices sur quand ne pas utiliser ces techniques ?
Markus: Eh bien, lorsque les critères que j'ai décrit plus hauts ne sont pas remplis :-) Plus sérieusement, il y a un dicton qui veut qu'un DSL utile finira inévitablement par ressembler à un GPL. Mon expérience me dit que ce n'est pas vrai, mais, bien sûr, il y a toujours un risque de démarrer le développement d'un DSL alors qu'on ne comprend pas vraiment le DSL. Le DSL sera bien, déclaratif et simple, jusqu'à ce qu'on comprenne vraiment le domaine. A ce moment, on est tenté d'ajouter des boucles, des conditions et tous les autres trucs qu'on trouve dans les GPL. C'est en effet un risque. Les langages modulaires et les extensions de langages peuvent remédier à ce risque un petit peu: au lieu de développer un DSL complètement séparé, on peut envisager d'étendre progressivement un langage de base comme Java ou le C avec des concepts spécifiques au domaine. Les utilisateurs peuvent toujours se redescendre au niveau du Java ou du C, pas besoin de fournir dans le DSL les concepts nécessaires à tous les cas particuliers du domaine. Certains des ateliers de conception de langages actuels (WPS en particulier) sont vraiment doués pour cette modularité de langage. Le projet mbeddr que j'ai mentionné plus tôt exploite cette idée pour étendre incrémentalement le C avec des concepts spécifiques au domaine pour le développement de logiciel embarqué.
InfoQ: Ça ressemble au meilleur des deux mondes — plutôt puissant. Mais le développement d'applications sera alors à nouveau à la charge des développeurs ?
Markus: Oui, tu as raison. Cela ne fonctionne que pour des DSL utilisés par des programmeurs qui connaissent le langage de base. Ça met en lumière une belle différence entre les deux styles de DSL: les DSL de domaine applicatif sont destinés aux experts du domaine; ils devraient contenir les concepts du domaine, et idéalement rien d'autre. Ils sont généralement développés top-down, i.e. on commence par les concepts du domaine trouvés dans le monde réel. L'opposé, si je puis me permettre, sont des DSL techniques. Ils sont adressés aux développeurs. Ils sont souvent construits en *ajoutant* des abstractions spécifiques au domaine dans un DSL, ils *devraient* contenir tous les trucs du GPL pour ne pas restreindre les utilisateurs, mais tout de même simplifier leur vie en fournissant des concepts de haut niveau. Ils sont typiquement développés bottom-up, i.e. on part du GPL et ses idiomes ou patterns.
InfoQ: Christian, tu travailles actuellement sur l'un des plus grands projets de MDSD d'Allemagne. Quelles sont les étapes à suivre, pour réussir la conception et l'utilisation de domain specific languages ?
Christian: La première étape est de comprendre le domaine et ses concepts. Sans cette connaissance il est impossible de trouver les bonnes abstractions. Ensuite, au moment de définir la syntaxe abstraite et concrète du langage, il faut s'assurer que les concepts restent compréhensibles et disposent de sémantiques claires. Travailler itérativement va souvent aider. Si on utilise des DSL pour générer du code ou de la documentation ou pour qu'un interpréteur puisse effectuer des simulations, alors il vaut mieux développer ces artefacts en même temps que les concepts dans le DSL. Ça aide à prouver la qualité de la syntaxe abstraite. Et si vous développez des DSL et des générateurs en tant que framework: utilisez-les vous-même. Ça vous montre si votre DSL atteint ses objectifs ou s'il est inutile. Un autre point auquel il faut réfléchir tôt est la taille et l'échelle du modèle pour être capable de concevoir des DSL utilisables avec des modèles réalistes. Utiliser des fichiers de tests de cinq lignes ne révélera pas les erreurs de conceptions vis-à-vis des performances.
InfoQ: Si tu regardes en arrière les années passées sur ton projet, quelles sont les erreurs les plus communes dans l'utilisation de DSL ?
Christian: Je pense qu'une erreur commune est l'over engineering de DSL — définir un concept pour tous les cas particuliers mène à zéro abstraction ou un langage trop générique — "aux airs de GPL" — avec le temps. Vous risquez de mettre les pieds dans l'enfer de la complexité. Pour affaiblir cet effet, il est important de faire évoluer le DSL au fil de l'eau. Par conséquent il ne faut pas craindre un refactoring du langage, en particulier si votre outillage le permet. C'est plus facile avec MPS qu'avec Xtext. Un autre piège courant est de trop se concentrer sur la syntaxe concrète et perdre de vue la syntaxe abstraite et la sémantique. Comme mentionné plus tôt, c'est une mauvaise idée de développer des DSL dans une tour d'ivoire sans contact ni application au domaine. Il faut prouver que le DSL répond au besoin du domaine de façon continue.
InfoQ: Markus, il semble que l'utilisation de DSL et une approche pilotée par le domaine ne rapporte pas dès le premier jour. Quelle est ton opinion sur la taille des projets et des organisations qui devrait être présentes pour tirer parti du MDSD ?
Markus: Je n'adhère pas à ce que tu viens de dire. Un petit DSL que je peux construire en deux heures peut très certainement payer dès le premier jour. Bien sûr, un plus gros DSL prend du temps à développer, et prend donc plus de temps avant de payer. Ce n'est qu'une question de ratio. Il n'y a donc pas de taille ou de configuration particulières. J'ai vu des DSL simples être développés par de petites équipes de développeurs. J'ai aussi vu de gros efforts de dépenses dont on estime un rendement dans les années ou décennies de durée de vie de la plateforme du produit. C'est une bonne idée de commencer avec un petit problème, en particulier au début, puisque qu'un effort plus important — comme d'habitude — présente un risque d'échec supérieur pour toutes les raisons bien connues associées à la taille et l'échelle. Encore une fois, j'aime l'approche d'extension incrémentale d'un langage de base: ça laisse le temps d'ajouter des abstractions spécifiques au domaine lorsque le besoin se manifeste ("à la troisième on automatise").
InfoQ: Dans le livre, trois frameworks de DSL sont mentionnés — Xtext, Jetbrains MPS et Spoofax. Pourrais-tu élaborer sur les différences entre ces frameworks ? Sont-ils interchangeables ou ont-ils leur scénarios ou cas d'utilisation uniques ?
Markus: Les trois sont vraiment différents, ce qui était une raison majeure de leur choix pour le livre. Xtext est le pilier pour la création de DSL textuel externe ces temps-ci. C'est mûr, bien supporté, avec un support d'Eclipse EMF, qui est la colonne vertébrale de beaucoup d'effort dans la modélisation aujourd'hui. Spoofax est aussi basé sur Eclipse, mais ne s'appuie pas sur EMF. C'est un système développé par TU Delft et bien plus innovant en termes de fonctionnalités supportées, e.g. il dispose d'un langage déclaratif pour le binding et le scoping, et va plus loin qu'Xtext sur le support de la modularité. D'un autre côté, c'est beaucoup moins répandu. JetBrains MPS est quelque peu différent de ces deux là. Il n'utilise pas de texte brut pour l'édition et l'analyse. A la place, il utilise une approche projectionnelle, où chaque action d'édition change l'AST (ndt arbre syntaxique abstrait) et ce que l'on voit et avec quoi on interagit n'est qu'une projection. Cela permet d'utiliser une gamme plus importante de notations, y compris des tableaux, des barres de fraction, et depuis peu des formes graphiques. Il facilite aussi l'extension de langages et la combinaison d'extensions développées indépendamment dans un même programme. Ce n'est pas aussi largement utilisé qu'Xtext mais ça augmente joliment. Avec tous ces outils, on peut construire de simples DSL de tous les jours, les outils sont interchangeables. Cependant, ils ne mettent pas l'accent sur la même chose. Par exemple, Xtext avec Xbase et Xtend inter-opèrent plutôt bien avec l'écosystème Java. Il est facile de construire un DSL qui réutilise le système de typage et les expressions de Java. Spoofax, étant développé par un groupe de recherche, est aussi un vecteur de recherche, comme l'illustrent certaines fonctionnalités récentes. MPS est clairement à son avantage pour construire un écosystème de langages, avec des langages se référençant, s'étendant ou s'embarquant les uns les autres ou, ou lorsqu'une "étrange" notation est requise par le domaine. C'est dur de répondre brièvement à cette question. Je pense que tu devrais lire la troisième partie du livre et forger ta propre opinion :-)
Le livre est disponible en version brochée en plus du PDF. Ce dernier peut être téléchargé contre un don. Actuellement, il n'y a aucun format spécifique à une liseuse.
A propos des auteurs du livre
Markus Völter travaille dans le développement de logiciels piloté par le modèle et les domain specific languages depuis 10 ans maintenant. Il est aussi régulièrement orateur sur le sujet à différentes conférences.
Christian Dietrich travaille comme consultant pour Itemis AG, en Allemagne. Itemis offre non seulement des services de conseil autour des projets Eclipse Xtext et Xtend utilisés pour définir des DSL et générer des artefacts à partir de modèles, mais contribue aussi activement au développement de ces projets.