Apesar de dividirmos conceitualmente o processo de design do processo de documentação, é comum que ambos aconteçam em paralelo na prática. Quando isto ocorre, a documentação ajuda no design, principalmente no sentido de separação de preocupações.

Ao documentarmos visões arquiteturais diferentes separadamente, preocupamo-nos separadamente com o design de diferentes aspectos do software. Entre os diversos aspectos de um software, podemos citar os aspectos funcionais, de dados, de concorrência, de desenvolvimento, de implantação e operacionais. Esta separação se torna benéfica porque há diferentes linguagens, que podem ser gráficas ou textuais, que melhor se encaixam à descrição de cada aspecto, ajudando não só numa melhor representação, como também numa melhor modelagem e avaliação em relação aos objetivos.

A seguir, vemos dois exemplos que ilustram a documentação de algumas decisões arquiteturais relacionadas a aspectos diferentes do SASF. No Paragraph 8, podemos observar como o SASF está dividido em grandes módulos funcionais e, assim, podemos inferir quais são suas principais funcionalidades e algumas de suas relações entre si. Podemos dizer que as decisões arquiteturais do exemplo são apresentadas sob o ponto de vista funcional do sistema, constituindo uma visão funcional do software. Note também que esta não é a melhor forma de representar, por exemplo, que o desenvolvimento do cadastro dos usuários será terceirizado ou ainda que o serviço de transmissão de vídeos deve executar em 7 servidores durante dias úteis e em 15 servidores nos finais de semana e feriados, quando demanda aumenta.

Exemplo 1

[Decisão Arquitetural 001] O SASF é dividido em cinco grandes módulos funcionais. Cada módulo é responsável por prover um conjunto de funcionalidades relacionadas entre si. Os grandes módulos do SASF são:

• Locadora de Filmes;
• Transmissor de Filmes;
• Motor de Sugestões;
• Cadastro de Usuários;
• Cadastro de Filmes.

As principais funcionalidades providas por cada módulo e suas relações de uso estão descritas no diagrama representado na Figura 1.

Figura 1: Módulos funcionais do SASF. O estereótipo <<Módulo>> do diagrama indica os módulos funcionais que compõem o sistema. Já o estereótipo <<usa>> indica relações de uso entre os módulos para que possam implementar suas funções. Por fim, o estereótipo <<especialização>> indica uma relação de especialização dos dados guardados no elemento responsável pelo cadastro.

Objetivos: A divisão em módulos funcionais possibilita a divisão da implementação entre os times de desenvolvimento de acordo com a especialidade de cada time.

Motivação: As diversas funções a serem providas pelo SASF foram agrupadas em preocupações comuns (cadastro de dados, locação e transmissão de filmes, e sugestões ao usuário). O cadastro deve ser especializado em dois tipos para dividir o esforço de desenvolvimento: cadastro de filmes e de usuários. O motor de sugestões deve ser alimentado com dados de histórico de locações do usuário e informações sobre a base de filmes no sistema.

No Exemplo 2, mostramos o SASF sob um ponto de vista de implantação. Neste exemplo, podemos observar informações de configuração para implantação de serviços para executar o SASF – informações que estavam ausentes no exemplo anterior.

Já sabemos que diferentes stakeholders demonstram diferentes preocupações sobre diferentes aspectos do sistema. Como a documentação da arquitetura versa sobre as muitas preocupações dos stakeholders, ela serve de ferramenta para comunicação, uma vez que provê um vocabulário comum sobre o sistema, além de registrar as relações entre as preocupações e de que forma os eventuais conflitos foram ou devem ser resolvidos.

Note que para servir de ferramenta de comunicação, o documento arquitetural deve ser construído de forma que respeite o conhecimento e as necessidades dos stakeholders. Para que isto seja possível, deve-se conhecer para quem o documento está sendo escrito. Portanto, devemos escrever a arquitetura de forma que possua partes que interessem aos usuários, aos clientes, aos desenvolvedores, aos testadores, ao gerente de projeto ou a outros stakeholders envolvidos no processo.

