Projetos de arquitetura para Smart Clients compostos com CAB e SCSF

Publicado em: 21 de junho de 2007

Por Mario Szpuszta

Resumo: As ofertas da Microsoft para construir Smart Clients compostos incluem o CAB (Composite UI Application Block) e a SCSF (Smart Client Software Factory) do Patterns & Practices Group. Este artigo revela os detalhes arquiteturais do CAB e da SCSF e mostra como projetar Smart Clients compostos, com esses recursos. Os exemplos são tirados de um projeto Smart Client de desktop integrado para banco, realizado na software house RACON Software GmbH, pertencente ao Raiffeisen Banking Group na Alta Áustria.

 

Conteúdo

Nesta página

Orientação arquitetural para Smart Clients compostos
Smart Clients compostos: cenário do mundo real
CAB (Composite UI Application Block)
Como projetar o shell e os serviços de infra-estrutura
Serviços de infra-estrutura
Como projetar e empacotar WorkItems
Estratégia dirigida a caso de uso
WorkItems controladores de módulos
Exclusão dos casos de uso
Sub-WorkItem ou WorkItem
Resumo-Identificação-WorkItem
Estratégia dirigida àentidade do negócio
Empacotamento de WorkItems em módulos
Smart Client Software Factory
Palavras finais
Sobre o autor

Orientação arquitetural para Smart Clients compostos

Smart clients são extremamente úteis para quem quiser atingir um grupo bem conhecido de usuários, com requisitos avançados. Quase sempre, somos levados a resumir as vantagens dos Smart Clients aaspectos simplistas, como uma interface de usuário de boa aparência. Embora, sem dúvida, isso seja significativo, se analisarmos a definição no MSDN, existem fatores mais importantes. De acordo com essa definição, um Smart Client éum aplicativo Windows, que cumpre os seguintes critérios:

• Além de oferecer excelentes interfaces de usuário, o Smart Client usa recursos locais,disponíveis aos clientes, inclusive de hardware, assim como componentes e aplicativos instalados no local.

• Aplicativo conectado, que troca informações com os serviços da Internet ou com a rede local da empresa.

• Embora seja um aplicativo conectado, o Smart Client fica off-line e pode deixar a conectividade o mais transparente possível para o usuário.

• Por fim, mas não menos importante, a implantação (deployment)inteligente e a atualização são critérios-chave de um Smart Client. Incluem-se nesses aspectos mecanismos como a implantação do ClickOnce (no-touch) e as atualizações automáticas.

Embora esses conceitos gerais apliquem-se aos Smart Clients, muitas vezes as empresas têm outras necessidades. Seus usuários desejam trabalhar com desktops integrados como, por exemplo, um shell comum que hospede diferentes tipos de aplicativos, com integração transparente e uma forma comum e simplificada de se trabalhar com eles. Essestipos de Smart Clients denominam-se Smart Clients compostos. Um Smart Client composto oferece ao cliente uma solução composta de várias e diferentes peças funcionais, os assim denominados módulos ou plug-ins, integrados em um ambiente hospedeiro comum.

Smart Clients compostos: cenário do mundo real

Estive pessoalmente envolvido na criação da arquitetura de um desktop comum para banco, de uma empresa do Raiffeisen Banking Group na cidade de Linz, Alta Áustria. O Raiffeisen Banking Group éo maior grupo de bancos privados na Áustria, com cerca de 2600 agências bancárias. O desenvolvimento de software para aplicativos bancários é, basicamente, gerenciado pela RACON Software GmbH, principal responsável pelos produtos de software de todos os bancos Raiffeisen da Alta Áustria. De modo geral, esses bancos têm muitos e diferentes aplicativos para, por exemplo, gerenciar os processos de empréstimos ou as transações de seguro e negócios de câmbio. Como um dos requisitos, os proprietários queriam que esses aplicativos pudessem compartilhar aspectos comuns, como o gerenciamento de clientes, inclusive busca e acesso às respectivas contas.

Depois de consolidar o cenário do lado dos serviços em um grande conjunto de Web Services, a RACON Software GmbH concluiu que tinha um cenário do lado do cliente construído com muitos e diferentes aplicativos, utilizando diferentes infra-estruturas. Como resultado, havia funcionalidades duplicadas e propagação de muitas interfaces de usuário, de vários tipos, em todo o banco. A meta era introduzir um desktop comum, como uma base nova para todos esses aplicativos para simplificar o dia-a-dia do usuário, conservando os aplicativos bancários existentes.

