アプリのアーキテクチャをモデル化する

  • [アーティクル]

ソフトウェア システムまたはアプリケーションがユーザーのニーズに確実に対応するように、ソフトウェア システムまたはアプリケーションの全体的な構造および動作の記述の一部として Visual Studio でモデルを作成することができます。 モデルを使用して、設計全体で使用するパターンを記述することもできます。 これらのモデルは、既存のアーキテクチャの理解、変更についての話し合い、開発者の意図の伝達に役立ちます。

この機能をサポートする Visual Studio のバージョンを確認するには、「アーキテクチャとモデリング ツールのエディション サポート」を参照してください。

モデルの目的は、自然言語による記述のあいまいさを減らし、開発者同士が設計を視覚化してさまざまな設計について話し合えるようにすることです。 モデルは、他のドキュメントまたはディスカッションと一緒に使用する必要があります。 モデルだけでは、アーキテクチャの完全な仕様を表すことができません。

注意

このトピックで言う "システム" は、開発するソフトウェアを指します。 システムは、多数のソフトウェアおよびハードウェアのコンポーネントで構成される大規模な集合体であったり、1 つのアプリケーションであったり、1 つのアプリケーションの一部であったりします。

システムのアーキテクチャは、次の 2 つの領域に分類できます。

  • 概要設計。 この設計では、主要なコンポーネントと、それらのコンポーネントが各要件を満たすために相互に対話する方法について記述します。 大きいシステムの場合は、コンポーネントごとに、そのコンポーネントを構成している、より小さなコンポーネントを示す概要設計が存在する場合があります。

  • コンポーネントの設計全体で使用する設計パターンと規則。 パターンで、プログラムの目的を達成するための特定の方法について記述します。 設計全体で同じパターンを使用することで、チームは、変更を加えたり、新しいソフトウェアを開発したりする際のコストを削減できます。

概要設計

概要設計では、システムの主要なコンポーネントと、それらのコンポーネントが設計の目標を達成するために相互に対話する方法について記述します。 概要設計を作成する際に必要な作業を次の一覧に示します。ただし、この順序で行う必要があるわけではありません。

既存のコードを更新する場合は、一般に、主要なコンポーネントを記述することから始めます。 必ず、ユーザー要件の変更について理解したうえで、コンポーネント間の対話を追加または変更するようにしてください。 新しいシステムを開発する場合は、ユーザーのニーズの主な特徴を理解することから始めます。 その後に、主要なユース ケースにおける対話のシーケンスを調査し、コンポーネントの設計にそれらのシーケンスを統合できます。

どのケースの場合も、さまざまな作業を同時に進め、早い段階でコードとテストを開発しておくと効果的です。 1 つの作業を完成させてから別の作業を開始するようなことはやめてください。 通常、要件も、システムを設計する最善の方法についての理解も、コードの作成とテストを実行している間に変化します。 したがって、まずは、要件および設計の主な特徴を理解してコーディングすることから始める必要があります。 細部は、プロジェクトの後の段階で満たすようにします。

  • 要件の理解。 どのような設計も、まずはユーザーのニーズを明確に理解することから始まります。

  • アーキテクチャ パターン。 システムのコア テクノロジとアーキテクチャ要素の選択。

  • コンポーネントとインターフェイスのデータ モデル。 クラス図を描画して、コンポーネント間で受け渡され、コンポーネントの内部に格納される情報を記述できます。

要件の理解

アプリケーション全体の概要設計は、要求モデルなどの、ユーザーのニーズを示す他の記述と組み合わせると、最も効果的に作成できます。 要求モデルの詳細については、「ユーザー要件のモデリング」を参照してください。

開発するシステムが、より大きなシステムに属するコンポーネントである場合、プログラム インターフェイスでは、要件の一部またはすべてを具体化します。

