Tags:

DSL (Domain-Specific Language)

DSLs (Domain-Specific Languages) ou Linguagens de Domínio Específico, são linguagens de programação criadas com o objetivo de solucionar problemas em um domínio específico de aplicações. Ao contrário das Linguagens de Propósito Geral, uma DSL possui expressividade bastante limitada, possibilitando ao usuário construir estruturas que modelem de forma clara e concisa funcionalidades específicas de um determinado domínio. As DSLs tem sido amplamente utilizadas como ferramenta de comunicação entre os analistas de negócio e desenvolvedores, pois permitem tratar as funcionalidades e soluções no nível de abstração do domínio do negócio, eliminando detalhes de implementação. Sendo assim, os analistas de negócio e demais pessoas que possuem conhecimento do negócio podem verificar a corretude de cada funcionalidade implementada e a completude do sistema, verificando se todos os possíveis cenários foram devidamente cobertos.

Classificação

As DSLs podem ser classificadas em 3 diferentes categorias: Interna e Externa, expressas de forma textual e por último as chamadas Language Workbenches, que permitem a criação de DSLs utilizando modelos gráficos.

As DSLs conhecidas como internas são linguagens que utilizam a infra-estrutura de uma linguagem de programação existente, também chamada de linguagem nativa, sendo assim, são implementadas como bibliotecas e componentes que estendem a linguagem nativa criando novos tipos de dados, rotinas, procedimentos, macros, etc. Abaixo segue uma ilustração deste tipo de DSL.

As DSLs externas são linguagens que possuem uma infra-estrutura própria para as etapas de análise (parsing), interpretação, compilação e geração de código. Sendo assim, desenvolver uma DSL externa é como desenvolver qualquer outra linguagem de programação própria, pois possuem sintaxe e estruturas de linguagem próprias. É comum utilizar-se também de outras estruturas para representação de DSLs externas, tais como, implementações em linguagens baseadas na linguagem XML. Abaixo segue uma ilustração deste tipo de DSL.

As chamadas Language Workbenches são ferramentas como IDEs, que disponibilizam diversos recursos gráficos que visam expressar o modelo de negócio de forma não textual, utilizando diagramas de diversos tipos, gráficos, estruturas de relacionamento e planilhas. Ferramentas e técnicas como esta tem sofrido um grande crescimento nos dias de hoje, pois muitos problemas de negócio são mais facilmente representados de forma gráfica eliminando limitações e excessos de complexidade que as representações textuais oferecem.

 Estrutura de uma DSL

Toda DSL, seja ela Interna ou Externa, é composta de algumas partes fundamentais. O modelo de execução de um script escrito em uma DSL é fundamentalmente semelhante. Ambas partilham das etapas de parsing do script de entrada, seja ele escrito em uma linguagem com sintaxe customizada (DSL Externa) ou escrito na linguagem nativa da aplicação que está utilizando-o, após o parsing os dados e operações extraídos são tratados e populam o modelo semântico (Semantic Model – representação do domínio da aplicação) e um roteiro de execução é produzido para enfim ser executado.

Algumas DSLs possuem uma etapa adicional após a geração do roteiro de execução que é a etapa de geração de código. Esta etapa é necessária caso haja a necessidade de se gerar um script de saída para ser executado por outra aplicação ou em outro ambiente de execução. Analisadas estas etapas é possível observar que estruturalmente o que difere uma DSL Externa de uma DSL Interna é a etapa de parsing do script de entrada. No caso de uma DSL Externa esta etapa é executada pelos analisadores léxicos, sintáticos e semânticos desenvolvidos para tal DSL, já para uma DSLs Interna estas etapas são tratadas pelos analisadores da linguagem nativa na qual a DSL foi implementada.

 Porque utilizar uma DSL?

Todo sistema, por mais trivial que seja a sua estrutura e funcionamento, possui regras de negócio que devem ser obedecidas e corretamente implementadas. A necessidade ou não da implementação de uma DSL para determinado projeto inclue muitos fatores que devem ser considerados. Abaixo constam as vantagens e desvantagens da criação e utilização de uma DSL em um projeto.

Vantagens

  • Facilita comunicação entre a equipe de desenvolvimento e os analistas de negócio;
  • Alto nível de abstração, eliminando detalhes desnecessários de implementação;
  • Trechos de código escritos em uma DSL são claros, concisos e auto-documentados;
  • Permite que as soluções sejam expressas no nível do domínio da aplicação, possibilitando que os analistas de negócio entendam, validem, modifiquem e até mesmo desenvolvam funcionalidades utilizando a DSL;
  • Aumento na produtividade;

Desvantagens

  • Custo de design e manutenção de uma nova linguagem;
  • Adição de mais níves de abstração, aumentando-se assim também os níveis de indireção;
  • No caso de DSLs externas, podem ocorrer problemas de integração com outros componentes e aplicações;
  • Baixo desempenho devido ao aumento dos níveis de abstração e a possível não existência de um otimizador do código gerado;
  • Curva de aprendizado de uma nova linguagem x Aplicabilidade limitada;
  • Falta de suporte de ferramentas adequadas para o desenvolvimento e manutenção da DSL;

Exemplos

  • Trecho de código de uma DSL Interna para criação de um computador abstrato utilizando a linguagem Java.
   public Computer createComputer(){
        Processor p = new Processor(2, 2500, Processor.Type.i386);
        Disk d1 = new Disk(150, Disk.UNKNOWN_SPEED, null);
        Disk d2 = new Disk(75, 7200, Disk.Interface.SATA);
        return new Computer(p, d1, d2);
   }
  • Código com o mesmo objetivo do anterior, porém implementado sob a forma de uma DSL Externa
   computer()
      .processor()
         .cores(2)
         .speed(2500)
         .i386()
      .disk()
         .size(150)
      .disk()
         .size(75)
         .speed(7200)
         .sata()
   .end();

Referências

Domain-Specific Languages, Martin Fowler. Addison-Wesley Professional. Setembro, 2010

DSL in Action, Debasish Ghosh. Manning Publications. 2011.

Por MATERA SYSTEMS

Postado em: 28 de setembro de 2012

Confira outros artigos do nosso blog

REST não é JSON

21 de agosto de 2017

Bruno Sofiato

[Webinar] Profile de aplicações Java com Oracle Mission Control e Flight Recorder

24 de julho de 2017

Danival Calegari

Criando Mocks de serviços REST com SoapUI

27 de junho de 2017

Monise Costa

JavaScript 6: diferença entre var, let e const

09 de maio de 2017

Otávio Felipe do Prado

Deixe seu comentário