Os motivos básicos do negócio incluíam a necessidade de reduzir os custos de treinamento e manutenção, minimizando a quantidade de aplicativos e consolidando os serviços comuns de atendimento ao cliente em uma infra-estrutura única.

A idéia era criar um "shell do banco" que funcionasse como um ponto de entrada central, hospedando todos os aplicativos. O acesso ao aplicativo seria baseado em papéis (role-based), embora a aparência e a sensação (look and feel)fundamentais, além do comportamento de todos os aplicativos hospedados no shell tivessem de ser idênticos para todos os usuários. Como algumas agências tinham apenas conexões de largura de banda baixa com o backbone, estratégias de cache inteligente também eram necessárias para manter os aplicativos em funcionamento. Além disso, para alguns funcionários, era preciso ter uma capacidade de desconexão, para trabalho off-line. Finalmente, era preciso ter uma excelente interface de usuário, assim como integração com aplicativos do Microsoft Office instalados localmente no cliente. Com estes requisitos de configuração, embora a RACON Software GmbH quisesse integrar os aplicativos Web existentes no desktop do banco, um aplicativo de Web, puro, não seria uma opção.

Quando começamos a analisar os aspectos técnicos, descobrimos que os requisitos para a arquitetura do Smart Clientprecisariam ser compatíveis com os seguintes aspectos:

• Arquitetura plugável para permitir o carregamento dinâmico de módulos com base na configuração e na atribuição papel-usuário, na inicialização do aplicativo ou atémesmo, mais tarde, durante o tempo de execução.

• Infra-estrutura para gerenciamento, registro e configuração de serviços comuns centrais, como agentes de Web Service, exigidos para todos ou para a grande parte dos módulos.

• Suporte para comunicação de baixo acoplamento entre os módulos e os componentes desses módulos, com base no padrão publicação/assinatura.

• Infra-estrutura existente para padrões comuns como, por exemplo, "Modelo-Visão-Controlador" (Model-View-Controller), Modelo-Visão-Apresentador (Model-View-Presenter)ou o Padrão de comando (Command Pattern).

Com os requisitos definidos, começamos a estudar os frameworks que iríamos construir para executar essa solução.

CAB (Composite UI Application Block)

Lançado em novembro de 2005 pela equipe da Microsoft Patterns & Practices, o CAB (Composite UI Application Block) éum framework para implementação de Smart Clients compostos, compatível com a maior parte dos requisitos anteriormente mencionados e foi nossa escolha inicial para implementar o shell do banco (bank-shell)para o Raiffeisen Banking Group na Alta Áustria. O CAB oferece as seguintes funcionalidades:

• Carrega de modo dinâmico módulos independentes e cooperativos em um shell comum, com base em uma configuração central.

• Dá suporte ao padrão de composição em vários níveis de peças funcionais como elementos e processos de interface do usuário ou serviços do lado do cliente.

• Event Broker para comunicação de baixo acoplamento entre peças funcionais carregadas em um aplicativo cliente.

• Implementação de padrão de comando, pronto para usar.

• Classes básicas para implementações MVC.

• Framework para serviços de infra-estrutura plugáveis como, por exemplo, serviços de autenticação, autorização, localização do módulo e serviços de carregamento de módulo.

Ao contrário de muitos outros frameworks de aplicativo do lado do cliente, o CAB não se baseia em um aplicativo shell predefinido, extensível via plug-ins: trata-se muito mais de um framework para construção de aplicativo shell extensível e de módulos que podem ser plugados neste shell, de modo dinâmico. Foi útil para este projeto, pois colocou o CAB no papel de um meta-framework acima da qual épossível construir frameworks próprios. Por fim, o CAB possibilita decidir quanto se deseja usar dos seus produtos e quanto se deseja estender ou adotar dos mesmos.

Decidimos que todo o projeto do Smart Client composto, com base em CAB, deveria adotar uma abordagem em camadas e, nessa circunstância, o CAB proporciona o framework fundamental, com toda a funcionalidade necessária para construir uma arquitetura plugável e extensível. O shell e as bibliotecas da infra-estrutura são a base do aplicativo (o framework acima do CAB), ao passo que este usa a funcionalidade do CAB para carregar plug-ins de modo dinâmico (denominados módulos) com as implementa-ções dos casos de uso do negócio. A Figura 1 descreve a arquitetura típica de um Smart Client composto, baseado em CAB.

