Resumo: Recentemente o grupo Patterns & Practices, da Microsoft, lançou uma série de Software Factories, dentre as quais temos o Web Client Software Factory (WCSF). Neste artigo vamos explorar a parte conceitual do WCSF, entender melhor em que cenários aplicá-lo, quais as motivações e qual a arquitetura de uma aplicação utilizando o Web Client Software Factory.

Conteúdo

Nesta página

Introdução
Composite Web Application Block
Pattern View-Presenter
Page-flow Application Block
Conclusão
Referências

Introdução

Assim como outras áreas já passaram por este processo, a área de software precisa formalizar e otimizar mais os processos de desenvolvimento, porém entregando um produto que possua qualidade e confiabilidade.

O intuito das Software Factories, lançadas pelo grupo P&P, é levar aos desenvolvedores e arquitetos, mais do que uma ferramenta, um conjunto de práticas comprovadas que possam ser agregadas aos softwares, dessa forma otimizando processos, aumentando a produtividade e garantindo uma ponto inicial que ajude a manter a qualidade do produto durante o desenvolvimento.

Como foi citado anteriormente o Web Client Software Factory é mais que um componente ou uma ferramenta, é um conjunto de práticas comprovadas, isso fica claro na figura abaixo retirada do Help do WCSF.

Figura 1 - Conteúdo do WCSF

Na figura 1 vemos que o conteúdo trazido pelo WCSF permite tanto um embasamento teórico como templates e designers que na prática irão aumentar a produtividade no desenvolvimento de softwares no Visual Studio 2005. Assim como outras ferramentas do grupo P&P, o WCSF possui o código-fonte aberto e é extensível e adaptável às necessidades de quem estiver incorporando-o aos projetos.

O público alvo do WCSF é basicamente formado por arquitetos e desenvolvedores, sendo que cada um destes vê no WCSF diferentes benefícios.

Para arquitetos são listados os seguintes benefícios:

• Promove uma abordagem padrão ao desenvolvimento de software;

• Promove a re-usabilidade de componentes compartilhados de arquitetura de patterns;

• Omite certa complexidade;

• Permite que desenvolvedores se concentrem codificando regras de negócio.

Para desenvolvedores temos os seguintes benefícios:

• Focar o desenvolvimento no negócio do software;

• Re-utilizar componentes de infraestrutura;

• Utilizar patterns para o desenvolvimento dos softwares.

Juntando arquitetos e desenvolvedores e pensando no cenário de times, temos mais benefícios ainda, pois trabalhando com o WCSF vemos que o projeto começa um ponto a frente do que normalmente começaria, pois uma das partes mais críticas, e que mais podem comprometer o projeto caso seja mal planejada, já está planejada, documentada e com implementações de referências. O trabalho necessário é o de estudar o produto e colocá-lo no contexto do projeto.

As capacidades técnicas do WCSF, que serão estudadas em mais detalhes durante o artigo são as seguintes: Modularidade, Experiência de Usuário, Pageflow, Deployment e updates, Segurança, Gerenciamento de estado, Gerenciamento de erros e Comunicação com Webservices.

Modularidade

O que diferencia uma Aplicação Web de uma Aplicação Web Modular é que a segunda é composta por uma série independente de componentes que são integrados em um servidor. Para o usuário que está acessando a aplicação não existe diferença entre os dois tipos de aplicação, ambas são apresentadas como uma aplicação completa.

Na seção que descreve o Composite Web Application Block entenderemos melhor as vantagens da Modularidade em softwares, porém podemos adiantar algumas agora:

• Alto nível de separação entre componentes de infraestrutura e de lógica de negócio;

• Maior independência no desenvolvimento dos componentes de negócio;

• Promove re-usabilidade;

Arquiteturas modulares combinam perfeitamente com a chamada Arquitetura Orientada à Serviços. A granularidade dos Web Services podem ser baseadas em módulos de negócios. É perfeitamente natural que seja feita essa divisão, e que os sistemas sejam construídos no topo desses Web Services baseados em módulos de negócios.

