Referências

A seção de referências apresenta documentos externos que fornecem informações suplementares importantes para a compreensão da arquitetura do sistema. Caso haja um número maior de referências, divida a estrutura da seção em subseções:

1. documentos externos
2. documentos internos
3. documentos governamentais
4. documentos não-governamentais
5. etc.

Metas e Restrições de Arquitetura

A arquitetura será formada considerando-se estes fatores:

• requisitos funcionais, capturados no Modelo de Casos de Uso
• requisitos não-funcionais, capturados nas Especificações Suplementares

No entanto, estas não são as únicas influências que formarão a arquitetura, haverá restrições impostas pelo ambiente de operação do software, pela necessidade de reutilizar recursos existentes, pela imposição de diversos padrões, pela necessidade de compatibilidade com os sistemas existentes e outros.  É possível que exista também um conjunto preexistente de princípios e políticas arquiteturais que orientarão o desenvolvimento e que precisará ser elaborado e verificado para o projeto.   Esta seção do documento de Arquitetura de Software é o lugar para descrever essas metas e restrições e quaisquer decisões arquiteturais resultantes delas sem local específico (como requisitos). 

Quando esse documento é criado, uma informação importante é a especificação do ambiente de implementação. Exemplos de itens que devem ser especificados são plataforma de destino (hardware, sistema operacional), sistema de janelas, ferramentas de desenvolvimento (linguagem, construtor de GUI), sistema de gerenciamento de bancos de dados e bibliotecas de componentes.  Também é útil especificar quais tecnologias de interface com o usuário são permitidas e quais não são.  Muitos sistemas escolhem não utilizar determinadas tecnologias de apresentação (JavaScript, Applets, Frames, XML, etc.) para que mais sistemas clientes sejam capazes de utilizar o aplicativo ou para facilitar o desenvolvimento do aplicativo.  As decisões são capturadas aqui no Documento de Arquitetura de Software, enquanto os detalhes de como utilizar e aplicar as tecnologias escolhidas são documentados no Produto de Trabalho: Diretrizes Específicas do Projeto.

Essas decisões são aplicadas elaborando-se um conjunto de critérios de avaliação de arquitetura que serão utilizados como parte da avaliação de iteração.

Os critérios de avaliação também são derivados de Casos de Mudança que documentam as prováveis mudanças futuras:

• nos recursos e nas propriedades do sistema
• no modo de utilização do sistema
• nos ambientes de operação e de suporte do sistema

Os Casos de Mudança esclarecem essas propriedades do sistema descritas por frases subjetivas, como "fácil de estender", "fácil de transportar", "fácil de manter", "robusto na face de alteração" e "rápido para desenvolver". Esses casos se concentram nos aspectos importantes e prováveis e não apenas nas possibilidades.

Os Casos de Mudança tentam prever as mudanças: tais previsões raramente tornam-se exatamente verdadeiras.

As propriedades de um sistema são determinadas pelos usuários, patrocinadores, fornecedores, desenvolvedores e outros envolvidos. As mudanças podem surgir de várias fontes, por exemplo:

• Drivers de negócios: processos e metas de negócios novos e modificados
• Drivers de tecnologia: adaptação do sistema a novas plataformas, integração com novos componentes
• Mudanças nos perfis do usuário médio
• Mudanças nas necessidades de integração com outros sistemas
• Mudanças no escopo decorrentes da migração da funcionalidade a partir de sistemas externos

A Visualização do Caso de Uso

A Visualização de Casos de Uso apresenta um subconjunto do Produto de Trabalho: Modelo de Caso de Uso, que apresenta casos de uso arquiteturalmente significativos do sistema. Ela descreve o conjunto de cenários e/ou os casos de uso que representam alguma funcionalidade central e significativa. Também descreve o conjunto de cenários e/ou casos de uso que possuem cobertura arquitetural substancial (que exercita vários elementos de arquitetura) ou que enfatizam ou ilustram um determinado ponto complicado da arquitetura.

Se o modelo for maior, ele normalmente será organizado em pacotes. Então, para facilitar a compreensão, a visão dos casos de uso deverá ser organizada de modo semelhante, por pacotes. Para cada caso de uso significativo, inclua uma subseção com as seguintes informações:

