Les DSL appliqués à MDA

Des années de mise en pratique et de retour d'expérience ont permis à l'approche MDA de gagner en maturité. Les principes sur lesquels se base l'approche MDA en ont fait un succès, comme la modélisation des applications, la séparation des préoccupations et l'utilisation de standards sûrs et largement diffusés.

MDA est née du besoin d'indépendance des applications par rapport aux plateformes d'exécution. L'approche MDA se base sur la séparation des préoccupations métier et techniques du développement d'une application. Les fonctions de l'application et les spécifications du support technique d'implémentation de l'application sont modélisées, séparément, dans des modèles UML. Le code source de l'application est généré automatiquement à partir de ces modèles. Les avantages que cette approche vise à atteindre, et que l'expérience des années a apportés sont :

• donner la possibilité aux entreprises de capitaliser leur savoir-faire dans des modèles pérennes, qui perdurent, indépendamment de la technologie utilisée.
  N'importe quelle entreprise possède un savoir-faire qu'elle cultive au fil de l'expérience, et qui n'évolue pas forcément à la même vitesse que la technologie utilisée pour son implémentation. La technologie évolue rapidement, alors MDA adopte la modélisation des spécifications métier, indépendamment de toute technologie, car les modèles sont des entités pérennes par nature. D'où le rôle important que tiennent les modèles dans le processus MDA ;
• automatiser certaines tâches du processus de développement d'une application pour augmenter la productivité.
  Les modèles sont traditionnellement utilisés pour améliorer la communication entre les membres d'une équipe, développeurs et experts du domaine. Dans MDA un modèle est aussi un élément productif du processus de développement. MDA se base sur les modèles, automatise les transformations de modèles et génère automatiquement le code source. Les modèles ne sont plus de simples graphiques, ce sont des entités informatisées, véhiculant une information précise, utile et nécessaire au développement de l'application ;
• permettre aux applications de tirer pleinement parti des fonctionnalités qu'offre chaque plateforme d'exécution sans pour autant s'engluer dans sa structure.
  MDA permet d'intégrer la description des plateformes d'exécution aux modèles fonctionnels de l'application, on obtient ainsi, une modélisation du comportement de l'application sur cette plateforme. On en déduit deux apports bénéfiques, d'un côté il est alors possible d'établir une stratégie propre à l'intégration de chaque plateforme. Et de l'autre MDA tient compte du caractère multiplateforme des applications, la migration logicielle se voit facilitée étant donné que les spécifications fonctionnelles sont entièrement indépendantes des plateformes d'exécution.

Aujourd'hui, MDA présente un réel avantage notamment sur les débuts de projets et pour la génération de certaines portions de code.

Sur les démarrages de projets, l'application est modélisée puis générée rapidement pour avoir une version initiale de celle-ci. Durant le développement du projet, le code est annoté de métadonnées qui permettront, à tout moment et grâce aux outils appropriés, d'inférer un modèle du code. Ce modèle devient une vue sur le code qui permet de mieux l'appréhender.

Pour la génération automatique de code, les portions de code ne nécessitant aucune reprise manuelle (le boiler plate code) sont déléguées entièrement au générateur, qui à chaque mise à jour ou modification du projet, écrase la version antérieure et régénère le code automatiquement. Dans le contexte MDA, la génération de code permet de gagner du temps sur le codage avec la prise en charge du boiler plate code, assure la synchronisation entre le modèle et le code et le respect des règles de qualité véhiculées par le modèle.

Cet article relate un retour d'expérience réel sur l'approche MDA. Les faits parlent d'une compagnie qui confie le développement d'une partie de leur nouvelle application à une équipe de développeurs, en leur proposant d'utiliser l'approche MDA telle qu'elle a été définie par la compagnie. L'équipe de développeurs commence le développement en suivant le processus MDA et tout se passe donc à merveille. Mais par manque de temps, les développeurs choisissent d'abandonner le processus MDA et de continuer le développement de façon classique afin de respecter les délais de livraison du projet. Résultat, le projet est livré à temps, mais mauvaise surprise à l'arrivée, l'application ne répond pas aux règles de qualité de la compagnie et s'avère difficile à maintenir. Conclusion de cette histoire pour livrer le produit à temps, il était nécessaire d'abandonner le cycle MDA, au détriment de la qualité du produit à la livraison.