Outro ponto interessante éque o modelo de objeto CAB oferece uma forma de projetar Smart Clients compostos usando uma abordagem dirigida a caso de uso. O seu modelo de objeto separa claramente classes controladoras de caso de uso de outroscomponentes, como visões e as respectivas classes controladoras ou apresentadoras. As classes controladoras de caso de uso, denominadas WorkItems, são responsáveis por reunirem todos os aspectos necessários de um caso de uso. Isto significa que são responsáveis por gerenciar o estado necessário de um caso de uso, agrupar as visões e os controladores necessários, gerenciar o workflow para concluir um caso de uso e, finalmente, por proporcionar o estado gerenciado para todos esses componentes.

Com a arquitetura em camadas apresentada na Figura 1 do nosso projeto, isso nos ajudou a alinhar melhor a estrutura da equipe de projeto com os processos de desenvolvimento para a criação de Smart Clients compostos com o CAB.

Aprendemos que três aspectos afetaram o processo de desenvolvimento dos Smart Clients baseados em CAB: o shell, os serviços de infra-estrutura e os casos de uso reais. Assim, recomendamos três iterações básicas para o desenvolvimento:

1. Comece a ter um entendimento de alto nível dos requisitos comuns àmaioria dos casos de uso. Requisitos comuns relativos àIU são candidatos àintegração no shell diretamente ou, no mínimo, com interferência no layout e no projeto do shell. Funcionalidades não relacionadas àIU, comum a todos (ou a quase todos) os casos de uso, são candidatos aos serviços centrais.

2. Crie diagramas detalhados de casos de uso, os quais são bons candidatos para se tornarem WorkItems (e sub-WorkItems) no projeto do aplicativo. As relações entre casos de uso são candidatas a usarem o padrão de comando ou o subsistema do Event Broker do CAB. Os WorkItems logicamente relacionados, como aqueles que implementam casos de uso para os mesmos atores (papéis de usuários na empresa) são bons candidatos para agrupamento em pacotes de módulos.

3. Refine os diagramas de casos de uso; analise as relações entre os casos de uso, assim como os aspectos relativos àreutilização e àsegurança de seus casos de uso (WorkItems). Durante esse refi-namento, talvez seja preciso refatorar um pouco o empacota-mento do WorkItem. Por exemplo, descobertas típicas são WorkItems, reutilizados independentemente de outros os quais devem, portanto, estar empacotados em um módulo separado.

Figura 1: Definição de camadas dos Smart Clients baseados em CAB

Os casos de uso identificados durante o detalhamento da análise específica são o fundamento para a identificação dos WorkItems no CAB. Se considerarmos a abordagem dirigida a caso de uso para projetar WorkItems, cada caso de uso mapeia um único WorkItem. Qualquer relação entre casos de uso no diagrama representa um indicador para dois fatos: primeiro, pode significar o confinamento de um WorkItem dentro de outro; segundo, estabelece a comunicação entre esses WorkItems, de modo definitivo. A comunicação pode ser implementada via serviços, Event Broker ou por comandos. De modo geral, refinamento e análise detalhada das relações entre os casos de uso são indicadores do tipo de relacionamento existente (pai-filho ou apenas comunicação entre os WorkItems) e, assim, ajudarão a decidir qual mecanismo de comunicação usar. Este refinamento afetarátambém a estratégia de empacotamento dos WorkItems. Portanto, éessencial ter em mente a relação refinamento-iteração, antes de iniciar o desenvolvimento de WorkItems de maior abrangência. Mais adiante, neste artigo, serão informados outros detalhes sobre a identificação e o empacotamento de WorkItems.

Figura 2: Exemplo típico de um shell com workspaces e UIExtensionSites

Como projetar o shell e os serviços de infra-estrutura

