O Documento de Arquitetura de Software fornece uma visão geral de arquitetura abrangente do sistema, usando diversas visões de arquitetura para descrever diferentes aspectos do sistema.  
Função:  Arquiteto de Software  
Opcionalidade/Ocorrência:  Desenvolvido principalmente durante a fase de elaboração.
Gabaritos e Relatórios: 
Exemplos: 
     
Representação em UML:  Um conjunto de visualizações arquiteturais relevantes: Caso de Uso, Lógica, Processo, Implantação, Implementação, Dados.
Informações Adicionais:   
Entrada de Atividades:    Saída das Atividades:   

Finalidade Para o início da página

O documento de arquitetura de software fornece uma visão geral de arquitetura abrangente do sistema de software. Serve como um meio de comunicação entre o arquiteto de software e outros membros de equipe de projeto, com relação a decisões arquiteturalmente significativas tomadas sobre o projeto.

Sincronização Para o início da página

A representação e os objetivos da arquitetura de software geralmente devem ser definidos antes das primeiras iterações e, depois disso, mantidos durante todo o projeto. Essas diretrizes de representação arquitetural são documentadas nas versões iniciais do Documento de Arquitetura de Software.

O Documento de Arquitetura de Software é desenvolvido basicamente durante a fase de elaboração, porque uma das finalidades dessa fase é estabelecer uma base arquitetural sólida.

A visão de caso de uso no documento provavelmente deve ser considerada antes das outras visões, pois os casos de uso impulsionam o desenvolvimento e são uma entrada essencial no planejamento da iteração. No caso de sistemas com grande grau de simultaneidade e distribuição, considere também as visões de processos e implantação inicialmente, pois elas poderão causar um impacto significativo em todo o sistema.

Responsabilidade Para o início da página

Um arquiteto de software é responsável pela elaboração do Documento de Arquitetura de Software, que captura as decisões de design mais importantes em várias visualizações arquiteturais.

O arquiteto de software estabelece a estrutura geral de cada visualização arquitetural: a decomposição da visualização, o agrupamento de elementos e as interfaces entre esses agrupamentos maiores. Conseqüentemente, comparado a outras funções, a visualização do arquiteto de software é ampla, mas não profunda.

O arquiteto de software também é responsável pela manutenção da integridade arquitetural do sistema por meio do processo de desenvolvimento, procedendo da seguinte forma:

  • Aprovando todas as mudanças nos elementos arquiteturalmente significativos, como interfaces principais, descritos no Documento de Arquitetura de Software.
  • Tomando parte nas decisões do "comitê de controle de mudanças" para resolver problemas que afetam a arquitetura de software.

Adaptação Para o início da página

Faça ajustes no esboço do Documento de Arquitetura de Software para adaptação à natureza do software:

  • Algumas visões de arquitetura podem ser irrelevantes:
    • A Visão de Implantação não é necessária para sistemas de uma única CPU.
    • A Visão de Processos não será necessária se o sistema usar apenas um único thread de controle.
    • A Visualização de Dados não é necessária, a não ser que a persistência de objeto seja um aspecto significativo do sistema e que o mecanismo de persistência exija um mapeamento entre objetos persistentes e não persistentes.
  • Alguns aspectos específicos do software podem necessitar de uma seção própria; por exemplo, os aspectos relacionados às questões de gerenciamento de dados ou de usabilidade.
  • Apêndices adicionais podem ser necessários para explicar determinados aspectos, como os fundamentos de algumas escolhas críticas junto com as soluções que foram eliminadas, ou para definir acrônimos ou abreviações, ou para apresentar princípios gerais de design.
  • A ordem das várias seções pode variar, dependendo do foco ou do interesse dos envolvidos no negócio.

Veja a seguir as vantagens e as desvantagens de cada visão de arquitetura:

Visualização de Casos de Uso

Essa visualização é obrigatória.

Visão Lógica

Essa visualização é obrigatória.

Visão de Processos

Essa visualização é opcional. Utilize essa visualização apenas se o sistema tiver mais de um encadeamento de controle e os encadeamentos separados interagem ou dependem uns dos outros.

Visão de Implantação

Essa visualização é opcional. Utilize essa visualização apenas se o sistema é distribuído em mais de um nó. Até mesmo nesses casos, somente use esta visão no local em que a distribuição acarretar implicações na arquitetura. Por exemplo, nos casos em que há um único servidor e vários clientes, a visão de implantação apenas precisaria definir as responsabilidades do servidor e dos clientes como uma classe de nós; não haveria necessidade de mostrar cada nó de cliente se todos tivessem as mesmas capacidades.

Visão da Implementação

Essa visualização é opcional. Utilize essa visualização apenas nos casos em que a implementação não for rigorosamente baseada no design, isto é, onde houver uma distribuição diferente de responsabilidades entre os pacotes correspondentes nos modelos de Design e Implementação. Se os empacotamentos dos modelos de design e implementação forem idênticos, esta visão poderá ser omitida.

Visão de Dados

Essa visualização é opcional. Utilize essa visualização apenas se a persistência for um aspecto significativo do sistema e a conversão do modelo de design para o modelo de dados não for feita automaticamente pelo mecanismo de persistência.



Rational Unified Process   2003.06.15