Artefatos > Conjunto de Artefatos de Análise e Design > Modelo de Design... > Modelo de Design > Diretrizes > Modelo de Design


Modelo de Design

O Artefato: Modelo de Design é um modelo de objeto que descreve a realização de casos de uso e serve como uma abstração do modelo de implementação e seu código-fonte.
Tópicos

Mapeamento do Modelo de AnáliseInício da página

Artefato: Classe de Análise representa papéis desempenhados por instâncias de elementos de design. Esses papéis podem ser preenchidos 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 vir a ser uma única classe no modelo de design.
  • Uma classe de análise pode fazer parte de uma classe no modelo de design.
  • Uma classe de análise pode vir a ser uma classe agregada no modelo de design (ou seja, as partes dessa classe agregada podem não estar definidas explicitamente no modelo de análise).
  • Uma classe de análise pode vir a ser um grupo de classes que herda da mesma classe no modelo de design.
  • Uma classe de análise pode vir a ser um grupo de classes relacionadas funcionalmente no modelo de design.
  • Uma classe de análise pode vir a ser um pacote no modelo de design (ou seja, pode tornar-se um componente).
  • Uma classe de análise pode vir a ser um relacionamento no modelo de design.
  • Um relacionamento entre as classes de análise pode vir a ser uma classe no modelo de design.
  • As classes de análise lidam principalmente com requisitos funcionais e objetos de modelo provenientes do domínio "problema". As classes de design lidam com requisitos não-funcionais e objetos de modelo provenientes do domínio "solução".
  • As classes de análise podem ser usadas para representar "os objetos aos quais desejamos que o sistema dê suporte", sem que você precise definir quantas suportarão o hardware e quantas suportarão o 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.

Mapeamento para o Modelo de Implementação Início da página

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 ser semelhante ao modelo de implementação, dependendo de como você mapeará classes, pacotes e subsistemas para componentes, 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 mais informações, consulte Atividade: Estruturar o Modelo de Implementação e Conceitos: Mapeamento para Código a partir do Design.

O mapeamento do modelo de design para o modelo de implementação deve ser consistente. O Artefato: Guia de Design define esse mapeamento. Um nível consistente de abstração deve ser aplicado em todo o modelo de design.

Características de um Bom Modelo de Design Início da página

Um bom modelo de design tem as seguintes características:

  • 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 informações sobre características específicas, consulte Pontos de Verificação: Modelo de Design.

Copyright  © 1987 - 2001 Rational Software Corporation


Exibir o Rational Unified Process usando quadros

Rational Unified Process