Artefatos > Conjunto de Artefatos de Análise e Design > Modelo de Design... > Modelo de Design > Diretrizes > Dependência de Importação no Design

Dependência

Uma dependência de importação no modelo de design é uma dependência estereotipada cuja origem é um pacote de design e cujo destino é um pacote de design diferente. A dependência de importação permite que seja feita referência ao conteúdo público do pacote de destino no pacote de origem.
Tópicos

Explicação Início da página

O gerenciamento de dependências de importação entre pacotes é um aspecto importante da estruturação de um modelo de objetos. Um pacote depende de outro se uma de suas classes possuir relacionamentos que sejam navegáveis para classes do outro pacote. Para expressar essas dependências, use a dependência de importação de um pacote para o pacote do qual ele depende.

As dependências entre pacotes são expressas por dependências de importação.

Uso Início da página

Você desenvolve dependências de importação da seguinte maneira:

  • Antes de iniciar o trabalho com o modelo de objetos, faça esquemas de dependências para usar como diretrizes durante o trabalho.
  • Quando o modelo estiver concluído, use-o para mostrar as dependências que realmente estão nele. Isso implica em atualizar dependências de importação no modelo de objetos.
  • Se você tiver dividido o modelo em pacotes anteriormente, use as dependências de importação para mostrar onde as dependências são permitidas.
  • A maneira como os pacotes dependem um do outro afeta a tolerância de um sistema à mudança. Será mais fácil alterar um modelo de objeto se você:
  • Referenciar um número mínimo de classes contidas de fora de cada pacote. Se você referenciar muitas classes, o pacote poderá ter muitas responsabilidades diferentes e deverá ser dividido em dois.
  • Faça cada pacote depender de um número pequeno de outros pacotes.
  • Teste cada pacote separadamente. Isso significa que você deve testar um pacote simulando o pacote do qual ele depende. Você não deve exigir que outros pacotes sejam parcial ou totalmente implementados. Se puder testar um pacote separadamente, o desenvolvimento e a manutenção do sistema para cada pacote será mais fácil.
  • Posicione as partes gerais do modelo de objetos em pacotes separados, dos quais outros pacotes dependem. Se houver tal pacote, preste bastante atenção ao liberar seu gerenciamento, já que várias partes do sistema podem ser afetadas por mudanças no pacote.

Exemplo

Suponha que você encontre algo em comum para as classes Painel do Cliente e Painel do Operador na máquina de reciclagem. Você atribui esses serviços gerais a uma nova classe, Painel, que você coloca em um novo pacote, Painéis. As outras duas classes poderão então fazer referência a essa classe para usar os serviços gerais. Como as classes pertencem a dois pacotes separados, os dois pacotes dependerão do novo pacote. Essa eliminação de redundância faz com que as mudanças na funcionalidade comum só precisem ser feitas em um lugar.

Copyright  © 1987 - 2001 Rational Software Corporation


Exibir o Rational Unified Process usando quadros

Rational Unified Process