Partition des solutions de système distribué pour l'implémentation

Mise à jour : novembre 2007

Lorsque des équipes de développement sont prêtes à implémenter des définitions d'application sur le diagramme d'application qui prennent en charge l'implémentation, le responsable du développement peut générer des projets pour ces définitions dans Visual Studio. Ces projets apparaissent dans l'Explorateur de solutions avec d'autres éléments de la même solution. Toutefois, certains scénarios peuvent se prêter au partitionnement de la solution en solutions plus petites. La création de solutions plus petites qui contiennent uniquement un sous-ensemble d'applications constitue un moyen flexible d'organiser des projets pour le développement. Visual Studio permet d'inclure des projets dans n'importe quel nombre de solutions, ce qui vous donne la possibilité de créer des solutions qui contiennent un sous-ensemble de projets. Par ailleurs, il peut être utile de conserver la solution d'origine comme solution « maître », ce qui permet de rapprocher les modifications dans la portée d'origine de la solution, et de créer des systèmes et de définir le déploiement dans cette portée.

Remarque :

Les approches et instructions contenues dans cette rubrique supposent l'utilisation du contrôle de code source. Pour plus d'informations, consultez Documents modèles de définition de système (SDM) sous contrôle de code source. Lors du partitionnement de solutions, il est recommandé d'utiliser des ports statiques sur les applications ASP.NET basées sur un système de fichiers qui utilisent des ports dynamiques par défaut. Des ports dynamiques sur une application ASP.NET peuvent provoquer une modification des numéros de port sur l'un de ses services Web, ce qui entraîne la déconnexion des références Web correspondantes. Pour plus d'informations, consultez Vue d'ensemble des applications ASP.NET dans les diagrammes d'application.

Les sections suivantes contiennent plus d'informations sur le partitionnement de solutions :

• Solutions partitionnées à partir d'une solution maître

• Conservation de la solution d'origine comme solution maître

• Mise à jour de la solution maître avec les modifications apportées aux solutions partitionnées

Solutions partitionnées à partir d'une solution maître

Dans les scénarios où les définitions d'application pour un système d'applications complexe et volumineux sont créées dans une solution unique, il peut être plus facile de gérer la solution en la divisant en solutions plus petites pour implémenter des applications. Chaque solution partitionnée contient alors un sous-ensemble de définitions d'application et leurs projets correspondants, y compris les fichiers de code, les fichiers de configuration et les fichiers .sdm, qui contiennent les informations de modèle de définition de système (SDM) pour les définitions d'application associées.

Vous pouvez employer différentes stratégies pour partitionner une solution. Par exemple, si le système global se compose de systèmes membres clairement délimités, vous pouvez choisir de créer des solutions selon les limites de chaque système dans la solution. Chaque solution contient alors les projets pour les définitions d'application référencées par un système. En fonction de la complexité de chaque système, ces solutions partitionnées peuvent être divisées en solutions encore plus petites. Vous pouvez aussi partitionner des solutions au niveau de développeurs individuels de telle sorte que la solution de chaque développeur contienne uniquement les parties du système dont il est responsable. Vous pouvez également partager des projets à l'aide du contrôle de code source. Toutefois, sachez que certains problèmes peuvent se produire lors du partage de projets. Pour plus d'informations, consultez Extraction et modifications simultanées des documents modèles de définition de système (SDM).

Remarque :

