Partitionnement de modèle

Vous pouvez développer un modèle dans un même fichier, puis le diviser en plusieurs fichiers que l'on appelle partitions de modèle. Le partitionnement d'un modèle est une solution à envisager lorsque la taille de sa structure de packages devient ingérable.

Vous ne devez partitionner un modèle que dans des circonstances extrêmes, car s'il n'est pas réalisé correctement, le partitionnement peut empêcher la collaboration et le développement en équipe. Avant de partitionner un modèle, vérifiez que son architecture est efficace et que vous lui associez un propriétaire adéquat, ceci afin de minimiser les partitions et de réduire les fusions conflictuelles ("non triviales").

Architecture efficace et propriétaire adéquat

L'efficacité de l'architecture d'un modèle dépend en grande partie de la manière dont il est décomposé. Les principes de décomposition suivants sont les mêmes que ceux qui régissent le développement orienté objet, la conception à base de composants et les architectures orientées services (SOA) :

Si votre modèle décomposé comprend toujours un grand nombre de dépendances, vous avez deux possibilités :

Après avoir établi une architecture efficace, vous pouvez attribuer la propriété des composants architecturaux à des individus ou à de petites équipes. Lorsqu'une seule personne ou une petite équipe collaborant étroitement travaille sur un package logique ou une branche d'un modèle, les fusions non triviales (conflictuelles) sont minimisées, que le modèle soit stocké dans un même fichier de modélisation ou dans plusieurs.

Vous pouvez éviter les fusions non triviales en partitionnant votre modèle dans plusieurs fichiers de modélisation, car les interdépendances architecturales sont logiques et non physiques. Lorsqu'un modèle est partitionné dans plusieurs fichiers de modélisation, les représentations des interdépendances des éléments deviennent des références interfichiers au lieu de références intrafichiers.

Les conflits de fusion résultant de références interfichiers rompues sont difficiles à résoudre. Les références interfichiers constituent des points de rupture potentiels, car les fichiers sont exposés (accessibles) dans le système de fichiers de l'ordinateur hôte. Ces références ne peuvent pas être suivies et mises à jour par Eclipse si vous déplacez, renommez ou modifiez de quelque manière que ce soit les fichiers en dehors de l'environnement Eclipse.

Quand partitionner un modèle

Le partitionnement d'un modèle en plusieurs fichiers est à envisager dans les situations suivantes :

Certaines politiques de gestion des configurations autorisent le développement en parallèle, dans lequel plusieurs membres d'une équipe travaillent en même temps sur un même modèle. Lors d'un développement en parallèle, les modifications non coordonnées peuvent avoir une incidence néfaste sur un fichier et sur le modèle logique ou le sous-ensemble de modèle que ce fichier représente. Vous devez fusionner toutes les modifications avant de pouvoir sauvegarder le fichier du modèle dans le système de gestion des configurations. Une fusion dite "triviale" (ou non conflictuelle) a lieu lorsque les modifications apportées par les différents intervenants ne sont pas contradictoires. Dans ce cas, l'outil de fusion de modèle fusionne les modifications automatiquement. Une fusion dite "non triviale (ou conflictuelle) a lieu lorsque plusieurs utilisateurs produisent des modifications contradictoires. Dans ce cas, un utilisateur doit jouer le rôle d'arbitre et déterminer les modifications à accepter.

Niveaux d'abstraction

Il est conseillé de ne partitionner le modèle qu'une fois son niveau d'abstraction stabilisé. En effet, lorsque le niveau d'abstraction d'un modèle est stable, le partitionnement est moins susceptible de changer. Vous devez aussi identifier les composants communs et les stabiliser en premier, car les modifications apportées aux composants communs peuvent créer des conflits et affecter toutes les autres partitions.

Les premières versions 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. Une fois que les sous-systèmes de niveau supérieur sont biens définis et stables, vous pouvez les séparer pour permettre le développement en parallèle et "ouvrir" plus rapidement le modèle. Dès que le contenu d'un sous-système particulier est stabilisé, vous pouvez diviser ce sous-système.

Espaces de travail synchronisés

Pour éviter l'altération des données lorsque vous manipulez les partitions d'un modèle, vous devez toujours travailler dans un espace synchronisé, contenant toutes les partitions au même niveau de révision.

Exemple

L'exemple suivant montre ce qui peut arriver si vous travaillez sur les partitions d'un modèle dans un espace de travail non synchronisé.

Dans un système de gestion de configurations, un modèle est scindé en deux partitions, le modèle X et le modèle Y. Les deux modèles sont au niveau de version 20. Le modèle X contient un package appelé P1. Le modèle Y est vide.

Deux utilisateurs prennent part au workflow suivant :

  1. L'utilisateur A extrait les deux modèles, tout deux à la version 20.
  2. L'utilisateur A apporte plusieurs modifications au package P1, puis il transfère celui-ci du modèle X au modèle Y.
  3. L'utilisateur A archive 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 apporte une modification à P1.
  5. Lorsque l'utilisateur B tente de sauvegarder ses modifications, le système de gestion de configurations l'invite à extraire soit la version présente dans l'espace de travail (le modèle X, version 20), soit la version plus récente (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 est possible qu'il doive répéter l'opération qui a provoqué la demande d'extraction de la part du système de gestion de configurations.

En revanche, si l'utilisateur B choisit d'extraire la nouvelle version du modèle (modèle X, version 21) pour sauvegarder ses modifications, il écrase les changements apportés par l'utilisateur A.

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.