sábado, 20 de junho de 2009

Domiain Specific Languages (DSL)

O acrônimo "DSL" quer dizer domain-specific language ou linguagem de domínio específico. Ao contrário de uma linguagem de propósito geral como Python, Ruby, C# ou Java, que pode implementar qualquer coisa, uma DSL está restrita um domínio como: consulta (SQL), formatação de texto (HTML), estruturação de dados (XML), automatização de testes (Cucumber) entre outros exemplos.

Para explicar o significado de DSL nos voltamos ao fundamentos.
- O que seria uma linguagem?
Linguagem, de acordo com o dicionário Michaelis, é um conjunto de sinais que serve o homem para exprimir suas idéias; agregado de palavras e métodos de os combinar usados por um povo; idioma, língua. Logo, uma linguagem especifica de domínio ao contrário de uma linguagem genérica, caracteriza-se por certas peculiaridades de palavras e métodos de uma área específica de interesse e seus domínios gramaticais ou léxicas para exprimir suas idéias; dialeto.

O uso de DSL visa tratar um problema específico, dentro de um domínio específico, através da criação de uma linguagem própria para o mesmo. Neste contexto, existem diversos tipos de DSL como por exemplo externas ou internas. Uma DSL externa geralmente pode ser interpretadas por uma linguagem de uso geral ou compiladas para obter uma linguagem mas natural ao seu domínio. Um exemplo que expressa bem esse conceito é o pyccuracy, uma ferramente de teste para aplicar bdd em uma linguagem que um usuário/cliente possa ler.

Em contrapartida, uma DSL internal normalmente é voltada para os próprios programadores realizar uma determinada área de aplicação. Uma DSL interna torna o código extremamente legível, ou seja, o código é fácil de ser lido e entendido por uma pessoa que entende sobre seu domínio, tornando o código muitas vs mais curto e menos cansativo de escrever.

Qualquer linguagem pode-se criar uma linguagem de domínio interna, em maior ou menor grau, sendo que linguagens dinâmicas existem certas características que facilitam esse tipo de programação. Um forte protocolo para objetos, uma sintaxe flexível e a capacidade de interceptar características da linguagem são essenciais para o aproveitamento máximo de uma DSL.

Uma DSL interna que estou desenvolvendo no momento é uma linguagem de consulta "hurrySQL" para o grok. Este framework utiliza um banco de dados OO (ZODB) e estou desenvolvendo uma DSL interna semelhante ao SQL para consultar os objetos python pela sua interface.

Exemplo:
>>> from hurrySQL import SELECT
>>> from RH.interface import IPessoa
>>>
>>> SELECT(IPessoa.nome, IPessoa.idade).FROM(IPessoa).WHERE(IPessoa.idade > 18)
[("Gustavo Rezende", 28), ("Paula Tejando", 22)]

Uma derivação desta DSL será para criação de tabelas HTML.
Exemplo:

>>> TABLE(IPessoa.nome, IPessoa.idade).FROM(IPessoa).WHERE(IPessoa.idade > 18)
<table>
    <tr>
        <td>Gustavo Rezende</td>
        <td>28</td>
    </tr>
    <tr>
        <td>Paula Tejando</td>
        <td>22</td>
    </tr>
</table>

Repare que estou utilizando a sintaxe do python para simular outra linguagem (SQL). Ou seja, um dialeto python diferente para um problema especifico.

Um outro exemplo de DSL interna que fiz que estou disponibilizando junto com este post é para escrever HTML em python. Para demonstrar a diferença entre uma api comum e uma DSL vou criar um XHTML com o BeautifuSoup do python.

Código equivalente não usando DSL:

>>> pag = BeautifulSoup()
>>> html = Tag(pag,"html")
>>> pag.append(html)
>>> head = Tag(pag, 'head')
>>> title = Tag(pag, 'title')
>>> title.append("Teste BeautifuSoup")
>>> head.append(title)
>>> html.append(head)
>>> body = Tag(pag, 'body')
>>> h1 = Tag(pag, 'h1',attrs=[("id","title")])
>>> h1.append("Teste BeautifulSoup")
>>> body.append(h1)
>>> p = Tag(pag, 'p',attrs=[("id","content")])
>>> p.append("Conteúdo da página")
>>> body.append(p)
>>> html.append(body)
>>> html
<html>
 <head>
  <title>
   Teste BeautifuSoup
  </title>
 </head>
 <body id="content">
  <h1 id="title">
   Teste pyhtmdsl
  </h1>
  <p id="content">
   Conteúdo da página
  </p>
 </body>
</html>


Utilizando a DSL (pyhtmdsl):

