Conceitos: Arquitetura de Software
Tópicos
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
questões: "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]
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.
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.
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 investidores no processo de desenvolvimento: usuários finais, 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.
A arquitetura é representada por várias visualizações arquiteturais diferentes,
que, em sua essência, são fragmentos 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 pelas seguintes visões:
As visualizações de arquitetura 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.
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 e outros, 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.
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 das questões gerais de estruturação. A
tabela mostra as categorias apresentadas em [BUS96]
e os padrões nelas contidos.
Categoria
|
Padrão
|
Estrutura
|
Camadas
|
Pipes e Filtros
|
Quadro-negro
|
Sistemas Distribuídos
|
Broker
|
Sistemas Interativos
|
Modelo-Visão-Controlador
|
Apresentação-Abstração-Controle
|
Sistemas Adaptáveis
|
Reflexo |
Microkernel
|
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 manipulação de eventos, manipulação de erros, acesso a
banco de dados, etc. 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 Diretrizes: Divisão em Camadas
para uma discussão 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.
Uma arquitetura de software, ou somente uma visã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. O estilo desempenha um papel vital na compreensão e integridade da arquitetura.
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]:
No RUP, a arquitetura é basicamente um resultado do workflow
Análise e Design. Como o projeto restabelece esse workflow 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 baseline.
|