Como descrito anteriormente, as primeiras tarefas são o projeto e a implementação do shell. O shell éo aplicativo em si, responsável pelo carregamento e pela inicialização dos serviços de base do cliente, carregamento e inicialização de módulos, assim como pela IU básica do aplicativo e por hospedar as visões carregadas pelos WorkItems. O CAB fornece todas as classes básicas necessárias para o suporte dessa funcionalidade -uma classe básica para um aplicativo shell, capaz de autenticar usuários com base em um serviço central de autenticação CAB e que possa carregar módulos, dinamicamente, com base no papel do usuário registrado em um, assim denominado, catálogo de perfis, conforme anteriormente mencionado.

Figura 3: Implementação por shell de interface IShellExtension personalizada, fornecida como um serviço central

Como a interface de usuário básica de um aplicativo éfornecida pelo shell e éigual para todos os módulos carregados no aplicativo, o shell precisa ter alguns pontos de extensão e deve cumprir as exigências comuns a todos os casos de uso. Exemplos típicos de elementos comuns de interface de usuário, bons candidatos para integração no shell são: menus, barras de ferramentas, painéis de tarefa e painéis de navegação. Aqui, o ponto importante éque algumas partes do shell serão apenas estendidas (por exemplo, acrescentando um menu àbarra de menus) e outras, completamente substituídas, enquanto os módulos são dinamicamente carregados no aplicativo. Para essas finalidades, o CAB fornece dois tipos de pontos de extensibilidade que poderão ser usados quando você for projetar o seu próprio shell: UIExtensionSites e Workspaces. Os workspaces são usados para substituir todas as partes da IU, enquanto o UIExtensionSite éusado para estender as partes existentes do shell como, por exemplo, adicionar entradas de menu ou controles de barras de ferramentas (tool-strips). A Figura2 ilustra um exemplo típico de um shell projetado no Visual Studio 2005.

Os workspaces e os UIExtensionSites são públicos e disponíveis para todos os serviços e módulos carregados no aplicativo Smart Client. O CAB permite acessá-los de modo bastante genérico, como abaixo:

1workItem.UIExtensionSites[“SiteName”]Add<ToolStripButton>( new ToolStripButton());
	

Entretanto, para evitar acoplamento forte e erros, recomendo umacamada de indireção entre o shell e os componentes a serem acrescentados ao shell. Com base na funcionalidade que o shell precisa fornecer a outros componentes, pode-se projetar uma interface implementada pelo shell (ou pelo principal apresentador de visualização do shell) para estendê-lo e registrá-lo como um serviço central usado por outros componentes do CAB, conforme ilustra a Figura 3.

Este é um conceito muito simples, porém poderoso, pois os componentes carregados no Smart Client (módulos com WorkItems ou com serviços centrais) não precisam conhecer os detalhes dos nomes do espaço de trabalho ou do UIExtensionSite. Os componentes carregados no Smart Client podem acessar esses serviços, como segue:

IShellExtensionService ShellService =
WorkItem.Services.Get<IShellExtensionService>();
ShellService.AddNavigationExtension(
“Some new Menu”, null, someCommand);
	

Além disso, a implementação desta interface IShellExtension pode aproveitar a infra-estrutura CAB existente para manter projeto-IU-shell desacoplados da implementação do serviço do shell, mas os desenvolvedores que criam grandes quantidades de WorkItems não precisam conhecer nenhum detalhe, como, por exemplo, nomes de UIExtensionSites ou detalhes similares do shell. Por fim, pode-se abstrair outras funcionalidades relacionadas ao shell por meio de um dos seus serviços, por exemplo, um sistema de mensagens ou de ajuda, integrado no shell. Todavia, épreciso lembrar, a importância de a interface do shell expor apenas a funcionalidade relativa ao shell-IU. Isso significa que éo ponto certo de acesso para permitir aos componentes carregados no Smart Client estenderem-se a menus, barras de ferramentas, barra de tarefas exibidas no lado esquerdo da janela ou adicionar uma mensagem em um painel comum de mensagens (conforme apresentados nos exemplos anteriores desta seção).

Serviços de infra-estrutura

Conforme já mencionado, os serviços de infra-estrutura encapsulam funcionalidades comuns em módulos e componentes carregados no Smart Client. Ao contrário da infra-estrutura do shell, esses serviços não estão vinculados às tarefas específicas da IU. De modo mais freqüente, encapsulam a lógica do lado do cliente. O CAB, como distribuído, introduz muitos serviços de infra-estrutura como, por exemplo, um serviço de autenticação e, outro, para carregar um catálogo de módulos configurado em outro lugar (por padrão, no arquivo ProfileCatalog.xml, armazenado no diretório do aplicativo). Por certo, também épossível introduzir serviços próprios. Exemplos típicos de serviços de infra-estrutura centrais não introduzidos pelo CAB são:

