Construindo aplicativos distribuídos

Aplicável a:

Padrões de software

Sumário:

Em todas as disciplinas de engenharia maduras existem padrões. Na engenharia de software também é assim. Aprender como aproveitar os padrões para definir uma solução de software requer tempo e esforço. Não basta conhecer o vocabulário dos padrões para ser proficiente em projeto. A capacidade de aplicar padrões para criar estruturas específicas de domínio é o mais importante. A melhor forma de obter proficiência na aplicação de padrões é projetar e desenvolver soluções de software, na prática. Com experiência e reforços constantes, o projeto de uma solução de software baseada em padrões passará a ser um hábito.

"Miles Davis apresenta estruturas (frameworks) refinadas em sua simplicidade e que ainda contêm tudo o que é necessário para estimular a performance com referência inequívoca à concepção primária".

–Bill Evans, em trecho extraído da capa do álbum de Miles Davis, Kind of Blue.

Nesta página

Introdução
Breve histórico dos padrões de software
Aprendendo a pensar em padrões
Como definir uma solução com padrões
Definição dos limites da solução
Definição da estrutura da solução
Como definir Frameworks de domínio
Padrões estruturais
Padrões comportamentais
Padrões de criação
Exemplo de uso dos padrões para definir uma solução de software
Conclusão
Referências

Introdução

A primeira vez que li o texto da capa do álbum de Miles Davis, Kind of Blue, fiquei surpreso com as similaridades entre os frameworks criados por Davis nessa célebre gravação e os atributos dos bons frameworks de software: simples, extensíveis e focalizadas. O que Davis criou na gravação Kind of Blue são estruturas de tempo, que definem os padrões do compasso de uma composição. Os padrões musicais de tempo são de uso comum e reutilizáveis em muitas composições. De forma similar, a solução de software precisa de estruturas para definir a arquitetura da solução no contexto do domínio do problema. Bons frameworks de software são geralmente definidas valendo-se de padrões de uso geral, reutilizáveis em vários domínios.

Em todas as disciplinas de engenharia maduras existem padrões. Na engenharia de software também é assim. Aprender como aproveitar os padrões para definir uma solução de software requer tempo e esforço. Alguns desenvolvedores têm a sorte de trabalhar com especialistas em padrões que dão orientação nas disciplinas de arquitetura e projeto; outros precisam adquirir essas habilidades sozinhos. Com ou sem orientadores, desenvolver competência em padrões não acontece por acaso e exige dedicação. Existe uma grande curva de aprendizado para adquirir o vocabulário dos padrões e outra, ainda maior, para entender onde os padrões podem se aplicados em uma solução de software.

Os benefícios de ter o conhecimento dos padrões vale o esforço. Os padrões permitem aos arquitetos e projetistas de software ter a capacidade de projetar rapidamente uma solução robusta, utilizando técnicas comprovadas. Os padrões também dão aos profissionais de software um vocabulário comum, com base no qual podem transmitir idéias sem ter de descrever cada detalhe do propósito do projeto.

Breve histórico dos padrões de software

Padrões orientados a objeto para a engenharia de software tornaram-se um tema importante há cerca de vinte anos. Em 1995, os padrões passaram a ser populares com a publicação do criativo Design Patterns: Elements of Reusable Object-Oriented Software [GOF]. Este livro classificou vários padrões para o projeto de soluções extensíveis orientadas a objeto.

A série POSA (Pattern-Oriented Software Architecture) começou a ser publicada em 1996. Os livros POSA classificam os padrões arquiteturais e aqueles para problemas especializados de software como concorrência, objetos em rede e gerenciamento de recursos. Em outubro de 2006 três volumes da série POSA estavam publicados e um quarto, no prelo.

Desde meados da década de noventa, os padrões de software tornaram-se uma indústria em si. Pesquisa recente de livros na Amazon.com sob o tema "padrões de software" trouxe 2.000 resultados. Além disso, existem várias empresas que prestam serviços de consultoria para treinar e orientar profissionais de software no quesito padrões.