Por exemplo, os usuários buscam pelas funcionalidades, capacidades e comportamento do sistema, não como ele foi dividido em módulos, como os módulos se comunicam entre si ou se eles foram desenvolvidos do zero ou tiveram partes reutilizadas de outros sistemas. Clientes e gerentes têm alguns interesses semelhantes, como custos de desenvolvimento ou cronograma de lançamento. No entanto, os clientes também se preocupam com o alinhamento do software ao seu negócio, enquanto o gerente procura como minimizar os custos para se adequar ao orçamento, ou como as tarefas de implementação serão divididas entre seu time de desenvolvimento. Finalmente, desenvolvedores e testadores estão interessados em aspectos técnicos do design, por exemplo, qual a divisão em módulos do sistema, quais as alternativas de design disponíveis ou como os atributos de qualidade (desempenho, escalabilidade, tolerância a faltas, etc.) devem ser implementados, cada um motivado pelo seu papel no processo de desenvolvimento.

Por outro lado, o documento precisa demonstrar consistência entre os diversos aspectos do design da arquitetura para que haja comunicação e integridade conceitual. A consistência é necessária porque, apesar da separação de preocupações ser uma ferramenta poderosa de design, as soluções para as diferentes preocupações trabalham interligadas durante a implementação, ou seja, quando resolvem o problema. Assim, precisamos de integridade em dois níveis: entre os stakeholders e entre os diversos aspectos do documento de arquitetura.

A integridade conceitual entre stakeholders é a defendida por Brooks, em The Mythical Man-Month, porque facilita o sucesso no desenvolvimento de sistemas de software. Se os stakeholders – e principalmente os desenvolvedores – não têm em mente o mesmo design que se transformará em produto, são poucas as garantias de que o produto implementado será o projetado. Por isso, no processo, o documento de arquitetura serve para restringir eventuais “deslizes conceituais” em relação ao design arquitetural e prevenir futuras discordâncias entre stakeholders, inclusive de interesses similares. O Exemplo 4 ilustra um caso de restrição aos desenvolvedores, mas que é benéfica por proporcionar a integridade conceitual entre times de desenvolvimento. Este caso é a definição das interfaces entre dois serviços presentes no sistema.

A integridade conceitual também se mostra necessária durante a inclusão de novos membros à equipe de desenvolvimento e ao longo da evolução e manutenção do software. Novos membros precisam de uma descrição da arquitetura porque normalmente são inseridos ao time sem qualquer conhecimento prévio do design. Já ao longo da evolução e manutenção do software, o conhecimento das regras de design a serem seguidas se faz necessário para que os requisitos de qualidade permaneçam implementados, mesmo durante mudanças. O exemplo a seguir ilustra uma regra de design para que um software de manipulação de imagens continue exercendo alta portabilidade.

Existe também a integridade entre os diversos aspectos da arquitetura no documento ou, em outras palavras, a integridade entre as visões da arquitetura. Este tipo de integridade deve ser mantido para que as partes do design funcionem em conjunto e que, portanto, o design seja passível de implementação. A consistência entre visões se faz necessária por que, apesar da separação de preocupações e de elementos arquiteturais facilitar o design, é em conjunto que eles são construídos e executados. Portanto, se há no documento mais de uma visão sobre os mesmos elementos do sistema, é essencial que na documentação dessas visões exista um mapeamento entre as diferentes representações desses elementos.

O Exemplo 6 ilustra a consistência entre visões sobre o armazenamento no SASF. Nele, podemos observar (1) os serviços providos pelo sistema de armazenamento do SASF por meio da visão funcional; (2) que boa parte dos serviços de armazenamento não serão implementados do zero, uma vez que serão obtidos pelo Sistema de Gerência de Banco de Dados adotado, por meio da visão de desenvolvimento; e (3) que o sistema de armazenamento estará executando, no mínimo, em três servidores, por meio da visão de implantação. Note que, se alguma das visões for inconsistente com as outras, podem surgir dúvidas sobre: (1) quais serviços estão disponíveis para quem usa armazenamento, (2) o que será implementado e o que será aproveitado durante a implementação da solução de armazenamento do SASF e, por fim, (3) que tipo de hardware será necessário para executar a solução de armazenamento.

