DSL como pilar para a arquitetura de software

Inaugurando minha participação aqui no fórum de arquitetura, gostaria de falar sobre um vídeo que saiu recentemente no site InfoQ intitulado Domain Expert DSLs. Essa palestra ministrada por Chirsterson e Kolk faz uma pequena introdução sobre o surgimento das DSL (domain specific language), explica sobre a Programação Intencional (Intentional Programming) e de forma bem rápida também cita um pouco da estrutura e forma de trabalho utilizando a ferramenta desenvolvida pela empresa Intentional Software.

Seria mais uma palestra sobre a aplicação de DSLs mas ela tem algumas referências bem interessantes
que nos fazem pensar em o quão importante é o uso das das linguagens específicas e o quanto elas são
vitais para a arquitetura e software que desenvolvemos diariamente.

O vídeo aborda um tema bem interessante chamado programação intencional, criada por Charles Simonyi enquanto pesquisador da Microsoft. Basicamente, a programação intencional libertaria o programador das limitações que as linguagens de computador impõe, de forma que trabalhariamos apenas com abstrações que representariam "intenções".

Não estariamos mais necessariamente presos à sintaxe do C++ ou Java. De fato, qualquer representação de um domínio incluindo ícones ou gráficos seriam uma forma de persistir o conhecimento e até mesmo não técnicos conseguiriam "programar". Para entender melhor, de uma olhada na entrevista com Simonyi ou
na pesquisa original.

Isso me fez lembrar que esse é também o objetivo das DSLs, representar um conhecimento específico da forma mais natural e expressiva possível. Me google-lembrei ainda de um artigo que Martin Fowler escreveu a alguns anos sobre "Language Workbenchs". Esse termo denotaria uma classe de ferramentas que permitiriam a Programação Orientada a Linguagens que é construção de software utilizando DSLs de forma prática.

Nesse artigo, Fowler chega à conclusão que mesmo arquivos de configuração XML (lembrou de alguns softwares??) são uma forma de DSL. Existem DSL interna e externas. Elas são construídas e mantidas de várias formas, sejam através de geradores de parser como ANTLR, SableCC, JavaCC e outros ou criadas utilizando-se builders em groovy ou mini-DSLs em clojure (revivendo lisp). Elas podem ainda estar escondidas nas mais simples planilhas excel :) ou serem construídas utilizando verdadeiras potências como Meta Programming
System
da JetBrain ou o interessantissimo Textual Modeling Framework .

Recentemente em um projeto pude observar na prática como é importante dar poder de expressão para
quem conhece o domínio e o negócio. Utilizamos uma planilha excel simples no formato do Drools e definimos um modelo independente simples mas poderoso o suficiente pra se implementar todas as regras de negócio. Rapidamente os analistas começaram a preencher essa planilha e esse artefato permitiu inclusive que houvesse refactoring de várias regras!. Para cada regra implementamos casos de teste validando as mesmas de forma que inconsistências e cenários eram facilmente testados mesmo antes dos outros componentes do sistema sequer terem algum design.

Fiz a mesma "brincadeira" com os analistas de teste dessa vez criando uma DSL específica para testes integrados automatizados. Simplesmente eles começaram a jogar vários cenários, validações e parametrizações sem qualquer
interferência da equipe de projeto. E isso tudo sempre com construções simples e voltadas ao "modelo"
da disciplina de testes.

Resumindo, o importante é dar poder de expressão para o dono do conhecimento. Seja ele o cliente, analista de requisitos, arquiteto ou analista de testes, todos devem participar ativamente do processo criativo e evolutivo que é a construção de uma solução, abastecendo o sistema com artefatos executáveis, causando maior e melhor interatividade entre disciplinas e com o sistema em si.

Exibições: 135

Comentar

Você precisa ser um membro de PanGea para adicionar comentários!

Entrar em PanGea

Comentário de Wallace Pontes em 26 abril 2012 às 13:58

Excelente artigo Leonardo!

Realmente lembrei logo do ambiente proposto pelo produto que utilizo desde 2006: Conceptwave OrderCare.  

Interessante sua perspectiva de ver o DSL como pilar de uma arquitetura. Eu já compartilho com o que disse Fowler: A Domain Specific Language (DSL) is a computer programming language of limited expressiveness focused on a particular domain.

O uso de DSL / Meta-programação abstrai a complexidade envolvida na arquitetura de software previamente definida, aproximando mais o analista de negócio do programador. Essa abstração é possível devido um escopo limitado, com expressividade limitada por parte do programador e, assim, um aumento de foco no próprio negócio... o melhor dos mundos!

Sem dúvida, os ambientes de Language Workbenchs são uma tendência irreversível e já temos bons produtos consolidados para o mundo Telecom, onde a disputa é acirrada. Podemos considerar o uso desses ambientes aonde existir BPM.

A proposta  é uma corrida pela produtividade que me lembra a concorrida disputa das aplicações RAD (Powerbuilder, Delphi e Visual basic) na década de 90 baseada em uma arquitetura Cliente/Servidor. Nessa última década, tivemos o desenvolvimento de várias frentes em prol desse objetivo macro: aumentar a produtividade, gerar mais software em um menor tempo,  realizar mais com menos recursos em uma arquitetura orientada a serviços.

Legal o "dar poder de expressão para o dono de conhecimento", é exatamente o que acontece nesses ambientes de Language Workbenchs. A distância entre todos os envolvidos diminui, aumentando a interatividade do grupo e a compreensão da solução proposta.

Percebo sempre uma recusa inicial por parte do programador, por não poder utilizar aquele framework XPTO, aquele padrão de projeto GoF ou mesmo não poder utilizar a IDE de desenvolvimento dos sonhos. No mundo dos negócios, nenhum gestor quer esse nível de preocupação.

Abraço!

Wallace de Pontes

Comentário de Fábio Almeida em 24 março 2009 às 5:09
Leonardo,

Tenho utilizado programação intencional freqüentemente nos meus projetos e consigo uma excelente aceitação por parte dos programadores.A programação intencional é uma técnica simples e poderosa.

Badge

Carregando...

© 2018   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço