Les travaux menés par Microsoft dans le domaine du développement guidé par les modèles ont fait émerger le projet Oslo. Les avancées du projet ont d’ailleurs été présentées lors de la dernière conférence PDC 2008.

Inévitablement, cette nouvelle plateforme a attiré notre attention ; et nos recherches sur le sujet nous ont naturellement confrontés à la notion de Domain Specific Language, ou DSL.

En première approche, nous avons cherché à connaître le point de vue des leaders d’opinion, reconnus par la communauté, sur le sujet. Nous tentons donc ici d’en faire une synthèse, afin de définir le concept de DSL. Nous apportons également un regard critique sur l’intérêt des DSL et leur utilisation.

Qu’est ce qu’un DSL ?

Selon une définition de Martin Fowler et quelque peu transformée par nos soins, un DSL est un langage de programmation informatique dédié à un domaine particulier, ayant un champ d’application délimité, et une syntaxe naturelle.

De cette définition, on déduit quatre éléments importants :

  • Un DSL est un langage interprétable par un système informatique. En cela, un schéma réalisé sur papier, par exemple, n’est pas un DSL.
  • Un DSL est un langage de programmation, et donc un langage qu’un être humain est capable de lire et écrire. Par ailleurs, un DSL a une syntaxe, naturelle et intuitive, qui facilite la lecture, et apporte une certaine fluidité. Cette syntaxe est également librement déterminée, et peut, éventuellement, s’appuyer sur un langage de programmation conventionnel.
  • Un DSL a un champ d’application délimité, à l’inverse des langages de programmation conventionnels. Seules les fonctionnalités syntaxiques nécessaires sont disponibles. Cela limite sa réutilisabilité, si on l’exploite dans un autre contexte. Mais, un DSL n’a pas vocation à être réutilisable.
  • Le DSL est dédié à un, et un seul, domaine, et devient inutilisable dans un autre domaine. Le domaine peut être métier, et concerner un secteur d’activité, une activité particulière, ou bien encore technique, et être lié à un système, ou un aspect d’un système.

Il existe 3 types de DSL : les DSL internes, les DSL externes, et les language workbenchs.

Les DSL internes s’appuient sur un langage d’expression qui est un sous-ensemble du langage de programmation conventionnel de l’application. Dans ce cas, on parle de fluent interface.

Les DSL externes s’appuient sur un langage d’expression qui n’est pas le langage conventionnel de l’application. Dans ce cas, il existe deux manières d’exploiter le DSL :

  • Par interprétation. Le script est parsé et transformé en une instance du modèle, généralement sous forme d’objets. L’instance du modèle est utilisée par l’application à l’exécution.
  • Par compilation. Le script est parsé, traduit dans le langage conventionnel de l’application, puis compilé, et intégré à l’application. L’exécution peut être différée. On parle également de génération de code.

Un language workbench est un atelier pour concevoir et fabriquer des DSL. Il propose ainsi un DSL dédié à la création d’autres DSL. En ce sens, il s’agit, en quelque sorte, d’un ‘meta-DSL’. La notion de language workbench dépasse la simple notion de DSL, et désigne également un ensemble d’outils complémentaires : designer visuel, éditeur de script …

Dans le cas d’un DSL externe, l’étape de parsing donne lieu à la génération d’une représentation abstraite du script initial, encore appelé arbre syntaxique abstrait (AST). L’étape de génération de code utilise cette représentation pivot, puis l’oublie. C’est le script initial qui est au centre du dispositif.

Dans le cas d’un language workbench, c’est la représentation abstraite qui est au centre. Ainsi, elle est persistée, et utilisée pour la génération de code. Elle est également projetée ou traduite, pour être exploitée dans des outils, généralement textuels ou graphiques. Ces outils permettent alors de manipuler cette représentation de différentes façons.

Quand utilise-t-on un DSL ?

Nous aurions pu tourner la question autrement, et se demander ainsi : quand doit-on utiliser un DSL ?. Mais en réalité, nous les utilisons depuis bien longtemps sans toujours nous en rendre compte ! Ce qui est récent, c’est le terme lui-même. Ce n’est en réalité que la conceptualisation et la généralisation de pratiques courantes dans le développement.

Des exemples de DSL peuvent être la configuration XML d’une application, ou les règles métiers propres à une application. Peuvent également être considérés comme des DSL : le langage SQL, les fichiers de mapping Hibernate ou iBATIS, les fichiers de configuration Struts, les expressions régulières, le langage de requête d’un moteur de recherche. Nous sommes donc entourés au quotidien par les DSL !

Un regard critique …

Les DSL sont en réalité un simple pattern de développement. Ce pattern est l’héritier du pattern interpréteur. Il s’agit donc d’un outil supplémentaire dans la boite à outils de l’architecte, pour lui permettre de réaliser le design d’une application.

Mais ce pattern n’est pas un pattern comme les autres. En règle générale, un pattern est utilisé ou non, de manière objective. Savoir si un DSL est utilisé ou non est une notion subjective, au moins en partie.

Un DSL ne s’identifie donc pas a priori, mais a posteriori. On ne décide pas d’utiliser un DSL, on se rend compte de son intérêt. Ce qui compte, c’est d’architecturer une application de manière pragmatique, pour répondre aux besoins.

L’architecture ne doit pas être rendue complexe par la volonté de faire appel à un DSL. Dans le cas contraire, cela revient à corrompre le principe de YAGNI, et faire de l’overdesign. La bonne approche reste donc, dans un premier temps, de construire l’application, puis de la refactorer itérativement, en songeant progressivement à l’utilisation d’un DSL, si cela s’avère réellement utile.

Le DSL reste un outil et ne doit pas être une fin en soi.

Billets sur le même thème

Oslo

Les DSL