Introdução

A arquitetura de software é um conceito de fácil compreensão e que a maioria dos engenheiros entende de modo intuitivo, especialmente quando se tem um pouco de experiência. No entanto, é difícil defini-lo com precisão. Em particular, é difícil desenhar uma linha bem definida entre o design e a arquitetura - a arquitetura é um aspecto do design que se concentra em alguns recursos específicos.

Em An Introduction to Software Architecture, David Garlan e Mary Shaw sugerem que a arquitetura de software é um nível de design voltado para problemas: "Além dos algoritmos e das estruturas de dados da computação; o design e a especificação da estrutura geral do sistema emergem como um novo tipo de problema. As questões estruturais incluem organização total e estrutura de controle global; protocolos de comunicação, sincronização e acesso a dados; designação de funcionalidade a elementos de design; distribuição física; composição de elementos de design; escalação e desempenho; e seleção entre as alternativas de design." [GAR93]

Mas há mais a arquiteturar do que apenas a estruturar; o artigo Working Group on Architecture da IEEE define isso como "o conceito de nível mais alto de um sistema em seu ambiente" [IEP1471]. Também abrange o "ajuste" à integridade do sistema, às restrições econômicas, às preocupações estéticas e ao estilo. Ele não se limita a um enfoque interno, mas leva em consideração o sistema como um todo em seu ambiente de usuário e de desenvolvimento, ou seja, um enfoque externo.

No RUP, a arquitetura de um sistema de software (em um determinado ponto) é a organização ou a estrutura dos componentes significativos do sistema que interagem por meio de interfaces, com elementos constituídos de componentes e interfaces sucessivamente menores.

Descrição de Arquitetura

Para falar e tirar conclusões sobre a arquitetura do software, primeiro defina uma representação de arquitetura, uma forma de descrever aspectos importantes de uma arquitetura. No RUP, esta descrição é capturada no Documento de Arquitetura de Software.

Visualizações Arquiteturais

Escolhemos representar a arquitetura de software em várias visualizações arquiteturais. Cada visualização arquitetural trata de um conjunto específico de interesses, específicos dos envolvidos no processo de desenvolvimento: usuários, designers, gerentes, engenheiros de sistema, mantenedores e assim por diante.

As visualizações capturam as principais decisões de design estruturais, mostrando como a arquitetura de software é decomposta em componentes e como os componentes são conectados por conectores para produzir formulários úteis [PW92]. As opções de design devem estar associadas aos Requisitos, tanto funcionais quanto suplementares, e a outras restrições. Mas essas opções, por sua vez, impõem restrições adicionais aos requisitos e às futuras decisões de design em um nível inferior.

Um Conjunto Típico de Visualizações Arquiteturais

A arquitetura é representada por várias visualizações arquiteturais diferentes, que, em sua essência, são extrações que ilustram os elementos "arquiteturalmente significativos" dos modelos. No RUP, você inicia em um conjunto típico de visualizações, denominado "modelo de visualização 4+1" [KRU95]. Ele é composto de:

• A Visualização de Casos de Uso, que contém casos de uso e cenários que englobam comportamento arquiteturalmente significativo, classes ou riscos técnicos. Ela é um subconjunto do Modelo de Caso de Uso.
• A Visualização Lógica, que contém as classes de design mais importantes e sua organização em pacotes e subsistemas e a organização desses pacotes e subsistemas em camadas. Também contém algumas realizações de casos de uso. É um subconjunto do Modelo de Design.
• A Visualização de Implementação, que contém uma visão geral do Modelo de Implementação e sua organização em termos de módulos em pacotes e camadas. A alocação de pacotes e classes (da Visão Lógica) nos pacotes e módulos da Visão de Implementação também é descrita. É um subconjunto do Modelo de Implementação.
• A Visualização do Processo, que contém a descrição das tarefas (processo e encadeamentos) envolvidas, suas interações e configurações, e a alocação de objetos e classes de design para tarefas. Esta visualização só precisará ser utilizada se o sistema tiver um grau significativo de Simultaneidade. No RUP, ela é um subconjunto do Modelo de Design.
• A Visualização de Implementação, que contém a descrição dos vários nós físicos da maioria das configurações comuns de plataforma e alocação de tarefas (da Visualização do Processo) nos nós físicos. Essa visualização só precisará ser usada se o sistema estiver distribuído. É um subconjunto do Modelo de Implementação.

