Waldemir Cambiucci - Solutions Architect - Microsoft Brasil : GAT / GAX

Algumas palavrinhas sobre Domain-Specific Language (DSL)

wcamb — Mon, 17 Aug 2009 16:56:00 GMT

Olá pessoal, tudo certo?

Semana passada voltei a falar com algumas empresas sobre DSLs e Fábricas de Software. Como muitos já sabem, o tema está bastante relacionado com a construção de frameworks de desenvolvimento, patterns, guias de automação e ainda com a abstração de um domínio para o desenvolvimento de software.

Uma DSL – Domain Specific Language – ou linguagem específica de domínio (alguns até preferecem linguagem de domínio específico), é uma ferramenta de geração de software e modelagem, que permite ao usuário a criação de soluções iniciais a partir de artefatos componentes da DSL. Uma DSL pode envolver linguagens de modelagem, templates, referências a frameworks de desenvolvimento, atividades, exemplos de código, etc.

Em resumo, uma DSL oferece ferramentas para a modelagem de soluções, com grande variabilidade de resultados. Um exemplo já clássico de DSL gráfica é o editor de modelos de dados do Entity Framework, sobre o Visual Studio 2008, veja:

Na figura acima você vê do lado esquerdo, os shapes disponíveis na DSL, como Entity, Association e Inheritance, que podem ser adicionados ao modelo desenhado a partir das tabelas do banco (no lado direito da figura). A DSL oferece assim, uma grande flexibilidade para a criação de novos modelos EDMX, em nosso exemplo.

Mas nem só de DSLs gráficas vive o mercado. Veja a figura abaixo:

Podemos classificar as DSLs em domínios horizontais e verticais, de acordo com o foco de cenário que deve atender. Também, sua especialização pode ser mais genérica (de propósito geral) ou mais específica (atendendo um cenário determinado). Ainda, uma DSL pode ser gráfica, textual, baseada em formulários ou um modelo híbrido.

Quando precisamos de uma DSL? Existem cenários de desenvolvimento que envolvem:

grande complexidade nas operações e métodos;
mudanças frequentes em requisitos e organização do software;
busca por maior agilidade entre a definição e a execução do projeto de software;
muitos pontos de manutenção do projeto, etc.

Em cenários como esses, a aplicação de uma DSL torna-se interessante. Segundo Martin Fowler, ainda podemos classificar uma DSL como interna (ou Embedded) e externa.

Uma DSL interna pode ser entendida como uma maneira de se projetar uma API ou uma interface no domínio da aplicação, usando uma linguagem mais natural para o desenvolvedor, com palavras dentro de um contexto ou domínio específico. Uma DSL interna aproveita os recursos de uma linguagem host maior, por exemplo, um parser de aplicação feito em C# (veja que não precisamos criar um compilador, regras rígidas de gramática ou descrições para C#, elas já existem).

Já uma DSL externa é mais ampla e exige um esforço de implementação maior, pois aplica restrições e considerações de gramáticas e linguagens de programação, como as linguagem Tipo-2 ou Livres de Contexto (pensando na Hierarquia de Chomsky, lembra dela?). ;) São exemplos de DSLs externas o T-SQL, transformadores XSLT, a linguagem SQL, etc. Sendo linguagens mais completas, oferecem um poder de modelagem para seus usuários muito maior.

Finalmente, podemos esperar para breve novidades no mundo das DSLs sobre a plataforma Microsoft. A plataforma OSLO promete um grande uso dessas ferramentas, para a criação e manipulação de modelos no chamado MDD – Model Driven Design. Mas esse é um assunto para outro post :)

DSL é um assunto bem interessante e tem muita coisa publicada na web. Se você ficou interessante em conhecer mais sobre DSL’s, alguns links que eu recomendo são esses:

DSLs: The Good, the Bad, and the Ugly
http://www.infoq.com/presentations/Truth-about-DSL

Como separar semântica e implementação da DSL
http://www.microsoft.com/brasil/msdn/arquitetura/Journal/SeparatingDSLSemanticsfromImplementation.mspx

Introducing Domain Specific Languages - Martin Fowler
http://msdn.microsoft.com/en-us/oslo/dd727707.aspx

Generating Code for DSLs
http://martinfowler.com/articles/codeGenDsl.html

FurtaSpace - www.afurtado.net (Blog do André Furtado, que tem diversos posts sobre DSLs)
http://afurtado1980.spaces.live.com/default.aspx

Frameworks de Desenvolvimento
http://blogs.msdn.com/wcamb/archive/tags/Frameworks/default.aspx

GAT/GAX
http://blogs.msdn.com/wcamb/archive/tags/GAT+_2F00_+GAX/default.aspx

Uma última pergunta: você tem usado DSLs em seu dia-a-dia como arquiteto? Quais DSLs têm sido mais importantes? Consegue reconhecê-las?

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

Waldemir.

Sculpture 1.0 Final : uma ferramenta de automação sobre o GAT/GAX.

wcamb — Thu, 05 Mar 2009 03:13:00 GMT

Olá pessoal, tudo certo?

Gostaria de recomendar hoje um projeto muito interessante do Codeplex, o Sculpture.

O Sculpture 1.0 Final foi publicado nesta terça-feira, dia 03/março. Confira:

Sculpture - Model Your Life
Ref.: http://sculpture.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=23952

