Sadek Drobi’s Blog

Depuis quelques temps, je tombe fréquemment sur des articles au sujet des DSL de Microsoft. Je me demande systématiquement : « pourquoi un autre langage de modélisation ? UML remplit bien ses fonctions et quand bien même, non seulement je ne crois pas en une modélisation forward blueprint (une modélisation exhaustive en début de projet), mais en plus, cette pratique va à l’encontre de mes principes d’agilité »

Ces lignes vont vous montrer pourquoi j’ai eu tort de tourner la page.
Microsoft Domain Specific Language Tools sont des outils pour implémenter des DSL, des langages spécifiques conçus pour répondre à un problème donné. Ils sont fournis sous la forme d’un SDK qui peut être installé sur Visual Studio 2005 Professional.
Ici, il peut y avoir confusion. Il ne faut pas voir les DSL Tools comme une partie intégrante de Visual Studio mais plutôt comme une solution à part entière (standalone).

• « Un outil pour fabriquer des outils » : cette définition, celle de Microsoft, souligne la différence avec les outils UML. La démarche UML/MDA (Model Driven Architecture) est jalonnée d’une série de transformations de modèles (éléments UML génériques), depuis d’un haut niveau d’abstraction, le CIM (Computation Independent Model), jusqu’à l’implémentation, le PSM (Platform Specific Model).
  C’est la différence clé. Ce que Microsoft propose :
• Dans une première phase, l’architecte construit la définition du langage pour le modèle spécifique, avec ses règles, ses validations, ses entités et leurs relations (cette spécificité garantit l’adéquation avec le domaine) et il intègre le tout dans un outil de modélisation à utiliser par les développeurs 
   
• Dans une deuxième phase, il laisse au développeur le soin d’utiliser cet outil et ses éléments pour définir l’implémentation de son application.

J’ai jusqu’à maintenant parlé des DSL dans leur aspect vertical, c’est-à-dire propre à un domaine métier. Je vais illustrer l’utilisation des DSL dans une démarche plutôt horizontale, technique, pour apporter la preuve de leur flexibilité.
Ma démonstration traite du pattern MVP (Model View Presenter). Je constate que le concept de code behind est souvent mal compris par les développeurs. Certains ont tendance à y inclure beaucoup de logique applicative. Or, tout ce qui est dans le code behind n’est ni testable, ni réutilisable !
Le pattern de conception MVP apporte une réponse intéressante à cette problématique en déportant la logique de présentation dans un composant spécifique testable indépendant de la technologie choisie pour la vue. Il offre ainsi un découpage des responsabilités sain et robuste.
Mais n’allons pas plus loin dans la description de ce pattern (voir les références pour plus d’informations) et revenons aux DSL Tools.
Il revient à l’architecte :

• De définir le méta-modèle du MVP (la sémantique du langage)
• De créer un outil intégrable à l’environnement de développement Visual Studio et de définir son apparence
•  D’assurer la validité du modèle implémenté en s’appuyant sur le méta-modèle par la définition de règles de validation (la syntaxe du langage).

A partir d’un nouveau projet de type « Langage Minimal », l’architecte définit le méta-modèle, composé des éléments suivants :

• View (qui correspond à une vue, de type WinForm, WebForm, XAML,…)
• ViewContract (une interface pour la vue)
• Presenter
• Model (référence un élément métier)

…et des relations suivantes :

• Un ViewContract est implémenté par une ou plusieurs View
• Un Presenter manipule une vue par son contrat (ViewContract)
• Un Presenter « utilise » un élément du modèle

Sont ensuite définies les règles de validation qui permettent d’assurer la cohérence :

• Erreur bloquante si une View n’implémente aucun ViewContract
• Erreur bloquante si un ViewContract n’est référencée par aucun Presenter
• Message d’alerte si un ViewContract n’est implémenté par aucune View
• Message d’alerte si un Presenter ne référence aucun ViewContract.

  using System;
using Microsoft.VisualStudio.Modeling.Validation;
using System.Globalization;
namespace Valtech.ModelViewPresenter
{
    ///
    /// Validation checks that will be applied to every ViewContract
    ///
    [Microsoft.VisualStudio.Modeling.Validation.ValidationState
    (Microsoft.VisualStudio.Modeling.Validation.ValidationState.Enabled)]
    public partial class ViewContract
    {
        ///
        /// PresenterReference : Validates that ViewContract is manipulated by a Presenter
        ///
        ///