1. O nome do caso de uso.
2. Uma breve descrição do caso de uso.
3. Descrições significativas do Fluxo de Eventos do caso de uso. Esta pode ser a descrição completa do Fluxo de Eventos ou subseções dela que descrevam fluxos ou cenários significativos do caso de uso.
4. Descrições significativas dos relacionamentos que envolvem o caso de uso, como os relacionamentos de inclusão e de extensão ou as associações de comunicação.
5. Uma enumeração dos diagramas significativos relacionados ao caso de uso.
6. Descrições significativas de Requisitos Especiais do caso de uso. Esta pode ser a descrição completa de Requisitos Especiais ou subseções dela que descrevam requisitos significativos.
7. Figuras da Interface com o Usuário significativas, esclarecendo o caso de uso.
8. As realizações desses casos de uso devem estar localizadas na visão lógica.

A Visualização Lógica

A Visualização Lógica é um subconjunto do Produto de Trabalho: Modelo de Design que apresenta elementos de design arquiteturalmente significativos. Ela descreve as classes mais importantes, sua organização em pacotes e subsistemas, e a organização desses pacotes e subsistemas em camadas. Também descreve as realizações de casos de uso mais importantes como, por exemplo, os aspectos dinâmicos da arquitetura.

Um sistema complexo pode necessitar de várias seções para descrever a Visão Lógica:

1. Visão Geral

   Esta subseção descreve toda a decomposição do modelo de design em termos de camadas e de hierarquia de pacotes. Se o sistema tiver vários níveis de pacotes, descreva primeiro os significativos no nível superior. Inclua quaisquer diagramas que mostrem pacotes significativos do nível superior, bem como suas interdependências e disposição em camadas. Em seguida, apresente todos os pacotes significativos dentro deles até chegar aos pacotes significativos da base da hierarquia.

2. Pacotes de Design Significativos do Ponto de Vista da Arquitetura

   Para cada pacote significativo, inclua uma subseção com as seguintes informações:

   1. O nome da camada.
   2. Uma breve descrição.
   3. Um diagrama com todas as classes e os pacotes significativos contidos no pacote. Para uma melhor compreensão, esse diagrama poderá mostrar algumas classes de outros pacotes, se necessário.
   4. Para cada classe significativa no pacote, inclua o respectivo nome, uma breve descrição e, opcionalmente, uma descrição de algumas de suas responsabilidades, operações e atributos mais importantes. Descreva também seus relacionamentos importantes, se necessário, para compreender os diagramas incluídos.
3. Realizações de Casos de Uso

   Esta seção ilustra o funcionamento do software, apresentando algumas realizações (ou cenários) de casos de uso selecionadas e explica como os diversos elementos do modelo de design contribuem para essa funcionalidade. As realizações apresentadas nesta seção foram escolhidas por representarem alguma funcionalidade significativa central do sistema final ou pela cobertura arquitetural (pelo uso de vários elementos de arquitetura) ou, ainda, por enfatizarem ou ilustrarem um ponto complicado específico da arquitetura. Os casos de uso e os cenários correspondentes dessas realizações devem estar localizados na visão de casos de uso.

   Para cada realização de casos de uso significativa, inclua uma subseção com as seguintes informações:

   1. O nome do caso de uso realizado.
   2. Uma breve descrição do caso de uso realizado.
   3. Descrições significativas do Fluxo de Eventos - Design da realização de casos de uso. Esta pode ser a descrição completa de Fluxo de Eventos - Design ou subseções dela que descrevam a realização de fluxos ou cenários significativos do caso de uso.
   4. Uma enumeração das interações ou dos diagramas de classes significativos relacionados à realização dos casos de uso.
   5. Descrições significativas de Requisitos Derivados da realização de caso de uso. Esta pode ser a descrição completa de Requisitos Derivados ou subseções dela que descrevam requisitos significativos.

Elementos de Design Significativos do Ponto de Vista da Arquitetura

Para ajudá-lo a se decidir sobre o que é significativo do ponto de vista da arquitetura, apresentamos alguns exemplos de elementos qualificados e suas características:

• Um elemento do modelo que encapsula uma importante abstração do domínio do problema, como:
  • Um plano de vôo em um sistema de controle de tráfego aéreo.
  • Um funcionário em um sistema de folha de pagamento.
  • Um assinante de um sistema telefônico.

• Um elemento do modelo usado por vários outros elementos do modelo.
• Um elemento do modelo que encapsula um mecanismo (serviço) importante do sistema
• Mecanismos de Design
  • Mecanismo de persistência (gerenciamento de memória, banco de dados, repositório).
  • Mecanismo de comunicação (RPC, difusão, serviço de broker).
  • Mecanismo de recuperação ou tratamento de erros.
  • Mecanismo de exibição e outras interfaces comuns (exibição em janelas, captura de dados, condicionamento de sinais etc.).
  • Mecanismos de atribuição de parâmetros.

