Arquitetando Software para um Cenário de Mudanças Constantes

No papel de arquitetos de software, profissionais de TI precisam projetar soluções capazes de acomodar a dinâmica ditada pelos ambientes de negócio e tecnológico. Ou seja, soluções com capacidade intrínseca de acomodar mudanças.

Em artigo recente para a IEEE, Martin Folwer coloca em cheque a real necessidade do profissional de arquitetura (Who needs an Architect?) na área de software. No artigo em questão, ele faz comparações (praticamente inevitáveis) entre a arquitetura de edificações e a arquitetura de software. A conclusão é que a diferença entre estas duas reside no fato de que, no caso da arquitetura de edificações, uma vez concretizadas, as decisões tomadas são difíceis de serem modificadas. Por exemplo, depois de finalizada a fundação de um edifício, do ponto de vista prático ou econômico é muito difícil (quando não impossível) realizar alterações estruturais. A tradução livre de dois trechos desse artigo, que transcrevo a seguir, serve como ponto de reflexão para o tema deste artigo:

Mesmo considerando o cenário desalentador exposto pelo autor, profissionais responsáveis pela arquitetura de software têm a obrigação e responsabilidade de buscar alternativas para projetar sistemas com a maior flexibilidade possível sem, no entanto, incorrer nos excessos da flexibilidade[1]. Como a complexidade em projetos de software é uma realidade com a qual os arquitetos de software precisam conviver, a busca por recursos que auxiliem no projeto de soluções flexíveis e menos complexas deve ser uma prática constante. Felizmente, existem inúmeros recursos que podem ajudá-lo de forma decisiva a alcançar esse objetivo.

Saiba mais: Engenharia de Software para programadores

Soluções disponíveis

Em particular, para arquiteturas de software baseadas na plataforma .NET da Microsoft, um recurso que certamente deve ser considerado são os Application Blocks (Blocos de Aplicação). Esse recurso, disponível de forma gratuita, é resultado de um trabalho contínuo desenvolvido pelo grupo de arquitetura prescritiva da Microsoft: PAG (Prescriptive Architecture Guidance).

Antes de abordarmos de forma específica os recursos disponibilizados pelos Blocos de Aplicação, vamos analisar dois cenários onde uma arquitetura flexível pode fazer toda a diferença na qualidade e, principalmente, na longevidade de uma solução.

A flexibilidade pode fazer a diferença

Em projetos de software, não é incomum encontrarmos elementos que não estejam diretamente sob controle do responsável pela arquitetura da solução. Também não é incomum que esses tipos de elementos venham a afetar a estabilidade da solução ou sua capacidade de atender ao propósito para o qual foi projetada. Portanto, as soluções projetadas para este cenário devem estar o mais bem preparadas possível para novas demandas. Em um projeto de software, nem sempre é possível antecipar toda e qualquer mudança futura, mas, com recursos apropriados, pode-se criar uma infra-estrutura flexível que possibilite acomodar essas necessidades de alteração sem maiores impactos.

Vejamos dois exemplos de situações que fogem do controle no projeto de uma solução e que ajudam a ilustrar a necessidade de sistemas flexíveis.

Interface com usuário

Os desenvolvedores de software têm retomado um velho tema: o retorno (se é que algum dia ele deixou de estar presente) do rich client (também conhecido como: cliente gordo, smart client, ou simplesmente interface gráfica). Nesse contexto, bastante conhecido por quem projeta software, mais uma vez a camada de apresentação – aquilo que muitas vezes significa software para o usuário final – deve ser alvo de uma nova abordagem.

Inicialmente (e não é preciso voltarmos muito no tempo), tínhamos as telas baseadas em caracteres de texto – os terminais 3270 e o MS-DOS são exemplos típicos deste modelo – nas quais toda a comunicação do usuário com um sistema era feito através de telas formatadas com texto.