O Sculpture é uma ferramenta baseada no Guidance Automation Toolkit e seus recursos (GAT/GAX). Já vimos bastante sobre essa dupla aqui no blog. Sendo assim, o Sculpture fornece um ambiente baseado em Wizards, conduzindo o desenvolvedor durante a criação de aplicações completas, a partir do modelo de banco de dados desejado.

Isso mesmo! Você aponta o modelo de dados que será usado, escolhe o tipo de aplicação que deseja e modela sua aplicação através de um conjunto de shapes, operando uma verdadeira DSL (domain specific language).

Que tipo de interface de aplicação você pode gerar? Veja o menu abaixo:

E que tipo de serviço podemos usar em nossa aplicação? Também temos um menu para isso:

E que tipo de acesso a dados podemos escolher? Veja abaixo:

Gostou? Vimos que é compatível com o Prism, mas ainda não terminei meus testes. Recomendo instalar o Prism v2.0 primeiro, antes do Sculpture 1.0. Aguardem mais dicas!

Para começar, recomendo a preparação de seu ambiente. Antes da instalação do Sculpture, você deve fazer a instalação dos pré-reqs sobre o Visual Studio 2008:

Visual Studio 2008 Service Pack 1
Ref. :http://www.microsoft.com/downloads/details.aspx?FamilyId=FBEE1648-7106-44A7-9649-6D9F6D58056E&displaylang=en

Guidance Automation Extensions - February 2008 Release (GAX)
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=DF79C099-4753-4A59-91E3-5020D9714E4E&displaylang=en

Guidance Automation Extensions for Visual Studio 2008 and Visual Studio 2008 Service Pack 1 Update (GAXP1409)
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=E28205C6-BB07-401B-9A76-804784598BF0&displaylang=en

Guidance Automation Toolkit for Visual Studio 2008 - Feb 2008 Release (GAT)
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=B91066B3-D1D6-4990-A45F-34CF8DBDC60C&displaylang=en

A partir dessa preparação, instale o pacote Sculpture. Ele deve criar uma nova pasta de templates de projetos no Visual Studio a partir do Guidance Packages, lembra dele? :)

Depois disso, é só experimentar as várias entradas do Wizard que é disparado para sua solução. Nos próximos posts vamos falar mais do pacote.

Tanto o Prism 2.0 como o Sculpture 1.0 podem ser entendidos como aceleradores para a construção de interfaces e aplicações. Enquanto o Prism oferece uma biblioteca (a CAL – Composite Application Library) para a construção de aplicações de composição, o Sculpture oferece um guia de automação, integrando uma fábrica de software com uma DSL para a construção de interfaces diversas, assim como o modelo de negócio e serviços.

Entender suas diferenças, arquiteturas e principais recursos será importante no momento da decisão pelo uso em nossos projetos. Por isso, experimente os dois pacotes (em ambiente controlado), sem moderação!!!

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

Waldemir.

Web Service Software Factory : Modeling Edition - Nova versão já disponível.

wcamb — Wed, 05 Mar 2008 03:28:00 GMT

Olá pessoal, tudo certo?

Ainda sobre Fábricas de Software e Guias de Automação, vale acompanhar o que está chegando por ai. O link a seguir tem um roadmap com os próximos lançamentos na plataforma Microsoft, veja aqui:

patterns & practices: Upcoming Release Roadmap
Ref.: http://msdn2.microsoft.com/en-us/practices/bb232643.aspx

Um especial destaque para a WPF Composite Client, que tem um apelo enorme para o tratamento de aplicações compostas e camadas de composição em interfaces WPF, muito interessante:

WPF Composite Client
Ref.: http://blogs.msdn.com/gblock/archive/2007/10/26/wpf-composite-client-guidance-it-s-coming.aspx

Ainda, no link do patterns & practices DVD de Abril de 2007, você tem acesso a 2 posters em PDF muito bacanas:

patterns & practices April 2007 DVD
http://www.microsoft.com/downloads/details.aspx?FamilyID=6724e09b-ca2e-425a-8d71-8febad3ba203&displaylang=en

Este primeiro poster, com a descrição dos tipos de guias disponíveis...

Ref..: http://download.microsoft.com/download/1/4/d/14d1a93d-3cce-4445-bd89-fa4f3aacab37/poster-1.pdf

E ainda um poster com um resumo de todas as fábricas de software disponíveis até 2007.

Ref.: http://download.microsoft.com/download/1/4/d/14d1a93d-3cce-4445-bd89-fa4f3aacab37/poster-2.pdf

Veja que algumas fábricas estão ausentes no poster acima, como a recém atualizada Web Service Software Factory Modeling Edition, que tem integrada uma DSL para modelagem de serviços, veja aqui:

Web Service Software Factory: Modeling Edition - February 2008
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=F7AA544D-AD73-4B65-88D5-63F751844540&displaylang=en

No post anterior, falamos dos novos pacotes do GAT/GAX para Visual Studio 2005/2008. Agora, citamos a Web Service Software Factory : Modeling Edition para Visual Studio 2005/2008.

Uma nota importante sobre essa nova fábrica de software : agora, ela tem uma DSL - Domain-Specific Language integrada, permitindo que as várias receitas e ações disponíveis para a geração de serviços sejam modeladas de forma visual, aproveitando os recursos e benefícios de uma linguagem específica de domínio.