O fato de módulos não possuírem forte dependência entre eles, permite que eles sejam atualizados, desenvolvidos e implantados independentemente.

Application Blocks

Application Blocks são códigos-fonte, reusáveis, que provêm soluções para problemas comuns no desenvolvimento de softwares. Eles podem ser integrados em aplicações, estendidos ou customizados de acordo com as necessidades especificas de cada software.

Composite Web Application Block

Um dos pilares do Web Client Software Factory é construir aplicações modulares. Isso é conseguido através do Composite Web Application Block. Veremos abaixo algumas metas desse application block e o motivos destas.

1. Decompor Web sites complexos – através da decomposição de um software em módulos temos vantagens referentes ao desenvolvimento da aplicação, consistência da arquitetura, implantação e atualização do software.

2. Diminuir a dependência entre times de desenvolvimento – se o software estiver dividido em módulos, times de desenvolvimento podem ser especializados para o módulo que devem implementar, seja especializado em conhecimento técnico para implementar determinado módulo ou para entender a regra de negócio de cada módulo. Além do que, a decomposição em módulos permite separar times que desenvolvem módulos de negócio de times que desenvolvem componentes de infraestrutura.

3. Utilizar uma arquitetura que promova re-usabilidade – módulos que servem de base para a aplicação, normalmente módulos de infraestrutura, podem ser reusados em outras aplicação com nenhuma, ou muito pouca, alteração de código.

4. Promover práticas de segurança – modularizar a aplicação facilita que sejam verificadas as superfícies que podem servir de ataque.

5. Maximizar a cobertura de testes baseados em código – colocando toda a regra de negócio em módulos, ao invés de colocar muito da lógica na interface, facilita que sejam escritos testes unitários para testar cada módulo.

Separação de Áreas

Como citado anteriormente, uma das grandes metas do Composite Web Application Block é permitir que times sejam divididos de acordo com especialidades, permitindo assim aumentar a qualidade do produto desenvolvido e também a produtividade dos desenvolvedores, que irão se concentrar em uma tarefa especifica. A figura 2 ilustra melhor como ficaria uma aplicação web sendo desenvolvida com o Composite Web Application Block, e tendo como foco a divisão das tarefas de acordo com as áreas.

Figura 2 - Separação de áreas com o Composite Web Application Block

O Composite Web Application Block separa as áreas em basicamente três:

• Web site e elementos compartilhados da interface do usuário;

• Lógica de negócio;

• Componentes de infraestrutura.

Design do Composite Web Application Block

Os módulos do Composite Web Application Block são divididos basicamente em duas categorias:

• Business Modules – Os módulos deste tipo são normalmente independentes um dos outros e não expõe funcionalidades para outros módulos, porém contém web pages para interação com o usuário. Além de serem referentes à uma determinada área de negócio da aplicação.

• Foundation Modules – Os módulos deste tipo são normalmente compartilhados entre Business modules e não contém web pages. É normal que sejam módulos que definem componentes de infra.

Figura 3 - Usuário interagindo com os módulos

Pattern View-Presenter

Quando temos uma aplicação Web, as páginas contêm o código necessário para solicitar dados e responder aos eventos do usuário. Implementando a lógica da página no code-behind enfrentamos dois problemas: testar o código e compartilhar o mesmo código em outras páginas que contenham o mesmo comportamento.

Para resolver o problema de reuso de código em diferentes páginas e o problema de teste podemos utilizar o pattern view-presenter. Nesse tipo de pattern a lógica de responder aos eventos do usuário e de exibir informações é separada. A View contém a lógica para exibir informações, enquanto a Presenter contém a lógica para responder aos eventos.

Figura 4 - Modelo do Pattern View-Presenter

O pattern View-Presenter pode ser implementado de diversas formas. Por exemplo, com o pattern Observer você pode ter o Presenter “escutando” por eventos e então atualizar a View conforme necessário. Também é possível implementar o pattern View-Presenter junto com o Pattern MVC. É importante ressaltar que só quem deve se comunicar com o Modelo é o Presenter.