• Serviço de autorização relacionado àfuncionalidade do negócio (o CAB introduz autorização apenas para carregamento de módulos, mas não para ações específicas que podem ser executadas nos módulos e no aplicativo)

• Agentes e proxies de Web Service com chamadas para Web Services e capacidade off-line encapsuladas

• Serviços de contexto para gerenciar contexto de usuário nos WorkItems (vide a seção "Contexto e WorkItems" mais adiante neste artigo)

• Serviços para acessar configurações centradas no aplicativo

• Serviços de implantação utilizando ClickOnce, em segundo plano, para atualizações programáticas, automáticas

Aprendemos que ésempre importante iniciar definindo interfaces para os serviços comuns, pois o CAB permite registrar serviços centrais baseados em tipos como abaixo:

MessageDisplayService svc = new
MessageDisplayService(_rootWorkItem);
_rootWorkItem.Services.
Add<IMessageDisplayService>(svc);
	

Figura 4: Exemplo de diagrama de casos de uso

módulos de infra-estrutura separados, carregados antes de outros módulos com implementações de caso de uso reais.

Como projetar e empacotar WorkItems

Os WorkItems são componentes responsáveis por encapsular toda a lógica de tarefas específicas que o usuário deseja realizar com o aplicativo. Dessa forma, os WorkItems são as partes centrais e mais importantes do Smart Client composto, pois fornecem a real funcionalidade do negócio aos usuários. O CAB tem condições de gerenciar a hierarquia dos WorkItems responsáveis pela realização conjunta do trabalho. Para essa finalidade, um WorkItem contém ou conhece uma ou mais visões (denominadas SmartParts) com as respectivas classes e modelos controladores. O WorkItem sabe quais SmartParts precisam ser exibidas e em que momento; sabe, também, quais sub-WorkItems precisam ser inicializados e quando. Além disso, um WorkItem-pai éo ponto de entrada de uma tarefa específica. Por fim, o WorkItem gerencia o estado necessário em todas as SmartParts/sub-WorkItems.

Durante o desenvolvimento descobrimos que existem dois modos para identificar WorkItems para Smart Clients compostos: uma abordagem dirigida a caso de uso e outra, dirigida a entidade do negócio. Alguns exemplos explicam melhor esta condição. (Note-se que, para as finalidades deste artigo, estes exemplos não são representativos do projeto com o qual eu estava envolvido, nem de qualquer outro grupo bancário.)

Estratégia dirigida a caso de uso

Uma das maiores vantagens da arquitetura do CAB éa possibilida-de de projetar os WorkItems com base nos diagramas de casos de uso.Freqüentemente, haverámapeamento entre casos de uso e WorkItems, um-a-um: de modo geral, um caso de uso será encapsulado em um WorkItem. Assim, os WorkItems nada mais são do que controladores de caso de uso, que implementam os proces-sos de interface de usuário necessários para completar um caso de uso (tarefa), reunindo todas as partes necessárias para tal. O diagra-ma de casos de uso ilustrado na Figura 4 foi projetado para um sistema de gerenciamento de ações usado para trocar opiniões com os clientes sobre as respectivas transações de títulos (negócio de ações) e atender as solicitações de transações dos títulos de clientes.

Figura 5: Exclusão de casos de usoFuncionário

O aplicativo que implementa os casos de uso na Figura 4 oferece suporte aos funcionários operacionais (front-office)para prestar serviços de consultoria aos clientes e, também, aos funcionários nas funções de apoio (back office)para concluir as transações de títulos. Para tanto, épreciso primeiramente mapear um caso de uso em um CAB-WorkItem. As relações entre os casos de uso podem ser de dois tipos: Cada caso de uso éum sub-caso de uso de outro ou um caso de uso éutilizado por muitos outros casos de uso além do próprio pai. Por certo, um caso de uso que éapenas um sub-caso de uso, não reutilizado por outros, resulta em um sub-WorkItem. Sub-casos de uso puros são sub-WorkItems, inacessíveis externamente pelos seus pais; jáos casos de uso utilizados por muitos outros casos de uso além dos próprios pais precisam estar acessíveis diretamente ou através dos respectivos WorkItems-pai.