Na versão anterior, esta fábrica de software permitia a execução dessas receitas e templates através de wizards acessados diretamente a partir do Guidance Navigator do guia de automação. Veja a figura abaixo para um exemplo de Guidance Navigator, dentro do Visual Studio.

Isso não dava muita flexibilidade para criação de novas combinações de serviços, entidades, contratos, operações, etc. Com o uso de uma DSL integrada, a versão Modeling Edition permite um escopo maior de soluções, além da possibilidade de modelagem visual de um problema. É de fato uma primeira fábrica de software oferecendo uma DSL para o desenvolvedor.

O resultado é a possibilidade de uma modelagem de mais alto nível, mascarando detalhes de implementação, enquanto permite maior variabilidade de soluções e combinações de recursos disponíveis com a fábrica de software. Veja um exemplo abaixo:

Para maiores detalhes sobre a modelagem de linguagens específicas de domínio, veja o livro:

Domain-Specific Development with Visual Studio DSL Tools (Microsoft .NET Development Series)
Ref.: http://www.amazon.com/Domain-Specific-Development-Visual-Studio-Microsoft/dp/0321398203

E um site com algumas informações sobre o livro:

Domain-Specific Development with Visual Studio DSL Tools (Released June 2007)
Ref.: http://www.domainspecificdevelopment.com/

...enquanto novos posts sobre o assunto estão sendo preparados... ;)

Guias de automação, fábricas de software, linguagens específicas de domínio, templates para Visual Studio, etc. são de fato recursos que precisam ser conhecidos pelo arquiteto, pois são ferramentas importantes para a maior qualidade no desenvolvimento de software. Seja para empresas fornecedoras de software (ISV) ou organizações no mundo corporativo, garantir produtividade, padronização e qualidade pode se tornar em breve uma questão de sobrevivência. Claro que em diferentes proporções para cada uma dessas empresas, mas de fato essa discussão tende a se tornar um diferencial crescente num mundo cada vez mais globalizado e competitivo.

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

Waldemir.

GAX/GAT February 2008 Final Release

wcamb — Sun, 02 Mar 2008 01:37:00 GMT

Olá pessoal, tudo certo?

Quem tem acompanhado nossas discussões sobre Guias de Automação e Fábricas de Software precisa ler esse post. No último dia 24/02 foi lançado o Final Release do GAX/GAT para Visual Studio 2008 e 2005, uma notícia que vinha sendo aguardada pelo mercado.

Como sabemos, existem 3 diferentes mecanismos de customização e padronização de código no ambiente Visual Studio:

Visual Studio Templates
Que permite a construção de templates de projeto e templates de itens de projetos;
Visual Studio SDK
Que permite a construção de addins e wizards para Visual Studio, permitindo acesso direto às funcionalidades do ambiente IDE;
Guidances Automation (GAT/GAX)
Pacotes de automação e geração de código, através da infra-estrutura GAT/GAX da Microsoft;

De fato, todas as Fábricas de Software disponibilizadas pela Microsoft são construídas através de Guias de Automação, que guiam os desenvolvedores por atividades complexas e repetitivas, garantindo maior padronização e controle sobre o código gerado.

Para relembrar, a figura abaixo apresenta os passos envolvidos na construção e uso de um Guia de Automação:

A infra-estrutura comum do GAX agora vale para o Visual Studio 2005 e Visual Studio 2008 e o link é esse aqui:

GAX - Guidance Automation Extensions - February 2008 Release
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=DF79C099-4753-4A59-91E3-5020D9714E4E&displaylang=en

Já o pacote para construção de guias GAT usado em design-time deve ser instalado de acordo com o ambiente destino:

...para o Visual Studio 2008:

GAT - Guidance Automation Toolkit for Visual Studio 2008 - February 2008 Release
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=B91066B3-D1D6-4990-A45F-34CF8DBDC60C&displaylang=en

...e para o Visual Studio 2005:

Guidance Automation Toolkit for Visual Studio 2005 - February 2008 Release
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=2700ED86-318C-4449-9DD2-5E1B60D1F4A5&displaylang=en

Agora é instalar e conferir...

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

Waldemir.

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

wcamb — Thu, 31 Jan 2008 01:39:00 GMT

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 (http://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.: http://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:

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.: http://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.

Guidance Automation Toolkit - Customizações no ambiente de desenvolvimento

wcamb — Sun, 20 Jan 2008 18:50:00 GMT

Olá pessoal, tudo certo?

Finalmente, o terceiro mecanismo para as customizações no ambiente de desenvolvimento são os Guias de Automação. Para o Visual Studio temos o GAT - Guidance Automation Toolkit, como sua principal ferramenta. Ele trabalha sobre um framework específico de automação, chamado Microsoft.Practices.RecipeFramework.

Como já falamos aqui no blog, o pacote GAT adiciona ao ambiente do Visual Studio a infra-estrutura de linguagens e ferramentas para a construção de pacotes de automação para geração de código. O objetivo é automatizar a codificação, baseando-se em templates e modelos de software que o arquiteto ou desenvolvedor selecionou como melhores práticas para um tipo de solução.

Vamos iniciar com a preparação do ambiente sobre o Visual Studio 2005, onde temos os seguintes extensions e pacotes de atualização indicados abaixo:

1) Microsoft .NET Framework 2.0 Service Pack 1
http://www.microsoft.com/downloads/details.aspx?familyid=79bc3b77-e02c-4ad3-aacf-a7633f706ba5&displaylang=en

