Particionamento de Modelo

É possível desenvolver um modelo em um único arquivo e, em seguida, dividi-lo em múltiplos arquivos. Cada novo arquivo é uma partição de modelo.

O particionamento de modelo pode facilitar a colaboração e o desenvolvimento para equipes que projetam sistemas complexos, fazendo o seguinte:
  • Impedindo que os membros da equipe trabalhem na mesma parte de um modelo ao mesmo tempo, quando a equipe utiliza um sistema de gerenciamento de configuração
  • Reduzindo a freqüência e a complexidade de sessões de mesclagem entre membros da equipe
  • Diminuindo a quantidade de tempo necessária para carregar modelos
No entanto, o particionamento de modelo pode impedir a colaboração e o desenvolvimento em equipe se ele for feito incorretamente. As seções a seguir fornecem recomendações para o particionamento correto de modelos.

Níveis de Abstração

Um modelo deve ser particionado apenas após seu nível de abstração estabilizar. Quando o nível de abstração de um modelo ficar estável, o particionamento provavelmente não será alterado.

Versões iniciais de um modelo normalmente descrevem os subsistemas de nível superior de um sistema. Você não deve separar o modelo até que tenha definido os subsistemas de nível superior que provavelmente sobreviverão a iterações futuras. Quando os subsistemas de nível superior estiverem maduros e estáveis, será possível separá-los para permitir o desenvolvimento em paralelo e aumentar a velocidade com que o modelo é aberto. Quando o conteúdo de um subsistema específico estabilizar, será possível dividi-lo.

Dependências

Você deve tentar minimizar as dependências entre modelos para reduzir a possibilidade de que uma alteração em um modelo afete outro.

Se você permitir dependências entre modelos, conflitos generalizados podem ocorrer em uma mesclagem. Esses conflitos normalmente são mesclagens fora de contexto, que podem ser mais difíceis de resolver. Um modelo particionado pode ser mais difícil de mesclar que um modelo único. Por exemplo, se você mesclar modelos particionados que contenham diagramas com referências a outros modelos, não poderá resolver totalmente as referências durante a mesclagem.

Políticas de Propriedade

É possível reduzir o número de mesclagens requeridas pelo estabelecimento de uma política de propriedade, de forma que cada arquivo tenha apenas um proprietário que possa fazer alterações.

Para praticar a propriedade de modelo, é necessário estabelecer o tamanho e o escopo de cada modelo para que uma única pessoa possa trabalhar nele. Quando uma única pessoa altera um modelo por vez, nenhum conflito surge ao entregar o modelo para uma área de trabalho compartilhada, o que elimina a necessidade por mesclagens no momento da integração e acelera o processo de integração.

Referências Interrompidas

Para evitar referências interrompidas, você não deve mover partições de modelos para fora do sistema de gerenciamento de configuração.

Se fizer isto, você interromperá as referências no modelo. Ao reintegrar o modelo no sistema de gerenciamento de configuração, deverá resolver todas as referências interrompidas. Dependendo da complexidade do modelo, dos tipos de alterações feitas e da quantidade de referências interrompidas, essa tarefa pode ser uma utilização ineficiente dos recursos.

Espaços de Trabalho Sincronizados

Para evitar corrupção de dados ao trabalhar com partições de um modelo composto, você deve trabalhar sempre em um espaço de trabalho sincronizado que contenha todas as partições do composto, com cada partição no mesmo nível de revisão.

Exemplo

O exemplo a seguir mostra o que pode acontecer se você trabalhar com partições de um modelo composto em um espaço de trabalho não sincronizado.

Em um sistema de gerenciamento de configuração, um modelo composto é consiste em duas partições de modelo, modelo X e modelo Y. Ambos os modelos estão na versão 20. O modelo X contém um pacote, P1. O modelo Y está vazio.
  1. O usuário A registra a saída de dois modelos, ambos na versão 20.
  2. O usuário A faz diversas alterações em P1 e move P1 do modelo X para o modelo Y.
  3. O usuário A registra a entrada do modelo X e do modelo Y. Ambos os arquivos agora estão na versão 21.
  4. O usuário B possui o modelo X, versão 20, em seu espaço de trabalho e faz uma alteração em P1. O sistema de gerenciamento de configuração avisa o Usuário B a registrar a saída da versão existentes no espaço de trabalho (modelo X, versão 20) ou da versão mais nova (modelo X, versão 21).

Se o Usuário B selecionar a versão existente no espaço de trabalho (modelo X, versão 20), poderá ser necessário repetir a operação que avisou o registro de saída.

No entanto, se o Usuário B selecionar a versão mais nova do modelo (modelo X, versão 21), todas as alterações feitas pelo Usuário A no modelo serão perdidas quando o Usuário B salvar o modelo.

Tarefas relacionadas
Organizando Modelos para Desenvolvimento em Equipe
Particionando Modelos
Termos de uso | Feedback
(C) Copyright IBM Corporation 2004, 2005. Todos os Direitos Reservados.