Partitionnement de modèle

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.

Le partitionnement de modèle facilite le travail de collaboration et de développement pour les équipes de conception de systèmes complexes, notamment :
  • En évitant que les membres de l'équipe ne travaillent simultanément sur la même portion d'un modèle, lorsqu'ils utilisent un système de gestion de configuration
  • En réduisant la fréquence et la complexité des sessions de fusion entre les membres de l'équipe
  • En diminuant la durée nécessaire au chargement des modèles
Toutefois, s'il n'est pas réalisé correctement, le partitionnement de modèle peut gêner la collaboration et le développement. Les sections suivantes fournissent des recommandations pour réaliser un partitionnement de modèle correct.

Niveaux d'abstraction

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.

Dépendances

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.

Règles de propriété

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.

Références rompues

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.

Espaces de travail synchronisés

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é.

Dans un système de gestion de configuration, un modèle composite est composé de deux partitions de modèle, le modèle X et le modèle Y. Il s'agit de la version 20 de ces deux modèles. Le modèle X contient un package, P1. Le modèle Y est vide.
  1. L'utilisateur A retire les deux modèles, tout deux à la version 20.
  2. L'utilisateur A procède à plusieurs changements de P1, qu'il déplace du modèle X vers le modèle Y.
  3. L'utilisateur A réintègre les modèles X et Y. Les deux fichiers sont désormais à la version 21.
  4. L'utilisateur B détient le modèle X, version 20, dans son espace de travail et procède à un changement de P1. Le système de gestion de configuration l'invite soit à retirer la version présente dans l'espace de travail (le modèle X, version 20) soit la dernière version (le modèle X, version 21).

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.

Tâches associées
Organisation des modèles pour le développement en équipe
Partitionnement des modèles
Conditions d'utilisation | Retours d'informations
(C) Copyright IBM Corporation 2004, 2005. All Rights Reserved.