Organização Lógica
A organização lógica de modelo deve atingir as seguintes metas:
Organização Física
O modelo de organização física tem duas abordagens:
Planejar a estratégia de particionamento físico tem vantagens, mas uma abordagem mais espontânea também é válida e, às vezes, pode solucionar problemas negligenciados ou não antecipados em uma abordagem planejada. Por exemplo, você pode decidir por desempenhar o particionamento físico quando o tamanho geral do modelo, ou profundidade da estrutura do pacote, se torna impossível de gerenciar devido a novos requisitos ou complexidades de design inesperadas.
Mesclagens de Modelo
A mesclagem de modelo é uma consideração importante quando se planeja a organização lógica e física de modelos.
Algumas políticas de gerenciamento de configuração permitem o desenvolvimento paralelo, no qual vários membros da equipe trabalham no mesmo modelo ao mesmo tempo. Durante o desenvolvimento paralelo, alterações não-coordenadas podem impactar o modelo. Você deve mesclar quaisquer alterações antes de salvar o arquivo de modelo no sistema de gerenciamento de configuração. Uma mesclagem comum ocorre quando alterações não estão em conflito e uma ferramenta mescla as alterações automaticamente. Uma mesclagem que não é comum ocorre quando alterações estão em conflito e você determina quais alterações aceitar.
Uma arquitetura de modelo efetivo depende intensamente da decomposição, que é a capacidade de dividir um sistema em partes. 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 seu modelo decomposto ainda contiver um grande número 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 mesclagens que não são comuns, independentemente do fato de armazenar o modelo em um único arquivo de modelagem ou em vários arquivos de modelagem.
Dois mecanismos estão disponíveis para modelos lógicos de particionamento: criação e fragmentação de um modelo separado.
Quando você cria um modelo separado, geralmente começa com muitos pacotes de modelos lógicos organizados em uma raiz de modelo lógico ou pacote raiz. Esses pacotes lógicos ocupam o mesmo arquivo físico de modelagem. Você seleciona um pacote abaixo da raiz e cria um modelo físico desse pacote. O pacote se torna então um novo modelo de alto nível na visualização Explorador de Projetos. O novo modelo não pertence mais logicamente ao modelo do qual ele foi particionado. Além disso, relacionamentos entre os elementos que o novo modelo contém e elementos ainda contidos pelo modelo lógico pai anterior ao modelo se tornam relacionamentos entre arquivos. Anteriormente, os relacionamento ficavam no arquivo, o que impactava os cenários de comparação e mesclagem de modelos.
Em oposição, com a fragmentação de um modelo, você seleciona qualquer elemento de tipo de classificador de um modelo e o gerencia como um fragmento. Um fragmento é um arquivo de recursos Eclipse físico separado, mas um modelo lógico pai possui seu conteúdo.
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.
Geralmente você particiona modelos fisicamente para tentar reduzir o número e magnitude das atividades de comparação e mesclagem dos modelos. No entanto, você não pode evitar a mesclagem que não seja comum 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. Conflitos de mesclagem que envolvem referências entre arquivos são difíceis de solucionar porque você não conhece o conteúdo lógico dos modelos em outros arquivos de modelo. Quando você tiver de executar uma mesclagem, o particionamento físico torna as sessões de mesclagem mais desafiadoras.
O particionamento físico de modelo é adequado nos seguintes cenários:
Se você não particiona modelos fisicamente, concentre-se na organização lógica, na propriedade do pacote lógico seguro e nos arquivos de modelo fisicamente grandes. Se você usa o Rational ClearCase, utilize as visualizações dinâmicas ou estáticas privadas e a nova base e entrega UCM para manter a integridade do modelo até completar a integração.
Além disso, só particione um modelo depois que o conteúdo lógico começar a estabilizar, para que as decisões de partição sejam menos provável de alteração. Por exemplo, versões anteriores de um modelo geralmente descrevem subsistemas de nível superior. Você não deve fazer a partição até que defina os subsistemas de nível superior que provavelmente permanecerão em iterações futuras. Quando os subsistemas de nível superior estiverem maduros e estáveis, será possível separá-los fisicamente, se isso aumentar os fluxos de trabalho de desenvolvimento paralelo ou o desempenho de tarefas como abrir ou publicar modelos. Além disso, concentre-se em estabilizar logicamente primeiro os componentes altamente compartilhados, pois alterações nesses componentes podem apresentar conflitos que afetam todas as outras partições.
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.