WorkItems controladores de módulos

Os casos de uso-pai são os pontos de entrada de todos os respec-tivos sub-WorkItems. De modo geral, cada módulo possui um WorkItem pai raiz denominado Controlador de caso de uso de módulo, o qual éresponsável por gerenciar o estado exigido para sub-WorkItems diretos e fornecer o contexto certo para os mesmos. Em geral, os Controladores de caso de uso de módulo adicionam os serviços que um módulo pode oferecer a outros, recuperam referências de serviço para outros serviços que precisam, registram UIExtenionSites e comandos para inicializar um dos seus sub-WorkItems e inicializam os respectivos sub-WorkItems. Os WorkItems simples, sem sub-WorkItems ou os próprios sub-WorkItems executam, de modo geral, as mesmas etapas, excetuando-se que devem apenas registrar os serviços disponíveis em seus respectivos níveis hierárquicos. Os WorkItems controladores de caso de uso de módulo devem ser criados sempre que um módulo for carregado no aplicativo.

Figura 6: Sub-WorkItem ou WorkItem-pai

Exclusão dos casos de uso

Se observarmos mais detalhadamente o diagrama de casos de uso da Figura 5, veremos que nem todos os casos de uso se transformarão em WorkItems. Veja o caso de uso "Solicitação de contato bancário". Épreciso lembrar que desejamos projetar um Smart Client usado apenas pelos funcionários do banco. Um cliente que faz uma consulta sobre uma transação de ações (expressa pela "Solicitação de contato bancário") pode dirigir-se diretamente àrecepção, usar o site do banco pela Internet, uma solução net-banking, ou algo similar. Em qualquer das circunstâncias, este caso de uso não énada que precise ser integrado ao Smart Client para os funcionários do banco, muito ao contrário. O caso de uso "ID do cliente" precisa fazer parte do Smart Client ora em projeto. Outro exemplo éo caso de uso “Consulta off-line”. O que isso significa para o Smart Client? Serámesmo um WorkItem separado?

Figura 7: Diagrama de classes apresentando os WorkItems dos casos de uso anteriores

Isso muda alguma coisa na lógica do negócio? Não; portanto, não seráum WorkItem. Todavia, este caso de uso éum indicador de algo completamente diferente: éum indicador da necessidade de suporte off-line. Isso éalgo que, portanto, deve ser comparado com os serviços de infra-estrutura identificados anteriormente: agentes de Web Services, por exemplo, precisam ser compatíveis com detecção de conexão, armazenamentos de dados de referência off-line e atualização de filas de mensagens.

Sub-WorkItem ou WorkItem

Alguns WorkItems também se tornarão pais, embora apareçam apenas como sub-WorkItems no diagrama de casos de uso. Em geral, isso acontece quando um caso de uso pertence logicamente a um caso de uso-pai, mas em uma análise detalhada descobre-se que ele não compartilha estado, contexto, nem nada mais com seu pai ou outros sub-casos de uso originais e, também, não depende de outras características comuns. Nesse caso, para evitar sobrecarga desnecessária, serápreciso transformá-los em WorkItems-pai também. Observe atentamente os casos de uso "Localizar ações" e "Localizar negócio" no diagrama de casos de uso da Figura 6. Esses casos de uso são utilizados apenas para localizar ações ou transações de negócio solicitadas. Não dependem do estado compartilhado, nem do contexto dos respectivos WorkItems-pai. Assim, são candidatos perfeitos para se tornarem, eles mesmos, em WorkItems-pai, chamados por meio de comandos registrados pelo módulo (mais precisamente, o WorkItem controlador de módulo) ao qual pertencem.

Resumo-Identificação-WorkItem

Finalmente, após criar os diagramas de casos de uso, mapeá-los de acordo com os WorkItems e, depois, excluir os casos de uso refatorando a hierarquia dos WorkItems, você obteráuma hierarquiacompleta de objetos WorkItem para os Smart Clients compostos, demodo similar ao quanto ilustra a Figura 7.

Em nome do desempenho e da simplicidade, recomendo, sem dúvida, manter os diagramas de casos de uso e, conseqüentemente o WorkItem, o mais simples possível. A vantagem da abordagem acima descrita éclara: uma forma estruturada para identificar WorkItems e, especialmente, identificar os aspectos de reutilização dos WorkItems.