Aprendendo a pensar em padrões

A primeira etapa crítica para tornar-se proficiente no aprendizado de padrões é conhecer o vocabulário do domínio. Exige estudar material que abranja plenamente o assunto. O livro Design Patterns [GOF] é a base de grande parte da literatura subseqüente sobre padrões e deve ser uma opção de leitura de qualquer aspirante a arquiteto ou projetista de software. Mesmo com exemplos definidos usando OMT (predecessora do UML) e C++, este volume foi obviamente escrito para ensinar padrões a partir do zero. Há muitos outros recursos que podem oferecer ao leitor exemplos em Java, C# e UML para serem usados como suplemento dos exemplos existentes em Design Patterns [GOF].

Design Patterns [GOF]começa com um somatório incrível de benefícios do projeto orientado a objeto e a motivação para o uso de padrões. Depois, continua com um exemplo de aplicativo nos quais os padrões são incorporados no projeto . O exemplo indica um número de padrões do livro, colocando-os no contexto de uma solução de software. Como conhecer o vocabulário é apenas metade do caminho para a proficiência em padrões (a aplicação destes é a outra metade), este capítulo é crítico na educação do leitor em como aplicá-los. Depois de ler o exemplo e os padrões mencionados, o leitor poderá passar para as outras seções, seqüencialmente, como faria com qualquer outro livro. Isto o ajudará a conhecer outros padrões e reforçará o que foi lido no exemplo.

Uma opção para conhecer os padrões é incluí-los em uma solução que esteja sendo desenvolvida durante a leitura do material sobre padrões. Essa solução pode ser um projeto feito dentro ou fora do seu ambiente de trabalho.

Como definir uma solução com padrões

O uso de padrões para definir uma solução de software é uma tarefa analítica que exige pensamento abstrato. Existem vários padrões documentados que permitem a definição da estrutura e do comportamento da solução, em diferentes níveis de abstração: para a arquitetura da solução e para as estruturas contidas na solução.

1. Limites

2. Estrutura

3. Frameworks que dão suporte ao domínio

Definição dos limites da solução

Conhecer os limites, é a primeira etapa para definir uma solução de software. Definir os limites do sistema acrescenta enfoque à solução, permitindo que seja projetada e desenvolvida. Sem limites claros, a solução será um alvo móvel e poderá mergulhar na ambigüidade.

Em geral, existem alguns requisitos de sistema, formais ou informais, provenientes de diferentes participantes, que servirão de base para derivar os limites da solução. Além de ter um conhecimento perfeito do propósito global da solução, os seguintes requisitos do sistema são críticos na definição dos limites: eventos externos que acionam a funcionalidade da solução e os processos externos dos quais depende a solução.

Considerado de modo holístico, esses requisitos permitem ao arquiteto definir o contexto da solução. Ter consciência dos eventos que desencadeiam o comportamento da solução e conhecimento dos dados que residem nas dependências da solução permitem ao arquiteto "normalizá-la", separando os objetos internos dos externos à solução. Entender os processos dos quais depende a solução permite ao arquiteto limitar o comportamento da solução, aproveitando aquele dos processos externos.

Definição da estrutura da solução

Depois de os limites da solução estarem definidos, o arquiteto estará pronto para decidir como estruturar a solução. A estrutura da solução proporciona um entendimento conceitual do espaço da solução e deve ser definida com bastante antecipação no processo, pois esta é uma etapa crítica para a definição do framework arquitetural da solução que ajudará a garantir a consistência de toda a solução, com o objetivo de fazê-la mais extensível e de fácil manutenção.

Similarmente à definição dos limites de uma solução, existem vários requisitos de sistema que permitem aos arquitetos definir a estrutura da solução. Às vezes, esses requisitos poderão, aparentemente, se contradizer, e várias compensações terão de ser ponderadas. Importante: os padrões estruturais escolhidos para uma solução não devem acarretar a implementação de quaisquer tecnologias específicas. As tecnologias usadas para implementar a solução devem se basear na capacidade da tecnologia de atender aos requisitos do sistema, funcionais ou não, dentro da estrutura da solução definida.