2) Microsoft .NET Framework 3.0 Redistributable Package
http://www.microsoft.com/downloads/details.aspx?familyid=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en

3) Microsoft .NET Framework 3.0 Service Pack 1
http://www.microsoft.com/downloads/details.aspx?familyid=ec2ca85d-b255-4425-9e65-1e88a0bdb72a&displaylang=en

4) Guidance Automation Extensions - July 2007 (GAT)
http://www.microsoft.com/downloads/details.aspx?familyid=C0A394C0-5EEB-47C4-9F7B-71E51866A7ED&displaylang=en

5) Guidance Automation Toolkit - July 2007 (GAX)
http://www.microsoft.com/downloads/details.aspx?familyid=E3D101DB-6EE1-4EC5-884E-97B27E49EAAE&displaylang=en

6) Visual Studio 2005 SDK Version 4.0
http://www.microsoft.com/downloads/details.aspx?FamilyID=51A5C65B-C020-4E08-8AC0-3EB9C06996F4&displaylang=en

7) Microsoft® Visual Studio® 2005 Team Suite Service Pack 1 - June 2007
http://www.microsoft.com/downloads/details.aspx?familyid=BB4A75AB-E2D4-4C96-B39D-37BAF6B5B1DC&displaylang=en

A partir desta instalação, nosso Visual Studio 2005 estará apto para trabalhar com o GAT/GAX, disponibilizando uma nova pasta de templates de projeto, como vemos a seguir:

Assim, a pasta Guidance Packages permite a criação de novos guias de automação, através do template de projeto "Guidance Package Development/Guidance Package". Por exemplo, podemos pensar na automação de um cenário para construção de aplicações ASP.NET. Pense em templates de navegação otimizados e homologados pela equipe de arquitetura. O objetivo nesse cenário é garantir produtividade durante a construção de novas aplicações, através da geração dinâmica de arquivos e items de projeto. Essa geração dinâmica de código ocorre sobre uma linguagem de templates, a Text Templating Transformation Toolkit ou simplesmente T4.

Um Guidance Package (ou Pacote de Automação) é criado para um propósito específico, visando atender algum tipo de solução que queremos automatizar. Assim, caracteriza-se também como uma unidade de versionamento e distribuição. Uma vez finalizado, o pacote pode ser registrado e distribuído para as várias estações de desenvolvimento. Os desenvolvedores finais serão os usuários desse pacote de automação.

A figura a seguir descreve bem esses passos no processo de modelagem e construção de um guia de automação:

De fato, um Guidance Package consiste de templates do Visual Studio, como vimos anteriormente (templates de projeto e templates de itens de projeto) e receitas de automação (passos de automação). Entre os elementos que compõem um guia de automação temos:

