Se você já desenvolveu algum programa, com certeza já utilizou linguagens como PHP, ASP, C#, C++, Delphi, VB, Java, Ruby, Delphi, ou alguma outra. Estas linguagens são para uso genérico, pois possibilitam fazer desde consultas a banco de dados, até trabalhar com arquivos, imagens, datas, enfim, existe uma gama quase que infinita de possibilidade para desenvolvimento com estas linguagens, permitindo criar inúmeros tipos de programas.

Criar software que atenda plenamente as necessidades do cliente não é uma tarefa fácil, ainda mais quando o programa precisa atender regras de negócios complexas de um cenário que a equipe de desenvolvimento não domina plenamente. Atender às solicitações mirabolantes de clientes pode ser considerado rotina em qualquer equipe de desenvolvimento, sem comentar o prazo, que certamente será apertado.

Para definição de especificação de software é muito comum reunir desenvolvedores e analistas com profissionais que dominam o negócio (gestor do negócio). Geralmente gestores de negócio não possuem conhecimento em programação, mas sim nos processos e regras que fazem o negócio funcionar. Estes então procuram passar todas as regras que o software precisa atender. A equipe de desenvolvimento então procura entender o negócio, e inicia o desenvolvimento de acordo com a visão que criaram do domínio do problema.

Pense em uma bola!

Quando pensamos em uma bola, sabemos o que é uma bola. O Problema é que cada pessoa pensa em um tipo de bola, com um tamanho, cor, material diferente. Existe até formas diferentes, bola de futebol americano, por exemplo, é oval.

Em reuniões de especificação de projeto cada pessoa cria uma visão do problema em questão, e visualiza uma solução que esteja alinhada com a visão criada. A visão criada pela equipe de desenvolvimento certamente terá buraco em relação a regra de negócio real, ou porque a visão criada foi outra ou porque o gestor de negócio pode ter esquecido de comentar todos os detalhes (ou os dois!).

Como podemos resolver este tipo de questão, de forma que a pessoa que conheça o negócio possa ficar responsável em gerir as regras específicas de negócios do software, e os desenvolvedores fiquem preocupados com o desenvolvimento?

Muitas destas questões podem ser facilmente resolvidas se criada uma linguagem específica para o domínio do problema, o DSL (Domain Specific Language). Criar esta funcionalidade pode ser mais fácil do que parece. Vamos ver alguns exemplos:

Loja Virtual

Você é o responsável pelo desenvolvimento de uma loja virtual para uma grande empresa. Esta loja possui ações de marketing em nível continental, e cada ação determina uma nova regra de negócio para vendas. Embora você conheça a questão tecnológica da operação, entender todas as regras de negócio e ficar alterando o sistema constantemente é algo que consome muitos recursos, e ainda permite falhas.

Algumas das possíveis regras de negócio são:

• Código de promoção

• Desconto por grupo de produto

• Desconto por produto

• Desconto por valor (a partir de R$ X ganha Y% de desconto)

• Desconto no frete

• Desconto por região (determinada cidade ganha X % de desconto)

• Desconto por assinante.

• Desconto por entrada de página no site (se a pessoa acessar a loja de acordo com algum outro site parceiro, ganha desconto).

• Gestão de comissão e desconto por fornecedor.

• Gestão de comissão e desconto por revendedor.

• Possibilidade de criar novos tipos de descontos ainda não pré-estabelecidos.

• Possibilidade de alterar ordem de cada promoção.

• Promoções especiais por época de ano.

• Promoção especial de queima de estoque (caso existam produtos no estoque que serão descontinuados, entrar automaticamente em liquidação).

Uma solução bastante elegante para este caso é criar um ambiente de configuração para que o gestor de negócios da loja virtual, sem nenhum conhecimento em programação, possa mudar a regra de negócio conforme as necessidades forem surgindo. Este ambiente pode ser apenas uma edição de um arquivo XML, por exemplo, ou qualquer outra forma, pré-configurada que permita que o gestor insira, altere ou apague regras de negócios, sem que seja necessário recompilar todo o código, e mandar novamente para produção e ainda sem que seja necessário acionar algum programador.

Neste caso, ao invés de criar toda a regra de negócio no código, a equipe de desenvolvimento teria que criar uma “mini-linguagem” para que o gestor, que conhece todo o processo e tem a visão de negócio consiga gerenciar.

Para criar a DSL é necessário, descrever um cenário junto ao cliente, focar nas regras de exceção e escrever no quadro branco até ter um pseudocódigo que o gestor do negócio possa entender. Deixe-o pensando e simulando o pseudocódigo por alguns dias, certamente alguns refinamentos serão necessários.

Quando tudo estiver aprovado, será necessário implementar um interpretador do pseudocódigo ao invés de criar toda a regra de negócio no sistema, dando assim poder ao gestor de negócio e tirando um peso da equipe de desenvolvimento.

DSL voltado ao desenvolvedor.

Vejamos agora outro exemplo…

