実装を目的とした分散システム ソリューションの分割
更新 : 2007 年 11 月
開発チームが実装をサポートするアプリケーション ダイアグラムにアプリケーション定義を実装する準備を整えると、開発リードは Visual Studio でアプリケーション定義のプロジェクトを生成できます。こうしたプロジェクトは、同じソリューション内の他のアイテムと共に、ソリューション エクスプローラに表示されます。しかし、ソリューションをより小規模なソリューションに分割するシナリオも考えられます。アプリケーションのサブセットだけを含む小規模なソリューションを作成すると、開発プロジェクトを柔軟に編成できます。Visual Studio では、任意の数のソリューションをプロジェクトに含められるため、プロジェクトのサブセットを含むソリューションを作成できます。また、元のソリューションを "マスター" ソリューションとして保持すると、ソリューションの元のスコープに及ぶ変更を整合させ、システムを作成して、スコープ内の配置を定義できるため便利です。
.gif "メモ") メモ : |
|---|
このトピックで説明するアプローチとガイダンスは、ソース コード管理の使用を前提としています。詳細については、「ソース管理におけるシステム定義モデル (SDM) ドキュメント」を参照してください。ソリューションを分割する場合、ファイル システム ベースの ASP.NET アプリケーション (既定では動的ポートが使用されます) で静的ポートを使用することをお勧めします。ASP.NET アプリケーションで動的ポートを使用した場合、Web サービスのポート番号が変わる可能性があり、対応する Web 参照に接続できなくなります。詳細については、「アプリケーション ダイアグラムでの ASP.NET アプリケーションの概要」を参照してください。 |
以下のセクションでは、ソリューションを分割する詳細を説明します。
マスター ソリューションから分割したソリューション
元のソリューションをマスター ソリューションとして保持する
分割されたソリューションの変更でマスター ソリューションを更新する
マスター ソリューションから分割したソリューション
大規模で複雑なアプリケーション システムのアプリケーション定義を単一のソリューションに作成するシナリオでは、ソリューションを小規模なソリューションに分割して、アプリケーションの実装を容易にします。分割した各ソリューションには、アプリケーション定義とそれに対応するプロジェクトのサブセットが含まれます。プロジェクトには、コード ファイル、設定ファイル、および関連付けられたアプリケーション定義のシステム定義モデル (SDM) 情報を格納した .sdm ファイルが含まれます。
ソリューションの分割にはさまざまな戦略を採用できます。たとえば、システム全体が明確に区別されたメンバ システムから成る場合、ソリューション内の各システムの境界に基づいてソリューションを作成するように選択できます。各ソリューションには、システムが参照するアプリケーション定義のプロジェクトが含まれます。各システムの複雑さに応じて、分割されたソリューションをさらに小規模なソリューションに分割できます。また、各開発者のレベルに応じてソリューションを分割し、それぞれの開発者が責任を持つシステムの一部だけをソリューションに含めることもできます。ソース コード管理を使用してプロジェクトを共有することもできます。ただし、プロジェクトを共有する場合は、いくつかの問題に注意してください。詳細については、「システム定義モデル (SDM) ドキュメントの同時チェックアウトと変更」を参照してください。
| メモ : |
|---|
システムの境界は、アプリケーション定義とそのプロジェクトを単一のソリューションからより小規模なソリューションに分割する論理的な基礎となりますが、ソリューションをこのように分割する際の要件はありません。複数のシステムが同じアプリケーション定義の使用を含んでおり、オーバーラップしている場合、この手法はあまり役に立ちません。 |
分割されたソリューションの内容
分割した各ソリューションにアプリケーション ダイアグラムを追加すると、アプリケーション定義は、そのソリューションのプロジェクト内のアプリケーション定義ファイル (.sdm) に基づくダイアグラムに表示されます。ソリューションの分割プロセスが完了すると、ソリューションに追加された新しいプロジェクトは、必要に応じて、アプリケーション ダイアグラム上でリバース エンジニアリングされます。分割された個々のソリューションには、任意のシステム ダイアグラムも含まれるため、各開発者はそれらの定義の使用を含むシステムをレビューできます。たとえば、アプリケーション定義への参照を共有するシステム ダイアグラムは、コンテキストを提供するために分割されたソリューションに含めることができます。分散システム デザイナを使用して、配置を評価するか、配置レポートを生成する場合は、アプリケーション ダイアグラムを使用または、分割されたソリューションにシステム ダイアグラムを追加できます。分割されたソリューションをプロジェクト開発だけに使用する場合、分散システム ダイアグラムをそれらのソリューションに含める必要はありません。
| メモ : |
|---|
アプリケーション ダイアグラムを閉じて .sdm ファイルを削除した場合、そのプロジェクトを含むソリューション内でアプリケーション ダイアグラムを次に開くと、.sdm ファイルが再生成されます。ただし、再生成された .sdm ファイルには、別のソースから再作成できる情報だけが格納されます。そのため、削除した .sdm ファイルだけに格納されていた情報は失われます。また、関連付けられた定義への参照は壊れることがあります。詳細については、「アプリケーション ダイアグラムのトラブルシューティング」を参照してください。共有するアプリケーション定義が分割されたソリューションにない場合、そのアプリケーション定義は、ソリューションに含まれるシステム ダイアグラム上で破損した状態として表示されます。失われたアプリケーション定義を参照するシステムの配置を定義または評価しようとしても、実行できないか、実行できても成功しません。詳細については、「システム定義モデル (SDM) ドキュメントの同期」を参照してください。システム ダイアグラムを追加する場合、アプリケーション ダイアグラムはソリューション内に存在する必要があります。 |
元のソリューションをマスター ソリューションとして保持する
ソリューションを小規模なソリューションに分割した後、元のソリューションを "マスター" ソリューションとして保持できます。この手法を採用すると、ときどきシステム全体を表示してレビューできます。また、マスター ソリューションが存在し、それに独自のアプリケーション ダイアグラムが含まれている場合、分割した各ソリューションでアプリケーション ダイアグラムを使用する必要はありません。
| メモ : |
|---|
マスター ソリューションを保持または保守するための要件はありません。たとえば、システム境界が Web サービス間の接続に基づいて明確に分割されている場合、分割したソリューションを個別に管理し、それらの対話を外部 Web サービスへの接続として表せば十分です。Web サービスへの参照がソリューションの境界を超えている場合、外部 Web サービスは分割された各ソリューションのアプリケーション ダイアグラムに自動的に追加されます。詳細については、「アプリケーションを定義するためのアプリケーションの種類とプロトタイプ」を参照してください。ただし、分割された下位のソリューションで作成されたシステムを参照する、より上位のシステムをデザインする場合、下位レベルの必要なシステム定義だけを含むシステム定義を作成できます。しかし、そうしたシステムの配置を定義して評価するには、ソリューションに参照先のアプリケーションすべてが含まれていることを確認してください。 |
たとえば、3 人の開発者から成る開発チームが、個別のソリューション 3 つを開発しており、分割されたソリューションがアプリケーション定義に関連付けられたプロジェクトを含んでいるとします。3 つのソリューションは、単一のアプリケーション システムの境界を跨ぐ、より大きな分割済みソリューションの一部です。一方、分割されたソリューションは、他のアプリケーション システムを記述する多数の分割済みソリューションの 1 つであり、マスター ソリューションのスコープ内に存在するシステム全体を構成します。
開発チームは分割されたソリューションで作業を進めながら、各変更をソース コード管理にチェックインします。開発リードは、次に、適切なダイアグラムとファイルをソース コード管理からチェックアウトして、マスター ソリューションを更新します。この操作は、コードと構成ファイルへの変更を適切なダイアグラムと同期して行います。詳細については、「システム定義モデル (SDM) の概要」および「システム定義モデル (SDM) ドキュメントの相互関係」を参照してください。
分割されたソリューションの変更でマスター ソリューションを更新する
アプリケーション アーキテクト、開発リード、またはシステム アーキテクチャの担当者は、分割されたソリューションに対する変更でマスター ソリューションを定期的に更新して検証できます。担当者は、開発チーム内で分割されたプロジェクトを含む分割済みソリューションをチェックアウトし、分割されたソリューション内、またはさらに細かく分割されたソリューション内でプロジェクトを直接処理できます。
このようにすると、アーキテクチャが変更された場合はシステム全体をレビューする際に、システム全体のデザインが引き続き適切に配置されていることを検証する際に、ソリューション間に変更を反映する際に役立ちます。ソリューション全体にわたるアプリケーション ダイアグラムだけがソリューションに含まれており、それがシステムを保守する唯一の場所である場合、マスター ソリューションを定期的に更新してレビューすることも大切な作業です。
マスター ソリューションのプロジェクトをソース コード管理で更新した後、アプリケーション ダイアグラムをマスター ソリューション内で開くと、アプリケーション アーキテクトまたは開発リードは、プロジェクトに加えた変更がダイアグラムに与える影響をレビューできます。アプリケーション アーキテクトまたは開発リードは、チェックインされた変更の一覧を調べるか、コード ファイルの差分を比較して、正確な変更を確認できます。アプリケーション アーキテクトまたは開発リードは、アプリケーション ダイアグラムとプロジェクト コードを同期するか、必要なプロジェクトをチェックアウトして同期警告を解決して、必要な変更をアプリケーション定義とシステム定義の使用に反映できます。
アプリケーション アーキテクトまたは開発リードは、プロジェクトに加えた変更に納得したら、変更をソリューションにチェックインします。変更した結果に満足できない場合は、アーキテクトまたは開発リードは開発チームと協力して、すべての競合を解決して、コードをダイアグラムと同期させます。
参照
処理手順
方法 : システム定義モデル (SDM) ドキュメントの競合を解決する
参照
システム定義モデル (SDM) ドキュメントの同時チェックアウトと変更