>>> HTML(
...     Head(
...         Title("Teste pyhtmdsl")),
...     Body(id="content")(
...         H1(id="title")
...             ("Teste pyhtmdsl"),
...         P(id="content")
...             ("Conteúdo da página")))
<html>
 <head>
  <title>
   Teste pyhtmdsl
  </title>
 </head>
 <body id="content">
  <h1 id="title">
   Teste pyhtmdsl
  </h1>
  <p id="content">
   Conteúdo da página
  </p>
 </body>
</html>
Postado por às Um comentário:

domingo, 14 de junho de 2009

Desdobrando o Manifesto Ágil: O funcionamento do software acima de documentação abrangente (versão Alpha)

O manifesto contém quatro princípios fundamentais que valorizam:

  • Os indivíduos e suas interações acima de procedimentos e ferramentas;

  • O funcionamento do software acima de documentação abrangente;

  • A colaboração dos clientes acima da negociação de contratos;

  • A capacidade de resposta à mudanças acima de um plano pré-estabelecido

Este texto esta em versão Alpha e é o segundo de uma série de 4 posts fundamentando e mostrando os alicerces do manifesto Ágil.


O funcionamento do software

acima de documentação abrangente


Para explicar esta citação, volto aos princípios do "Lean Thinking", onde se encaixa muito bem aqui a “Cadeia de Valor”, a formação da estrutura do valor está vinculada à percepção do cliente ao produto/serviço e atender às suas necessidades exatamente com o que eles desejam.


“MUDA é uma palavra japonesa que você não pode deixar de conhecer. Soa estranho, pois muda significa “desperdício”, especificamente, qualquer atividade humana que absorve recursos, mas não cria valor: erros que exigem retificação, produção de artefatos que ninguém deseja, e acúmulo de artefatos em espéra, etapas de processamento que, na verdade, não são necessárias, ..., grupos de pessoas em uma atividade posterior, que ficam esperando porque uma atividade anterior não foi realizada dentro do prazo, e bens e serviços que não atendem às necessidades do cliente.” (Womack et al.1998, p. 3)

Um dos fundamento do Pensamento Enxuto é a eliminação de desperdício, redução de estágios do processo (alguns cargos “como analista” ou processos não deveriam nem existir) e a delegação e transferência do máximo de tarefas e responsabilidades, tanto da gerência quanto da mão-de-obra indireta – manutenção, preparação ferramental, qualidade, etc...; para os trabalhadores que realmente agregam valor ao produto ou serviço.

A maioria dos artefatos/documentação sugeridas pela Engenharia de Software tradicional não tem valor algum para o cliente. Muitos dos artefatos/documentação são produzidos simplesmente para transcrever o que um mau programador deve codificar, sendo que o código é o que realmente agrega valor ao cliente.

Segundo Womack et al. (1998), da mesma forma que “as atividades que não podem ser medidas não podem ser adequadamente gerenciadas”, as atividades usadas para criar um bem ou serviço que não possam ser precisamente identificadas, analisadas e associadas, igualmente, não poderiam ser questionadas, melhoradas ou até eliminadas. Daí a importância de se gerenciar as cadeias de valor específicas para bens ou serviços específicos, pois conforme o autor as atividades que compõem estas cadeias podem ser divididas nas seguintes categorias:

  • aquelas que realmente criam valor, o qual é percebido pelo cliente;

  • aquelas que não criam valor, no entanto são necessárias para os sistemas de desenvolvimento ou produção de um produto ou serviço;

  • aquelas que não criam valor para o cliente, as quais podem e devem ser imediatamente eliminadas.

Para Porter et al. (1999), o conceito de “cadeia de valor” identifica as várias atividades que a empresa desempenha para executar o seu negócio. Estas atividades, diferenciadas do ponto de vista tecnológico e econômico, são chamadas de “atividades de valor” e vão gerar o valor, que é mensurado através do preço que os compradores estão dispostos a pagar pelo produto ou serviço. “O negócio é rentável quando o valor que cria é superior ao custo do desempenho das atividades de valor”. Logo, as atividades e o custo de gerar qualquer tipo de documentação devem ser avaliadas pelo desejo do cliente.

Vale aqui citar alguns avanços da tecnologia, ferramentas e técnicas que são usados nas metodologias Ágeis e reduzem enormemente a necessidade de uma documentação abrangente. BDD, TDD, DDD, ubiquitous language são ótimos exemplos destes avanços. Dentre outras avanços, temos também outra vertente; geração de documentação a partir do código. Estas tecnologias trazem uma enorme vantagem competitiva pois este tipo de documentação tem custo zero e nunca fica desatualizada.

Postado por às Nenhum comentário:
Assinar: Postagens (Atom)