Há alguns bons anos atrás deparei-me com um problema. Estava tendo uma demanda muito grande para projetos via Web. O Prazo estava muito apertado, e a maior parte da minha equipe tinha pouco, se não nenhuma experiência com programação web, pois todos estavam acostumados com desenvolvimento desktop. Explicar como funcionava o formulário web, métodos get e post, por exemplo, estava consumindo muito tempo. Explicar como o Java script interagia com os campos do formulário em alguns dias também não é algo muito digestível. O projeto na época era em ASP. (ASP.Net ainda estava sendo criado pelo Scott Guthrie e sua equipe da Microsoft).

Manter os valores dos campos quando um formulário fosse enviado de volta ao servidor também era trabalhoso e consumia muito tempo. A solução que resolvi adotar foi criar uma metalinguagem que abstraía toda a parte pesada do programador, e permitia, por exemplo, criar um campo de CNPJ, com mascara, validação, ícone com mouse-over de ajuda, formatação com estilo, persistência de informação entre outras funcionalidades com apenas uma linha de código digitado.

Esta meta linguagem ainda criava todas as instruções SQLs necessárias para as operações básicas como insert, update, select e delete. Tratamentos números, de data e prevenção de SQL-Injection também eram tratados pelo interpretador desta meta-linguagem.

Campos de data com calendário em pop-up, campo com validação e formatação decimal, inteiro, máscaras para CPF, CEP, telefone, entre outros que possuem uma grande quantidade de Java script por trás era tão fácil criar quanto chamar um método, ou escrever uma linha em XML.

Embora toda a plataforma ainda fosse ASP, o programador tinha que aprender a chamar os campos de acordo com uma configuração pré-estabelecida. Isto é um exemplo simples de uma DSL, uma “linguagem” criada para solucionar um problema específico. Ainda que esta metalinguagem tenha sido utilizada apenas pelos programadores, poderia ser liberada para algum gestor da regra de negócio do cliente, que diversas vezes solicitava adição e remoção de campos.

Programas devem ser focados no negócio!

O programa é apenas parte da solução de negócio. Eles devem existir de forma que permitam uma gestão de negócio inteligente e flexível. Não devem ser de forma alguma gargalo para maximizar lucros, devem, pelo contrário, devem permitir que resultados cada vez maiores sejam atingidos.

Com a DSL, a equipe de programação pode concentrar-se em outros problemas tecnológicos, diferentes de alterações periódicas da regra de negócio, como criar novas funcionalidades, melhorar a interface e usabilidade, entre outros que o gestor de negócio não consiga fazer sozinho.

Criar uma DNL não significa necessariamente que você vai criar uma plataforma, mas sim uma linguagem com escopo bem definido que permitirá que o usuário programe alguns eventos específicos da aplicação, como por exemplo, criar uma interface de configuração para a sua aplicação.

Exemplos de DSL

A DSL pode ser criada em basicamente qualquer linguagem, como Java, C#, Vb, entre outras linguagens de uso genérico.

Alguns exemplos de DSL são:

• Excel

• SQL

• PostScript

• ANT

• HTML (para layout)

• Expressões regulares

• Arquivos de configuração de sistema

• Arquivo de gerenciamento de permissão de usuários

• Arquivos com fórmulas financeiras

• Arquivo que contém o mapa do site

Ok… Alguns destes exemplos podem dar horas de discussão em um bar, se é DSL ou não, depende do conceito de cada um, na minha visão estes são exemplos, pois foram concebidos para atender um problema de domínio específico, como automatizar alguns processos para o desenvolvedor (ANT para java ou n-Ant para .net).

Todo poder a DSL.

Resumindo, a DSL pode ser considerada uma coleção de sintaxe e semântica que descreve a intenção de negócio, e permite que o gestor de negócio, ou o responsável pelo problema específico, tenha uma gestão mais próxima do problema, permitindo que a equipe de desenvolvimento foque no desenvolvimento de novas funcionalidades e não fique focada em alterações da regra de negócio.

Por que desenvolver uma DSL?

• Aproxima o gestor do negócio mais próximo para dar instruções à máquina.

• Facilita alterações.

• Não precisa necessariamente recompilar o sistema

• Mais fácil de manter o código

• Mais ágil, permite mais iterações.

O que preciso para criar uma DSL

Para criar uma DSL é necessário identificar as necessidades de negócio. Deve ter uma necessidade de negócio que justifique sua criação, que pode ser.

• Permitir maximizar o lucro

• Permitir uma economia monetária

• Satisfazer o cliente

Identifique quem mantém os processos do negócio. Geralmente, a pessoa que está ligada com o dia a dia do processo, não necessariamente está ligada com a estratégia, mas sim com o processo. Um usuário que dê bastante feedbacks pode ser um bom gestor de negócio.

Quando especificando uma DSL, foque nas palavras chaves e ouça o gestor, pois eles precisam das funcionalidades, não fale das tecnologias, ouça o seu cliente, e compreenda seus problemas. Eles não são programadores, mas procuram um meio de gerir facilmente o negócio.

Foque no objetivo do seu cliente, utilize a criatividade, escute-o bastante e deixe o seu ego de lado, afinal, o negócio é dele, tem que ser gerido por ele.

Forte Abraço,