ソフトウェア システムまたはアプリケーションがユーザーのニーズを満たしていることを確認するために、ソフトウェア システムまたはアプリケーションの全体的な構造と動作の説明の一部として、Visual Studio でモデルを作成できます。 モデルを使用して、設計全体で使用されるパターンを記述することもできます。 これらのモデルは、既存のアーキテクチャを理解し、変更について話し合い、意図を明確に伝えるのに役立ちます。
この機能をサポートする Visual Studio のエディションを確認するには、 アーキテクチャおよびモデリング ツールのエディションのサポートを参照してください。
モデルの目的は、自然言語の説明で発生するあいまいさを軽減し、自分と同僚が設計を視覚化し、代替設計について話し合うのに役立ちます。 モデルは、他のドキュメントやディスカッションと共に使用する必要があります。 単独では、モデルはアーキテクチャの完全な仕様を表していません。
注
このトピック全体を通して、「システム」とは、開発しているソフトウェアを意味します。 多くのソフトウェアおよびハードウェア コンポーネントの大規模なコレクション、単一のアプリケーション、またはアプリケーションの一部である可能性があります。
システムのアーキテクチャは、次の 2 つの領域に分けることができます。
高度な設計。 ここでは、主要なコンポーネントと、各要件を満たすために相互に対話する方法について説明します。 システムが大きい場合、各コンポーネントには、小さなコンポーネントで構成される方法を示す独自の高度な設計が含まれている可能性があります。
コンポーネントの設計 全体で使用される設計パターンと規則。 パターンは、プログラミング目標を達成するための特定のアプローチを記述します。 設計全体で同じパターンを使用することで、チームは変更を加え、新しいソフトウェアを開発するコストを削減できます。
高度な設計
大まかな設計では、システムの主要なコンポーネントと、システムが相互に対話して設計の目標を達成する方法について説明します。 次の一覧のアクティビティは、高レベルの設計の開発に関連していますが、必ずしも特定の順序ではありません。
既存のコードを更新する場合は、まず主要なコンポーネントについて説明します。 ユーザー要件に対する変更を理解し、コンポーネント間の相互作用を追加または変更してください。 新しいシステムを開発する場合は、まずユーザーのニーズの主な機能を理解します。 その後、主要なユース ケースの相互作用のシーケンスを調べ、そのシーケンスをコンポーネント設計に統合できます。
どの場合も、さまざまなアクティビティを並列で開発し、早期にコードとテストを開発すると便利です。 別の作業を開始する前に、これらの側面の 1 つを完了しようとしないでください。 通常、コードの記述とテスト中に、システムを設計するための最適な方法に関する要件と理解の両方が変わります。 したがって、まず、要件と設計の主な機能を理解し、コーディングする必要があります。 プロジェクトの後のイテレーションで詳細を入力します。
要件の理解。 設計の出発点は、ユーザーのニーズを明確に理解することです。
アーキテクチャ パターン。 システムのコア テクノロジとアーキテクチャ要素に関して行った選択。
コンポーネントとインターフェイスのデータ モデル。 クラス ダイアグラムを描画して、コンポーネント間で渡され、コンポーネント内に格納される情報を記述できます。
要件の理解
完全なアプリケーションの高度な設計は、要件モデルまたはその他のユーザーのニーズの説明と共に最も効果的に開発されます。 要件モデルの詳細については、「 モデルのユーザー要件」を参照してください。
開発しているシステムが大規模なシステムのコンポーネントである場合、要件の一部またはすべてがプログラム インターフェイスに組み込まれている可能性があります。
要件モデルでは、次の重要な情報が提供されます。
提供されたインターフェイス。 提供されるインターフェイスには、システムまたはコンポーネントがユーザーに提供する必要があるサービスまたは操作が、人間のユーザーであるか、他のソフトウェア コンポーネントであるかに関係なく一覧表示されます。
必要なインターフェイス。 必要なインターフェイスには、システムまたはコンポーネントが使用できるサービスまたは操作が一覧表示されます。 場合によっては、これらのすべてのサービスを独自のシステムの一部として設計できます。 その他の場合、特に多くの構成で他のコンポーネントと組み合わせることができるコンポーネントを設計する場合は、必要なインターフェイスが外部の考慮事項によって設定されます。
サービスの品質要件。 システムが満たす必要があるパフォーマンス、セキュリティ、堅牢性、およびその他の目標と制約。
要件モデルは、ユーザーまたは他のソフトウェア コンポーネントのどちらであるかに関係なく、システムのユーザーの観点から記述されます。 彼らはあなたのシステムの内部動作を何も知らない。 これに対し、アーキテクチャ モデルの目標は、内部の作業を記述し、ユーザーのニーズを満たす方法を示することです。
要件とアーキテクチャ モデルを分離しておくと、ユーザーと要件を簡単に話し合えるので便利です。 また、要件を変更せずに、設計をリファクタリングし、代替アーキテクチャを検討するのにも役立ちます。
要件またはアーキテクチャ モデルに配置する必要がある詳細の量は、プロジェクトの規模とチームのサイズと分布によって異なります。 短いプロジェクトの小規模なチームは、ビジネス概念といくつかの設計パターンのクラス図をスケッチする以外に進まないかもしれません。複数のリージョンに分散された大規模なプロジェクトでは、より詳細な情報が必要になります。
アーキテクチャ パターン
開発の初期段階では、設計が依存する主要なテクノロジと要素を選択する必要があります。 これらの選択を行う必要がある領域は次のとおりです。
データベースとファイル システムの選択、ネットワークアプリケーションと Web クライアントの選択など、基本テクノロジの選択肢。
フレームワークの選択肢 (Windows Workflow Foundation または ADO.NET Entity Framework の選択など)。
統合方法の選択肢 (エンタープライズ サービス バスまたはポイントツーポイント チャネル間など)。
これらの選択は、スケールや柔軟性などのサービスの品質要件によって頻繁に決定され、詳細な要件が判明する前に行うことができます。 大規模なシステムでは、ハードウェアとソフトウェアの構成が強く相互に関係しています。
選択内容は、アーキテクチャ モデルの使用方法と解釈方法に影響します。 たとえば、データベースを使用するシステムでは、クラス ダイアグラム内の関連付けはデータベース内のリレーションシップまたは外部キーを表しますが、XML ファイルに基づくシステムでは、関連付けは XPath を使用する相互参照を示している可能性があります。 分散システムでは、シーケンス図内のメッセージはネットワーク上のメッセージを表すことができます。自己完結型アプリケーションでは、関数呼び出しを表すことができます。
デザイン パターン
設計パターンは、ソフトウェアの特定の側面、特にシステムのさまざまな部分で繰り返される側面を設計する方法の概要です。 プロジェクト全体で統一されたアプローチを採用することで、設計コストを削減し、ユーザー インターフェイスの一貫性を確保し、コードの理解と変更のコストを削減できます。
オブザーバーなどの一般的な設計パターンは、よく知られており、広く適用できます。 さらに、プロジェクトだけに適用できるパターンもあります。 たとえば、Web 販売システムでは、顧客の注文に変更が加えられるコードに複数の操作があります。 すべての段階で注文の状態が正確に表示されるようにするには、これらすべての操作が特定のプロトコルに従ってデータベースを更新する必要があります。
ソフトウェア アーキテクチャの作業の一部は、設計全体で採用する必要があるパターンを決定することです。 プロジェクトが進行すると、既存のパターンに対する新しいパターンと改善が検出されるため、これは通常、進行中のタスクです。 開発計画を整理して、主要な各設計パターンを早期に実行すると便利です。
ほとんどの設計パターンは、フレームワーク コードで部分的に具体化できます。 パターンの一部を減らすと、データベースが正しく処理されるようにするデータベース アクセス層など、特定のクラスまたはコンポーネントを開発者が使用する必要があります。
デザイン パターンはドキュメントで説明され、通常は次の部分が含まれます。
名前。
該当するコンテキストの説明。 開発者がこのパターンの適用を検討する必要がある条件は何ですか?
解決する問題の簡単な説明。
主要部分とその関係のモデル。 これらは、クラスまたはコンポーネントとインターフェイスであり、それらの間の関連付けと依存関係があります。 通常、要素は次の 2 つのカテゴリに分類されます。
名前付け規則。
パターンが問題を解決する方法の説明。
開発者が採用できる可能性があるバリエーションの説明。