Estratégia dirigida àentidade do negócio

Uma abordagem muito mais simples, para aplicativos menores, simples, éidentificar e estruturar os WorkItems com base nas entidades donegócio processadas pelo aplicativo Smart Client. Cria-se uma lista de entidades do negócio processada pelo aplicativo. Exemplos típicos são: Cliente, Produto, Ações, StockCredit, StockDebit e StockTransfer. Para cada uma dessas entidades cria-se um WorkItem. Como StockTransfer éuma combinação de ambos, usa o StockCredit e o StockDebit como sub-WorkItems.

Empacotamento de WorkItems em módulos

Depois de identificar os WorkItems, serápreciso empacotá-los em módulos. Módulo éuma unidade de implantação de Smart Clients baseados em CAB. Basicamente, o pacote écomposto de WorkItems logicamente relacionados, que endereçam o mesmo espaço do negócio em um módulo. Tendo como base o diagrama original de casos de uso da Figura 4, isso representaria criar um módulo para consultar ações, outro para WorkItems do negócio de ações e um último, para o gerenciamento de ações, conforme apresentado pela Figura 8.

Todavia, existem alguns critérios adicionais para a decisão sobre o empacotamento dos WorkItems em módulos. Esses critérios adicionais são:

• Segurança

• Possibilidade de configuração

• Reutilização

Antes de qualquer coisa, os módulos são configurados em um catálogo de perfis, que contém uma lista de módulos CAB, os quais precisam ser carregados de modo dinâmico no momento em que o Smart Client composto éinicializado. Esses módulos podem ser configurados com base em uma associação com o papel do usuário. Assim, a segurança desempenha um papel central na decisão sobre como empacotar os WorkItems em módulos.

Digamos que um usuário não tenha autorização para gerenciar nenhuma ação, conforme apresentado nos casos de uso acima mencionados. Mas, definitivamente, um usuário não autorizado a criar/bloquear novas ações precisaráencontrá-las para realizar tarefas. Ao configurar o módulo de gerenciamento das ações (que contém o WorkItem "Localizar ações", de acordo com o pacote da Figura 8) de forma a evitar que os funcionários do banco que trabalham em funções de apoio (back office)o utilizem, estes também não poderão usar o WorkItem "Localizar ações". Todavia, como eles precisam desse WorkItem para outras tarefas, faz sentido empacotá-lo em um módulo separado. Se for preciso reutilizar WorkItems de forma independente de outros, também ébom encapsulá-los em módulos separados. Da mesma forma, se for preciso configurá-los separadamente, basta colocá-los em módulos separados.

No exemplo apresentado na Figura 8, isto éválido para os WorkItems "Localizar ações", "Localizar negócio" e "Cobrança de pedido de ações". Portanto, vale a pena encapsulá-los em módulos separados, conforme ilustra a Figura 9.

Se, ao final, os requisitos de configuração, segurança e reutili-zação forem equivalentes (ou quase) para alguns dos WorkItems transferidos para módulos separados, conforme a Figura 9, também épossível empacotá-los em um módulo, em lugar de três.

Por exemplo, se os requisitos de segurança, configuração e reutilização de todos os WorkItems "Localizar X" forem iguais, pode-se criar um módulo contendo todos os WorkItems "Localizar X".

Por fim, éimportante ressaltar que cada módulo resultaráem um assembly .NET separado. Depois de criados o shell e os serviços de in-fra-estrutura e de estarem identificados todos os WorkItems, inclusive a respectiva estrutura de empacotamento, as equipes de desenvolvi-mento podem começar a desenvolver os módulos e seus WorkItems.

Smart Client Software Factory

Embora o CAB proporcione uma ótima infra-estrutura, a curva de aprendizado, para alguns, pode ser longa. Além disso, o trabalho com CAB exige que os desenvolvedores realizem muitas etapas manuais como, por exemplo, a criação de classes herdadas da classe base do WorkItem para criar um controlador de caso de uso ou para criar classes controladoras, visualizadoras e modeladoras, manual-mente. Nos projetos do mundo real, com grandes equipes, estes procedimentos podem resultar em práticas muito diferentes para a realização dessas etapas, pois cada desenvolvedor tem preferências e estilos de trabalho individuais.

