Vous pouvez développer un modèle dans un fichier unique, puis le diviser en plusieurs fichiers. Chaque nouveau fichier constitue une partition du modèle.
Il est conseillé de ne partitionner le modèle qu'une fois son niveau d'abstraction stabilisé. Une fois stable, le partitionnement est moins susceptible de changer.
Les versions précédentes d'un modèle décrivent souvent les sous-systèmes de niveau supérieur d'un système. Il est conseillé de ne pas séparer le modèle tant que vous n'avez pas défini les sous-systèmes de niveau supérieur susceptibles de survivre aux itérations futures. Si les sous-systèmes de niveau supérieur sont matures et stables, vous pouvez les séparer pour permettre un développement parallèle et améliorer la vitesse d'ouverture du modèle. Si le contenu d'un sous-système individuel est stable, vous pouvez diviser le sous-système.
Il est recommandé de limiter les dépendances entre les modèles pour éviter que les changements apportés à un modèle n'affectent les autres.
Si vous affectez des dépendances entre les modèles, des conflits de grande envergure peuvent se produire lors d'une fusion. D'une manière générale, ces conflits sont des fusions hors contexte, qui peuvent être plus difficiles à convertir. La fusion d'un modèle partitionné peut être plus difficile que celle d'un modèle unique. Par exemple, si vous fusionnez des modèles partitionnés contenant des diagrammes faisant référence aux autres modèles, vous ne pouvez pas intégralement convertir les références lors de la fusion.
Vous pouvez réduire le nombre de fusions nécessaires en établissant une règle de propriété. De cette façon, chaque fichier est associé à un seul propriétaire autorisé à le modifier.
Pour mettre la propriété d'un modèle en pratique, vous devez définir la taille et la portée de chaque modèle de sorte qu'une seule personne puisse le gérer. Si une seule personne modifie un modèle à la fois, aucun conflit ne se produit lorsque vous déposez le modèle dans une zone de travail partagée. Ainsi, vous n'avez plus besoin de procéder à une fusion au moment de l'intégration et vous accélérez le processus d'intégration.
Pour éviter les références rompues, vous pouvez extraire les partitions de modèle de votre système de gestion de configuration.
Dans ce cas, vous rompez les références du modèle. Lors de la réintégration du modèle dans le système de gestion de configuration, vous devez convertir toutes les références rompues. Selon la complexité du modèle, le type de changement apporté et le nombre de références rompues, cette tâche peut être une utilisation inefficace des ressources.
Pour éviter l'altération des données lorsque vous gérez les partitions d'un modèle composite, vous devez toujours travailler dans un espace de travail synchronisé contenant toutes les partitions du modèle composite, chacune étant au même niveau de révision.
Exemple
L'exemple suivant illustre ce qu'il se produit lorsque vous gérez les partitions d'un modèle composite dans un espace de travail qui n'est pas synchronisé.
Si l'utilisateur B sélectionne la version présente dans l'espace de travail (le modèle X, version 20), il va probablement devoir répéter l'opération qui lui a demandé le retrait.
Toutefois, si l'utilisateur B sélectionne la dernière version du modèle (le modèle X, version 21) et qu'il l'enregistre, tous les changements auxquels a procédé l'utilisateur A sont perdus.