Visual Studio で 依存関係図 を作成して、アプリのアーキテクチャを大まかに説明します。 依存関係図を使用してコードを検証することで、コードがこの設計と一致していることを確認します。 ビルド プロセスにレイヤーの検証を含めることもできます。
この機能をサポートする Visual Studio のエディションを確認するには、 アーキテクチャおよびモデリング ツールのエディションのサポートを参照してください。
注
.NET Core プロジェクトの依存関係図は、Visual Studio 2019 バージョン 16.2 以降でサポートされています。
依存関係図とは
従来のアーキテクチャ図と同様に、依存関係図は、設計の主要なコンポーネントまたは機能単位とその相互依存関係を識別します。 レイヤーと呼ばれる図の各ノード は、名前空間、プロジェクト、またはその他の成果物の論理グループを表します。 デザインに存在する必要がある依存関係を描画できます。 従来のアーキテクチャ図とは異なり、ソース コード内の実際の依存関係が、指定した目的の依存関係に準拠していることを確認できます。 Team Foundation Server 上の通常のビルドの検証部分を作成することで、プログラム コードが将来の変更によってシステムのアーキテクチャに準拠し続けられるようにすることができます。 「依存関係図: リファレンス」を参照してください。
依存関係図を使用してアプリを設計または更新する方法
次の手順では、開発プロセス内で依存関係図を使用する方法の概要を示します。 このトピックの後のセクションでは、各手順の詳細について説明します。 新しいデザインを開発する場合は、既存のコードを参照する手順を省略します。
注
これらの手順はおおよその順序で表示されます。 タスクを重ねて、自分の状況に合わせて並べ替え、プロジェクトの各イテレーションの開始時に再検討することが必要になる場合があります。
アプリケーション全体またはアプリケーション内のレイヤーの依存関係図を作成します。
アプリケーションの主要な機能領域またはコンポーネントを表すレイヤーを定義します。 これらのレイヤーには、その機能に従って名前を付けます (例: "Presentation"、"Services")。 Visual Studio ソリューションがある場合は、各レイヤーをプロジェクト、名前空間、ファイルなどの 成果物のコレクションに関連付けることができます。
レイヤー間の既存の依存関係を検出します。
レイヤーと依存関係を編集 して、コードに反映させる更新されたデザインを表示します。
主要なアーキテクチャ ブロックまたはコンポーネントを表すレイヤーを作成し、各レイヤーで他のレイヤーがどのように使用されるかを示す依存関係を定義することで、アプリケーションの新しい領域を設計します。
図のレイアウトと外観を編集 して、同僚と話し合うのに役立ちます。
依存関係図に対してコードを検証 し、必要なコードとアーキテクチャの間の競合を強調します。
新しいアーキテクチャに準拠するようにコードを更新します。 検証で競合が表示されないまで、コードを繰り返し開発してリファクタリングします。
コードが設計に準拠し続けられるように、ビルド プロセスにレイヤー検証を含めます。
依存関係図を作成する
依存関係図は、モデリング プロジェクト内に作成する必要があります。 既存のモデリング プロジェクトに新しい依存関係図を追加したり、依存関係図の新しいモデリング プロジェクトを作成したり、同じモデリング プロジェクト内の既存の依存関係図をコピーしたりすることができます。
Important
既存の依存関係図をモデリング プロジェクトから別のモデリング プロジェクトまたはソリューション内の別の場所に追加、ドラッグ、またはコピーしないでください。 この方法でコピーされた依存関係図は、図を変更した場合でも、元の図と同じ参照を持つことになります。 これにより、レイヤーの検証が正しく機能しなくなり、図を開こうとしたときに要素の不足やその他のエラーなどの他の問題が発生する可能性があります。
機能領域またはコンポーネントを表すレイヤーを定義する
レイヤーは、プロジェクト、コード ファイル、名前空間、クラス、メソッドなどの 成果物の論理グループを表します。 Visual C# プロジェクトや Visual Basic プロジェクトの成果物からレイヤーを作成したり、Word ファイルやPowerPointプレゼンテーションなどのドキュメントをリンクして、仕様やプランをレイヤーにアタッチしたりできます。 各レイヤーは図に四角形として表示され、それにリンクされている成果物の数が表示されます。 レイヤーには、より具体的なタスクを記述する入れ子になったレイヤーを含めることができます。
一般的なガイドラインとして、"Presentation" や "Services" などの機能に従ってレイヤーに名前を付けます。 アーティファクトが密接に相互に依存している場合は、それらを同じレイヤーに配置します。 成果物を個別に更新したり、別のアプリケーションで使用したりできる場合は、それらを異なるレイヤーに配置します。
ヒント
レイヤーにリンクできる特定の種類の成果物がありますが、依存関係図に対する検証はサポートされていません。 成果物が検証をサポートしているかどうかを確認するには、 レイヤー エクスプローラー を開き、成果物リンクの [検証のサポート ] プロパティを調べます。 レイヤー間の既存の依存関係を検出するを参照してください。
なじみのないアプリケーションを更新するときに、コード マップを作成することもできます。 これらの図は、コードの探索中にパターンと依存関係を検出するのに役立ちます。 ソリューション エクスプローラーを使用して名前空間とクラスを調べます。これは、多くの場合、既存のレイヤーに適切に対応します。 ソリューション エクスプローラーから依存関係図にドラッグして、これらのコード成果物をレイヤーに割り当てます。 その後、依存関係図を使用して、コードを更新し、設計と一貫性を保つことができます。
参照:
レイヤー間の既存の依存関係を検出する
依存関係は、あるレイヤーに関連付けられている成果物が、別のレイヤーに関連付けられている成果物への参照を持つ場所に存在します。 たとえば、あるレイヤーのクラスは、別のレイヤーにクラスを持つ変数を宣言します。 既存の依存関係は、リバース エンジニアリングによって検出できます。
注
特定の種類の成果物に対して依存関係をリバース エンジニアリングすることはできません。 たとえば、テキスト ファイルにリンクされているレイヤーとの間でリバース エンジニアリングされる依存関係はありません。 リバース エンジニアリングできる依存関係を持つ成果物を確認するには、1 つまたは複数のレイヤーを右クリックし、[ リンクの表示] をクリックします。 レイヤー エクスプローラーで、サポート検証の列を調べます。 依存関係は、この列に False が表示される成果物に対してリバース エンジニアリングされません。
レイヤー間の既存の依存関係をリバース エンジニアリングするには
1 つのレイヤーまたは複数のレイヤーを選択し、選択したレイヤーを右クリックし、[ 依存関係の生成] をクリックします。
通常、存在してはならない依存関係がいくつか表示されます。 これらの依存関係を編集して、目的の設計に合わせて調整できます。
レイヤーと依存関係を編集して目的のデザインを表示する
システムまたは目的のアーキテクチャに加える予定の変更を説明するには、次の手順を使用して依存関係図を編集します。 また、コードを拡張する前に、リファクタリングの変更を行ってコードの構造を改善することも検討してください。 コードの構造の改善を参照してください。
| から へ | 次の手順を実行します。 |
|---|---|
| 存在しない依存関係を削除する | 依存関係をクリックし、DELETE キーを押 します。 |
| 依存関係の方向を変更または制限する | Direction プロパティを設定します。 |
| 新しい依存関係を作成する | 依存関係と双方向の依存関係ツールを使用します。 複数の依存関係を描画するには、ツールをダブルクリックします。 完了したら、 ポインター ツールをクリックするか、 Esc キーを押します。 |
| レイヤーに関連付けられている成果物が、指定した名前空間に依存できないように指定する | レイヤーの [禁止された名前空間の依存関係 ] プロパティに名前空間を入力します。 名前空間を区切るには、セミコロン (;) を使用します。 |
| レイヤーに関連付けられている成果物が指定された名前空間に属してはならないことを指定する | レイヤーの Forbidden Namespaces プロパティに名前空間を 入力します。 名前空間を区切るには、セミコロン (;) を使用します。 |
| レイヤーに関連付けられている成果物が、指定した名前空間のいずれかに属している必要があることを指定する | レイヤーの [必須名前空間] プロパティに 名前空間を 入力します。 名前空間を区切るには、セミコロン (;) を使用します。 |
コードの構造の改善
リファクタリングの変更は、アプリケーションの動作に影響を与えない改善点ですが、将来コードの変更と拡張を容易にするのに役立ちます。 適切に構造化されたコードには、依存関係図に簡単に抽象化できる設計があります。
たとえば、コード内の名前空間ごとにレイヤーを作成し、依存関係をリバース エンジニアリングする場合は、レイヤー間に一方向の依存関係の最小セットが存在する必要があります。 クラスまたはメソッドをレイヤーとして使用して、より詳細な図を作成する場合、結果も同じ特性を持つ必要があります。
そうでない場合、コードは一生変更するのが難しくなり、依存関係図を使用した検証には適しません。
アプリケーションの新しい領域を設計する
新しいプロジェクトまたは新しいプロジェクトの新しい領域の開発を開始するときに、コードの開発を開始する前に、主要なコンポーネントを識別するのに役立つレイヤーと依存関係を描画できます。
可能であれば、依存関係図に特定可能なアーキテクチャ パターンを表示します。 たとえば、デスクトップ アプリケーションを記述する依存関係図には、プレゼンテーション、ドメイン ロジック、データ ストアなどのレイヤーが含まれる場合があります。 アプリケーション内の 1 つの機能をカバーする依存関係図には、モデル、ビュー、コントローラーなどのレイヤーが含まれている場合があります。
名前空間、クラス、コンポーネントなど、レイヤーごとにコード成果物を作成します。 これにより、コードに従い、コード成果物をレイヤーにリンクしやすくなります。 各成果物を作成したらすぐに、適切なレイヤーにリンクします。
ほとんどのクラスとその他の成果物をレイヤーにリンクする必要はありません 。これは、既にレイヤーにリンクしている名前空間などの大きな成果物内にあるためです。
新しいフィーチャの新しいダイアグラムを作成します。 通常、アプリケーション全体を説明する 1 つ以上の依存関係図があります。 アプリケーション内で新しい機能を設計する場合は、既存のダイアグラムに追加したり変更したりしないでください。 代わりに、コードの新しい部分を反映する独自の図を作成します。 新しいダイアグラムのレイヤーには、新しいフィーチャのプレゼンテーション、ドメイン ロジック、データベース レイヤーが含まれる場合があります。
アプリケーションをビルドすると、コードがダイアグラム全体とより詳細な機能図の両方に対して検証されます。
プレゼンテーションとディスカッションのレイアウトを編集する
レイヤーと依存関係を特定したり、チーム メンバーと話し合ったりするには、次の方法で図の外観とレイアウトを編集します。
レイヤーのサイズ、図形、位置を変更します。
レイヤーと依存関係の色を変更します。
- 1 つ以上のレイヤーまたは依存関係を選択し、右クリックして [ プロパティ] をクリックします。 [ プロパティ ] ウィンドウで、 Color プロパティを編集します。
図に対してコードを検証する
図を編集したら、いつでも手動でコードに対して検証したり、ビルドするたびに自動的に検証したりすることができます。
参照:
新しいアーキテクチャに準拠するようにコードを更新する
通常、更新された依存関係図に対してコードを初めて検証するときにエラーが表示されます。 これらのエラーには、いくつかの原因が考えられます。
アーティファクトが間違ったレイヤーに割り当てられます。 この場合は、成果物を移動します。
クラスなどの成果物は、アーキテクチャと競合する方法で別のクラスを使用します。 この場合は、コードをリファクタリングして依存関係を削除します。
これらのエラーを解決するには、検証中にエラーが表示されないまでコードを更新します。 これは通常、反復的なプロセスです。 これらのエラーの詳細については、「 依存関係図を使用してコードを検証する」を参照してください。
注
コードを開発またはリファクタリングするときに、依存関係図にリンクする新しい成果物が存在する可能性があります。 ただし、既存の名前空間を表すレイヤーがあり、新しいコードによってそれらの名前空間に追加されるマテリアルが増えるだけの場合など、これは必要ない場合があります。
開発プロセス中に、検証中に報告された競合の一部を抑制したい場合があります。 たとえば、既に対処しているエラーや、特定のシナリオに関連しないエラーを抑制できます。 エラーを抑制する場合は、Team Foundation で作業項目をログに記録することをお勧めします。 このタスクを実行するには、「 依存関係図を使用してコードを検証する」を参照してください。
ビルド プロセスにレイヤー検証を含める
コードの将来の変更が依存関係図に準拠していることを確認するには、ソリューションの標準ビルド プロセスにレイヤー検証を含めます。 他のチーム メンバーがソリューションをビルドするたびに、コード内の依存関係と依存関係図の違いはビルド エラーとして報告されます。 ビルド プロセスにレイヤーの検証を含める方法の詳細については、「 依存関係図を使用したコードの検証」を参照してください。