Com o advento das interfaces gráficas, esse tipo de solução deixou de ser predominante e, com isso, proliferaram sistemas nos quais a camada de comunicação com o usuário usava e abusava de ícones, botões, listas e grades de textos, entre outros itens. O problema desse tipo de solução (bastante conhecido de todos) era a dificuldade de manter a estação do usuário atualizada com as versões mais recentes do sistema. Esse problema era agravado pelo fato de alguns desses componentes comuns - DLLs, Controles gráficos, etc – existirem em múltiplas versões e serem reutilizados por diversos sistemas distintos. Nesse cenário, vivenciamos o conhecido: “Inferno das DLLs”.

Então, eis que surge a WEB. Com seu modelo centralizado, a WEB permite que o software seja disponibilizado em um único lugar, possibilitando assim que todos os usuários acessem de forma automática a versão mais atualizada do sistema tão logo se conectem ao servidor no qual reside a aplicação. Aparentemente, essa tecnologia resolveria todos os problemas, certo? Na verdade não. Apesar de resolver a questão da atualização das versões do sistema, a tecnologia WEB (e em particular a HTML) não foi concebida, primordialmente, como uma solução de alta produtividade para a interação com o usuário.

Apesar das muitas tentativas e após vários anos de evolução, o desenvolvimento da camada de apresentação com tecnologia baseada em HTML ainda não conseguiu, de forma satisfatória, oferecer os mesmos recursos se comparada à interface gráfica dos clientes ricos. Com o advento e o avanço de tecnologias como Applets e Win Forms, temos novamente a possibilidade de oferecer interfaces mais ricas em nossos sistemas sem que, para isso, precisemos pagar o preço amargo do “Inferno das DLLs”.

O que interessa neste cenário é que as mudanças de tela texto para tela gráfica, desta para a WEB e agora o retorno ao cliente rico (endossado por institutos como Gartner) leva, na maioria dos casos, à necessidade constante de adequar ou reescrever os sistemas para tirar proveito das novas tecnologias e, principalmente, para atender de forma mais adequada as demandas dos usuários. E o que isso tudo tem a ver com facilidade e flexibilidade na arquitetura de software? Você já deve ter percebido: conceber uma aplicação que seja capaz de acomodar a demanda por uma nova proposta de interface com o usuário e que, ao mesmo tempo, seja capaz de acomodar uma mudança futura (que certamente vai existir). Essa é uma grande justificativa para a busca de elementos que tornem seus sistemas mais adaptáveis.

Na proposta de arquitetura em 3 camadas, já temos uma separação bastante razoável dos três principais aspectos que governam uma aplicação: camada de apresentação, regras de negócio e camada de dados. Com isto, podemos em tese substituir o código da camada de apresentação sem afetar todo o restante dos sistemas, ou seja, regras de negócio e camada de acesso a dados. Será, então, que isso resolve todos os problemas? Certamente não. Mesmo nesse modelo de camadas, provavelmente ainda encontraremos alguns aspectos que poderão dificultar, limitar, ou até impedir a mudança do código da camada de apresentação.

Uma forma de se aproximar ainda mais do objetivo de uma camada de apresentação independente, que ofereça o maior grau possível de reaproveitamento em caso de uma exigência qualquer (seja de negócio ou técnica) consiste na aplicação da proposta de especialização dos elementos da camada de apresentação, conhecida como MVC – Model View Controler. Nessa proposta temos: View - o código da camada de apresentação com atribuições claras para tratar dos elementos de interação com o usuário; Controler – para tratar da navegação entre estes elementos; Model - para tratar da comunicação com as regras de negócio.

Interface com o banco de dados

Outro exemplo bastante significativo no qual a necessidade de uma arquitetura flexível pode significar a vida ou a morte de uma solução reside nas APIs de acesso a dados. Desde o aparecimento do Windows, vimos uma evolução constante nas APIs de acesso a dados - ODBC, DAO, RDO, OLE DB, ADO, RDS, ADO.NET. Como neste cenário as mudanças são uma constante, uma proposta bastante apropriada consiste em isolar todas as chamadas a API de acesso a dados de uma aplicação em um único módulo. Nesse caso, com as técnicas de orientação a objetos, podemos criar uma classe que abstraia todas as chamadas à API de acesso a dados, de forma que toda requisição do sistema para acesso ao banco de dados seja feita através dessa classe. Quando chegar o momento de implementar uma nova API de acesso a dados ou até mesmo oferecer acesso a um outro banco de dados diferente, bastará modificar essa classe e todo o programa se beneficiará sem que isto cause um impacto desastroso em todo o sistema. Neste modelo, a solução para contar com uma abordagem homogênea para acesso a dados por todo o programa é uma redução significativa de linhas de código dedicadas a este fim.

