Análise e crítica: Architectural Blueprints - The "4+1'' View Model of Software Architecture

O desenvolvimento de um software exige aos projetistas (e toda equipe envolvida) modelos que facilitem a identificação e a compreensão dos principais componentes do sistema. Decompor requisitos funcionais - subdividindo-os em módulos -, estabelecer requisitos não-funcionais - identificando pontos críticos da aplicação, tais como performance e disponibilidade de serviços - e propor interfaces que ofereçam fácil usabilidade são tarefas complexas no que tange alcançar um sistema bem documentado e arquiteturalmente bem definido, o que tem trazido ao mundo da engenharia de software diversas abordagens visando facilitar a construção de modelos destes componentes. Entretanto, em alguns casos tais modelos em vez de oferecer clareza, são bastante confusos ao especificar qual o seu objetivo no sistema proposto.

Neste contexto, o paper Architectural Blueprints - The 4+1 View Model of Software Architecture[1] apresenta um modelo para descrição de arquiteturas de softwares baseado no uso de múltiplas visões concorrentes, permitindo subdividir e atribuir as diferentes responsabilidades aos demais participantes do "time" (usuário final, desenvolvedores, engenheiros, projetistas, etc) além de facilitar na decomposição dos requisitos funcionais e não-funcionais de uma aplicação. Intitulado de "4+1 View Model" este modelo descreve a arquitetura de um software fazendo uso de cinco visões concorrentes: A (1) visão lógica descreve o design de um objeto, a (2) visão de processos descreve os aspectos inerentes a concorrência e sincronização, a (3) visão física descreve o mapeamento do software para o hardware e apresenta os aspectos distribuídos do software em questão, e a (4) visão de desenvolvimento descrevendo a organização estática no ambiente de desenvolvimento. Arquitetos de software podem organizar a descrição de suas decisões arquiteturais utilizando estes quatro tipos de visões e então utilizar-se de "casos de uso" para representar os requisitos funcionais (sendo esta a quinta visão). Kruckten afirma que a importância dos "casos de uso" está na validação e ilustração dos requisitos após finalizar o design da arquitetura do software. Esta proposta de modelagem permite que os participantes supracitados encontrem o que eles precisam em uma arquitetura de software. Ou seja, os engenheiros da aplicação podem utilizar esta abordagem para a visão física e a visão de processos; usuários finais, clientes, focam a visão lógica; e os gerentes de projeto podem focar a visão de desenvolvimento.

Kruckten também deixa claro que estas visões não são independentes. Ou seja, elementos de uma visão podem estar interconectados com elementos de uma outra visão, obedecendo certas regras de design e heurísticas. Como exemplo, pode-se considerar a relação entre a visão lógica e a visão de processos. No primeiro caso, diversas características de uma classe podem ser observadas, tais como a (1) autonomia de um objeto, identificando se este é ativo, passivo ou protegido; (2) se este será armazenado ou não, entre outras. Por outro lado, na segunda visão supracitada, deve-se implementar cada objeto com sua própria thread de controle. Assim, o resultado é o mapeamento das classes e seus objetos (da primeira visão) em um conjunto de tarefas e processos (da segunda visão). É importante salientar também que o uso das visões depende diretamente da complexidade (ou da necessidade) da aplicação em questão. Por exemplo, se o sistema não for multiprocessado, não há necessidade de utilizar a visão física.

Em fim, acho que o paper aborda um assunto bastante importante no que tange alcançar uma boa arquitetura de software. A proposta de Kruckten é bem centrada e plausível e acredito que a separação dos modelos inerentes aos diferentes requisitos ajuda a cada "stakeholder" a focar na sua responsabilidade, sem ter que entender e criar modelos que não são de seu interesse, minimizando tempo de desenvolvimento (consequentemente diminuindo custos) e facilitando a manutenbilidade da documentação do sistema proposto, a qual é um dos problemas graves existentes no desenvolvimento de um software (documentação incompleta e/ou inconsistente).

Thiago Sales

[1] Philippe Kruchten. Architectural blueprints—The “4+1” View Model of Software Architecture. IEEE Software, 12(6):42–50, November 1995.