Em geral, qualquer mecanismo que provavelmente seja usado em vários pacotes diferentes (ao contrário de ser completamente interno em um pacote) e para o qual é recomendável uma única implementação comum em todo o sistema ou, pelo menos, uma única interface que oculte várias implementações alternativas.

• Um elemento do modelo que participa de uma interface principal no sistema com, por exemplo:
  • Um sistema operacional.
  • Um produto desenvolvido internamente e adquirido pronto para ser usado (sistema de janelas, RDBMS, sistema de informações geográficas).
  • Uma classe que implementa ou suporta um padrão de arquitetura (como padrões usados para separar elementos do modelo, incluindo o padrão controlador de visão de modelos ou o padrão de broker).

• Um elemento do modelo de visibilidade localizada, mas que pode causar um grande impacto no desempenho geral do sistema, por exemplo:
  • Um mecanismo de varredura usado para verificar sensores em uma taxa bastante elevada.
  • Um mecanismo de rastreamento usado na solução de problemas.
  • Um mecanismo de ponto de verificação usado em um sistema de alta disponibilidade (ponto de verificação e reinício).
  • Uma seqüência de inicialização.
  • Uma atualização on-line do código.
  • Uma classe que encapsula um algoritmo novo e tecnicamente arriscado ou um algoritmo que precise ser muito bem protegido ou estar muito seguro como, por exemplo: o cálculo do nível de irradiação, os critérios que impedem colisões de aviões em espaço aéreo congestionado e a criptografia de senhas.

Os critérios significativos do ponto de vista da arquitetura evoluirão nas iterações iniciais do projeto à medida que você for descobrindo as dificuldades técnicas e entendendo melhor o sistema. Entretanto, por via de regra, você deve rotular no máximo 10% dos elementos do modelo como "significativos arquiteturalmente". Caso contrário, você arrisca diluir o conceito de arquitetura e "tudo é arquitetura".

Ao definir e incluir, na visão lógica, os elementos do modelo significativos do ponto de vista da arquitetura, considere também os seguintes aspectos:

• Identifique a possibilidade de uso comum e de reutilização. Que classes poderiam ser subclasses de uma classe comum ou instâncias da mesma classe com parâmetros?
• Identifique a possibilidade de atribuição de parâmetros. Que parte do design pode se tornar mais reutilizável ou flexível com a utilização de parâmetros estáticos e em tempo de execução (como o comportamento controlado por tabela ou os dados de recurso carregados no tempo de inicialização)?
• Identifique a possibilidade de utilização de produtos desenvolvidos internamente e adquiridos prontos para serem usados.

A Visualização do Processo

A visão de processos descreve a estrutura dos processos do sistema. Como essa estrutura causa um grande impacto na arquitetura, todos os processos devem ser apresentados. Em cada processo, apenas os threads superficiais e significativos do ponto de vista da arquitetura precisam ser apresentados. A visão de processos descreve as tarefas (processos e threads) envolvidas na execução do sistema, suas interações e configurações, além da alocação de objetos e classes para tarefas.

Para cada rede de processos, inclua uma subseção com as seguintes informações:

1. O nome da camada.
2. Os processos envolvidos.
3. As interações entre os processos no formato de diagramas de comunicação, em que os objetos são processos reais que incluem seus próprios encadeamentos de controle. Descreva, em poucas palavras, as características de comunicação, a vida útil e o comportamento de cada processo.

A Visualização de Implementação

Esta seção descreve uma ou mais configurações (hardware) de rede física nas quais o software será implementado e executado. Também descreve a alocação de tarefas (da Visualização do Processos) para os nós físicos. Para cada configuração de rede física, inclua uma subseção com as seguintes informações:

1. O nome da camada.
2. Um diagrama de implementação que ilustre a configuração, seguido de um mapeamento de processos para cada processador.
3. Se houver várias configurações físicas possíveis, descreva apenas a configuração típica e explique as regras gerais de mapeamento que devem ser seguidas para a definição de outras. Inclua também, na maioria dos casos, descrições de configurações de rede para a execução de simulações e testes de software.

Esta visualização é gerada a partir do Produto de Trabalho: Modelo de Implementação.

A Visualização de Implementação

Esta seção descreve a decomposição do software em camadas e a implementação de subsistemas no modelo de implementação. Também fornece uma visão geral da alocação dos elementos de design (da Visualização Lógica) para a implementação. Ela contém duas subseções:

1. Visão Geral

   Esta subseção nomeia e define as diversas camadas e o seu conteúdo, as regras que determinam a inclusão em uma camada específica e as fronteiras entre as camadas. Inclua um diagrama de componentes que mostre os relacionamentos entre as camadas.

