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.

O que é Projeto de Software?

Contextualizar “Projeto de Software” requer compreender diferentes propostas apresentadas pela comunidade científica. Assim, de forma sintetizada, entende-se aqui por “Projeto de Software” como um processo de planejamento e resolução de problemas para a construção de um software. Ou seja, foca o concepção e o desenvolvimento de um software, onde desenvolvedores de softwares devem colaborativamente contribuir com artefatos (requisitos, documentação, etc) de maneira organizada, seguindo as regras definidas por um processo de desenvolvimento de software.

Segundo [1], o “Projeto de Software” ocorre quando os requisitos do software
são obtidos e o software é desenvolvido e testado. Ainda salienta que, uma das principais falhas no desenvolvimento de um software está relacionada coma inabilidade de projetistas lidar corretamente com clientes e suas necessidades de mudanças. Além disso, projetistas de software possuem dificuldades de analisar seus projetos e demonstrar que estes estão corretos e que representam os requisitos adquiridos. De fato, os problemas supracitados podem ser parcialmente “corrigidos” com novos processos de desenvolvimento de software, tais como Desenvolvimento de Software Orientado a Aspectos (AOSD) e Desenvolvimento Orientado a Modelos (Model-Driven Development - MDD). No primeiro caso, existe um ganho no poder de expressar requisitos não-funcionais. Já no segundo, projetistas passam a ter uma abstração maior das funcionalidades do software provendo maneiras automatizadas para zeração do código.

Reeves [2] tenta propor que o projeto de software apenas ocorre no processo de codificação do software. Ou seja, o código-fonte do software é, de fato, o projeto de software. Gerou-se muitas polêmicas em torno desta tentativa de definir “Projeto de Software”, pois, se o código-fonte é o “projeto”, entãodesenvolvedores são projetistas (o que não é verdade). Ou seja, o código-fonte não pode ser o projeto de software.

Apesar das controvérsias na definição de “Projeto de Software”, pode-se observar que projetar um software requer definir de forma consistente os processos do ciclo de desenvolvimento de software (an´alise, projeto, codificação, etc), gerando e atualizando artefatos em cada etapa do desenvolvimento e organizando as interações entre os envolvidos.

Thiago Sales

[1] Kruchten, P. 2005. Software Design in a Postmodern Era. IEEE Software.
22, 2 (Mar. 2005), 16-18.

[2] Reeves, J. W. 1992. What is Software Design. The C++ Journal. No. 2
Vol. 2.