Même si l'approche MDA paraît séduisante par ses apports dans le monde du développement logiciel, elle présente aussi des inconvénients. L'approche MDA est de plus en plus remise en question pour de nombreuses raisons :

• la modélisation d'une application demande de la pratique et une certaine capacité d'analyse et de synthèse. La plupart des développeurs privilégient la programmation au détriment de la phase analyse de la conception d'une application. Si le modèle ne correspond pas, formellement, à la description des besoins, dès lors l'application finale est compromise ;
• chaque entreprise peut utiliser sa propre définition de l'approche MDA, en modifiant celle-ci selon les besoins visés, mais au risque de perdre de vue les principes ainsi que les avantages de l'approche ;
• le roundtrip s'intègre difficilement dans MDA. Chaque nouvelle fonctionnalité ou ajout nécessite une reprise du modèle, puis une génération et un risque d'écrasement du code manuel. De plus, les étapes « modélisation, génération, intégration » sont souvent très coûteuses en temps et en coûts ;
• la synchronisation entre les différents modèles devient difficile à maintenir au fil des changements d'un modèle ou d'un autre. De plus, les outils d'automatisation ne communiquent pas tous entre eux et certains sont spécifiques à une plateforme ;
• le processus MDA devient vite lourd par l'utilisation de modèles UML à chaque étape. Jugé trop générique et trop complexe, l'UML est petit à petit mis de côté au profit d'outils plus légers et plus précis tels que les DSL ;
• la génération du code dans MDA ne se fait pas à 100 %, on se retrouve donc à mélanger du code source généré et du code source manuel. Ce procédé est souvent source d'erreurs, de bogues et donc de perte de temps et de coûts. Certains outils écrasent inévitablement le code source manuel s'il y a régénération ;
• une fois l'application finie, souvent le processus MDA est délaissé et les étapes ne sont plus respectées lors de mises à jour logicielles. Le code est enrichi, mais le modèle n'est pas mis à jour. Survient alors une totale désynchronisation entre le modèle de départ de l'application et le code source final.

L'approche MDA est formulée pour respecter les besoins utilisateur et pour développer des applications de qualité, ce qu'elle fait, pour peu que l'on puisse respecter son processus. On reproche souvent à MDA, malgré son efficacité, d'être un processus long et lourd à mettre en œuvre. Mais alors, y aurait-il un moyen de bénéficier des avantages de l'approche MDA tout en arborant une ligne de développement plus légère, plus pragmatique ?

Nous utilisons depuis longtemps et dans diverses activités des DSL parfois sans même nous en apercevoir. Peuvent être considérés comme des DSL le langage SQL, les expressions régulières, le langage de requête d'un moteur de recherche. Ou plus familier encore comme la notation musicale. Nous sommes donc entourés au quotidien par les DSL.

Un DSL (Domain Specific Language), par opposition aux langages de programmation généralistes tels que Java, C… et aux langages de modélisation généralistes tels que UML, se présente comme un langage :

Spécifique

Un DSL est un langage, de transformation, de modélisation, de programmation ou d'interrogation, selon ce pour quoi il a été conçu. Il est spécifique au domaine, contrairement à un langage généraliste, tel que Java, qui peut pratiquement traiter toute problématique.

Doté d'un vocabulaire précis et concis

Un DSL est simple d'utilisation et non ambigu. Son expressivité est basée sur un vocabulaire ciblé, propre au domaine métier.

Que vous aurez créé

La syntaxe du DSL est simple à personnaliser, elle se base sur un vocabulaire et des règles syntaxiques entièrement définies par son concepteur.

Formulé pour un problème ou un domaine particulier

Grâce à sa syntaxe personnalisable, exprimant des concepts communs à son domaine d'application, un DSL est paramétrable au métier, à une communauté ou à un projet. Facile à interpréter, il est un outil de communication entre les experts du domaine et le développeur, il permet aux experts de participer à la conception fonctionnelle de l'application.

