Documento de Arquitetura de Software		 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.
Papel: Arquiteto de Software
Templates:
Exemplos:
Mais informações:

Entrada para Atividades: Saída de Atividades:

Finalidade Início da página

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

Ocorrência 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 da arquitetura 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, pois uma das finalidades dessa fase é estabelecer uma base sólida de arquitetura.

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 Início da página

O arquiteto de software é responsável pela produção do Documento de Arquitetura de Software, que captura as decisões de design mais importantes em várias visões de arquitetura.

O arquiteto de software estabelece a estrutura geral de cada visão de arquitetura: a decomposição da visão, o agrupamento de elementos e as interfaces entre esses agrupamentos principais. Portanto, comparada aos outros papéis, a visão do arquiteto de software é ampla, e não detalhada.

O arquiteto de software também é responsável por manter a integridade arquitetural do sistema durante o processo de desenvolvimento fazendo o seguinte:

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

Adaptação Início da página

Ajuste o esquema do Documento de Arquitetura de Software para adaptá-lo à natureza do seu 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 Visã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 diversas seções pode variar de acordo com os envolvidos no sistema e seu foco ou interesse.

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

Visão de Casos de Uso

Esta visão é obrigatória.

Visão Lógica

Esta visão é obrigatória.

Visão de Processos

Esta visão é opcional. Utilize-a somente se o sistema tiver mais de um thread de controle e se os threads separados interagirem ou forem dependentes entre si.

Visão de Implantação

Esta visão é opcional. Utilize-a somente se o sistema for distribuído por 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

Esta visão é opcional. Utilize-a somente nos casos em que a implementação não for rigorosamente baseada no design, isto é, no local em que 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

Esta visão é opcional. Utilize-a somente se a persistência for um aspecto significativo do sistema e se a conversão do Modelo de Design no Modelo de Dados não for feita automaticamente pelo mecanismo de persistência.

 

Copyright  (c) 1987 - 2001 Rational Software Corporation


Exibir o Rational Unified Process usando quadros

Rational Unified Process