Resumo: Architectural Blueprints — The “4+1” View Model of Software Architecture

Matheus Castro
3 min readJan 5, 2016

--

Este resumo refere-se ao artigo Architectural Blueprints — The “4+1” View Model of Software Architecture do autor Philippe Kruchten.

Introdução

O autor inicia o artigo perguntando se os diagramas realmente conseguem demonstrar a arquitetura de um software. Em seguida ele afirma que muitas representações arquiteturais não abordam preocupações com os stakeholders, ou seja, todos os que de alguma forma estão envolvidos com o projeto. Para solucionar isso é necessário representações que consigam abordar diversas visões, já que em projeto de software existem uma gama de diferentes visões.

The “4+1” Views

O modelo “4+1” de visão é o proposto, pois consegue atender à abordagens grandes e desafiadoras. Um modelo de arquitetura é algo que está em alto nível, que busca atender aos requisitos funcionais e não funcionais. As 5 diferentes visões que compõe o modelo “4+1” são:

  • Lógica;
  • Processo;
  • Físico;
  • Desenvolvimento;
  • E Cenário (casos de uso), sendo o quinto possível.

Cada uma das visões é descrita por um modelo que utiliza a sua própria notação particular. Cabe ao arquiteto decidir qual dos vários estilo existentes para usar em casa visão.

Arquiteturas

  • Lógica, suporta principalmente os requisitos funcionais e é fortemente centrada nos conceitos da orientação à objetos.
  • Processos, está relacionada com a parte dos requisitos não funcionais.
  • Desenvolvimento, é focada na modularização do software, a qual o sistema é divido em pequenos subsistemas organizados hierarquicamente em camadas, servindo como base para linha de produto e dando suporte na divisão de tarefas para a equipe de desenvolvimento.
  • Física, leva em consideração os requisitos não funcionais do sistema e tem um impacto mínimo em todo código-fonte, sendo seu mapeamento feito em todos os nós, por isso precisa de ser altamente flexível.

Cenários

Os Cenários, é o que dá liga aos elementos das outras 4 visões, uma vez que foram pensados para trabalharem de forma conjunta, com sequências de interações entre os objetos e processos, sendo uma abstração dos requisitos mais importantes. É um ponto de vista redundante dos outros mas que serve à dois propósitos: como guia para descobrir os elementos arquitetônicos durante o projeto arquitetural, e como papel de validação e ilustração quando o projeto de arquitetura é completado. Serve também como ponto de partida para os testes de um protótipo de arquitetura.

Conclusões

Os pontos de vista não apresentam independências, eles estão ligados entre si, ou seja, há uma correspondência entre as visões, que são organizadas em: da lógica para a visão de processos, da lógica para o desenvolvimento e do processo para a física. Nem sempre arquiteturas precisam ter “4+1” pontos de vista, porém os cenários são úteis em todos os casos.

Existe também um processo iterativo, que é dividido em 4 fases, desenhar, organizar, especificar e otimizar e são subdivididos em 12 passos. Junto com o processo iterativo, tem a abordagem orientada para cenários, em que as funcionalidades mais críticas do sistema, as mais importantes, por assim dizer, são capturadas através de cenários ou casos de uso. Ao final do artigo o autor afirma que esse modelo tem sido bastante utilizado em projetos grandes dando suporte a todos os stakeholders.

LinkedIn

--

--