Recipes (Receitas)
Wizards (Sequência de passos para entrada de dados, nos moldes dos Addin's Wizards que vimos no post anterior)
Value Providers (Provedores de valores)
Type Converters (Conversores de tipos)
Actions (Ações)
Code Generation (Geração de código, onde temos os templates em linguagem T4)

A figua abaixo apresenta bem a hierarquia de componentes de um guia de automação, veja:

Entendido os conceitos sobre o GAT/GAX, vejamos como utilizá-lo. Uma sequência de passos para a construção de um guia de automação é dada abaixo:

Definir as receitas desejadas para o guia, incluindo a definição de argumentos, wizards e ações;
Definir os templates de Visual Studio envolvidos;
Escrever as ações;
Escrever os tipos de argumentos e conversores necessários;
Definir templates T4, se uma ação utilizar templates T4 para geração de código;
Testar o pacote de automação;
Construir o pacote com os arquivos de setup, para distribuição;

Ao final, um pacote de guia conterá os seguintes artefatos:

arquivo de configuração do guia de automação (necessário);
templates de Visual Studio;
templates T4;
DLL implementando ações, editores de tipos, provedores de valores e conversores de tipos (note que uma única DLL é recomendada);

Uma boa maneira de iniciar seus trabalhos sobre o guia de automação GAT é seguir os passos da solução exemplo, que vem com a instalação do GAT/GAX. Veja na tela principal da solução os principais passos recomentados, são 7 passos:

Finalmente, vamos exportar esse guia de automação para outras máquinas. A solução template do Guidance Package gera também um template de Setup, que disponibiliza o pacote para instalação. Veja abaixo os projetos contidos na solução de um guia de automação, onde notamos o projeto de Setup que deve ser instalado na estação do desenvolvedor:

Desse modo, passamos pelos principais elementos sobre a modelagem e construção de um Guia de Automação. Recomendo fortemente a leitura dos arquivos de ajuda do GAT e GAX, para um maior detalhamento. O material tem bastante informações importante, que ajudará na evolução e construção de guias de automação sofisticados.

A Microsoft também disponibiliza uma série de Fábricas de Software, que nada mais são do que pacotes de automação prontos para assuntos específicos. Isso significa que a base das várias Fábricas de Software que a Microsoft disponibiliza é realmente o GAT/GAX que vimos aqui. Entre as fábricas mais conhecidas temos:

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

Em posts futuros, vamos avançar em outros assuntos relacionados ao ganho de produtividade no ambiente de desenvolvimento. Entre eles teremos as Fábricas de Software e as Linguagens de Domínio Específico, ou DSL's - Domain Specific Languages. Fiquem ligados.

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

Waldemir.

Visual Studio 2005 SDK Version 4.0 - Customizações no ambiente de desenvolvimento.

wcamb — Thu, 17 Jan 2008 03:25:00 GMT

Olá pessoal, tudo certo?

Em nossa discussão sobre mecanismos para customização do ambiente de desenvolvimento em .NET, já falamos de templates de projeto e templates de itens de projeto. A idéia é passar pelos mecanismos básicos de customização e por fim, discutir em detalhes o Guidance Automation Toolkit (GAT). Hoje falaremos sobre o SDK - Software Development Kit v4.0 para o Visual Studio 2005.

2. Customização de funcionalidades através do Visual Studio 2005 SDK Version 4.0

Quando pensamos no uso de um SDK de um determinado produto, temos em mente acessar funcionalidades e recursos de forma programática, sem restrições. O mesmo acontece com o SDK do Visual Studio. Com ele, podemos acessar os recursos para administração de itens de projeto, soluções ativas, referência, componentes em uso, etc.

Desse modo, é possível criar customizações que adicionam funcionalidades integradas ao IDE (Integrated Development Environment) do Visual Studio. Entre as opções temos:

Criação de macros de expansão de código;
Criação de menus customizados;
Criação de janelas de ferramentas customizadas;
Visualização de informações consolidadas sobre os projetos abertos;
Extensões em conteúdo de arquivos de ajuda;
Criação de addin's de navegação;
Criação de wizards diversos, etc.

Assim, através do SDK acessamos o modelo de objetos do Visual Studio, implementado através das bibliotecas EnvDTE.dll e EnvDTE80.dll. (DTE - Development Tools Environment).

Uma customização muito comum é a criação de Addin's para o IDE. Já que estamos falando sobre ganhos de produtividade, pense num ADDIN que ofereça um Wizard, permitindo uma entrada de dados e que oriente o desenvolvedor na adição de novos recursos ao projeto ativo. Por exemplo, podemos visualizar todas as referências existentes no projeto, permitindo ainda adicionar novas referências de forma amigável.

Vamos imaginar um Addin implementado através de um classe chamada Viewer. O objetivo desse Addin é navegar pelas referências ativas de um projeto no Visual Studio, como vemos a seguir:

A figura acima apresenta a tela principal do Addin, navegando pelas referências e tipos presentes para o projeto. Esse tipo de customização é baseado no uso de classes do modelo de objetos do DTE, como vemos a seguir:

Veja que uma série de métodos são oferecidos, permitindo a implementação de atividades durante momentos como abertura ou fechamento do addin, conexão ao menu principal, shutdown, entre outros.

E para acessar a hierarquia de recursos presentes no projeto, o Addin faz uso da seguinte estrutura:

Veja que o método acima percorre os vários projetos da solução ativa e para cada projeto, percorre as várias referências presentes, criando uma lista para o desenvolvedor. Isso é feito através da instância VSProj.References.

Da mesma forma, veremos que é possível a construção de Code Snippet para obtenção de nomes de projeto, arquivos ou recursos, que poderão ser usados em templates ou guias de automação, utilizando a mesma navegação pelas estruturas do EnvDTE. Veja um exemplo de Code Snippet para obtenção do nome do projeto:

EnvDTE._DTE dte = (EnvDTE._DTE)automationObject;

Array activeProjects = (Array)dte.ActiveSolutionProjects;

EnvDTE.Project activeProject = (EnvDTE.Project)activeProjects.GetValue(0);

replacementsDictionary.Add("$projectname$", activeProject.Name);

Maiores detalhes sobre esse tipo de navegação pelos recursos do projeto você tem aqui:

DTE2.ActiveSolutionProjects Property
Ref.: http://msdn2.microsoft.com/en-us/library/envdte80.dte2.activesolutionprojects(VS.80).aspx

O download do SDK v4.0 do Visual Studio 2005 está disponível aqui:

Download : Visual Studio 2005 SDK Version 4.0
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyID=51A5C65B-C020-4E08-8AC0-3EB9C06996F4&displaylang=en

Finalmente, a partir da instalação do SDK no ambiente do Visual Studio, novos templates são oferecidos para o desenvolvedor, como vemos na figura a seguir na pasta "Other project Types/Extensibility". Entre eles temos:

Visual Studio Integration Package
Visual Studio Language Package
Domain Specific Language Designer
Domain Specific Language Setup
Help Integration Wizard

Note que o SDK v4.0 também inclui as ferramentas para construção de DSL's, que veremos em posts futuros.

Importante: a documentação do SDK é leitura obrigatória para explorarmos os detalhes de implementação de Addins. Portanto, esse post não esgota o assunto, mas apenas aponta algumas direções e tópicos que achei interessante, entre os mecanismos de customização do ambiente Visual Studio 2005. No próximo post falaremos um pouco mais sobre guias de automação e linguagens para geração de código, como a T4 - Text Templating Transformation Toolkit.

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

Waldemir.

Project Template e Item Template - Customizações no ambiente de desenvolvimento.

wcamb — Wed, 16 Jan 2008 00:22:00 GMT

Olá pessoal, tudo certo?

Voltando ao assunto principal, retomamos nossa discussão sobre templates e padrões para o ambiente de desenvolvimento. Lembrando sempre que uma das atividades do time de arquitetura é direcionar a equipe de desenvolvimento na adoção de boas práticas na produção de software, com qualidade e produtividade.

Recentemente, tive uma discussão com um time de arquitetos de um cliente, que questionava exatamente as alternativas para a padronização e uso de templates na plataforma Microsoft. Assim, perguntavam sobre customizações do ambiente de desenvolvimento, ou seja, customizações sobre o próprio Visual Studio, afim de direcionar o desenvolvedor no momento da criação de código. Focando a versão 2005, citamos 3 mecanismos básicos:

Construção de templates de projeto e templates de itens de projeto;
Customização de funcionalidades através do SDK v4.0 para o Visual Studio 2005;
Construção de guias de automação para o desenvolvimento de soluções;

Neste post, vamos falar iniciamente sobre o primeiro modo, a construção de templates no Visual Studio 2005.

1. Construção de templates de projeto e templates de itens de projeto

A construção de templates é feita através da funcionalidade "Export Template" do Visual Studio. Esse recurso permite a geração de um pacote .ZIP, que agrupa arquivos de recursos, fontes, imagens e links de referência de um projeto ou arquivo fonte, que poderá ser reutilizado pelos desenvolvedores de forma integrada ao Visual Studio.

Você encontra esse recurso no menu File do IDE do Visual Studio, veja:

A partir de um projeto modelo selecionado, é possível criar um template de projeto ou de item, como mostrado na caixa de diálogo abaixo:

Para o exemplo de geração de um template de projeto, é gerado um arquivo .ZIP, contendo os arquivos de recursos e fontes componentes do projeto. Também é adicionado a esse pacote o arquivo com as referências e lista de componentes do template. Esse arquivo vem com extensão ".vstemplate". Veja o conteúdo de um pacote de template aqui:

Um exemplo desse arquivo ".vstemplate" é dado a abaixo:

<VSTemplate Version="2.0.0" xmlns="http://schemas.microsoft.com/developer/vstemplate/2005" Type="Project">
<TemplateData>
    <Name>ConsoleAppDemo - Lab</Name>
    <Description>ConsoleAppDemo - Lab</Description>
    <ProjectType>CSharp</ProjectType>
    <ProjectSubType>
    </ProjectSubType>
    <SortOrder>1000</SortOrder>
    <CreateNewFolder>true</CreateNewFolder>
    <DefaultName>ConsoleAppDemo - Lab</DefaultName>
    <ProvideDefaultName>true</ProvideDefaultName>
    <LocationField>Enabled</LocationField>
    <EnableLocationBrowseButton>true</EnableLocationBrowseButton>
    <Icon>__TemplateIcon.ico</Icon>
</TemplateData>
<TemplateContent>
    <Project TargetFileName="ConsoleAppDemo1.csproj" File="ConsoleAppDemo1.csproj" ReplaceParameters="true">
      <ProjectItem ReplaceParameters="true" TargetFileName="Program.cs">Program.cs</ProjectItem>
      <Folder Name="Properties" TargetFolderName="Properties">
        <ProjectItem ReplaceParameters="true" TargetFileName="AssemblyInfo.cs">AssemblyInfo.cs</ProjectItem>
      </Folder>
    </Project>
</TemplateContent>
</VSTemplate>

No template acima, temos um padrão de projeto baseado no arquivo ConsoleAppDemo1.csproj, que foi o projeto base a partir do qual geramos o template. Isso aparece no tag <TemplateContent>.

Outros exemplos de arquivos de template podem agrupar soluções com vários projetos, como vemos a seguir:

<?xml version="1.0" encoding="utf-8" ?>
<VSTemplate Version="2.0.0"   xmlns="http://schemas.microsoft.com/developer/vstemplate/2005" Type="ProjectGroup">
<TemplateData>
    <DefaultName>Template Solution Test - ClassLibraries 1 e 2</DefaultName>
    <Name>Template Solution Test - ClassLibraries 1 e 2</Name>
    <Description>Template Solution Test - ClassLibraries 1 e 2</Description>
    <Icon>Default.ico</Icon>
    <ProjectType>CSharp</ProjectType>
    <CreateNewFolder>false</CreateNewFolder>
    <DefaultName></DefaultName>
    <ProvideDefaultName>false</ProvideDefaultName>
</TemplateData>
<TemplateContent>
    <ProjectCollection>
      <ProjectTemplateLink ProjectName="ClassLibrary1">
        .\ClassLibrary1\ClassLibrary1.vstemplate
      </ProjectTemplateLink>
      <ProjectTemplateLink ProjectName="ClassLibrary2">
        .\ClassLibrary2\ClassLibrary2.vstemplate
      </ProjectTemplateLink>
    </ProjectCollection>
</TemplateContent>
</VSTemplate>

No exemplo acima, note que o tag <TemplateContent> contém agora o tag <ProjectCollection>, onde encontramos a referência para dois templates de projetos previamente gerados:

<ProjectTemplateLink ProjectName="ClassLibrary1">
.\ClassLibrary1\ClassLibrary1.vstemplate
</ProjectTemplateLink>

<ProjectTemplateLink ProjectName="ClassLibrary2">
.\ClassLibrary2\ClassLibrary2.vstemplate
</ProjectTemplateLink>

Assim, criando os templates de projetos individuais, podemos gerar um template de solução, que agrupa vários projetos, para customizações mais completas. O pacote .zip final com o template gerado é colocado na pasta:

"C:\Documents and Settings\user\My Documents\Visual Studio 2005\My Exported Templates"

Mas ainda é possível criar novas pastas, agrupando templates por projetos, departamentos, funcionalidades, etc. No momento da criação de uma nova solução ou projeto, os templates previamente gerados são oferecidos ao desenvolvedor, que agora não inicia o desenvolvimento do zero. Até aqui, falamos de templates de projetos, mas o mesmo mecanismo funciona para templates de arquivos ou recursos individuais de um projeto, chamados de Item Template.

Uma boa referência sobre a criação de templates você encontra aqui, com uma série de links sobre os tags e funcionalidades dos arquivos ".vstemplates":

Create Reusable Project And Item Templates For Your Development Team
http://msdn.microsoft.com/msdnmag/issues/06/01/codetemplates/default.aspx

No próximo post, vamos falar das customizações sobre o SDK v4.0 do Visual Studio 2005.

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

Waldemir.

Gramáticas, Linguagens e Compiladores: um retorno às bases.

wcamb — Mon, 14 Jan 2008 00:57:00 GMT

Olá pessoal, tudo certo?

No post anterior iniciamos nossa discussão sobre guias e DSL's. E já que o assunto envolve a definição de linguagens e geração de código, pensei em voltar um pouco às bases.

Quando pensamos em linguagens, podemos citar duas formas básicas para a formalização de linguagens de programação: as gramáticas (com suas leis de formação) e as regras de testes ou reconhecedores (com suas regras de validação).

Podemos definir uma gramática como um conjunto de leis de formação que definem de maneira rigorosa o modo de geração de textos corretos de uma linguagem. Assim, partindo-se de uma gramática, é possível gerar textos válidos na linguagem-alvo. Da mesma forma, uma linguagem é um conjunto de todos os textos que podem ser gerados a partir da gramática que define aquela linguagem.

Logo, gramáticas são mecanismos geradores, que permitem a síntese de textos pertencentes a uma determinada linguagem. A base desse assunto é a Hierarquia de Chomsky. Algumas referências sobre o assunto você encontra aqui:

Chomsky Hierarchy
Ref.: http://en.wikipedia.org/wiki/Chomsky_hierarchy

A Hierarquia de Chomsky define tipos diferentes de linguagens, de acordo com a rigidez de suas gramáticas e regras de formação. De forma resumida, citamos 4 tipos de gramáticas:

Gramáticas Irrestritas ou de tipo 0 (zero)
Gramáticas Sensíveis ao Contexto ou de tipo 1
Gramáticas Livres de Contexto ou de tipo 2
e finalmente as Gramáticas Lineares ou de tipo 3, as que possuem maior importância para o estudo e desenvolvimento de compiladores.

Durante o processo de definição de uma linguagem, podemos usar as chamadas meta-linguagens. Por exemplo, pense numa meta-linguagem quando temos um texto escrito em português para definir a gramática inglesa. Nesse caso, português é a meta-linguagem, usada para explicar a gramática alvo, a gramática inglesa. Em computação, uma meta-linguagem muito conhecida é a BNF ou "BACKUS-NAUR FORM". Veja um exemplo de BNF abaixo:

<syntax> ::= <rule> | <rule> <syntax>
<rule> ::= <opt-whitespace> "<" <rule-name> ">" <opt-whitespace> "::="
<opt-whitespace> <expression> <line-end>
<opt-whitespace> ::= " " <opt-whitespace> | ""
<expression> ::= <list> | <list> "|" <expression>
<line-end> ::= <opt-whitespace> <EOL> | <line-end> <line-end>
<list> ::= <term> | <term> <opt-whitespace> <list>
<term> ::= <literal> | "<" <rule-name> ">"
<literal> ::= '"' <text> '"' | "'" <text> "'"

Outro exemplo simples de definição em BNF, para formação de expressões como 000101, 010101, 11100101, etc, é dada abaixo:

<integer> ::= <digit><integer> | <digit>
<digit> ::= 0 | 1

Conceitos como terminais, símbolos, vocabulários, entre outros, são elementos da definição de linguagens de programação. Veja alguns links sobre BNF aqui:

Backus–Naur form
Ref.: http://en.wikipedia.org/wiki/Backus-Naur_form

Finalmente, temos o desafio de construir nosso gerador de código ou compilador. Entenda os geradores de código como programas específicos, que trazem alguma sofisticação, mas que na verdade são baseados em rotinas simples e bem definidas. Tipicamente, um compilador apresenta os seguintes componentes:

Funções de acesso a arquivos (acesso físico ao disco)
Funções de acesso lógico
Funções para extração de caracteres
Analisador Léxico
Analisador Sintático
Otimizador ou analisador semântico
e o Gerador de código

Veja maiores detalhes sobre cada componente de uma compilador aqui:

Ref.: http://en.wikipedia.org/wiki/Compiler

A figura abaixo apresenta um mapa das principais atividades realizadas por um compilador, para ilustrarmos melhor esse post.

E uma leitura importante sobre compiladores sempre é o livro do dragão :)