IV-A. Les DSL à la place d'UML, pourquoi ?▲

IV-B. Le nouveau processus▲

Dans cette nouvelle définition de l'approche MDA, il est toujours question de séparation des préoccupations. Les spécifications techniques sont définies par les DSL, le CIM et le PIM sont regroupés dans un modèle DSL. Le PSM jugé redondant avec le code, celui-ci est remplacé par le code lui-même.

Le générateur de code permet de spécifier l'architecture de la plateforme d'exécution cible et de générer, après application des règles de transformations, le code source de l'application. À partir du DSL, le générateur de code va appliquer les règles de transformation contenues dans des templates, pour traduire le modèle DSL en code source dans le langage de programmation de la plateforme d'exécution cible.

En utilisant les DSL, le processus MDA devient moins contraignant et moins lourd à mettre en place. Nous remarquons d'emblée l'absence du modèle PSM, celui remplacé par le code lui-même. Le CIM et le PIM sont regroupés dans le DSL, du fait que la différence entre le CIM et le PIM n'est pas toujours clairement délimitée :

• la première étape du processus consiste à établir le vocabulaire du DSL. Ce vocabulaire doit être simple, qui reflète le domaine métier de l'application et compréhensible aussi bien par les développeurs que par les experts du domaine. C'est ce qui va permettre aux experts du domaine de participer, aisément, à la conception technique de l'application. Ce qui garantit un plus grand respect des besoins des clients ;
• la seconde étape consiste à définir le métamodèle, les règles syntaxiques de votre DSL. Les règles syntaxiques vont bien sûr se baser sur le vocabulaire déterminé dans la première étape, libre à vous de définir la syntaxe de votre DSL. Un DSL se présente sous deux formes, textuelle ou graphique. Vous pouvez utiliser les profils UML pour la conception du métamodèle d'un DSL graphique ou une grammaire ou XML schéma pour la conception du métamodèle d'un DSL textuel ;
• que le DSL soit textuel ou graphique, l'étape qui suit consiste à définir le modèle de votre application, à spécifier ses besoins fonctionnels. Le modèle de l'application est constitué de types de données, de concepts contenant des propriétés permettant d'exprimer au mieux les fonctions de votre application. Rappelons que le modèle DSL est indépendant des plateformes d'exécution. Un DSL graphique est plus visuel et efficace pour représenter des relations entre éléments. Un DSL textuel permet de décrire et d'éditer des détails plus aisément ;
• à présent il s'agit de considérer l'aspect technique de votre application et les règles de génération du code source. Ces deux tâches s'exécutent par le biais du générateur de code. Le générateur de code permet d'éditer des templates afin d'obtenir votre architecture cible. Ces mêmes templates vont contenir les règles de génération du code source.

Il est évident qu'avec cette version de l'approche MDA, il y a moins de modèles et moins de redondance d'informations. De plus, le DSL est plus accessible qu'UML. La modélisation par les DSL rend le processus plus pragmatique et simplifié par rapport à une approche MDA basée sur UML.

Petite remarque intéressante sur la conception et l'utilisation de DSL. Théoriquement parlant, c'est à l'architecte logiciel qu'incombe la tâche de conception du DSL qui sera ensuite utilisé par le développeur pour implémenter l'application destinée au client. Architectes, développeurs et clients, sont trois acteurs dont le centre de communication est pour ainsi dire le DSL, c'est pour cela que soigner sa conception est important.

L'approche MDA n'a pas de politique rigide dont il faut absolument suivre rigoureusement les règles. MDA se base sur un principe, la séparation des préoccupations, à respecter. Et tient compte de tous les aspects du développement logiciel grâce à la modélisation. Cette nouvelle définition de l'approche MDA utilise les DSL pour la modélisation des applications informatiques. Toujours dans le respect des objectifs principaux de MDA, et dans une optique plus pragmatique du développement logiciel :

La pérennité des savoir-faire