As visualizações arquiteturais estão documentadas em um Documento de Arquitetura de Software. Você pode prever visualizações adicionais para expressar várias questões especiais: visualização da interface com o usuário, visualização de segurança, visualização de dados e outras. No caso dos sistemas simples, você pode omitir algumas das visões contidas no modelo de visão 4+1.

Foco Arquitetural

Embora as visões acima possam representar todo o design de um sistema, a arquitetura se preocupa somente com alguns aspectos específicos:

• A estrutura do modelo - os padrões organizacionais, por exemplo, Divisão em Camadas.
• Os elementos essenciais - casos de uso críticos, classes principais, mecanismos comuns, etc., em oposição a todos os elementos presentes no modelo.
• Alguns cenários-chave mostrando os principais fluxos de controle em todo o sistema.
• Os serviços para capturar a modularidade, os recursos opcionais e os aspectos de linha de produto.

Basicamente, as visualizações arquiteturais são abstrações ou simplificações do design inteiro, em que características importantes são ressaltadas, deixando os detalhes de lado. Essas características serão importantes quando os seguintes aspectos estiverem em discussão:

• Evolução do sistema - passagem para o próximo ciclo de desenvolvimento.
• Reutilização da arquitetura, ou de partes dela, no contexto de uma linha de produto.
• Avaliação das qualidades suplementares, como desempenho, disponibilidade, portabilidade e segurança.
• Atribuição do trabalho de desenvolvimento a equipes ou subcontratantes.
• Decisões sobre a inclusão dos componentes desenvolvidos internamente e adquiridos prontos para serem usados.
• Inserção em um sistema mais amplo.

Padrões Arquiteturais

Os padrões arquiteturais são formulários prontos que solucionam problemas arquiteturais recorrentes. Uma estrutura arquitetural ou uma infra-estrutura arquitetural (middleware) é um conjunto de componentes em que você pode construir um determinado tipo de arquitetura. Muitas das maiores dificuldades arquiteturais devem ser resolvidas na estrutura ou na infra-estrutura, geralmente, direcionadas a um domínio específico: comando e controle, departamento de informática, sistema de controle, etc.

Exemplos de Padrões de Arquitetura

[BUS96] agrupa padrões arquiteturais de acordo com as características dos sistemas em que eles são mais aplicáveis, com uma categoria tratando de problemas gerais de estruturação. A tabela mostra as categorias apresentadas em [BUS96] e os padrões nelas contidos.

Duas dessas categorias são apresentadas mais detalhadamente aqui, a fim de esclarecer essas idéias. Para obter uma abordagem completa, consulte [BUS96]. Os padrões são apresentados neste formulário amplamente utilizado:

• Nome do padrão
• Contexto
• Problema
  • Impõe a descrição de vários aspectos problemáticos que devem ser considerados
• Solução
  • Fundamentos
  • Contexto resultante
  • Exemplos

Nome do Padrão

Camadas

Contexto

Um sistema grande que requer decomposição.

Problema

Um sistema que deve manipular problemas em diferentes níveis de abstração.  Por exemplo: problemas de controle de hardware, problemas de serviços comuns e problemas específicos do domínio. Seria extremamente indesejável escrever componentes verticais que lidem com essas questões em todos os níveis. O mesmo problema teria que ser manipulado (possivelmente de modo inconsistente) várias vezes em diferentes componentes.

Força

• Peças do sistema devem ser substituídas.
• Alterações efetuados nos componentes não devem ser irregulares.
• Responsabilidades similares devem ser agrupadas juntas.
• Tamanho dos componentes - pode ser necessário decompor os componentes complexos.

Solução

Estruture os sistemas em grupos de componentes que formem camadas umas sobre as outras. Faça com que as camadas superiores utilizem os serviços somente das camadas abaixo (nunca das camadas acima). Tente não utilizar serviços que não sejam os da camada diretamente abaixo (não ignore camadas, a menos que as camadas intermediárias somente incluam componentes de passagem).

Exemplos:

1. Camadas Genéricas

Uma arquitetura estritamente em camadas estabelece que os elementos de design (classes, pacotes, subsistemas) utilizem apenas os serviços da camada abaixo deles.  Os serviços podem incluir identificação de erros, acesso ao banco de dados e outros. Ela contém mecanismos mais palpáveis, em oposição às chamadas brutas em nível de sistema operacional documentadas na camada inferior.

