Organisation des modèles

Si vous partagez des modèles UML avec des membres de l'équipe, il est recommandé d'établir une organisation des modèles et une stratégie de partitionnement de modèle. L'organisation des modèles comporte deux aspects : logique et physique.

Organisation logique

L'organisation logique des modèles doit remplir les objectifs suivants :

Organisation physique

L'organisation physique des modèles comporte deux approches :

Bien que la planification de la stratégie de partitionnement physique offre des avantages, une approche plus spontanée convient également et peut parfois couvrir des enjeux ignorés ou non anticipés lors d'une approche planifiée. Par exemple, vous pouvez décider d'effectuer un partitionnement physique lorsque la taille de modèle globale ou l'étendue de la structure de package devient ingérable en raison d'exigences nouvelles ou de complexités de conception imprévues.

Fusions de modèles

La fusion de modèles est un point important lors de la planification de l'organisation physique et logique des modèles.

Certaines règles de gestion de configuration permettent un développement parallèle, dans lequel plusieurs membres de l'équipe travaillent sur un même modèle en même temps. Lors d'un développement parallèle, des changements non coordonnés peuvent affecter le modèle. Vous devez fusionner les changements pour pouvoir sauvegarder le fichier de modèle dans le système de gestion de configuration. Une fusion triviale se produit lorsque les changements n'engendrent pas de conflits. Dans ce cas, l'outil de fusion de modèle fusionne les changements automatiquement. Une fusion non triviale se produit lorsque des changements engendrent des conflits et que vous devez déterminer les changements à accepter.

Propriété et architecture de modèle efficaces

Une architecture de modèle efficace repose en grande partie sur la décomposition, c'est-à-dire la possibilité de diviser un système en composants. Les principes de décomposition suivants sont les mêmes que ceux qui guident le développement orienté objet, la conception basée sur les composants et les architectures orientées service :

Après la décomposition, si votre modèle contient toujours un grand nombre de dépendances, vous avez deux options :

Après avoir établi une architecture efficace, vous pouvez attribuer la propriété des composants architecturaux à des individus ou à des petites équipes. Lorsqu'une personne ou une petite équipe travaille sur un package ou une branche logique dans un modèle, vous minimisez les fusions non triviales avec ce modèle, que vous stockiez le modèle dans un fichier de modélisation unique ou dans plusieurs fichiers de modélisation.

Types de partitionnement physique

Deux mécanismes sont disponibles pour le partitionnement des modèles logiques : la création d'un modèle distinct et la fragmentation.

Lorsque vous créez un modèle distinct, vous commencez généralement par utiliser divers packages de modèle logique organisés sous une racine commune, le package racine. Ces packages logiques occupent le même fichier de modélisation physique. Vous sélectionnez un package sous la racine et créez un modèle physique à partir de celui-ci. Ce package devient alors un nouveau modèle logique de niveau supérieur dans la vue Explorateur de projets. Le nouveau modèle n'est plus logiquement détenu par le modèle à partir duquel il a été partitionné. En outre, les relations entre les éléments que le nouveau modèle contient et les éléments qui figurent encore dans le modèle logique parent deviennent des relations inter-fichiers. Il s'agissait précédemment de relations intra-fichiers, ce qui affecte les scénarios de comparaison/fusion de modèles.

En revanche, lors de la fragmentation d'un modèle, vous sélectionnez un élément de type discriminant dans un modèle et vous le gérez comme un fragment. Un fragment est un fichier de ressources physique Eclipse distinct, dont le contenu est détenu par un modèle logique parent.

Quand faut-il effectuer le partitionnement physique d'un modèle ?

Vous devez partitionner un modèle uniquement en cas d'urgence. Le partitionnement de modèle peut, en effet, entraver la collaboration et le développement coopératif s'il n'est pas fait correctement.

En général, vous partitionnez des modèles physiquement pour tenter de réduire le nombre et la taille des activités de comparaison/fusion de modèles. Vous ne pouvez pas empêcher les fusions non triviales en partitionnant les modèles dans plusieurs fichiers de modélisation, car les interdépendances architecturales sont logiques et non physiques. Si vous partitionnez un modèle dans plusieurs fichiers de modélisation, les représentations des interdépendances d'élément deviennent des références inter-fichiers au lieu de références intra-fichiers. Les conflits de fusion impliquant des références inter-fichiers sont difficiles à résoudre car vous ignorez le contenu logique des modèles qui se trouvent dans d'autres fichiers de modèle. Lorsque vous devez effectuer une fusion, le partitionnement physique rend les sessions de fusion plus complexes.

Le partitionnement physique de modèle est approprié dans les scénarios suivants :

Si vous ne partitionnez pas physiquement les modèles, concentrez vos efforts sur l'organisation logique, la propriété forte de packages logiques et les fichiers de modèle physiquement grands. Si vous utilisez Rational ClearCase, employez des vues dynamiques ou statiques privées ainsi que des opérations de réajustement et de livraison UCM pour conserver l'intégrité du modèle jusqu'à ce que vous ayez terminé l'intégration complète.

De même, ne partitionnez un modèle que lorsque son contenu logique commence à se stabiliser et que, par conséquent, les décisions de partitionnement sont moins susceptibles d'être modifiées. Par exemple, les premières versions d'un modèle décrivent souvent les sous-systèmes de niveau supérieur. Vous ne devez pas partitionner le modèle avant d'avoir défini les sous-systèmes de niveau supérieur qui seront toujours présents dans les itérations futures. Lorsque les sous-systèmes de niveau supérieur sont mûrs et stables, vous pouvez les séparer physiquement si cette opération améliore les enchaînements d'activités du développement parallèle ou les performances de tâches comme l'ouverture ou la publication de modèles. Concentrez également vos efforts sur la stabilisation logique des composants communs très partagés. Ces composants doivent être traités en premier car leur modification peut générer des conflits ayant une incidence sur toutes les autres partitions.

Espaces de travail synchronisés

Pour éviter une corruption des données lorsque vous travaillez avec des partitions de modèle, vous devez toujours travailler dans un espace de travail synchronisé qui contient toutes les partitions au même niveau de révision.

Exemple

L'exemple suivant montre ce qui peut se passer si vous travaillez avec des partitions de modèle dans un espace de travail non synchronisé.

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

Deux utilisateurs exécutent les enchaînements d'activités suivants :

  1. L'utilisateur A extrait les deux modèles qui sont tous les deux en version 20.
  2. L'utilisateur A apporte plusieurs changements à P1 et déplace P1 du modèle X au modèle Y.
  3. L'utilisateur A restitue le modèle X et le modèle Y. Les deux fichiers sont désormais en version 21.
  4. L'utilisateur B dispose du modèle X, version 20, dans son espace de travail et apporte un changement à P1.
  5. Lorsque l'utilisateur B tente de sauvegarder ses changements, le système de gestion de configuration invite l'utilisateur B à extraire, soit la version existante dans l'espace de travail (modèles X, version 20), soit la version la plus récente (modèle X, version 21).

Si l'utilisateur B sélectionne la version existante dans l'espace de travail (modèle X, version 20), il devra peut-être répéter l'opération qui a entraîné l'extraction.

Toutefois, si l'utilisateur B sauvegarde ses changements avec la dernière version du modèle (modèle X, version 21), il écrase les changements apportés par l'utilisateur A.

Tâches associées
Organisation des modèles pour le développement coopératif
Partitionnement de modèles UML

Vos commentaires