|
O Produto de Trabalho: Classes de Análise representa as funções
desempenhadas por instâncias de elementos de design; essas funções podem ser preenchidas por um ou mais elementos de
modelo de design. Além disso, um único elemento de design pode desempenhar vários papéis. As observações abaixo abordam
as maneiras como os papéis de análise podem ser desempenhados:
-
Uma classe de análise pode tornar-se uma única classe de design no modelo de design.
-
Uma classe de análise pode tornar-se parte de uma classe de design no modelo de design.
-
Uma classe de análise pode tornar-se de uma classe de design agregada no modelo de design. (Ou seja, as partes
dessa agregação podem não estar modeladas explicitamente como classes de análise.)
-
Uma classe de análise pode tornar-se um grupo de classes de design que herda da mesma classe no modelo de design.
-
Uma classe de análise pode tornar-se um grupo de classes de design funcionalmente relacionadas no modelo de design.
-
Uma classe de análise pode tornar-se de um subsistema de design no modelo de design.
-
Uma classe de análise pode tornar-se parte de um subsistema de design, como uma ou mais interfaces e suas
implementações correspondentes.
-
Uma classe de análise pode vir a ser um relacionamento no modelo de design.
-
Um relacionamento entre classes de análise pode tornar-se uma classe de design no modelo de design.
-
As classes de análise manipulam principalmente os requisitos funcionais e objetos de modelo provenientes do domínio
de "problema", as classes de design manipulam os requisitos não-funcionais e objetos de modelo provenientes do
domínio de "solução".
-
As classes de análise podem ser utilizadas para representar "os objetos que desejamos que sejam suportados pelo
sistema", sem tomar uma decisão sobre quantos devem ser suportados com hardware e quantos com software. Assim,
parte de uma classe de análise pode ser usada pelo hardware e não estar definida no modelo de design.
Qualquer combinação dos itens descritos acima também é possível.
Se um Modelo de Análise separado for mantido, certifique-se de manter a rastreabilidade do elemento de design
identificado para as Classes de Análise às quais corresponderem. Para obter informações adicionais, consulte Mapeando para o Modelo de Análise.
Esta seção se aplicará apenas se um Modelo de Análise for mantido.
Durante o design, são identificados elementos de design que suportam um alinhamento mais estrito com a arquitetura e as
tecnologias escolhidas. Toda Classe de Análise no Modelo de Análise deve ser associada a pelo menos uma classe de
design no Modelo de Design.
Para modelar essa rastreabilidade, uma dependência de <<rastreio>> deve ser desenhada do elemento de design
para a(s) classe(s) que ela representa, conforme mostrado no diagrama a seguir:
Nota: os links de rastreabilidade são desenhados dos elementos do Modelo de Design aos elementos do
Modelo de Análise, de modo que o Modelo de Design seja dependente do Modelo de Análise e não ao contrário.
Antes de iniciar o design, você deve escolher como as classes do modelo de design devem se relacionar às classes de
implementação. No Guia de Design, você pode obter mais informações específicas sobre o projeto.
O modelo de design pode se aproximar mais ou menos do modelo de implementação, dependendo de como você mapeia classes,
pacotes e subsistemas para classes de implementação, arquivos, pacotes e subsistemas no modelo de implementação.
Durante a implementação, você abordará muitas vezes pequenas questões táticas relacionadas ao ambiente de implementação
que não devem impactar o modelo de design. Por exemplo, as classes e os subsistemas podem ser adicionados durante a
implementação para lidar com o desenvolvimento paralelo ou ajustar dependências de importação. Para obter informações
adicionais, consulte Tarefa: Estruturar o Modelo de Implementação e Técnica: Mapeando de Design para Código.
O mapeamento do modelo de design para o modelo de implementação deve ser consistente. O Produto de Trabalho: Diretrizes Específicas do Projeto deve definir
este mapeamento e um nível consistente de abstração deverá ser aplicado em todo o modelo de design.
Um bom modelo de design tem as características a
seguir:
-
Satisfaz os requisitos do sistema.
-
Resiste a mudanças efetuadas no ambiente de implementação.
-
É de fácil manutenção em relação a outros possíveis modelos de objeto e à implementação do sistema.
-
Tem um procedimento de implementação claro.
-
Não inclui informações que estejam melhor documentadas no código do programa.
-
Adapta-se facilmente a mudanças efetuadas em requisitos.
Para obter características específicas, consulte Lista de
Verificação: Modelo de Design.
|