L'approcher MDA vise à pérenniser les savoir-faire métier de l'entreprise en modélisant les spécifications fonctionnelles d'une application, indépendamment des spécifications techniques liées à la plateforme d'exécution. Les modèles jouent donc un rôle important dans la pérennité des savoir-faire métier, mais le formalisme de modélisation est tout aussi important.

Le standard UML est largement répandu et permet de modéliser l'application à différents niveaux d'abstraction, indépendamment des spécifications techniques. Mais son vocabulaire reste générique et assez technique pour des experts du domaine. Les DSL respectent tout aussi bien ces exigences, indépendamment des plateformes d'exécution il confère une grande liberté dans l'expression des modèles. La modélisation des applications se fait grâce à un vocabulaire personnalisé, compréhensible par tous les membres de l'équipe.

Les gains de productivité

Dans MDA ce n'est pas la technologie utilisée pour la modélisation qui permet d'améliorer la productivité, ce sont plutôt les modèles et ce qu'on en fait. Les modèles véhiculent l'information nécessaire à l'obtention du code source de l'application, après transformations successives des modèles. Le processus de transformation est, dans sa majorité, automatisé. Ainsi, quelle que soit la technologie de modélisation utilisée, UML ou DSL, l'important est que les modèles reflètent fidèlement les besoins utilisateur et qu'ils soient rentabilisés dans un processus de transformation, qui aboutit par la suite à la génération du code source de l'application.

Dans un contexte d'amélioration de la productivité, les DSL permettent en plus la génération du code source depuis les PIM. L'architecture de la plateforme d'exécution est automatiquement décrite par le générateur de code, permettant ainsi de se passer du PSM. Les DSL rendant le processus plus souple et plus rapide.

La prise en compte des plateformes d'exécution

Quelle que soit la technologie utilisée pour la modélisation, UML ou DSL, les spécifications techniques liées à la plateforme d'exécution sont toujours prises en compte. Nous avons vu qu'avec UML les préoccupations techniques sont modélisées dans le PSM, nous avons vu aussi qu'avec l'utilisation du DSL le PSM est remplacé par le code source lui-même. Avec les DSL, ce sont les templates créés dans le générateur de code qui permettent d'exprimer l'architecture de la plateforme cible. Ces templates contiennent, aussi, les règles de transformations du modèle en code source.

De nombreux outils, payants ou gratuits, existent sur le marché pour la conception de DSL textuels ou graphiques. En voici quelques-uns :

XText est un framework développé sur Eclipse et qui permet de concevoir vos propres DSL textuels très facilement ;

MagicDraw est un modeleur commercial. Il permet de définir un métamodèle basé sur un profil UML en vue de concevoir un DSL graphique ;

Acceleo est un générateur de code permettant de traduire les modèles en code source. Il est aussi compatible avec de nombreux modeleurs ;

DSL Tools de Microsoft permet entre autres la définition de DSL et la génération de code.

Faire le choix d'un langage dédié à un domaine particulier permet d'avoir une liberté dans la description du langage qui assure une parfaite adéquation au domaine. Il n'y a pas d'informations superflues, le langage ne décrit que ce qui est utile au domaine et au développement de l'application. Mais il faut tenir compte de l'effort et du temps qu'il est nécessaire de fournir pour construire un tel langage. Dans notre cas de figure, l'approche MDA ne doit pas être rendue complexe par la seule volonté de faire du DSL.

Il existe de nombreux DSL, dédiés à un domaine particulier. Par exemple l'outil POV-Ray (Persistence Of Vision Raytracer) qui implémente un langage bien à lui, proche de la syntaxe du langage C et dédié à la modélisation en trois dimensions. Ou encore l'outil Scade qui fournit un environnement de développement pour les systèmes critiques, et permet de générer du code en langage C ou Ada. Le langage textuel de Scade est basé sur Lustre qui est un langage de programmation utilisé pour la conception de logiciels critiques. Lustre peut être considéré comme un DSL dédié au domaine de conception de systèmes critiques.

Un grand merci à Deepin pour sa disponibilité tout au long du chemin.

Un grand merci à gorgonite pour ses précieux conseils lors de la relecture technique.

Un grand merci à ClaudeLELOUP pour sa relecture orthographique et sa patience.