2. Camadas

   Para cada camada, inclua uma subseção com as seguintes informações:

   1. O nome da camada.
   2. Um diagrama de componentes que mostra os subsistemas de implementação e suas dependências de importação.
   3. Se apropriado, um resumo do relacionamento da camada com os elementos na visualização lógica ou de processos.
   4. Uma enumeração dos subsistemas de implementação localizados na camada. Para cada subsistema de implementação:
   5. • Forneça o respectivo nome, uma abreviação ou um apelido, uma descrição breve e um análise lógica de sua existência;
      • Se apropriado, indique o relacionamento do subsistema de implementação com os elementos na visualização lógica ou de processos. Em muitos casos, um ou mais subsistemas de design serão implementados por um subsistema de implementação a partir da visualização lógica.
      • Se um subsistema de implementação contiver subsistemas de implementação e/ou diretórios arquiteturalmente
        significativos, considere refletir isso na hierarquia de subseções.
        
      • Se um subsistema de implementação não mapear de um-para-um com um diretório de implementação, inclua uma explicação de como o subsistema de implementação está definido em termos de diretórios e/ou arquivos de implementação.

A Visualização de Dados

Essa visualização é relevante apenas para sistemas que envolvem persistência suportada de banco de dados. Ela descreve os elementos persistentes e significativos do ponto de vista da arquitetura no modelo de dados. Ela fornece uma visão geral do modelo de dados e de sua organização em termos de tabelas, visões, índices, triggers e procedimentos armazenados usados para oferecer persistência ao sistema. Ela também descreve o mapeamento das classes persistentes (da Visão Lógica) para a estrutura de dados do banco de dados.

Geralmente, ela inclui:

• O mapeamento das classes de design persistentes mais importantes, principalmente onde o mapeamento não é comum.
• As partes do sistema significativas do ponto de vista da arquitetura, que foram implementadas no banco de dados, na forma de triggers e procedimentos armazenados.
• Decisões importantes em outras visões com implicações de dados, como escolha da estratégia de transação, distribuição, simultaneidade, tolerância a falhas. Por exemplo, a escolha de usar o gerenciamento de transações baseadas em banco de dados (dependendo do banco de dados para confirmar ou anular transações) requer que o mecanismo de tratamento de erros usado na arquitetura inclua uma estratégia para recuperação de uma transação que falhou, com atualização do estado de persistência dos objetos armazenados em cache na memória do aplicativo.

Você deve apresentar elementos do modelo de dados arquiteturalmente significativos, descrever suas responsabilidades, bem como alguns relacionamentos e comportamentos muitos importantes (acionadores, procedimentos armazenados, etc.).

Tamanho e Desempenho

Esta seção descreve as características volumétricas e de capacidade de resposta do sistema para definição da arquitetura. As informações apresentadas podem incluir:

• O número de elementos-chave que o sistema manipulará (por exemplo, o número de vôos simultâneos para um sistema de controle de tráfego aéreo, o número de chamadas telefônicas simultâneas para um comutador de telecomunicação, o número de usuários on-line simultâneos para um sistema de reserva de companhia aérea etc.).
• As principais medidas de desempenho do sistema, como tempo médio de resposta para eventos importantes, taxas de transferência média, máxima e mínima, etc.
• A base (em termos de disco e memória) dos programas executáveis; essencial no caso de um sistema incorporado que deve existir em limites estritamente reservados.

A maioria dessas qualidades é capturada como requisitos; elas são apresentadas nesta seção por moldarem a arquitetura de maneiras significativas e garantirem um enfoque especial. Discuta como a arquitetura suporta cada requisito.

Qualidade

Nesta seção, liste as principais dimensões de qualidade do sistema que formam a arquitetura. As informações apresentadas podem incluir:

• Requisitos de desempenho de operação, como MTBF (Tempo Médio entre Defeitos).
• Objetivos de qualidade, como "nenhum tempo de inatividade não planejado"
• Objetivos de extensibilidade, como "o upgrade do software poderá ser feito durante a execução do sistema".
• Objetivos de portabilidade, como plataformas de hardware, sistemas operacionais, linguagens.

Para cada dimensão, explique como a arquitetura suporta esse requisito. É possível organizar a seção pelas diferentes visões (lógica, de implementação etc.) ou pela qualidade. Quando características específicas são importantes no sistema, por exemplo, proteção, segurança ou privacidade, o suporte arquitetural para essas características deve ser cuidadosamente descrito nesta seção.