A arquitetura é um modelo do sistema, uma vez que descreve suas características. Ao documentar a arquitetura, obtemos um modelo manipulável do sistema que tem utilidade não só ao arquiteto, mas também a outros stakeholders. Com o modelo manipulável, é possível avaliar as decisões arquiteturais registradas e validá-las em relação aos requisitos que o software deve satisfazer. Além disso, o documento pode ainda servir de ferramenta que permita a verificação de se implementação está de acordo com o design, podendo prevenir eventuais deslizes arquiteturais.

Podemos citar três categorias2 de validação da arquitetura em relação aos requisitos: análise baseada em inspeções, análise baseada em modelos e análise baseada em simulações. No entanto, a possibilidade de aplicação de uma técnica de uma dada categoria de validação está diretamente ligada à representação usada no documento de arquitetura.

Por fim, a documentação permite rastreabilidade entre os requisitos e os elementos da arquitetura e implementação que satisfazem esses requisitos. Ao documentar as decisões arquiteturais, registramos (1) seus objetivos, que normalmente são qualidades a serem alcançadas pelo software, e (2) como esses objetivos são alcançados, por meio da descrição dos elementos que compõem o sistema e suas relações e regras de design que devem ser respeitadas durante a implementação. Este registro serve de ponte entre dois extremos do processo de desenvolvimento: os requisitos e a implementação, e assim permite a navegação entre pontos relacionados, sejam eles requisitos, decisões de design ou partes da implementação.

A rastreabilidade nos permite analisar qual o impacto de uma decisão de design, tanto em termos de quais requisitos ela afeta, quanto quais elementos de software ela dita a existência ou, em caso de manutenção, quais elementos são ou devem ser afetados por mudanças nos requisitos ou nas decisões. O exemplo a seguir mostra aspectos de rastreabilidade na documentação da arquitetura do SASF.

Uma decisão existencial é aquela que indica a presença de um ou vários elementos arquiteturais no design e na implementação.

Os elementos arquiteturais já foram apresentados anteriormente, mas vamos relembrá-los aqui. Estes elementos são as partes em que o software é dividido e podem ser classificados em dois tipos: elementos arquiteturais estáticos e elementos arquiteturais dinâmicos. Os elementos estáticos descrevem a estrutura do sistema em tempo de design e são constituídos de elementos de software (por exemplo, classes, pacotes, procedimentos, serviços remotos), elementos de dados (por exemplo, entidades e tabelas de bancos de dados, arquivos ou classes de dados), e elementos de hardware (por exemplo, servidores em que o sistema vai executar ou armazenar dados). Por sua vez, os elementos dinâmicos descrevem o comportamento do sistema em tempo de execução e entre eles podemos incluir processos, módulos, protocolos, ou classes que realizam comportamento. Note que as relações entre os elementos arquiteturais, tanto estáticos quanto dinâmicos, são representadas também como elementos arquiteturais. Estes elementos são chamados de conectores e podem ser associações, composições, generalizações, entre outros.

No Exemplo 1, observamos uma decisão arquitetural que divide o SASF em diversos módulos menores, constituindo assim uma decisão existencial que define diversos elementos e as relações entre si.

Já no Exemplo 8, observamos uma decisão arquitetural que também dita a presença de elementos na arquitetura do SASF. No entanto, ao contrário do exemplo citado anteriormente que dita elementos estruturais do software, o Exemplo 8 dita elementos comportamentais esperados nele. Assim, podemos encontrar decisões existenciais que sejam decisões estruturais ou comportamentais. As decisões comportamentais são mais relacionadas à implementação dos requisitos de qualidade.

Na prática, é importante observarmos que a divisão entre decisões estruturais e comportamentais não é absoluta. Podemos encontrar decisões que, para descrever um comportamento, necessitem de novas estruturas arquiteturais. Assim, por conveniência, é melhor descrever estas novas estruturas na própria decisão comportamental do que documentar uma nova decisão estrutural. Podemos observar este caso no exemplo anterior, onde descrevemos as partições do conjunto de dados para então descrever o comportamento de particionamento dos dados e assim conseguir algum nível de escalabilidade horizontal.

Por outro lado, há decisões que proíbem a existência de elementos arquiteturais. Essas decisões são chamadas de decisões não-existenciais e elas servem para restringir as alternativas de design de baixo nível. Alguns padrões arquiteturais, como o 3- tier ou mesmo o padrão Camadas, proíbem a comunicação entre alguns dos elementos que eles descrevem, constituindo decisões não-existenciais.