Quanto ao problema relativo à Testes, é possível implementar o Presenter e testá-lo sem que a View esteja implementada. Criando uma implementação “falsa” da View o Presenter pode ser testado usando teste-unitário. Dessa forma se várias implementações diferentes da View consumirem o Presenter, este só será testado uma vez.

Page-flow Application Block

Com o Page-flow Application Block é possível remover das páginas Web a lógica de navegação e deixar essa tarefa para um workflow. Esse projeto com workflows é responsável por orquestrar o processo de navegação da aplicação Web. Essa tarefa de orquestrar a navegação pode ser algo simples, com um fluxo fixo e com páginas fixas ou pode envolver tarefas mais complexas onde a navegação depende de um mecanismo de regras ou da interação do usuário com o sistema.

Existem patterns aonde o uso de controladores permite retirar da página Web a lógica da navegação, porém a vantagem do Page-flow Application Block é que temos um framework já construído para esse propósito especifico e por ser construído com base no Workflow Foundation, é possível estender esse application block e utilizar recursos do Workflow Foundation que ainda não estejam inseridos.

Abaixo temos duas imagens comparando como seria a navegação utilizando um controlador ou mesmo colocando a lógica na página e outra mostrando como é feito utilizando o Page-flow Application Block.

Figura 5 - Lógica de navegação inserida em controlador/página

Figura 6 - Lógica de navegação com o Page-flow AB

Apesar de utilizar o Windows Workflow Foundation, para utilizar o Page-flow Application block não é necessário um grande conhecimento a respeito dessa plataforma. Através da documentação do próprio application block é possível entender os requisitos e iniciar o uso.

As seguintes funcionalidades são cobertas pelo Page-flow Application block:

• Navegação – O Page-flow Application block suporta estruturas complexas de navegação, envolvendo operadores de decisão e repetição.

• Botão voltar – Em aplicações Web é necessário prever o uso do botão Voltar do navegador, para que a lógica da navegação não seja comprometida. É necessário prever se as atividades de negócio poderão ser executadas novamente e deixar claro para o usuário qual a resposta do software.

• Navegação Dirigida à dados – Em muitas aplicações a navegação está ligada diretamente a dados inseridos pelo usuário ou capturados de fontes externas. Utilizando o Page-flow Application block é possível criar estruturas que utilizem estes dados para decidir os próximos passos da navegação.

• Reuso – É possível criar workflows que sejam reutilizados por outros. Se temos uma seqüência de tarefas comuns em vários processos executados no software, é possível separar isso em um workflow e fazer com que outros workflow utilizem-no.

• Suspender e Continuar – Muitos processos podem demorar dias, semanas ou até meses para que sejam finalizados. É possível armazenar instâncias de workflow que estejam sendo executadas e quando necessário continuar a sua execução. Isso armazenado e não ocupa recursos no servidor enquanto estiver ocioso.

• Abandono – É possível abandonar um processo que está sendo executado. Essa ação de encerrar um processo pode estar inserida na lógica do workflow de dependendo de regras inseridas é realizada a finalização do processo.

A figura abaixo mostra a estrutura do Page-flow Application block.

Figura 7 - Estrutura do Page-flow Application Block

Conclusão

Como vimos, o Web Client Software Factory provê uma série de recursos e técnicas comprovadas, que permitem estruturar e desenvolver aplicações web modulares. Desafios comuns como testar código de páginas web e remover das páginas a lógica de navegação são alguns dos requisitos que o WCSF cobre facilita o trabalho de desenvolvedores e arquitetos que se preocupam em manter uma solução consistente e de fácil manutenção.

Referências

• http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=pt-BR&EventID=1032335777&CountryCode=BR – Webcast sobre Web Client Software Factory (Português).

• http://www.codeplex.com/websf -Página do Web Client Software Factory

• http://www.microsoft.com/patterns - Página do grupo Patterns & Practices

• http://thespoke.net/blogs/dfa.oliveira/ - Blog pessoal