2. Camadas de Sistema de Negócios

O diagrama acima mostra um outro exemplo de divisão em camadas, onde há camadas verticais específicas de aplicativo e camadas horizontais de infra-estrutura. Observe que a meta é ter "chaminés" muito curtas de negócios e alavancar a freqüência entre aplicativos.  Do contrário, é provável que várias pessoas resolvam o mesmo problema, possivelmente de maneira diferente.

Consulte a Diretriz: Divisão em Camadas para obter uma discussão adicional sobre este padrão.

Nome do Padrão

Quadro-negro

Contexto

Um domínio em que nenhuma abordagem fechada (algorítmica) para resolver um problema é conhecida ou viável. Exemplos são os sistemas de IA, o reconhecimento de voz e os sistemas de inspeção.

Problema

Vários agentes de resolução de problemas (agentes de conhecimento) devem cooperar para resolver um problema que não pode ser resolvido por agentes individuais. Os resultados do trabalho de cada agente devem estar acessíveis a todos os outros agentes. Assim, eles poderão avaliar se podem ou não contribuir para encontrar uma solução e divulgar os resultados de seus trabalhos.

Força

• A seqüência em que os agentes de conhecimento podem contribuir para resolver o problema não é determinista e talvez dependa das estratégias de solução de problemas.

• A entrada de diferentes agentes (resultados ou soluções parciais) pode ter diferentes representações.

• Os agentes não sabem da existência um do outro diretamente, mas podem avaliar as contribuições divulgadas de cada um deles.

Solução

Vários Agentes de Conhecimento têm acesso a um data store compartilhado denominado Quadro-negro. O quadro-negro fornece uma interface para inspecionar e atualizar seu conteúdo. O módulo/objeto Controle ativa os agentes seguindo algumas estratégias. Após a ativação, um agente inspeciona esse quadro-negro para ver se ele pode contribuir na resolução do problema. Se o agente determinar que é possível contribuir, o objeto Controle poderá permitir que os agentes coloquem sua solução parcial (ou final) no quadro.

Exemplo:

Este exemplo mostra a visão estrutural ou estática modelada através da UML. Ele será parte de uma colaboração parametrizada, que será restringida a parâmetros reais para instanciar o padrão.

Estilo Arquitetural

Uma arquitetura de software, ou somente uma visualização arquitetural, pode ter um atributo chamado estilo arquitetural, que reduz o conjunto de formulários que podem ser escolhidos e impõe um determinado grau de uniformidade à arquitetura. O estilo pode ser definido por um conjunto de padrões, ou pela escolha de componentes ou conectores específicos que funcionarão como os tijolos básicos da construção. Em um determinado sistema, alguns estilos podem ser capturados como parte da descrição arquitetural em um guia de estilo de arquitetura-fornecido por meio do produto de trabalho Diretrizes Específicas do Projeto no RUP. O estilo desempenha um papel vital na compreensão e integridade da arquitetura.

Plantas Arquiteturais

A representação gráfica de uma visualização arquitetural é denominada planta arquitetural. Nas várias visualizações descritas acima, as plantas são compostas pelos seguintes diagramas da Unified Modeling Language [UML01]:

• Visualização Lógica. Diagramas de classe, máquinas de estado e diagramas de objetos
• Visualização do Processo. Diagramas de classes e diagramas de objetos (abrangendo processos e encadeamentos da tarefa)
• Visualização de Implementação. Diagramas de Componentes
• Visualização da Implementação. Diagramas de Implementação
• Visualização de Casos de Uso. Os diagramas de casos de uso representam casos de uso, atores e classes de design normais. Os diagramas de seqüências representam objetos de design e suas colaborações.

O Processo de Arquitetura

No RUP, a arquitetura é basicamente um resultado do fluxo de trabalho de análise e design. Como o projeto restabelece esse fluxo de trabalho a cada iteração, a arquitetura se desenvolve e torna-se refinada e aprimorada. Como cada iteração inclui a integração e o teste, a arquitetura é bastante sofisticada pelo tempo que o produto é liberado. Esta arquitetura é o foco principal das iterações da fase de Elaboração, no final da qual a arquitetura normalmente serve como linha de base.