Conceitos:
|
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:
Camadas
Um sistema grande que requer decomposição.
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.
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.
Quadro-negro
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.
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.
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.
Um exemplo emergente e importante de um estilo arquitetural é o SOA (Service-Oriented Architecture): o SOA é uma etapa evolutiva que constrói um desenvolvimento com orientação de objeto e com base em componente para fornecer por meio de uma camada de serviço serviços análogos para funções de negócios que preenchem todos ou parte dos processos de negócios capturados, por exemplo, nos Casos de Uso de Negócios. Enquanto os serviços podem ser oferecidos por meio de um componente, eles têm um aspecto composto em que gerenciam uma colaboração de um conjunto de componentes (mapeando para entidades de negócios de nível inferior) para fornecer uma função de negócios de textura granulada, com valor mais alto. Essas idéias ainda estão evoluindo e ainda não há um acordo universal sobre a terminologia ou a precisão das características necessárias de um SOA, mas parece haver uma aceitação geral de que, por exemplo:
Para explorar mais o SOA, consulte o white paper do IBM Rational Software"Utilizando a Arquitetura Orientada ao Serviço e o Desenvolvimento com base em Componente para Construir Aplicativos de Serviço da Web".
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.
Rational Unified Process
|