Decisões de propriedades não determinam a existência de partes do software, mas apresentam alguma qualidade ou característica que uma ou mais partes devem exibir. O papel deste tipo de decisão é o de guiar tanto o design de baixo nível, quanto a implementação, uma vez que descreve os princípios e regras ou restrições de design que devem ser respeitadas ao longo do desenvolvimento.

Os exemplos mais comuns de decisões de propriedades são as decisões sobre preocupações transversais ao software, como por exemplo, decisões de logging, decisões de tolerância a faltas ou mesmo decisões sobre a precisão na obtenção dos resultados. Podemos observar uma ilustração mais completa deste tipo de decisão nos exemplos a seguir (Exemplo 9 e Exemplo 10). Note que, em ambos os exemplos, as decisões não descrevem a existência de elementos que devem estar na arquitetura, mas descrevem as propriedades de elementos arquiteturais que foram descritos em outras decisões.

A última classe de decisões arquiteturais que apresentamos é a executiva. Este tipo de decisão está mais relacionado ao processo de desenvolvimento do que aos elementos de design. Entre as decisões executivas, podemos encontrar decisões que descrevem: a metodologia utilizada durante desenvolvimento, como o time está dividido durante a implementação do sistema, como o treinamento de novos membros deve ocorrer, ou quais tecnologias e ferramentas devem ser adotadas para auxiliar o processo. Os exemplos a seguir mostram algumas decisões executivas.

No capítulo de fundamentos de arquitetura, mostramos que as decisões arquiteturais devem possuir uma descrição, objetivos e alguma fundamentação. Estes atributos se tornam essenciais ao processo de design das decisões, pois representam, respectivamente, o que deve ser feito, para que deve ser feito e a justificativa da solução. No entanto, há outros atributos que são especialmente úteis quando precisamos documentar as decisões arquiteturais. São eles o escopo, o histórico, o estado atual e as categorias da decisão arquitetural.

Entre as vantagens que eles proporcionam, podemos dizer que esses atributos facilitam a manutenção de um registro histórico das decisões e a rastreabilidade entre requisitos e elementos do software. A seguir, mostramos cada atributo de uma decisão arquitetural separadamente:

public class ThreeTierDesignTest extends TestCase {
  public void test_communication_web_ui_and_services() {
    String sasfClassesDir =
        System.getProperties("sasf.classes.directory");
    DesignWizard dw = new DesignWizard(sasfClassesDir);
    PackageNode services =
        dw.getPackage("com.sasf.service");
    PackageNode webUI = dw.getPackage("com.sasf.webui");
    Set<PackageNode> callers =
        services.getCallerPackages();
    for (PackageNode caller : callers) {
      assertTrue(caller.equals(webUI));
    }
  }

  public void test_communication_services_and_storage() {
    String sasfClassesDir =
        System.getProperties("sasf.classes.directory");
    DesignWizard dw = new DesignWizard(sasfClassesDir);
    PackageNode services =
        dw.getPackage("com.sasf.service");
    PackageNode storage =
        dw.getPackage("com.sasf.storage");
    Set<PackageNode> callers =
        storage.getCallerPackages();
    for (PackageNode caller : callers) {
      assertTrue(caller.equals(services));
    }
  }

}

O conjunto de pontos de vista 4+1 de Kruchten foi descrito inicialmente no artigo The 4+1 View Model of Architecture [15] e é um dos primeiros a serem descritos na literatura. Inicialmente, os pontos de vista são chamados pelo autor de visões. No entanto, se analisarmos a definição e o uso das visões empregados pelo autor, percebemos ela são compatíveis com nossas definições e usos dos pontos de vista.

O conjunto é composto por quatro pontos de vista, sendo cada um especializado em um aspecto da arquitetura, e um ponto de vista redundante, que contém cenários de uso. Os pontos de vista mais relevantes desse conjunto são: Lógico, de Processos, de Desenvolvimento e Físico. Como o conjunto de Rozanski e Woods é uma evolução do 4+1, ao descrevê-lo na seção a seguir, apresentaremos melhor os pontos de vista de Kruchten.

