Realizar a modelagem arquitetural de um sistema não é uma tarefa trivial. Uma arquitetura tem na maioria das vezes muitos stakeholders envolvidos, tais como os usuários finais, clientes, administradores de sistema, gerente de projetos, analistas de suporte, desenvolvedores, testadores e até outros sistemas. Além disso, cada stakeholder apresenta problemas e demanda requisitos e restrições das mais diferentes naturezas tais como desempenho, usabilidade, segurança, tecnologias legadas ou normas governamentais.

Dado este cenário, apresento aqui uma resenha de um método que tem ganho bastante popularidade nos círculos arquiteturais e já possui dezenas de casos de referência aqui no Brasil. O método, chamado de visão 4+1, foi originalmente publicado por Philip Krutchen, um dos “pais” do processo unificado da Rational (RUP), em 1995 na IEEE - The 4+1 View Model of Architecture.

O método usa a mesma premissa usada na modelagem de “sistemas” complexos na engenharia, onde a complexidade é representada não por um, mas por um conjunto de modelos tais como plantas baixas, plantas estruturais, hidráulicas, elétricas, entre diversas outras.

Na modelagem arquitetural, o método assume como ponto de partida (o elemento +1) um conjunto de cenários significativamente relevantes para a modelagem arquitetural. Um cenário é um caminho ou percurso percorrido por um usuário na sua interação como o sistema sob desenho. Um cenário relevante é um percurso que representa, na visão do arquiteto, um risco ou ponto de atenção para o projeto. Por exemplo, em um projeto que lide com a integração de um sistemas entre plataformas baixas e altas, podemos elencar um cenário de transporte de informações (interoperabilidade) para análise. Uma lista de casos de uso pode ser um ponto de partida para que estes cenários sejam elencados.

Para cada cenário elencado, podemos explorá-lo em diversas outras visões UML conforme os requisitos arquiteturais do pojeto. Estas visões são, respectivamente:

• Visão Lógica - Representada através de diagramas de classes e pacotes para capturar a funcionalidade (domínio) sob desenho.
• Visão de Componentes - Representada através de um diagrama de componentes para capturar a gerência de configuração de um sistema (executáveis, DLLs, componentes e outros elementos).
• Visão de Implantação - Representada através de um diagramas de implantação para capturar a distribuição física de uma aplicação entre os seus elementos físicos (máquinas, nodos) e também servidores de banco de dados, aplicações, messageria e orquestração, entre outros.
• Visão de processos - Representada através de diagramas UML de estruturas compostas, diagramas de estados e atividades para representar concorrência entre threads, contenção de objetos, entre outros aspectos fundamentais na modelagem de sistemas de tempo real.

Nem todas as visões são obrigatórias. Algumas dicas para escolher que visões usar incluem:

• Em sistemas pequenos (ex: cliente-servidor), podemos ignorar a visão de implantação e implementação.
• Em sistemas de informação, normalmente podemos ignorar a visão de processos.

Podemos elencar cinco vantagens primárias do uso deste método.

1. As múltiplas representações capturam os interesses de múltiplos stakeholders.
2. As múltiplas representações permitem realizar validações cruzadas e expor falhas prematuras no modelo.
3. As visões estão centradas nos cenários de risco do projeto e portanto representam uma estratégia de mitigação de riscos técnicos.
4. As visões são independentes e podem ser escolhidas conforme o contexto do problema sendo atacado (uso de duas, três, quatro ou cinco visões).
5. Finalmente, estas visões permitem realizar um elo entre a visão do usuário (casos de uso) e o código. Sem estas visões, o desenvolvedor realizaria suposições diversas e provavelmente cada caso de uso teria um determinado formato. Em outras palavras, teríamos um sistema sem coerência arquitetural (estratégica). Metaforicamente, estaríamos criando um animal com patas de elefante, asas de morcego e cabeça de tamanduá.

Para quem quiser buscar maior embasamento neste método, minha recomendação primária é o RUP versão 7, disponível em português. Outros papers relevantes são:

• Architectural manifesto: Designing software architectures, Part 5 - Introducing the 4+1 view model
• Paper original do Kruchten - The 4+1 View Model of Architecture

Devemos lembrar, entretanto, que a visão “4+1″ nunca foi proposto para ser usado como única técnica. Em outros sistemas, entretanto, devemos avaliar a extensão do modelo 4+1 para incluir outras visões tais como a visão de dados, uma visão de análise de causa raiz ou uma visão de processos de negócio.

Pensamendo do dia:

“Os muito poderosos e os muito estúpidos possuem uma coisa em comum. Ao invés de alterarem as suas visões para se ajustarem aos fatos do mundo, eles alteram os fatos para ajustá-los às suas visões.”, Doctor Who.