Compilers: Principles, Techniques, and Tools (2nd Edition)
Ref.: http://www.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811

Durante o processo de definição e construção de nossos guias de automação ou mesmo nossas DSL's não vamos precisar aplicar toda a rigidez do processo envolvido na construção de compiladores, interpretadores ou mesmo geradores de código para linguagens formais. Porém, muitos dos elementos da teoria de compilação são ferramentas importantes para o arquiteto nesse processo. Conhecer essas teorias e manter uma leitura constante desses assuntos é sem dúvida um diferencial.

Como arquitetos, retornar as bases de tempos em tempos é uma prática saudável. :)

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

Waldemir.

Guidance Automation Toolkit, Software Factory, Domain-Specific Languages e outros assuntos.

wcamb — Fri, 11 Jan 2008 19:46:00 GMT

Olá pessoal, tudo certo?

Nos últimos posts temos falado sobre frameworks, templates e temas relacionados com a produtividade de software. Reusabilidade de serviços, otimização, qualidade na codificação e desafios no desenvolvimento são tópicos sempre recorrentes. Em linhas gerais, o mundo da arquitetura de software sempre envolve essas questões e cabe ao arquiteto direcionar suas equipes para a correta adoção das melhores práticas para uma codificação de qualidade e com produtividade. Existem diversas ferramentas que suportam o arquiteto nessa tarefa. Como exemplo, podemos citar as Fábricas de Software (Software Factories).