Com os requisitos do sistema usados para definir os limites da solução, existem alguns outros requisitos que podem pesar sobre a estrutura da solução: requisitos de segurança, desempenho e transacionais

Os requisitos de segurança podem precisar do acréscimo de outros componentes à solução, os quais podem influenciar a sua estrutura definida. De forma similar, os requisitos de desempenho da solução talvez permitam ou proíbam a adição de elementos estruturais que possam sobrecarregá-la, assim como os requisitos transacionais, que talvez exijam partes adicionais da solução que possam afetar sua estrutura.

Algumas poucas publicações sobre arquitetura de software classificam diferentes padrões de arquitetura estrutural. Com base nos limites definidos dos sistemas e nos requisitos de sistema acima mencionados, o arquiteto pode selecionar a estrutura adequada à solução. É preciso notar que nem todos os padrões arquiteturais podem ser formalmente documentados e que a solução pode exigir uma variação em relação à atual.

Os exemplos a seguir descrevem os acionadores dos requisitos do sistema e como se aplicam aos diferentes padrões arquiteturais.

O padrão arquitetural "Camadas" (Layers) [POSA 1] poderá ser apropriado se os requisitos contiverem as seguintes provisões:

• Partes diferentes da solução podem ser conceitualizadas em diferentes níveis:

  • Se a solução for válida para reutilização em cada camada conceitual.

  • Se um protocolo comum puder ser usado para acessar os serviços contidos em cada camada.

• A solução será exposta publicamente e deseja ocultar as complexidades da implementação.

• Existem vários processos externos nos quais a solução possui dependências, exigindo adaptadores técnicos.

O padrão arquitetural "Modelo-Visão-Controlador" (Model-View-Controller) [POSA 1] poderá ser apropriado, se os seguintes forem requisitos da solução:

• A solução contém uma interface de usuário e deseja exibir objetos do mesmo tipo, em formatos diferentes.

• A solução pode ser acessada por consumidores além de uma interface de usuário, como um processo externo:

• Se a solução quiser expor os mesmos objetos (Modelo) para todos os consumidores.

Isto não deve implicar exclusão mútua dos padrões Modelo-Visão-Controlador e Camadas. Por exemplo, uma camada pública dentro de uma solução em camadas pode usar o padrão Modelo-Visão-Controlador para o consumidor da interface do usuário.

Como definir Frameworks de domínio

Depois de definida a estrutura da solução, a definição dos frameworks dentro dessa estrutura é o próximo esforço arquitetural que deve acontecer. Em soluções mais complexas, vários frameworks são necessários para preencher os requisitos funcionais.

Compreender os objetos e as relações no contexto do domínio do problema é a primeira etapa da definição dos frameworks de domínio. Para começar a definição dos objetos e das relações da solução, um bom lugar será o modelo de análise UML. Se o modelo de análise da solução ficar muito grande, ele poderá ser desdobrado em subdomínios. Cada subdomínio poderá prestar-se a um framework diferente.

Em Design Patterns [GOF] os padrões estão divididos em três categorias: estrutural, comportamental e de criação. Observar os requisitos da solução, sua estrutura arquitetural e os modelos de análise no contexto dessas categorias é uma boa forma de começar a definir os frameworks de domínio.

Padrões estruturais

São utilizados para definir a composição de objetos e controlar o acesso aos subsistemas de objetos. Se utilizar o modelo de análise no contexto da estrutura da solução, o arquiteto pode começar a definir os frameworks no contexto dos padrões estruturais.

Os exemplos a seguir descrevem os prós e contras dos requisitos do sistema e como se aplicam aos diferentes padrões de projeto estrutural. Em oposição aos padrões arquiteturais que definem completamente uma solução ou subsistema, em geral existem vários padrões de projeto estrutural em um único framework.

