Artefato:
|
![]() |
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: | ||
|
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.
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.
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:
Faça ajustes no esboço do Documento de Arquitetura de Software para adaptação à natureza do software:
Veja a seguir as vantagens e as desvantagens de cada visão de arquitetura:
Essa visualização é obrigatória.
Essa visualização é obrigatória.
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.
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.
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.
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
|