Sobre esse tema, vale recomendar o livro "Software Factory" de Jack Greenfield, uma leitura obrigatória sobre o assunto.

Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools
Ref.: http://www.amazon.com/Software-Factories-Assembling-Applications-Frameworks/dp/0471202843/ref=sr_1_1?ie=UTF8&s=books&qid=1200059711&sr=1-1

Outro elemento importante nessa discussão são as DSL'S - Domaing-Specific Languages, que permitem a construção de ferramentas visuais para a composição de soluções, gerando código de forma automática e com grande controle sobre a qualidade do código gerado. O desenvolvimento de uma DSL passa pelo entendimento do negócio, assim como os artefatos de software que serão utilizados, como bibliotecas, templates, patterns de desenvolvimento, etc.

Uma leitura recomendada sobre DSL's é o livro "Visual Studio DSL Tools", da série Microsoft .NET Development.

Domain-Specific Development with Visual Studio DSL Tools (Microsoft .NET Development Series)
Ref.: http://www.amazon.com/Domain-Specific-Development-Visual-Studio-Microsoft/dp/0321398203/ref=pd_bbs_1?ie=UTF8&s=books&qid=1200059661&sr=8-1

Mas antes de avançarmos sobre Fábricas de Software ou DSL's, vamos falar um pouco sobre ferramentas de extensibilidade e guias de automação. Nesse ponto, a Microsoft oferece já há algum tempo o pacote GAT - Guidance Automation Toolkit, de fato o fundamento para o trabalho com Fábricas de Software e Linguagens de Domínio Específico.