Outro conjunto importante de pontos de vista é o descrito por Rozanski e Woods no livro Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives [22]. Ele é uma evolução do conjunto 4+1, pois adiciona dois novos pontos de vista ao conjunto de Kruchten, e provê mais informações que ajudam no design do que na documentação.

Os pontos de vista presentes neste conjunto são:

O último conjunto de pontos de vista que apresentamos é o descrito por Clements et al no livro Documenting Software Architectures: Views and Beyond [5]. Este conjunto foi criado com o objetivo de facilitar a documentação, ao contrário da maioria descrita na literatura, que têm seu foco no auxílio do projeto da arquitetura.

O conjunto do SEI possui apenas três pontos de vista, que devem ser especializados por meio dos chamados estilos arquiteturais. Os pontos de vista deste conjunto são:

Apesar dos benefícios proporcionados pela documentação da arquitetura, documentá-la não é fácil. A dificuldade de documentar a arquitetura reside, principalmente, em três características que descrevemos a seguir:

Muitos autores afirmam que a documentação do design arquitetural é benéfica para o processo de desenvolvimento do software. Além dos trabalhos já referenciados ao longo do texto, citamos: o livro The Art of Systems Architecting [20] de Maier e Rechtin, que descreve os benefícios proporcionados quando o documento de arquitetura é consistente entre suas múltiplas visões; o artigo de Wirfs-Brock, Connecting Design with Code [25], que cita a importância de documentar as decisões de design em diversos níveis de detalhe, inclusive o arquitetural; o livro Software Architecture: Foundations, Theory, and Practice [24], de Taylor et al, que mostra este assunto de forma bem abrangente; e o livro Code Complete [17], de McConnell, que afirma a arquitetura é uma ferramenta para o controle da complexidade do software.

O documento de arquitetura descrito como um conjunto de decisões arquiteturais é o tema de diversos artigos. Entre eles, podemos citar: Building Up and Reasoning About Architectural Knowledge [13], An Ontology of Architectural Design Decisions in Software Intensive Systems [14] e The Decision View's Role in Software Architecture Practice [12], de Kruchten et al e que são focados em descrever a arquitetura como decisões arquiteturais e em montar um arcabouço conceitual de como descrever decisões arquiteturais, propondo inclusive um ponto de vista neste sentido; Architecture Knowledge Management: Challenges, Approaches, and Tools [2], de Babar e Gorton, que mostram ferramentas para organizar e documentar as decisões arquiteturais; e The Decision View of Software Architecture [8], de Dueñas e Capilla, e Software Architecture as a Set of Architectural Design Decisions [11], de Jansen e Bosch, que mostram a importância das decisões na arquitetura.

Além dos trabalhos que apresentam conjuntos de pontos de vista e que já foram referenciados na Seção "Visões arquiteturais", podemos citar o livro Software Design [4], de Budgen, que afirma que diferentes representações lidam com diferentes qualidades e interesses, além de mostrar alguns benefícios de se documentar a arquitetura por meio de visões. Já o artigo Four Metaphors of Architecture in Software Organizations: Finding Out the Meaning of Architecture in Practice [23], de Smolander, descreve como alguns stakeholders percebem a arquitetura na prática e assim justifica o uso de visões arquiteturais. Por fim, citamos o livro Applied Software Architecture [10], de Hofmeister et al, que apresenta mais um conjunto de pontos de vista.

Em relação a análises baseadas em inspeções, citamos o livro da série do SEI, Evaluating Software Architectures [6], de Clements et al, que descreve os métodos SAAM, ATAM e ARID, inclusive com estudos de casos.

Já sobre ADLs, citamos dois surveys sobre o assunto: um conduzido por Clements, A Survey of Architecture Description Languages [7], e outro por Taylor e Medvidovic, A Classification and Comparison Framework for Software Architecture Description Languages [21].

E, finalmente, apresentamos alguns trabalhos sobre verificação de conformidade: Software Reflexion Models: Bridging The Gap Between Design and Implementation [18] e Software Reflexion Models: Bridging The Gap Between Source and High-Level Models [19], por Murphy et al; Bridging the Software Architecture Gap [16], de Lindvall e Muthig; e Design tests: An approach to programmatically check your code against design rules [3], de Brunet et al.