Bien que les limites du système fournissent une base logique pour diviser des définitions d'application et leurs projets d'une solution unique en solutions plus petites, la division d'une solution de cette manière n'est pas obligatoire. Dans les scénarios où les systèmes se chevauchent (c'est-à-dire qu'ils contiennent des utilisations de la même définition d'application), cette approche est moins pratique.

Contenu de solutions partitionnées

Vous pouvez ajouter un diagramme d'application à chaque solution partitionnée, provoquant l'apparition des définitions d'application sur le diagramme selon les fichiers de définition d'application (.sdm) dans les projets de cette solution. Après le processus de partitionnement, tout nouveau projet ajouté à la solution fait l'objet d'une ingénierie à rebours sur le diagramme d'application, si besoin. Chaque solution partitionnée peut aussi contenir des diagrammes système, ce qui permet aux individus de vérifier les systèmes qui contiennent des utilisations de ces définitions. Par exemple, des diagrammes système qui partagent des références à une définition d'application peuvent être inclus dans une solution partitionnée pour fournir le contexte. Vous pouvez utiliser le diagramme d'application ou ajouter des diagrammes système à une solution partitionnée si vous souhaitez évaluer le déploiement ou générer des rapports de déploiement à l'aide de concepteurs de systèmes distribués. Si vous souhaitez utiliser des solutions partitionnées uniquement pour le développement de projet, la présence d'un diagramme de système distribué dans ces solutions n'est pas obligatoire.

Remarque :

Si vous supprimez un fichier .sdm lorsque le diagramme d'application est fermé, le fichier .sdm sera régénéré la prochaine fois que vous ouvrirez le diagramme d'application dans une solution qui contient ce projet. Toutefois, ce fichier .sdm régénéré contient uniquement des informations pouvant être recréées à partir d'une autre source. Toute information ayant été stockée uniquement dans le fichier .sdm supprimé sera perdue. De plus, les références à la définition associée peuvent être rompues. Pour plus d'informations, consultez Dépannage de diagrammes d'application. Si une définition d'application partagée n'est pas présente dans une solution partitionnée, les utilisations de cette définition sur les diagrammes système qui sont inclus dans la solution apparaîtront rompues. Toute tentative de définition ou d'évaluation du déploiement pour les systèmes qui font référence à une définition d'application manquante ne sera pas possible ou échouera. Pour plus d'informations, consultez Synchronisation dans les documents modèles de définition de système (SDM). Un diagramme d'application doit exister dans la solution si des diagrammes système sont ajoutés.

Conservation de la solution d'origine comme solution maître

Après avoir partitionné une solution en solutions plus petites, vous pouvez aussi conserver la solution d'origine comme solution « maître ». Cette approche permet d'afficher et de vérifier occasionnellement la totalité du système. Par ailleurs, l'utilisation du diagramme d'application dans chaque solution partitionnée si une solution principale existe et qu'elle contient son propre diagramme d'application n'est pas obligatoire.

Remarque :

La conservation ou la gestion d'une solution maître n'est pas obligatoire. Par exemple, si les limites de système peuvent être divisées clairement selon les connexions entre services Web, il peut être suffisant de gérer chaque solution partitionnée séparément et de représenter les interactions entre elles comme connexions aux services Web externes. Les services Web Externes sont ajoutés automatiquement au diagramme d'application dans chaque solution partitionnée où le service Web fait référence à des limites entre solutions. Pour plus d'informations, consultez Types et prototypes d'applications pour la définition d'applications. Toutefois, si vous souhaitez concevoir des systèmes de niveau supérieur qui font référence à des systèmes créés dans des solutions partitionnées de niveau inférieur, vous pouvez créer des définitions de système qui incluent uniquement les définitions de système de niveau inférieur requises. Toutefois, pour définir et évaluer le déploiement pour ces systèmes, veillez à ce que la solution contienne toutes les applications référencées.

Par exemple, supposons qu'une équipe de développement se compose de trois développeurs qui travaillent sur trois solutions individuelles, chacune d'entre elles étant une solution partitionnée qui contient les projets associés aux définitions d'application. Ces trois solutions font partie d'une plus grande solution partitionnée qui englobe les limites d'un système d'applications unique. La solution partitionnée fait elle-même partie d'un ensemble composé de nombreuses solutions partitionnées qui décrivent d'autres systèmes d'applications, qui comprennent un système global qui existe dans la portée d'une solution maître.

Lorsque les équipes de développement travaillent sur des solutions partitionnées, ils archivent leurs modifications dans le contrôle de code source. Le responsable du développement peut ensuite mettre à jour la solution maître à partir du contrôle de code source en extrayant les diagrammes et fichiers appropriés. Cette action synchronise les modifications apportées au code et aux fichiers de configuration avec les diagrammes appropriés. Pour plus d'informations, consultez Vue d'ensemble du modèle de définition de système (SDM) et Relations entre documents modèles de définition de système (SDM).

Mise à jour de la solution maître avec les modifications apportées aux solutions partitionnées

Les architectes d'application, les responsables de développement ou les personnes chargées de l'architecture d'un système peuvent mettre à jour et valider périodiquement la solution maître avec les modifications apportées aux solutions partitionnées. Cette personne peut extraire une solution partitionnée contenant ces projets qui ont été divisés parmi les équipes de développement, qui peuvent travailler directement sur ces projets dans la solution partitionnée ou dans les solutions davantage partitionnées.

Cela est utile pour passer en revue le système global si des modifications architecturales ont été apportées, pour valider que la conception du système global se déploiera encore correctement, et pour propager les modifications entre solutions. Il est aussi important de mettre à jour et de vérifier périodiquement la solution maître si la solution contient le seul diagramme d'application entre toutes les solutions et s'il s'agit du seul emplacement dans lequel les systèmes sont gérés.

Lorsque le diagramme d'application est ouvert dans la solution maître suite à l'actualisation de ses projets à partir du contrôle de code source, un architecte d'application ou un responsable du développement peut vérifier l'impact des modifications apportées à ces projets sur le diagramme. Pour consulter les modifications exactes, l'architecte ou le responsable du développement peut passer en revue la liste des modifications qui ont été archivées ou comparer les différences dans les fichiers de code. L'architecte ou le responsable du développement peut ensuite synchroniser le diagramme d'application avec le code de projet ou résoudre tous les avertissements de synchronisation en extrayant les projets nécessaires afin que toute modification devant être apportée puisse se propager aux définitions d'application et à leurs utilisations dans les définitions de système.

Si l'architecte ou le responsable du développement est satisfait des modifications apportées à ces projets, ces modifications peuvent être archivées dans la solution. Sinon, l'architecte ou le responsable du développement doit travailler avec les équipes de développement pour résoudre tous les conflits afin que le code puisse se synchroniser avec le diagramme.

Voir aussi

Tâches

Comment : résoudre des conflits dans les documents modèles de définition de système (SDM)

Référence

Extraction et modifications simultanées des documents modèles de définition de système (SDM)

Autres ressources

Concepteurs de systèmes distribués dans des environnements de travail en équipe