O padrão estrutural Composição (Composite) [GOF] poderá ser aplicável se o domínio contiver as seguintes relações:

• Objetos do mesmo tipo (subclasse) estão contidos em objetos desse mesmo tipo em uma estrutura hierárquica.

• Desejamos tratar partes da hierarquia ou de modo independente, em alguns cenários, ou combinadas, em outros.

O padrão estrutural Fachada (Façade) [GOF] poderá ser aplicável:

• Se o subsistema for significativamente complexo e os detalhes tiverem de ser abstraídos para o consumidor.

• Se os requisitos do sistema indicarem que o subsistema pode ser implantado em um servidor remoto, fazendo com que a interface fique remotamente exposta.

Padrões comportamentais

Padrões comportamentais referem-se a algoritmos e comunicações entre objetos. Os padrões comportamentais abordam questões como: quais comportamentos aplicam-se a qual estado do objeto e qual algoritmo aplicam-se a um determinado objeto em um dado contexto.

O padrão comportamental Estado (State) [GOF] seria uma boa adição a qualquer estrutura se:

• Houver mudança de comportamento do objeto com base no seu estado.

• Os consumidores acessam o objeto por meio de uma fachada sem estado, e a aplicabilidade de um método exposto pela interface deve ser determinada no tempo de execução.

O padrão comportamental Estratégia (Strategy) [GOF] seria uma boa adição a qualquer estrutura se:

• O objeto desejar expor uma interface estática e determinar qual algoritmo executar, com base em um critério definido no tempo de execução.

Padrões de criação

Referem-se à instanciação de objetos. Os padrões de criação concentram-se na composição de objetos complexos e no encapsulamento do comportamento de criação.

O padrão estrutural Construtor (Builder) [GOF] poderá ser aplicável se:

• Um objeto exigir representações diferentes em contextos diferentes. O padrão comportamental Singleton [GOF] seria uma boa adição a qualquer estrutura se:

• Uma única instância de um objeto fosse necessária.

Exemplo de uso dos padrões para definir uma solução de software

O exemplo deste artigo refere-se a um sistema simples de verificação de pagamento de um negócio de comércio eletrônico.

Limites da solução

Os requisitos da solução dizem que é preciso aceitar um pedido do sistema de preenchimento de pedidos e verificar se o pagamento é legítimo em um dos sistemas de verificação: cartão de crédito bancário ou cartão de débito. A Figura 1 apresenta os processos externos e os eventos que servem de base para o sistema de verificação de pagamento.

Figura 1. Eventos e dependências externas da solução

 

Estrutura da solução

Os requisitos também definem que a solução exige uma interface pública segura. Como os sistemas externos de verificação de pagamento são executados em plataformas diferentes, sabemos que precisamos de adaptadores de tecnologia para ter acesso a esses sistemas. Se considerarmos esses requisitos, a estrutura é válida para o padrão de arquitetura Camadas [POSA1] com três camadas: pública, domínio e adaptadora de tecnologia. A Figura 2 apresenta a estrutura da solução.

 

Figura 2. Estrutura em camadas da solução

Modelo de análise

Os requisitos da solução estabelecem que um evento externo aprove um número de conta, o valor total que deve ser confirmado e um método de pagamento para a solução. Com base nos requisitos, concluímos que há dois objetos do domínio necessários para preencher os requisitos da solução: Conta e Pagamento. A Figura 3 apresenta os objetos e as relações no modelo de análise.

 

Figura 3. Modelo de análise da solução.

Padrões estruturais da solução

Depois de definir o modelo de análise, fica claro que a solução precisa ser estruturada com base nos objetos Conta e Pagamento. Os requisitos também dizem que, em determinadas circunstâncias, uma conta pode ter contas-filha correlatas - como uma empresa que deseja faturamento centralizado para todos os pedidos mas quer rastrear as pessoas que fazem os pedidos. Para este requisito, implementamos o padrão Composição [GOF]. Além disso, prevemos o crescimento desse sistema, em tamanho e complexidade, e gostaríamos de incluir isso no projeto, usando o padrão Fachada [GOF] para abstrair essas complexidades. A Figura 4 retrata os padrões estruturais da solução.

 

