Visões arquiteturais - 4+1
É comum as pessoas se referirem à arquitetura como uma coleção de caixinhas, algumas empilhadas e outras lado a lado. Eis um exemplo desta descrição:
|
Browser |
|
|
Web Services |
DCOM |
|
Business |
|
|
Workflow engine |
Security |
|
ODBC |
|
|
Database |
Integration |
|
OS |
|
Esta é uma forma amplamente utilizada. Não há dúvida que Browser não acessa ODBC. Mas várias questões ficam sem respostas. Web Services não tem nenhuma relação com Security? (Posso assumir que não há segurança direta no Web Service nem DCOM?) Posso considerar que Business não acessa a ODBC em nenhum momento? Se aparentemente Business não tem nenhuma relação com OS, este sistema é portável para qualquer sistema operacional?
E o que significam exatamente estas caixinhas? Programas inteiros? Módulos? Ou é dependência de compilação? E como fica o fluxo de informação?
Uma arquitetura de um sistema pode ser algo muito complexo e não há apenas uma forma de representá-la. O ideal é haver várias visões, sendo que cada visão da arquitetura tem um objetivo. Para isso existe uma forma de descrever arquiteturas através de visões conhecida como “4+1″ (lê-se four by one). Esta abordagem foi adotada como uma das fundações do RUP.
Estas visões arquiteturais se resumem em quatro visões mais uma, onde a última tem como função “fechar” a idéia exposta nas outras quatro. Utilizando um pequeno subconjunto de cenários importantes - instâncias de casos de uso - para mostrar que os elementos das quatro visões trabalham juntos, sem emendas. Esta é a visão “+1″, redundante com as outras, mas servindo com um objetivo distinto.
Estas visões arquiteturais se resumem em quatro visões mais uma, onde a última tem como função “fechar” a idéia exposta nas outras quatro. Utilizando um pequeno subconjunto de cenários importantes - instâncias de casos de uso - para mostrar que os elementos das quatro visões trabalham juntas sem emendas. Esta é a visão “+1″, redundante com as outras, mas servindo com um objetivo distinto.
As quatro visões são:
- Visão lógica: suporta primariamente requisitos comportamentais, os serviços que o sistema deve prover para os usuários finais. Projetistas decompõem o sistema em um conjunto de abstrações chaves, obtidas principalmente do domínio do problema. Essas abstrações são objetos ou classes de objeto que expõem os princípios de abstração, encapsulamento, e herança. Além de colaborar na análise funcional, a decomposição identifica mecanismos e elementos de projeto que são comuns ao longo do sistema;
- Visão de processo: endereça concorrência e distribuição, integridade de sistema e tolerância à falhas. Esta visão também especifica quais threads de controle executam cada operação de cada classe identificada na visão lógica. A visão de processo pode ser vista como um conjunto independente de rede lógicas executando programas - processos - que são distribuídos através de um conjunto de recursos de hardware, os quais são conectados a um barramento ou LAN ou WAN;
- Visão de desenvolvimento: foca na organização dos módulos de software no ambiente de desenvolvimento. As unidades dessa visão são pequenos pedaços de software - bibliotecas ou subsistemas - que podem ser desenvolvidos por um ou mais desenvolvedores. Esta visão suporta a alocação de requisitos e trabalho para times e suporta avaliação de custos, planejamento, monitoramento do progresso de projetos e raciocínio sobre reutilização de software, portabilidade e segurança;
- Visão física: leva em conta os requisitos do sistema, como disponibilidade, confiabilidade, desempenho e escalabilidade. Esta visão mapeia os vários elementos identificados nas visões lógicas, processos e desenvolvimento - redes, processos, tarefas e objetos - em nós de processamento.