A SCSF (Smart Client Software Factory) éuma extensão do Visual Studio 2005 Professional (ou superior) para automatizar e simplificar essas tarefas. Baseia-se nas Extensões do Guia de Automação (GAX) também oferecidas pela equipe da Microsoft Patterns & Practices. As GAXs formam uma infra-estrutura que permite aos arquitetos e princi-pais desenvolvedores criar extensões no Visual Studio, facilmente, para automatizar tarefas típicas de desenvolvimento, tendo como principal objetivo aplicar e assegurar diretivas e diretrizes comuns para seus projetos. A SCSF proporciona essas diretrizes para Smart Clientsbaseados em CAB e automatiza tarefas como a criação de novos módulos, visões baseadas no padrão MVP, publicações e assinaturas de eventos. Os artigos MSDN, abaixo, podem ser consultados para mais informações sobre SCSF e GAX:

Figura 9: Novo empacotamento, conforme requisitos de segurança e reutilização

https://msdn.microsoft.com/vstudio/teamsystem/workshop/gat/default.aspx

https://msdn.microsoft.com/vstudio/teamsystem/workshop/gat/intro.aspx

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/ dnpag2/html/scsflp.asp

A SCSF éuma ferramenta muito útil pois oferece suporte aos desenvolvedores na criação de Smart Clients baseados em CAB respeitando, ao mesmo tempo, as decisões arquiteturais e, ainda,aumentando a produtividade do desenvolvedor devido às tarefas integradas e automatizadas no Visual Studio 2005.

Palavras finais

Com o CAB e a SCSF, a equipe da Microsoft Patterns & Practices oferece uma poderosa infra-estrutura para a criação de Smart Clients compostos. O processo de análise dirigido a caso de uso para identificar WorkItems empacotados em módulos, carregados dinamicamente pelo shell, oferece uma excelente forma para identificar funcionalidades centrais, reutilizáveis, para Smart Clients compostos, maiores. Este procedimento evita a implementação duplicada e, assim, reduz o custo de manutenção. Enquanto o CAB fornece todas as classes básicas necessárias em seu framework, a SCSF acrescenta os pacotes orientativos necessários para automatizar determinadas tarefas de desenvolvedor e ainda fornece orientação aos desenvolvedores. Juntos, permitem a criação de ótimos Smart Clients compostos, de modo ágil e altamente produtivo.

Neste momento, a RACON Software GmbH. implementa o primeiro conjunto de módulos, de grande porte, com mais de 150 WorkItems, integrados em um framework de desktop comum para banco. As primeiras análises desse framework de desktop para banco demonstraram que as abordagens para projetar e criar a infra-estrutura funcionaram bem, facilitando o desenvolvimento, tanto quanto possível, especialmente para desenvolvedores de LOB. O padrão de serviço utilizado, Extensão do shell, facilita a integração de visões mais complexas construídas com o WPF (Windows Presentation Foundation) pois os desenvolvedores de LOB não precisam se preocupar com a interoperabilidade do Windows Forms com o WPF, jáque essa funcionalidade estáencapsulada como um recurso nesse serviço (Shell-Extension). Por fim, a abordagem dirigida a caso de uso oferece uma ótima solução para identificar WorkItems reutilizados através de diferentes conjuntos de módulos. Resumindo, o CAB e a SCSF levaram a equipe de desenvolvimento da RACON Software GmbH um passo adiante na procura de uma abordagem pragmática para a criação de um framework de desktop comum e extensível para banco.

Sobre o autor

Mario Szpuszta trabalha no Developer and Platform Group da Microsoft na Áustria e coordena arquitetos de software de contas corporativas nesse país. Ele sempre se dedicou ao trabalho com as tecnologias da Microsoft e começou trabalhando com o .NET Framework, bem no início. Nos últimos dois anos concentrou-se no desenvolvimento de software seguro, desenvolvimento Web -ASP.Net e Web Services, assim como na integração do Microsoft Office em aplicações personalizadas utilizando o .NET da Microsoft, baseado em Visual Studio Tools for Office, XML e Smart Documents. Mario trabalhou com Ingo Rammer como co-autor na elaboração do Advanced .NET Remoting, 2ªedição, e colaborou com Matthew MacDonald na confecção do Pro ASP.NET 2.0 in C#.