Figura 4. Padrões estruturais: Composição e Fachada.

 

Padrões comportamentais da solução

Analisando os requisitos da solução, entendemos que o estado da conta pode exigir que as solicitações de crédito sejam negadas, por exemplo, se a conta estiver negativa. O padrão Estado [GOF] nos permite colocar essa restrição no objeto da conta.

Alem disso, ainda é preciso que a solução faça interface com dois sistemas diferentes de verificação de crédito, no mínimo. Este requisito faz com que o projeto tenha uma interface consistente para acessar os sistemas de verificação de pagamento os quais, por sua vez, fazem com que a solução implemente o padrão Estratégia [GOF]. A Figura 5 apresenta a solução com os padrões estruturais e comportamentais.

 

Figura 5. Solução com padrões estruturais e comportamentais.

 

Padrões de criação da solução

Todas as autorizações de uma conta devem acontecer de modo seqüencial, ou seja, apenas uma única instância da conta deve estar na solução em um dado momento: este é o último requisito a ser cumprido pela solução. O padrão Singleton [GOF] cumpre esse requisito. Decidimos usar o padrão Construtor [GOF] para encapsular a lógica singleton com a outra lógica exigida para construir o objeto da conta. A Figura 6 apresenta a estrutura de autorização do pagamento com os seguintes padrões: Criação, Estrutural e Comportamental.

 

Figura 6. Estrutura de autorização do pagamento.

 

Conclusão

Os padrões são ferramentas importantes para a análise e o projeto de uma solução de software. Oferecem ao arquiteto a possibilidade de conceitualizar uma solução em diferentes níveis. São, ainda, uma forma valiosa de comunicar conceitos entre os profissionais de software.

Arquiteturas e projetos de solução devem mapear os requisitos funcionais. Ao implementar padrões no projeto de uma solução, o arquiteto pode criar estruturas específicas de domínio para fazer com que a solução de software seja totalmente consistente. Considerando que a arquitetura e o projeto de sistemas são altamente subjetivos, a melhor forma de avaliar uma estrutura é saber se cumpre os requisitos funcionais definidos e se é flexível, extensível e permite manutenção.

Não é preciso ter um processo formal para definir uma solução baseada em padrões. Uma abordagem ágil para codificar os requisitos funcionais e refratária a estruturas baseadas em padrões poderá ser ideal se o domínio não estiver inicialmente bem definido. Ao contrário, se o domínio estiver bem definido, o projeto da solução poderá ser iniciado com padrões e modificado para cumprir outros requisitos, como desempenho.

Aprender a arquitetar uma solução de software usando padrões requer esforço. Não basta conhecer o vocabulário dos padrões para ser proficiente em projeto. A capacidade de aplicar padrões para criar frameworks específicos de domínio é o mais importante. A melhor forma de obter proficiência na aplicação de padrões é projetar e desenvolver soluções de software, na prática. Com experiência e esforços constantes, o projeto de uma solução de software baseada em padrões passará a ser um hábito.

Referências

[POSA1]

Buschmann, Frank, Regine Meunier, Hans Rohnert, Peter Sommerlad e Michael Stal. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. West Sussex, Inglaterra: John Wiley & Sons Ltd., 1996.

[GOF]

Gamma, Erich, Richard Helm, Ralph Johnson e John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Boston, MA-EUA: Addison Wesley Professional, 1995.

Sobre o autor

Joseph Hofstader é arquiteto de sistemas da Avaya, e foi nomeado Distinguished Member of Technical Staff. Nos últimos 12 anos, Joe vem se dedicando à arquitetura, ao projeto e ao desenvolvimento de soluções no setor de telecomunicações. Fez mestrado na George Mason University de Fairfax, VA - EUA.