É possível desenvolver um modelo em um único arquivo e, em seguida, dividi-lo em múltiplos arquivos, que são denominados partições de modelo. Você pode considerar o particionamento de um modelo quando o tamanho ou a estrutura de pacote do modelo se tornar não gerenciável.
Você deve particionar apenas um modelo em circunstâncias extremas, porque o particionamento do modelo pode atrapalhar a colaboração da equipe e o desenvolvimento se não o fizer corretamente. Antes de considerar a partição de um modelo, você deve assegurar-se de que possui uma arquitetura efetiva para o seu modelo e designar a participação efetiva dele, de modo que possa minimizar as partições e reduzir mesclas não triviais.
Uma arquitetura de modelo efetivo depende intensamente da decomposição. Os seguintes princípios de decomposição são os mesmos que conduzem ao desenvolvimento orientado a objetos, design baseado em componente e arquiteturas orientadas ao serviço:
Se o seu modelo decomposto ainda contiver um número maior de dependências, você terá duas opções:
Depois de estabelecer uma arquitetura efetiva, você poderá designar o direito à propriedade de componente arquiteturais para os indivíduos ou pequenas equipes. Quando apenas uma pessoa ou uma pequena equipe na proximidade trabalhar em um pacote lógico ou ramificação em um modelo, você minimizará as mesclas não-triviais, independentemente do fato de armazenar o modelo em um único arquivo de modelagem ou em vários arquivos de modelagem.
Você não pode evitar a mescla não-trivial particionando os modelos em vários arquivos de modelagem porque as interdependências arquiteturais são lógicas e não físicas. Se você particionar um modelo em vários arquivos de modelagem, as representações das interdependências de elemento se tornarão referências de arquivo cruzado em vez de referência em arquivo.
Os conflitos de fusão que ocorrem devido a referência de arquivo cruzado são difíceis de serem resolvidos. As referências de arquivo cruzado representam potenciais pontos de interrupção porque você expõe os arquivos no sistema de arquivo host. Portanto, se você mover, renomear ou então modificar os arquivos fora do ambiente Eclipse, o Eclipse não poderá rastrear as referências de arquivo cruzado.
Você deve considerar a partição de um modelo em vários arquivos nas seguintes situações:
Algumas políticas de gerenciamento de configuração permitem o desenvolvimento paralelo, no qual vários membros da equipe trabalham em um modelo ao mesmo tempo. Durante o desenvolvimento paralelo, as alterações não coordenadas podem causar impacto em um arquivo e no modelo lógico ou no subconjunto de modelos que o arquivo representa. Você deve mesclar quaisquer alterações antes de salvar o arquivo de modelo no sistema do gerenciamento de configuração. Uma mescla trivial ocorre quando as alterações não entram em conflito, de modo que a ferramenta de mescla de modelo mescla as alterações automaticamente. Uma mescla não-trivial ocorre quando vários usuários fazem alterações de conflito e um usuário tem que determinar quais alterações aceitar.
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. Você também deve identificar os componentes comuns e estabilizá-los primeiro porque as alterações nos componentes comuns podem criar conflitos que afetam outras partições.
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.
Para evitar danos nos dados ao trabalhar com partições de modelo, você sempre deve trabalhar em um espaço de trabalho sincronizado que contenha todas as partições no mesmo nível de revisão.
Exemplo
O seguinte exemplo mostra o que pode acontecer se você trabalhar com partições de um modelo em um espaço de trabalho não sincronizado.
Em um sistema de gerenciamento de configuração, um modelo possui duas partições, o modelo X e o modelo Y. Ambos os modelos estão na versão 20. O modelo X contém um pacote, denominado P1. O modelo Y está vazio.
Dois usuários entraram no seguinte fluxo de trabalho:
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 salvar suas alterações com uma versão mais recente do modelo (modelo X, versão 21), ele substituirá as alterações que o Usuário A efetuou.