DSL Factory

La communauté francophone autour des DSL Tools, et de l'extensibilité Visual Studio
The French-speaking community about DSL Tools and Visual Studio Extensibility
Bienvenue à DSL Factory Identification | Inscription | Aide
dans
Accueil Blogs Forums Photos Fichiers Roller

Alain

  • Candle le retour

    Aprés avoir digéré le départ de Jean-Marc et m'être remis de petits soucis de santé (hernie discale), il est grand temps de reprendre les choses en main.

    Comme Jean-Marc vous l'a annoncé, le voici dans l'équipe chargé de l'extensibilité de Visual Studio chez Microsoft. C'est une super nouvelle pour lui (un peu pour nous aussi) et surtout pour les DSL Tools qui vont avoir le meilleur des ambassadeurs (Et ce n'est pas parce que c'est un ami que je dis ça).

    En tout cas, bonne chance Jean-Marc.

    Concernant le site dslfactory, nous allons effectuer à la rentrée un petit changement. Le site va changer de nom pour s'appeler vsxFactory. Ce nom permettra de bien refléter la volonté d'aborder les problèmatiques d'extensibilité de Visual Studio en général même si les DSL tools conserveront une place prépondérante. Nous vous avertirons du changement effectif dès que l'infrastructure sera mise en place. Bien entendu, le nom actuel sera conservé avec une redirection pendant un moment.

    En attendant, j'ai publié sur codeplex le projet candle que certains d'entre vous connaissent dèjà. Ce projet était le premier projet que je faisais avec les DSL Tools (d'abord version beta puis version 1) et je le considère comme expérimental car il contient pas mal d'expèrimentation et n'implémente pas les meilleures pratiques pour créer un modèle. Par contre, il est complètement opérationnel et a dèjà été utilisé sur des projets réels.

    Ces bonnes pratiques vont faire le sujet de mes prochains articles et je suis en train de les mettre en pratique dans un nouveau projet reprenant les concepts de Candle que je vais publier prochainement.

    Pour finir, je ne saurais trop vous conseiller de lire cet excellent article de nos amis de netfxFactory qui se sont mis aux DSL Tools et qui ont dèjà bien approfondi le sujet.

     

     

  • Projet Candle

    Candle est un ensemble de DSL pour la mise en oeuvre d'une architecture multi-couches en environnement SOA utilisant les DSL Tools.

    Vous pouvez le télécharger dans l'espace 'Fichiers' du site. Il nécessite le runtime DSL Tools téléchargeable sur le site de Microsoft.

    Le principe de Candle est de modéliser un composant multi-couches et de générer le code associé grace à des stratégies de génération. L'idée de base est de génerer tout (ou du moins le + possible)  le mécanisme 'de plomberie' d'une architecture multi-niveaux pour permettre au développeur de se focaliser sur le code métier.

    Candle gére un référentiel des modèles permettant de gérer les dependences entre composants.

    L'outil est actuellement en version Beta et je vous invite à le télécharger. Pour vous faire une idée, vous pouvez télécharger les 2 tutoriaux qui vous montrent rapidement la mise en oeuvre d'un service en WCF et sa consommation par un client.

    Un article est à venir pour vous expliquer son fonctionnement, mais n'hésitez pas à me faire part de vos commentaires dans le forum dédié.


    Cliquez pour agrandir

  • Introduction aux DSL Tools

    Petite introduction sur ce que sont les DSL Tools et leurs utilisations.

    Les DSL Tools sont un ensemble d’outils permettant de créer une extension dans Visual Studio gérant la mise en œuvre d’un processus de modélisation.

    Ils s’installent à partir du Visual Studio SDK qu’il vous faut télécharger (plus d’infos ici).

    Les DSL Tools prennent en charge 3 concepts principaux :

    • La création d’un langage de modélisation
      La modélisation permet de manipuler graphiquement des concepts au sein d’un designer en implémentant un langage de modélisation. Le langage de modélisation le plus connu est bien évidemment UML mais il en existe des tas d’autres. En particulier Visual Studio 2005 (version architecte) intègre des outils de modélisation vous permettant de décrire vos diagrammes logiques d’applications et de déploiements en fournissant les designers adéquats. (figure 1)
    • La persistance du modèle
      La persistance du modèle dans un format manipulable et standardisé est quelque chose de primordial pour qui veut l'utiliser pour autre chose que de la spécification.  Par exemple, cette notion n’est pas le point fort d’UML. Il existe bien le format XMI mais celui-ci n’est pas toujours évident à utiliser, du fait des nombreuses possibilités de structure dues aux multiples versions de XMI (1.0, 1.1, 1.2, 2.0) et d’UML (1.3, 1.4, 1.5, 2.0) combinées.
    • La génération
      La génération est la conséquence de la persistance. Si le format du modèle est standardisé et qu’il contient les spécificités propres à vos besoins, la génération s’en trouve facilité et prend tout son sens. Il est à noter que j’utilise le terme ‘génération’ sans précision sur la nature de ce qui va être généré. Bien que la génération de code soit la 1ère idée qui vient à l’esprit, il est possible de générer toute sorte de choses (documentation, tests, html…)


    Le concept de langage

    Dans le ‘Robert méthodique’, nous trouvons les définitions suivantes pour langage:

    • « Fonction d'expression de la pensée et de communication entre les hommes, mise en œuvre au moyen d'un système de signes vocaux (parole) et éventuellement de signes graphiques (écriture) »
    • « Tout système de signes permettant la communication »

    Dans un contexte informatique, la notion de « signes vocaux » ne nous intéresse évidemment pas mais tout le reste est pertinent.  Ce que nous voulons en élaborant un langage est de pouvoir conceptualiser et communiquer sans ambiguïté d’une manière compréhensible pour pouvoir ensuite manipuler le concept véhiculé.

    Il existe de nombreux langage. UML est le plus connu. Il a été pensé pour permettre la modélisation (d’où son nom) mais il n’a pas été conçu dans un premier temps pour communiquer autrement que visuellement. Pour permettre la communication lui a été adjoint, par la suite, un formalisme de persistance : XMI (à partir de la version 1.3) qui ne concerne que la structure du modèle mais ne couvre pas la représentation graphique de celui-ci.

    Ce formalisme se base sur le langage XML et c’est d’ailleurs suite à l’avènement de ce langage (car c’en est un) que de nombreux autres sont apparus. On peut citer, sans être exhaustif : BPEL4WS, xhtml, ebXML, Owl…). Pour ces langages, on utilise le terme de métamodéle.

    UML est basé sur la notion de diagrammes (UML 2.0 en contient 13), il a été conçu pour être le plus générique possible. Bien qu’il soit principalement utilisé pour modéliser des concepts informatiques, il pourrait très bien être utilisé pour tout autre chose. Du fait de sa généricité, UML ne propose pas intentionnellement de processus de conception et  introduit les notions de stéréotype, de valeur étiquetée et de contrainte avec son langage (encore un) associé OCL. Et c’est bien là que le bat blesse, ces notions ne sont en aucun cas standardisé puisqu’elles répondent à un besoin spécifique. Chacun est libre de leurs utilisations. C’est pour palier ce nécessaire besoin de spécialisation qu’a été ajouté la notion de Profile dans UML qui est un regroupement de stéréotypes, de valeurs étiquetées et de contraintes spécifiques à un domaine (ex : Profile Real Time, Edoc, corba…)

    On voit bien la difficulté de mise en œuvre de cette approche, si on a un besoin très précis de modélisation, il faudra chercher si il existe un Profile adapté en priant qu’il réponde à tous nos besoins et qu’il évolue dans le bon sens. Si il ne couvre pas tout le périmètre, vous allez le spécialiser en lui ajoutent vos propres stéréotypes et … tout recommence.

    Un autre problème avec ces extensions est la difficulté d’opérer des validations complexes sur leurs utilisations au sein du modèle ou de mettre en œuvre des mécanismes de répercussions de modifications (une modification d’un élément dans le modèle peut avoir des conséquences sur d’autres aspects de celui-ci)

    Les besoins de spécialisation sont devenus une nécessité et UML essaye de les prendre en compte en ajoutant à chaque fois des extensions pour répondre à toutes ces problématiques (XMI, profile, OCL…)

    C’est à ce niveau que les DSL Tools peuvent apportées une réponse. Le but n’est pas de remplacer UML mais de pouvoir créer un langage répondant à un besoin spécifique. Ce langage peut-être complètement nouveau, basé sur UML ou sur tout autre langage. Il aura cet avantage qu’avec les DSL Tools vous aurez spécialisé le designer graphique,  typé votre modèle (au sens de validation stricte) et créé les règles d’utilisation et de transformation de celui-ci. Une implémentation de MDA en quelque sorte mais avec l’avantage de maitriser de bout en bout le processus.

    Les DSL Tools sont donc un framework vous permettant de mettre en place tous ces mécanismes tout en n’étant pas dédié au formalisme UML. A vous d’inventer votre monde (si cela a un intérêt) mais vous pouvez très bien, pour les inconditionnels, recréer un module de modélisation UML avec vos propres stéréotypes. C’est d’ailleurs ce que propose Microsoft avec le diagramme de classes bien que ressemblant fortement au diagramme de classes d’UML, il est spécifique à .NET avec par exemple les notions d’accesseurs qui ne sont plus décrits avec des stéréotypes mais disponibles directement dans le modèle.

    Vous trouverez une présentation powerpoint sur le site.

    posté le Friday, November 03, 2006 5:25 PM par AlainM | 0 commentaire(s)
    Classé sous :
    Attachment(s): sdm.jpg

Calendrier des messages

<August 2008>
SuMoTuWeThFrSa
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456

Catégorie des messages

Abonnements

Propulsé par Community Server, par Telligent Systems