Architectural Views e Viewpoints

Olá pessoal, tudo certo?

Depois de alguns postsintrodutórios para C++, volto a falar um pouco sobre arquitetura.

Todos concordamos que qualquer software possui uma arquitetura, certo?! Entretanto, todos concordamos que nem todo software possui um conjunto apropriado de artefados descrevendo essa arquitetura.

Como arquitetos, as vezes precisamos encontrar formas de descrever nossa arquitetura sem que exista um software funcionando, ou mesmo código que suporte algumas dessas decisões.

Ao meu ver, uma das melhores formas de descrever uma arquitetura é usando um conjutno seleto, que deve ser mantido e atualizado de architectural views. Obviamente, essas views devem seguir algum padrão e coerência com aquelas desenvolvidas em outros sistemas e, para isso, devem estar submetidas a algum padrão estabelecido em viewpoints.

Achou confuso?! Pois bem, nesse post, tento explicar um pouco mais sobre o que são architectural views e viewpoints.

Definindo “Architectural View”

Por definição,

Architectural View é uma forma de retratar os aspectos ou elementos da arquitetura que são relevantes para as preocupações em uma determinada perspectiva – e, por conseqüência, as partes interessadas (stakeholders?!), para quem essas preocupações são importantes.

Ou ainda, conforme a .

Architectural View is a representation of one or more structural aspects of an architecture that illustrates how the architecture addresses one or more concerns held by one or more of its stakeholders.

Simplificando, Architectural Views são pequenos artefatos, geralmente em forma de diagramas, que servem para explicar aos interessados considerações a respeito da arquitetura.

É importante destacar que uma View jamais revela a arquitetura completamente. Em vez disso, destaca apenas os pontos de interesse de um conjunto delimitado de stakeholders.

O que adicionar a uma Architectural View

Quando estiver dedicindo o que incluir em um view, considere:

• Quem são os stakeholders que você deseja atender com essa view? Considere quais são os interesses desse grupo e qual é o expertise (escrevi um post sobre isso outro dia);
• Quanto conhecimento/compreensão técnica esses stakeholders possuem? Patrocinadores e usuários, por exemplo, serão experts em suas áreas de interesse mas com baixo expertise sobre hardware e software;
• Quais preocupações do stakeholder deseja atender com a view?
• Quanto background e contexto arquitetônico os stakeholders possuem?
• Quanto (em que nível) os stakeholders precisam saber sobre o aspecto tratado na view?

É importante destacar que:

o principal desafio, durante a elaboração de uma view é definir o nível certo de detalhe (level-of-detail). Prover muitos detalhes tira o foco dos stakeholders; Prover poucos detalhes permite que os stakeholders realizem inferências que não são válidas.

Definindo “Architectural Viewpoint”

Por definição,

Viewpoint é uma coleção de padrões, templates, e convenções para contrução de um tipo de view. Ela define os stakeholders que serão atendidos além de guidelines, princípios e modelos para construção de views.

Relacionando e inferindo…

Podemos inferir algumas implicações a partir das definições apresentadas. Perceba:

• Viewpoint define os objetivos, público e conteúdo para uma classe de Views;
• Uma View deve estar conforme com uma viewpoint e deve expressar a resolução de um número de preocupações dos stakeholders;
• Uma Architectural Definition é composta por um número variável de views.

Benefícios na adoção de Viewpoints e Views

Usar views e viewpoints para descrever a arquitetura de um software facilita o processo de definição de diversas formas. Perceba:

• Separation of Concerns (SoC) – Descrever muitos aspectos de um sistema através de uma única representação dificulta a comunicação e, o que é mais grave, pode resultar na geração de “acoplamentos” entre aspectos independentes;
• Comunicação facilitada com stakeholders;
• Melhor gerenciamento da complexidade;
• Maior compreensão do time de desenvolvimento.

Viewpoints fundamentais

Considero fundamentais as seguintes viewpoints:

• Funcional – Descrevendo os elementos funcionais do sistema, suas responsabilidades, interfaces e interações;
• Informação/Persistência – Descrevendo a forma como a arquitetura armazena, manipula, gerencia e distribui informação;
• Concorrência – Descrevendo a estrutuda de concorrência do sistema e mapeando os elementos funcionais para “unidadades concorrentes”. Isso deve permitir identificar claramente quais são as partes do sistema que executam concorrentemente e como estas operações são coordenadas e controladas;
• Desenvolvimento – Descrevendo a arquitetura que suporta o processo de desenvolvimento do software. Views de desenvolvimento comunicam os aspectos da arquitetura que interessam para aqueles stakeholders envolvidos com a construção, teste, manutenção e melhoria do sistema;
• Distribuição – Descrevendo o ambiente em que o sistema deverá ser distribuído, incluindo as dependências para o runtime.
• Operacional – Descrevendo como o sistema será operado, administrado e mantido quando estiver funcionando em ambiente de produção.

Certo!?

Era isso.