Software Factory e Domain Specific Language - Uma discussão sobre modelagem.

  • Article

Olá pessoal, tudo certo?

Já conversamos por aqui sobre vários aspectos envolvidos na reutilização de conhecimento, uso de templates e modos de padronização no desenvolvimento de software. Nos últimos posts, falamos de templates de projetos, guias de automação e outros mecanismos para a customização do ambiente de desenvolvimento, sempre visando a qualidade e a produtividade de software.

Vamos voltar ao assunto, avançando nossa discussão sobre as Fábricas de Software (Software Factories) e as Linguagens de Domínio Específico (Domain Specific Language).

Sempre que pensamos em qualidade e produtividade de software, existem algumas perguntas que são recorrentes na cabeça do arquiteto, como:

  • Qual a real necessidade do meu negócio?
  • Quais tecnologias são relevantes (sobre comunicação, apresentação, workflow, transação, storage, monitoração, etc)?
  • Quais metodologias, patterns, templates, guias ou recomendações devo utilizar?
  • Como garantir o uso de boas práticas em meu time?
  • Como monitorar e controlar a qualidade de software?
  • Como estar preparado para mudanças?
  • Como ser ágil?
  • Entre outras tantas.

E como temos visto, existem diversos mecanismos que ajudam o arquiteto nessas perguntas, como:

  • Guias de desenvolvimento;
  • Guias livres de contexto / com contexto;
  • Kits ou guias de automação, como nossos GAT/GAX;
  • Implementações de referência e arquiteturas de referência;
  • Modelos de desenvolvimento e arquitetura;
  • Frameworks de desenvolvimento;
  • Linguagens de Domínio-Específico (DSL’s);
  • Fábricas de Software (Software Factories);

Da lista acima, os guias com contexto conhecidos como "patterns" são os mais comuns, por darem uma visão de solução/problema muito prática. Porém, temos visto uma crescente atenção sobre outras ferramentas, com destaque especial para as Fábricas de Software. Existe uma razão para essa mudança. Hoje, existem mais de 26 guias do Patterns & Practices (https://msdn.microsoft.com/practices/), falando de aplicações e patterns aderentes para diversos cenários.

Por isso, quando pensamos na quantidade de informação disponível nesses guias, enfrentamos alguns desafios:

  • São mais de 25 mil páginas de informação, você vai lembrar de tudo depois de ler?
  • Será que você vai ler de novo a cada projeto?
  • Se você aconselhar seus desenvolvedores a lerem, será que eles irão ler de fato?
  • Será que eles vão ter tempo e vão entender tudo?
  • Eles serão capazes de aplicar os conselhos no contexto correto?

Desse modo, surge a real necessidade de se usar ferramentas mais rígidas e de aplicação mais eficaz no processo de desenvolvimento de software, garantindo a qualidade, o padrão e a produtividade durante o projeto.

Em nossa discussão, vimos que os Guias de Automação permitem a criação de processos automatizados de geração de código, permitindo a reutilização de templates e códigos aprovados pelo arquiteto, o que garante maior velocidade na construção de novas soluções. Nesse sentido, a partir da seleção de fontes otimizados e aderentes a nichos específicos de aplicação, o arquiteto pode criar guias de automação que orientem o desenvolvedor na construção de novas aplicações com código otimizado, de forma automática.

Nesse sentido, as Fábricas de Software ampliam essa discussão, com considerações importantes sobre os seguintes componentes:

  • Patterns: Fornecem soluções gerais para problemas comuns;
  • Frameworks: Fornecem componentes suportados e reuso de componentes;
  • Modelos: Fornecem um modo de descrição de um problema específico;
  • Metodologias: Definem um conjunto codificado de práticas recomendáveis;
  • Ferramentas: Suportam a criação, manutenção e debugging;

Como já foi dito, alguns exemplos de Software Factories disponíveis pela Microsoft são:

  • Mobile Client Software Factory
  • Smart Client Software Factory
  • Web Client Software Factory
  • Web Service Software Factory
  • Application Block Software Factory

Para cada fábrica de software temos um conjunto de patterns, modelos, frameworks e guias de automação empacotados numa mesma ferramenta para o desenvolvedor. E como principal infra-estrutura utilizada na construção dessa ferramenta, a Microsoft utilizou a plataforma GAT/GAX para construção dos guias e seus artefatos.

Assim, podemos concluir que a modelagem de uma fábrica de software passa pela definição e otimização de seus artefatos componentes. Sem eles, não faz sentido pensarmos na construção de uma fábrica de software. A partir da definição de artefatos, podemos cercar os modelos, processos e a orientação de automação que será atendida pela fábrica de software em desenvolvimento.

Recentemente, a Microsoft publicou um novo extension para Visual Studio 2005, que permite a modelagem e construção de Web Services. Essa fábrica é conhecida como Service Factory e está disponível no seguinte link:

Web Service Software Factory: Modeling Edition (Novembro 2007)
Ref.: https://msdn2.microsoft.com/en-us/library/bb931187.aspx

Um elemento interessante sobre essa fábrica de software é sua integração entre artefatos, guias e linguagens de domínio específico. Ela apresenta de forma integrada 3 DSL's no Visual Studio 2005, permitindo a modelagem dos principais componentes de um serviço de uma forma visual:

  • Service Contract Model
  • Data Contract Model
  • Host Model.

A figura abaixo apresenta o uso da DSL para modelagem dos componentes de um Web Service na Service Factory:

 image

Note que para a construção dessa fábrica de software, seus autores precisaram modelar uma série de receitas, para o completo mapeamento de tarefas para a construção de um Web Services. Algumas receitas foram:

  • Criar uma solução: ativada na criação de uma solução
  • Gerar tipos de dados e mensagens: ativada para itens ".xsd"
  • Criar um contrato de serviço: ativada para um item de projeto contrato de serviço
  • Gerar interface de serviço: ativada para itens ".wsdl"
  • Gerar adaptadores: ativada para itens ".wsdl"
  • Criar um endpoint de Web Service: ativada para folders de solução nos endpoints
  • Expor uma interface de serviços: ativada para projetos de endpoints

E para a implementação dessas receitas, foram utilizados modelos em linguagens de domínio específico, o que gerou uma ferramenta visual e muito intuitiva para o desenvolvedor, facilitando o processo de construção de Web Services.

Concluindo, para a construção de uma fábrica de software integrada a uma linguagem de domínio específico, precisamos entender o domínio da aplicação, suas principais ferramentas e artefatos, antes da geração do modelo de interação com a fábrica de software.

Para maiores detalhes sobre essa fábrica de software e seus detalhes de implementação, veja:

Web Service Software Factory Community
Ref.: https://www.codeplex.com/servicefactory/Release/ProjectReleases.aspx?ReleaseId=8130

Recomendo fortemente o uso dessa fábrica de software como fonte de inspiração para o entendimento e estudo de alternativas para a construção de fábricas de software customizadas e integradas a DSL's.

Por enquanto é só! Até o próximo post :)

Waldemir.