Na sexta-feira tive a oportunidade de participar numa workshop organizada pela Microsoft sobre DSL Tools, oriendada por Annie Matthewman da Charteris. O objectivo da workshop foi apresentar as Dsl Tools no seu enquadramento geral com o conceito de Software Factories, bem como exercitar “hands-on” como as utilizar, com uma série de exercícios em redor de uma linguagem gráfica para representar expressões regulares.
Na workshop foi utilizada a versão de Fevereiro 2006, em que as Dsl Tools já vêm incluídas no SDK do Visual Studio. Fez-se a construcção dos conceitos (coisas como Literais, Wildcards, representar a multiplicidade e sequenciamento, etc.), depois a criação da linguagem gráfica, e finalmente a geração de artefactos com base em “desenhos” criados. Muito parecido com o que se faz nos walkthroughs que estão incluídos nas DSL Tools, e se não se cobriram todos os temas, foi ocasião de perceber na prática o motivo para alguns dos problemas/erros mais comuns na criação de linguagens, e também de ter algum conhecimento da realidade da equipa que, em Inglaterra, está a desenvolver as tools.
Acho que a questão que mais dificuldades/erros causa nos exercícios é o mapeamento entre o Domain Model (os conceitos da linguagem) e a sua representação gráfica, a Designer Definition. A equipa que está a desenvolver as tools optou claramente por dissociar a representação gráfica da linguagem conceptual, o que se faz algum sentido não deixa de levantar questões. Uma destas, a meu ver, é que a representação gráfica pode não ser correcta perante a definição da linguagem: por exemplo, podemos especificar que um determinado conector só pode ligar quadrados verdes (conceito X) a bolas vermelhas (conceito Y), apesar de na definição da linguagem também se poder ligar o X a Z, um terceiro conceito.
Esta questão assume dimensões mais problemáticas já que não existe nem um editor visual para fazer o mapeamento entre o Domain Model e a Designer Definition, nem qualquer validador que verifique a “completude” da representação visual.
A próxima versão das DSL Tools (em final de Março?) pode ajudar a relativizar estas questões, uma vez que o Modelo e o Designer vão passar a ser definidos num mesmo ficheiro .DSL (em vez dos actuais .DSLDM e .DSLDD), com o designer no Visual Studio a permitir editar os dois.
Aquilo que a V1 das Tools não vai suportar é a possibilidade de ter formas dentro de formas, sendo que esta é talvez a segunda questão mais referida como insuficiência das tools.
Tenho andado a discutir com pessoas e pensar sobre situações em que será vantajoso desenvolver linguagens interessantes e com elevado potencial de reutilização. Parecem-me existir, globalmente, dois grandes tipos de situações: linguagens para utilização técnica e linguagens ao nível do negócio. É muito mais fácil encontrar situações interessantes de modelar no domínio Técnico que no domínio do Negócio: é trivial identificar DSLs para modelar expressões regulares, ou uma Active Directory, ou um FileSystem, ou formatos de configuração das nossas aplicações, etc., e ver as vantagens que essas mini-linguagens poderiam ter. Mais difícil é identificar situações ao nível dos requisitos do negócio, e mesmo se identificadas, perceber o que fazer com elas, que artefactos gerar.
Num Arccast com Ron Jacobs no Channel9, o Steve Cook aborda um pouco esta distinção, referindo dois pontos interessantes: primeiro, que a criação de DSL’s se deve iniciar pela análise de desenvolvimentos e situações existentes, e não por um “pensamento criativo” de coisas que podem ser interessantes; o segundo, que uma “killer application” para as DSL Tools parece ser na área dos configuradores, de código de cola entre vários módulos ou elementos das aplicações que desenvolvemos. Parece-me uma visão pouco ambiciosa, mas é claramente melhor que pedir o céu.
jota