Blocos de Aplicação

A cada novo refinamento, usando-se técnicas como Patterns ou outras, procuramos já na arquitetura nos defender de prováveis demandas por modificações. As técnicas são muitas, e as opções precisam ser analisadas à luz das exigências de negócio e do ambiente em questão: tecnologia, infra-estrutura, profissionais, etc.

O conjunto de implementações disponibilizado pela Microsoft para o termo Blocos de Aplicação (Application Blocks) é uma excelente fonte para identificação de elementos que mereçam atenção especial no quesito flexibilidade. Além de servirem de referência geral, uma vez que são baseados em implementações conhecidas (Patterns), os Blocos de Aplicação também representam uma solução imediata, pronta para ser usada em projetos baseados na tecnologia .NET.

São 9 os Blocos de Aplicação disponíveis no momento:

• UIPAB: Bloco para Implementação da Camada de Interface com Usuário - User Interface Application Block;
• CAB: Bloco para Armazenamento Intermediário - Caching Application Block;
• CMAB: Bloco para Gerenciamento de Configurações - Configuration Management Application Block;
• AIAB: Bloco para Chamadas Assíncronas - Asynch Invocation Application Block;
• EMAB: Bloco para Gerenciamento de Exceções- Exception Management Application Block;
• DAAB: Bloco para Acesso a Dados - Data Access Application Block;
• AAB: Bloco para Agregação de Serviços - Aggregation Application Block;
• UAB: Bloco para Atualização de Aplicações - Updater Application Block;
• LAB: Bloco para Log em Aplicações - Logging Application Block.

O diagrama a seguir ajuda a entender melhor onde cada um desses elementos pode se enquadrar no cenário de uma aplicação projetada com o modelo multicamadas:

Cada Bloco é composto do código de implementação em VB.NET e C#, do código de exemplo de utilização e da documentação que abrange os seguintes aspectos:

• Projeto do bloco, para quem deseja entender como foi projetado o Bloco;
• Como desenvolver aplicações com o uso do Bloco;
• Como planejar a distribuição, instalação e posterior manutenção do Bloco em ambiente de produção;
• Referência.

Para os dois exemplos citados neste artigo – especialização da camada de apresentação e isolamento da API de acesso a dados, podemos lançar mão dos seguintes blocos:

• UIPAB: Bloco para Implementação da Camada de Interface com Usuário - User Interface Application Block. Este bloco implementa o Pattern MVC e facilita o emprego dessa proposta em projetos .NET, independentemente de serem baseados em WEB (ASP.NET) ou Windows (WinForms);
• DAAB: Bloco para Acesso a Dados - Data Access Application Block. Com esta implementação, é possível concentrar todas as chamadas a API para acesso a dados numa única classe que pode ser reutilizada por múltiplos projetos.

Esses blocos são boas opções para quem terceiriza o desenvolvimento de software e precisa manter um padrão entre as várias empresas contratadas para o desenvolvimento.

Conclusão

Não deixe de considerar a enorme gama de opções disponíveis para adequar cada vez mais as soluções de software aos cenários de negócio e tecnológico, sem, é claro (parafraseando Marting Fowler), negligenciar o inimigo: você mesmo.

Revista MSDN Magazine Edição 3

• 
  Confira nesta edição da msdn Magazine como proteger as Strings de Conexão com Banco de Dados e Outras configurações sigilosas, treinamento em ASP.NET parte 3 e muito mais

• [1] Será que uma solução/arquitetura pode ser excessivamente flexível? Sim. Segundo Malveua, Raphael C. Software Architect BootCamp, as conseqüências de criar um software excessivamente flexível são: ineficiência, dificuldade de compreensão, excesso de código e documentação de convenções extras.