要求モデルは、次のような重要な情報を提供します。

  • 提供インターフェイス。 提供インターフェイスは、システムまたはコンポーネントがユーザー (人間のユーザーまたは他のソフトウェア コンポーネント) に提供する必要があるサービスまたは操作をリストします。

  • 要求インターフェイス。 要求インターフェイスは、システムまたはコンポーネントが使用できるサービスまたは操作をリストします。 場合によっては、これらのすべてのサービスを、独自のシステムの一部として設計することができます。 そうしない場合、特に、さまざまな構成で他のコンポーネントと組み合わせて使用できるコンポーネントを設計する場合、要求インターフェイスは、外部の考慮事項に基づいて設定されます。

  • サービス品質要求 システムが満たさなければならないパフォーマンス、セキュリティ、堅牢性、およびその他の目標と制約。

    要求モデルは、システムのユーザー (人間またはその他のソフトウェア コンポーネント) の観点から作成します。 システムのユーザーは、システムの内部動作には関知しません。 一方、アーキテクチャ モデルの目的は、内部動作を記述し、それらの動作によってユーザーのニーズが満たされる方法を示すためのものです。

    要求モデルとアーキテクチャ モデルを分けておくと、ユーザーと要件について話し合いやすくなるため、効果的です。 また、要件を変更せずに、設計をリファクタリングしてさまざまなアーキテクチャを検討する際にも有効です。

    要求モデルまたはアーキテクチャ モデルに組み込む必要がある詳細情報の量は、プロジェクト規模およびチームのサイズや分散状況によって異なります。 短期プロジェクトの小さなチームであれば、ビジネス概念のクラス図やある程度のデザイン パターンを描く以上のことは必要でない可能性がありますが、複数の地域に分散する大規模なプロジェクトであれば、より詳細な情報が必要になる可能性があります。

アーキテクチャのパターン

開発の早い段階で、設計の基礎にする主要なテクノロジと要素を選択する必要があります。 こうした選択が必要になる領域の例を次に示します。

  • データベースとファイル システムのどちらにするか、ネットワーク アプリケーションと Web クライアントのどちらにするか、といった基本的なテクノロジの選択。

  • Windows Workflow Foundation と ADO.NET Entity Framework のどちらにするか、といったフレームワークの選択。

  • エンタープライズ サービス バスとポイントツーポイント チャネルのどちらにするか、といった統合方法の選択。

    こうした選択は、しばしば、スケールや柔軟性といったサービス品質要求に基づいて行なわれます。また、詳細な要求が明らかになる前に選択できます。 大規模なシステムでは、ハードウェアとソフトウェアの構成は密接に相関してます。

    何を選択するかによって、アーキテクチャ モデルの使用方法および解釈方法が変わります。 たとえば、クラス図の関連付けは、データベースを使用するシステムではデータベース内の関係や外部キーを表す可能性がありますが、XML ファイルをベースとするシステムでは XPath を使用する相互参照を指す可能性があります。 シーケンス図のメッセージは、分散システムでは送信されるメッセージを表す可能性がありますが、独立した 1 つのアプリケーションでは関数呼び出しを表す可能性があります。

設計パターン

デザイン パターンとは、ソフトウェアの特定の側面、特に、システムのさまざまなパーツで繰り返し発生する側面を設計する方法の概要です。 プロジェクト全体で同じアプローチを採用することで、設計コストを削減し、ユーザー インターフェイスの一貫性を保証し、コードを理解および変更するためのコストを削減できます。

よく知られていて、広く適用されている、Observer などの汎用的なデザイン パターンがいくつかあります。 さらに、特定のプロジェクトにのみ適用可能なパターンもあります。 たとえば、Web 販売システムでは、顧客の注文内容に変更を加えるコードにいくつかの操作が含められます。 注文の状態がどの段階においても正確に表示されるように、これらのすべての操作は、データベースを更新するための特定のプロトコルに従う必要があります。

ソフトウェア アーキテクチャの作業の中には、デザイン全体に適用する必要があるパターンを決定する作業があります。 これは、通常、継続的に行われるタスクです。プロジェクトが進行するにつれて、新しいパターンや、既存のパターンに対する改善項目が明らかになるからです。 早い段階で、主要な設計パターンのそれぞれを用いるように開発計画を整理すると有効です。

ほとんどのデザイン パターンは、フレームワーク コード内に部分的に組み込むことができます。 たとえば、データベースが正しく処理されるように保証するデータベース アクセス層などの、特定のクラスまたはコンポーネントを使用するように開発者に要求してパターンのパーツを削減できます。

デザイン パターンについてはドキュメントに記述します。一般に、これらのパーツが含まれます。

  • 名前。

  • 適用可能なコンテキストの説明。 このパターンを適用するときに開発者が考慮しなければならない条件。

  • 解決される問題の簡単な説明。

  • 主要なパーツおよびそれらの関係のモデル これらは、関連付けと依存関係を持つ、クラス、またはコンポーネントとインターフェイスである可能性があります。 これらの要素は、通常、次の 2 つのカテゴリに分類されます。

  • 名前付け規則。

  • パターンが問題を解決する方法の説明。

  • 開発者が採用できるバリエーションの説明。

関連するコンテンツ