Capítulo 6 – Projeto de arquitetura
6.3 Padrões de arquitetura
A ideia de padrões como uma forma de apresentar, compartilhar e reusar o conhecimento sobre sistemas de software é hoje amplamente usada. O gatilho para isso foi a publicação de um livro sobre os padrões de projeto orientado a objetos (GAMMA et al., 1995), o que levou ao desenvolvimento de outros tipos de padrões, como padrões para o projeto organizacional (COPLIEN e HARRISON, 2004), padrões de usabilidade (USABILITY GROUP, 1998), interação (MARTIN e SOMMERVILLE, 2004), gerenciamento de configuração (BERCZUK e APPLETON, 2002), e assim por diante. Os padrões de arquitetura foram propostos na década de 1990 sob o nome de ‘estilos de arquite- tura’ (SHAW e GARLAN, 1996), com uma série de cinco volumes de manuais sobre a arquitetura de software orien- tada a padrões, publicados entre 1996 e 2007 (BUSCHMANN et al., 1996; BUSCHMANN et al., 2007a; BUSCHMANN et al., 2007b; KIRCHERE e JAIN, 2004; SCHMIDT et al., 2000).
Nesta seção, apresento os padrões de arquitetura e descrevo brevemente alguns padrões comumente usados em diferentes tipos de sistemas. Para obter mais informações a respeito dos padrões e seu uso, você deve consultar manuais de padrões publicados.
Você pode pensar em um padrão de arquitetura como uma descrição abstrata, estilizada, de boas práticas experimentadas e testadas em diferentes sistemas e ambientes. Assim, um padrão de arquitetura deve descrever uma organização de sistema bem-sucedida em sistemas anteriores. Deve incluir informações de quando o uso desse padrão é adequado, e seus pontos fortes e fracos.
Por exemplo, a Tabela 6.1 descreve o conhecido padrão MVC (modelo-visão-controlador, do inglês Model-View- -Controller). Esse padrão é a base do gerenciamento de interação em muitos sistemas baseados em Web. A descrição estilizada de padrão inclui o nome do padrão, uma breve descrição (com um modelo gráfico associado), e um exem- plo do tipo de sistema em que o padrão é usado (novamente, talvez com um modelo gráfico). Você também deve incluir informações sobre quando o padrão deve ser usado e suas vantagens e desvantagens. Modelos gráficos da arquitetura associados com o padrão MVC são mostrados nas figuras 6.2 e 6.3. Estes modelos apresentam a arquite-
109
Capítulo 6 Projeto de arquitetura
tura a partir de diferentes visões — a Figura 6.2 é uma visão conceitual, e a Figura 6.3 mostra uma possível arquitetura run-time, quando esse padrão é usado para gerenciamento de interações em um sistema baseado em Web.
Em uma pequena seção de um capítulo geral, é impossível descrever todos os padrões genéricos que podem ser usados no desenvolvimento de software. Em vez disso, apresento alguns exemplos de padrões amplamente usados e que capturam os bons princípios de projeto de arquitetura. No site do livro, há mais exemplos de padrões genéricos de arquitetura.
6.3.1 Arquitetura em camadas
As noções de separação e independência são fundamentais para o projeto de arquitetura, porque permitem que alterações sejam localizadas. O padrão MVC, apresentado na Tabela 6.1, separa os elementos de um sistema, permitindo mudá-los de forma independente. Por exemplo, pode-se adicionar uma nova visão ou alterar uma exi- bição existente sem quaisquer alterações nos dados subjacentes do modelo. O padrão de arquitetura em camadas é outra maneira de conseguir a separação e independência. Esse padrão está na Tabela 6.2. Aqui, a funcionalidade do sistema é organizada em camadas separadas, e cada camada só depende dos recursos e serviços oferecidos pela camada imediatamente abaixo dela.
Figura 6.2 A organização do MVC Controlador Visão Modelo Seleção de visão Mudança de estado Notificação de mudança Consulta de estado Eventos de usuário Mapeia ações de usuário
para atualizar modelo Seleciona visões
Modelos renders Solicita atualização de modelo
Envia eventos de usuário para controlador
Encapsula estado de aplicação Notifica visão de mudanças de estado
Tabela 6.1 O padrão modelo-visão-controlador (MVC)
Nome MVC (Modelo-Visão-Controlador)
Descrição Separa a apresentação e a interação dos dados do sistema. O sistema é estruturado em três componentes lógicos que interagem entre si. O componente Modelo gerencia o sistema de dados e as operações associadas a esses dados. O componente Visão define e gerencia como os dados são apresentados ao usuário. O componente Controlador gerencia a interação do usuário (por exemplo, teclas, cliques do mouse etc.) e passa essas interações para a Visão e o Modelo. Veja a Figura 6.2.
Exemplo A Figura 6.3 mostra a arquitetura de um sistema aplicativo baseado na Internet, organizado pelo uso do padrão MVC. Quando é usado É usado quando existem várias maneiras de se visualizar e interagir com dados. Também quando são desconhecidos os
futuros requisitos de interação e apresentação de dados.
Vantagens Permite que os dados sejam alterados de forma independente de sua representação, e vice-versa. Apoia a apresentação dos mesmos dados de maneiras diferentes, com as alterações feitas em uma representação aparecendo em todas elas. Desvantagens Quando o modelo de dados e as interações são simples, pode envolver código adicional e complexidade de código.
110 Engenharia de software
Essa abordagem em camadas apoia o desenvolvimento incremental de sistemas. Quando uma camada é de- senvolvida, alguns dos serviços prestados por ela podem ser disponibilizados para os usuários. A arquitetura tam- bém é mutável e portável. Enquanto sua interface for inalterada, uma camada pode ser substituída por outra equi- valente. Além disso, quando a camada de interfaces muda ou tem novos recursos adicionados, apenas a camada adjacente é afetada. Como sistemas em camadas localizam dependências das máquinas em camadas internas, isso facilita o fornecimento de implementações de multiplataformas de um sistema de aplicação. Apenas as camadas internas dependentes da máquina precisam ser reimplementadas para levar em conta os recursos de um sistema operacional diferente ou banco de dados.
A Figura 6.4 é um exemplo de uma arquitetura em camadas, com quatro camadas. A camada mais baixa inclui software de apoio ao sistema — geralmente, apoio de banco de dados e de sistema operacional. A próxima ca- mada é a camada de aplicação, que inclui os componentes relacionados com a funcionalidade da aplicação e os
Figura 6.3 Arquitetura de aplicações Web usando o padrão MVC
Browser Controlador Formulário para mostrar Solicitação de atualização Notificação de mudança Solicitação de refrescamento Eventos do usuário Processamento de solicitação HTTP Lógica específica de aplicação Validação de dados Página dinâmica Geração Gerenciamento de formulários Lógica de negócios Banco de dados Visão Modelo
Tabela 6.2 O padrão de arquitetura em camadas
Nome Arquitetura em camadas
Descrição Organiza o sistema em camadas com a funcionalidade relacionada associada a cada camada. Uma camada fornece serviços à camada acima dela; assim, os níveis mais baixos de camadas representam os principais serviços suscetíveis de serem usados em todo o sistema. Veja a Figura 6.4.
Exemplo Um modelo em camadas de um sistema para compartilhar documentos com direitos autorais, em bibliotecas diferentes, como mostrado na Figura 6.5.
Quando é usado É usado na construção de novos recursos em cima de sistemas existentes; quando o desenvolvimento está espalhado por várias equipes, com a responsabilidade de cada equipe em uma camada de funcionalidade; quando há um requisito de proteção multinível.
Vantagens Desde que a interface seja mantida, permite a substituição de camadas inteiras. Recursos redundantes (por exemplo, autenticação) podem ser fornecidos em cada camada para aumentar a confiança do sistema. Desvantagens Na prática, costuma ser difícil proporcionar uma clara separação entre as camadas, e uma camada de
alto nível pode ter de interagir diretamente com camadas de baixo nível, em vez de através da camada imediatamente abaixo dela. O desempenho pode ser um problema por causa dos múltiplos níveis de interpretação de uma solicitação de serviço, uma vez que são processados em cada camada.
111
Capítulo 6 Projeto de arquitetura
componentes utilitários que são usados por outros componentes da aplicação. A terceira camada está preocupada com o gerenciamento de interface de usuário e fornecimento de autenticação e autorização de usuário, com a camada superior fornecendo recursos de interface com o usuário. Certamente, o número de camadas é arbitrário. Qualquer camada na Figura 6.4 pode ser dividida em mais camadas.
A Figura 6.5 é um exemplo de como esse padrão de arquitetura em camadas pode ser aplicado a um sistema de biblioteca chamado LIBSYS, que permite controlar o acesso eletrônico de um grupo de bibliotecas universitárias aos materiais com direitos autorais. Esse sistema tem arquitetura de cinco camadas, na qual a camada inferior são os bancos de dados individuais de cada biblioteca.
Você pode ver um exemplo do padrão de arquitetura em camadas na Figura 6.12 (Seção 6.4). Ela mostra a or- ganização do sistema de saúde mental (MHC-PMS) que discuti nos capítulos anteriores.
6.3.2 Arquitetura de repositório
A arquitetura em camadas e padrões MVC são exemplos de padrões nos quais a visão apresentada é a organi- zação conceitual de um sistema. Meu próximo exemplo — o padrão Repositório (Tabela 6.3) — descreve como um conjunto de componentes que interagem podem compartilhar dados.
Figura 6.4 Uma arquitetura genérica em camadas
Interface de usuário
Lógica de negócio principal/funcionalidade de aplicação Recursos de sistema
Apoio de sistema (SO, banco de dados etc.) Gerenciamento de interface de usuário
Autenticação e autorização
Figura 6.5 A arquitetura do sistema LIBSYS
Interface de browser Índice da biblioteca Busca distribuída Recuperação de documentos Gerente de direitos Contabilidade BD1 BD2 BD3 BD4 BDn Login
LIBSYS gerente de consultaFormulários e de impressãoGerente
112 Engenharia de software
A maioria dos sistemas que usam grandes quantidades de dados é organizada em torno de um banco de dados ou repositório compartilhado. Esse modelo é, portanto, adequado para aplicações nas quais os dados são gerados por um componente e usados por outro. Exemplos desse tipo de sistema incluem sistemas de comando e controle, sistemas de informações gerenciais, sistemas de CAD e ambientes interativos de desenvolvimento de software.
A Figura 6.6 é uma ilustração de uma situação na qual um repositório pode ser usado. Esse diagrama mostra um IDE que inclui diversas ferramentas para apoiarem o desenvolvimento dirigido a modelos. O repositório, nesse caso, pode ser um ambiente controlado de versões (veja o Capítulo 25) que mantém o controle das alterações de software e permite a reversão para versões anteriores.
A organização de ferramentas em torno de um repositório constitui uma maneira eficiente de compartilhar grandes quantidades de dados. Não há necessidade de transmitir dados explicitamente de um componente para outro. No entanto, os componentes devem operar em torno de um modelo aprovado de repositório de dados. Inevitavelmente, esse é um compromisso entre as necessidades específicas de cada ferramenta, e pode ser difícil ou impossível integrar novos componentes se seus modelos de dados não se adequam ao esquema acordado. Na prática, pode ser difícil distribuir o repositório por meio de uma série de máquinas. Embora seja possível a dis- tribuição de um repositório logicamente centralizado, pode haver problemas com a redundância e inconsistência de dados.
No exemplo mostrado na Figura 6.6, o repositório é passivo e o controle é de responsabilidade dos componen- tes que usam o repositório. Uma abordagem alternativa, derivada de sistemas de inteligência artificial, usa um mo-
Tabela 6.3 O padrão repositório
Nome Repositório
Descrição Todos os dados em um sistema são gerenciados em um repositório central, acessível a todos os componentes do sistema. Os componentes não interagem diretamente, apenas por meio do repositório. Exemplo A Figura 6.6 é um exemplo de um IDE em que os componentes usam um repositório de informações sobre
projetos de sistema. Cada ferramenta de software gera informações que ficam disponíveis para uso por outras ferramentas.
Quando é usado Você deve usar esse padrão quando tem um sistema no qual grandes volumes de informações são gerados e precisam ser armazenados por um longo tempo. Você também pode usá-lo em sistemas dirigidos a dados, nos quais a inclusão dos dados no repositório dispara uma ação ou ferramenta.
Vantagens Os componentes podem ser independentes — eles não precisam saber da existência de outros componentes. As alterações feitas a um componente podem propagar-se para todos os outros. Todos os dados podem ser gerenciados de forma consistente (por exemplo, backups feitos ao mesmo tempo), pois tudo está em um só lugar.
Desvantagens O repositório é um ponto único de falha, assim, problemas no repositório podem afetar todo o sistema. Pode haver ineficiências na organização de toda a comunicação através do repositório. Distribuir o repositório através de vários computadores pode ser difícil.
Figura 6.6 Uma arquitetura de repositório para um IDE
Repositório do projeto Tradutor
de projeto
Editores
UML Geradores de código
Analisador
de projeto de relatórioGerador
Editores Java Editor Python
113
Capítulo 6 Projeto de arquitetura
delo ‘quadro-negro’ que aciona os componentes do modelo quando dados específicos se tornam disponíveis. Isso é apropriado quando a forma de repositório de dados não é tão bem estruturada. As decisões sobre qual ferramenta ativar só podem ser feitas quando os dados são analisados. Esse modelo foi introduzido por Nii (1986). Bosch (2000) incluiu uma boa discussão sobre como esse estilo se relaciona com atributos de qualidade do sistema.
6.3.3 Arquitetura cliente-servidor
O padrão repositório está preocupado com a estrutura estática de um sistema e não mostra sua organização de tempo de execução. Meu próximo exemplo ilustra uma organização muito usada para sistemas distribuídos, em tempo de execução. O padrão cliente-servidor é descrito na Tabela 6.4.
Um sistema que segue o padrão cliente-servidor é organizado como um conjunto de serviços e servidores associados e clientes que acessam e usam os serviços. Os principais componentes desse modelo são:
1. Um conjunto de servidores que oferecem serviços a outros componentes. Exemplos de servidores incluem:
servidores de impressão que oferecem serviços de impressão; servidores de arquivos que oferecem serviços de gerenciamento de arquivos; e um servidor de compilação, que oferece serviços de compilação de linguagens de programação.
2. Um conjunto de clientes que podem chamar os serviços oferecidos pelos servidores. Em geral, haverá várias
instâncias de um programa cliente executando simultaneamente em computadores diferentes.
3. Uma rede que permite aos clientes acessar esses serviços. A maioria dos sistemas cliente-servidor é implemen-
tada como sistemas distribuídos, conectados através de protocolos de Internet.
Arquiteturas cliente-servidor são normalmente consideradas arquiteturas de sistemas distribuídos, mas o mo- delo lógico de serviços independentes rodando em servidores separados pode ser implementado em um único computador. Novamente, um benefício importante é a separação e a independência. Serviços e servidores podem ser modificados sem afetar outras partes do sistema.
Os clientes podem ter de saber os nomes dos servidores disponíveis e os serviços que eles fornecem. No entan- to, os servidores não precisam conhecer a identidade dos clientes ou quantos clientes estão acessando seus servi- ços. Os clientes acessam os serviços fornecidos por um servidor por meio de chamadas de procedimento remoto usando um protocolo de solicitação-resposta, tal como o protocolo HTTP usado na Internet. Essencialmente, um cliente faz uma solicitação a um servidor e espera até receber uma resposta.
A Figura 6.7 é um exemplo de um sistema baseado no modelo cliente-servidor. Esse é um sistema multiusuário baseado na Internet para fornecimento de uma biblioteca de filmes e fotos. Nesse sistema, vários servidores geren- ciam e apresentam os diferentes tipos de mídia. Os quadros de vídeo precisam ser transmitidos de forma rápida e em sincronia, mas em resolução relativamente baixa. Eles podem ser comprimidos em um arquivo, de modo que o servidor de vídeo possa lidar com a compressão e descompressão de vídeo em diferentes formatos. As fotos, porém, devem permanecer em uma resolução alta; por isso, é conveniente mantê-las em um servidor separado.
Tabela 6.4 O padrão cliente-servidor
Nome Cliente-servidor
Descrição Em uma arquitetura cliente-servidor, a funcionalidade do sistema está organizada em serviços — cada serviço é prestado por um servidor. Os clientes são os usuários desses serviços e acessam os servidores para fazer uso deles. Exemplo A Figura 6.7 é um exemplo de uma biblioteca de filmes e vídeos/DVDs, organizados como um sistema cliente-servidor. Quando é usado É usado quando os dados em um banco de dados compartilhado precisam ser acessados a partir de uma série de locais.
Como os servidores podem ser replicados, também pode ser usado quando a carga em um sistema é variável. Vantagens A principal vantagem desse modelo é que os servidores podem ser distribuídos através de uma rede. A funcionalidade
geral (por exemplo, um serviço de impressão) pode estar disponível para todos os clientes e não precisa ser implementada por todos os serviços.
Desvantagens Cada serviço é um ponto único de falha suscetível a ataques de negação de serviço ou de falha do servidor. O desempenho, bem como o sistema, pode ser imprevisível, pois depende da rede. Pode haver problemas de gerenciamento se os servidores forem propriedade de diferentes organizações.
114 Engenharia de software
O catálogo deve ser capaz de lidar com uma variedade de consultas e fornecer links para o sistema de infor- mação da Internet que incluam dados sobre os filmes e videoclipes, além de um sistema de comércio eletrônico que apoie a venda das fotografias, filmes e videoclipes. O programa do cliente é, simplesmente, uma interface de usuário integrada, construída usando-se um browser da Internet para acesso a esses serviços.
A principal vantagem do modelo cliente-servidor é que se trata de uma arquitetura distribuída. O uso efetivo pode ser feito por sistemas em rede com muitos processadores distribuídos. É fácil adicionar um novo servidor e integrá-lo com o resto do sistema ou atualizar os servidores de forma transparente, sem afetar outras partes do sistema. No Capítulo 18, discuto as arquiteturas distribuídas, incluindo arquiteturas cliente-servidor e arquiteturas de objetos distribuídos.
6.3.4 Arquitetura de duto e filtro
Meu último exemplo de um padrão de arquitetura é o padrão duto e filtro. Esse é um modelo de organização em tempo de execução de um sistema no qual as transformações funcionais processam suas entradas e produzem saídas. Os dados fluem de um para o outro e transformam-se enquanto se movem através da sequência. Cada etapa do processamento é implementada como uma transformação. Os dados de entrada fluem por meio dessas transformações até serem convertidos em saídas. As transformações podem executar sequencialmente ou em paralelo. Os dados podem ser processados por cada item de transformação ou em um único lote.
Figura 6.7 Uma arquitetura cliente-servidor para uma biblioteca de filmes
Servidor de catálogos Catálogo de biblioteca Servidor de vídeos Arquivo de filmes Servidor de fotos Arquivo de fotos Servidor Web Informações sobre vídeos e fotos Cliente 1 Cliente 2 Cliente 3 Cliente 4
Internet
Tabela 6.5 O padrão duto e filtro
Nome Duto e filtro
Descrição O processamento dos dados em um sistema está organizado de modo que cada componente de processamento (filtro) seja discreto e realize um tipo de transformação de dados. Os dados fluem (como em um duto) de um componente para outro para processamento.
Exemplo A Figura 6.8 é um exemplo de um sistema de duto e filtro usado para o processamento das faturas.
Quando é usado Comumente, é usado em aplicações de processamento de dados (tanto as baseadas em lotes como as baseadas em transações) em que as entradas são processadas em etapas separadas para gerarem saídas relacionadas.
Vantagens O reúso da transformação é de fácil compreensão e suporte. Estilo de workflow corresponde à estrutura de muitos processos de negócios. Evolução por adição de transformações é simples. Pode ser implementado tanto como um sistema sequencial quanto concorrente.
Desvantagens O formato para transferência de dados tem de ser acordado entre as transformações de comunicação. Cada transformação deve analisar suas entradas e gerar as saídas para um formato acordado. Isso aumenta o overhead do sistema e pode significar a impossibilidade de reúso de transformações funcionais que usam estruturas incompatíveis de dados.
115
Capítulo 6 Projeto de arquitetura
O nome ‘duto e filtro’ vem do sistema original Unix, em que foi possível vincular os processos usando ‘dutos’. Estes passam um fluxo de texto de um processo para outro. Os sistemas que obedecem a esse modelo podem