Veja os links para download abaixo (GAT/GAX são ambos necessários):

GAX - Guidance Automation Extensions - que fornece o núcleo de ferramentas, templates e assistentes para a criação de guias de automação;
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=C0A394C0-5EEB-47C4-9F7B-71E51866A7ED&displaylang=en

GAT - Guidance Automation Toolkit - que permite a construção de guias e navegadores sobre os artefatos utilizados em sua solução de automação.
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=E3D101DB-6EE1-4EC5-884E-97B27E49EAAE&displaylang=en

Os pacotes GAT/GAX adicionam ao ambiente do Visual Studio a infra-estrutura necessária de linguagens e ferramentas para a construção de pacotes de automação para geração de código. O objetivo é automatizar a codificação, baseando-se em templates e modelos de codificação que o arquiteto selecionou como melhores práticas para um nicho de solução específico. Por exemplo, podemos pensar na automação de um cenário para construção de aplicações ASP.NET, que faça uso de bibliotecas de um framework corporativo e que utilize templates de navegação otimizados e homologados pela equipe de arquitetura. O objetivo num cenário como esse é garantir que os desenvolvedores tenham produtividade durante a construção de novas aplicações, enquanto que as variações de soluções nesse mesmo domínio ficam sob controle. Essa geração dinâmica de código ocorre sobre uma linguagem de templates, a Text Templating Transformation Toolkit ou simplesmente T4.

O exemplo abaixo em template T4 gera um código C# que implementa uma classe para escrever "Hello Iteration: n", onde n é o número de iterações que passamos como parâmetro para o template:

Finalmente, como parte dessa preparação para tabalharmos com GAT/GAX, devemos instalar 2 pacotes importantes:

Enterprise Library 3.1 - May 2007
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=4C557C63-708F-4280-8F0C-637481C31718&displaylang=en

Visual Studio 2005 SDK Version 4.0
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=51A5C65B-C020-4E08-8AC0-3EB9C06996F4&displaylang=en

Nos próximos posts, vamos avançar no assunto, discutindo alguns aspectos importantes sobre GAT/GAX, enquanto evoluímos juntos rumo a DSL's de sucesso! :)

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

Waldemir.