Share via

ソリューション アーキテクチャの作成

  • [アーティクル]

優れたアーキテクチャを作成するためには、複数のアーキテクチャ戦略について調査する必要があります。 各戦略には、プラットフォームの選択、使用されているテクノロジ、コードの再利用などに基づいて、それぞれに異なるメリットがあります。 それぞれのコストとメリットを詳しく調査するために、各戦略の設計を行い、概念実証を作成します。 その後、各戦略を製品要件と品質要求に照らし合わせて評価し、最終的に、製品の実装に使用する戦略を選択します。 製品全体にわたって作業が必要になるアーキテクチャ上の問題として、セキュリティとパフォーマンスを考慮する必要もあります。

このトピックの内容

  • 複数のアーキテクチャ分割設計の作成

  • システム アーキテクチャと配置の設計

  • 概念実証の作成

  • 選択肢の評価

  • アーキテクチャの選択

  • パフォーマンス モデルの開発

複数のアーキテクチャ分割設計の作成

問題を分析して、さまざまなアプローチを検討します。 ビジネス上および技術上の主要な課題を表す一連の要件を選択し、 それらの課題 (レガシ システムの統合など) の特徴を調べて、現在のニーズに基づく将来のニーズ、コードの再利用性、および保守コストを予測します。

アプリケーション ダイアグラムの作成

ドメイン モデルと要件を入力として使用して、システムのコア論理要素を表現するアプリケーション ダイアグラムを作成します。 アプリケーション ダイアグラムは、後にシステム ダイアグラムに分割されます。 その際には、複数の分割方法を検討および評価します。

アプリケーション ダイアグラムは、UML (Unified Modeling Language) ユース ケース図として表現できます。 ユース ケース図を使用すると、主要なサブシステムとその依存関係を示すことができます。 また、各サブシステムにユース ケースを配置して、どのサブシステムがどのユーザー シナリオを管理するのかを示すこともできます。

評価基準の確立

アーキテクチャ上重要な課題を表す要件やシナリオを特定するための基準を決定します。 そのためには、既存のエンタープライズ アーキテクチャのドキュメントを調べて、 アプリケーションに適用する必要があるビジネス上の要件、技術上の要件、および企業の標準を確認します。 アーキテクチャ上重要であることが確認されている追加の基準 (レガシ システムとの統合、コードの再利用性、既存のベンダー ライブラリやベンダー プラットフォームの再利用、保守コストの管理など) や、 技術解を実装するときのリスクとコストを表す追加の基準も取り込みます。

要件の候補グループの選択

各サービス品質要求および製品要件を評価基準に照らし合わせて評価します。 アーキテクチャ上の課題を表す要件があった場合は、モデリングの候補と見なします。 たとえば、新しい製品で古い顧客データベースをサポートする必要があるという要件は、レガシ システムとの統合という基準を満たしているため、 統合の動作のモデリングの候補になります。

シナリオの候補グループの選択

各シナリオを評価基準に照らし合わせて評価します。 アーキテクチャ上の課題を表すシナリオがあった場合は、モデリングの候補と見なします。 たとえば、ユーザーがクライアントの更新プログラムをダウンロードするシナリオは、保守コストに関係する基準を満たしているため、 クライアント更新の処理方法のモデリングの候補になります。

候補グループの絞り込み

シナリオと要件の候補を見直して、 評価基準が重複しているものや、他により適切なものがあるものを取り除き、 新しいアプリケーションの主要なアーキテクチャ上の課題、リスク、およびコストを表すコア グループへと候補グループを絞り込みます。 評価基準を最もよく表すもの、最も大きなリスクを表すもの、技術解の設計時に発生する可能性が最も高いコストを表すものを残します。 アプリケーションの最も包括的な部分や最も重要な部分に対応するものも残します。

分割基準の作成

要件を動機として使用して、確立されたアーキテクチャ パターン (ファサード、モデル ビュー コントローラーなど) を分析し、実装の候補を特定します。 候補となるパターンをそれぞれの動機から特定し、結合性、連携性、拡張性、適応性、および柔軟性に関する設計上のトレードオフについて検討します。 評価する選択肢として実装の一連の候補を選択します。

システム アーキテクチャと配置の設計

システム アーキテクチャでは、アプリケーション ダイアグラムで特定されている要素のグループ化と構成を定義します。 システム ダイアグラムを作成して、候補となる各アーキテクチャ アプローチのシステム アーキテクチャを取り込み、 配置ダイアグラムで、依存関係とコア機能に基づく配置手順を示します。 インフラストラクチャ アーキテクトは、アプリケーションが配置されるデータセンターの論理構造を記述する論理データセンター ダイアグラムを作成します。 その論理データセンター ダイアグラムと照らし合わせて配置ダイアグラムを検証して、システムが配置可能であることを確認します。

システム モデルの作成

アーキテクトとリード開発者が、アプリケーション ダイアグラムからシステム ダイアグラムを作成します。 システム ダイアグラムを使用すると、再利用できるアプリケーション システムを、アプリケーション ダイアグラムの要素から構成される配置単位としてデザインできます。 また、他のシステムを含むより大規模で複雑なシステムをデザインして、分散システムのシナリオで使用したり、それらのシステムのアプリケーションの詳細を抽象化したりすることもできます。 新しいダイアグラム ファイルをそれぞれバージョン コントロールにチェックインします。

Visual Studio でシステム ダイアグラムを表現するには次の方法があります。

  • ユース ケース図。 主要なユーザー シナリオをユース ケースとして表し、システムの主要なコンポーネントをサブシステムとして表して、 各ユース ケースを対応するサブシステム内に配置できます。 詳細については、「UML ユース ケース図: ガイドライン」を参照してください。

  • UML コンポーネント図。 コンポーネント図を使用すると、依存関係に加えて、コンポーネント間の通信チャネルも示すことができます。 クラス図を作成して、コンポーネントがインターフェイスで参照できる型を記述したり、シーケンス図を作成してそれらのやり取りを示したりすることもできます。 詳細については、「UML コンポーネント図: ガイドライン」、「UML クラス図: ガイドライン」、および「UML シーケンス図: ガイドライン」を参照してください。

  • レイヤー図。 レイヤー図は、アプリケーションのブロック構造を記述したもので、 コンポーネントと、コンポーネント間の依存関係のみを示します。 コードを記述した後に、コードと依存関係を図と照らし合わせて検証できるという利点があります。 詳細については、「レイヤー図: ガイドライン」を参照してください。

各サブシステムに対して、その種類と動作を詳細に記述するパッケージを作成できます。 詳細については、「パッケージと名前空間の定義」を参照してください。

概念実証の作成

アーキテクチャの概念実証を作成することにより、プロジェクトの重大なリスクを軽減できます。 プロジェクトのできるだけ早い段階でリスクに対処することが重要です。そうすれば、アーキテクチャの基本部分をまだ簡単に変更できる段階で戦略上およびアーキテクチャ上重要な決定を行うことができます。 早い段階で概念実証を作成すると、プロジェクト全体のリスクが軽減し、未知の要素が減るため、 後のイテレーションの計画や見積もりをより正確に行えるようになります。 概念実証は、問題への対処がなされたら破棄する一時的なものとして作成することも、コア アーキテクチャの土台として作成することもできます。

リスクの調査

リスクの特定またはアーキテクチャ上の決定につながる要素を把握します。 関連するシナリオおよびサービス品質要求を調べて、 対象となる環境が示唆されていないかどうかを確認します。

アプローチの計画

必要な概念実証の形式を特定します。 この計画には、アプリケーション ダイアグラムとシステム ダイアグラムを使用します。 リスクによって特定されたアーキテクチャ上の問題のみを解決します。 また、最も単純な解決方法を探します。

概念実証の作成および実行

概念実証を作成します。 概念実証は、アプリケーション ダイアグラムから実装できます。 解決すべき問題に焦点を絞ります。 作成した概念実証は、論理データセンター ダイアグラムに適合する物理環境に配置します。 論理データセンター ダイアグラムの設定にできるだけ近い物理環境を使用する必要があります。 リスクの高い問題について概念実証をテストします。

選択肢の評価

LAAAM (Lightweight Architecture Alternative Analysis Method) を使用して、さまざまなアーキテクチャ戦略のうちのどれを使用してアプリケーションを作成するかを決定します。 LAAAM は、通常、完了までに 1 日かかります。 最初に、要件に基づくアプリケーションの主要な品質および機能のドライバーを記述するユーティリティ ツリーを作成します。 ドライバーは、コンテキスト、刺激、応答として記述されたステートメントの形式のシナリオとして記述します。 その後、アセスメント表を使用して、各シナリオに対するそれぞれの戦略の適合性を評価します。

ユーティリティ ツリーの作成

サービス品質要求と製品要件を調べてアプリケーションの品質および機能の主要なドライバーを特定し、 アプリケーションの全体的な品質を表すユーティリティ ツリーを作成します。 ツリーのルート ノードのラベルは "ユーティリティ" です。 ルート以下のノードのラベルには、品質の標準的な用語が使用されるのが一般的です (変更可能性、可用性、セキュリティなど)。 このツリーは優先順位付けの基盤となるため、品質の階層的な性質が表現されている必要があります。 ツリーのレベルが増えるたびに品質が詳細化されて、 最終的にはシナリオになります。

アセスメント表の作成

ユーティリティ ツリーの各リーフに対してシナリオを記述します。 シナリオは、コンテキスト、刺激、応答の形式で記述します (例: "一般的な操作では、データベース トランザクションを 100 ミリ秒未満で実行する")。

スプレッドシート (表) を作成して、各シナリオをそのアセスメント表の行として入力し、 各アーキテクチャ戦略を列として入力します。 戦略とシナリオが交差する場所に、1 ～ 4 の評価を入力します。

評価では、次の要素を考慮します。

  • 開発コスト 実装は容易か? 他の領域にどのような影響があるか?

  • 運用コスト 実行時に問題なく動作するか? 使用性やパフォーマンスなどに影響はないか?

  • リスク シナリオに確実に対処できるか? 未知のコストはないか? 将来の要件の増加に対応できなくなる可能性はないか?

戦略の概念実証が既に作成されている場合は、その概念実証からの情報を評価に役立てます。

表の一番下に各シナリオの評価の合計を入力し、 その数字を、アーキテクチャを決定するための話し合いに使用します。

完成したアセスメント表をプロジェクト ポータルにアップロードします。

アーキテクチャの選択

アセスメント表が完成したら、レビュー会議を開いて、次のイテレーションで使用するアーキテクチャを決定します。 その際には、アセスメント表と、概念実証の作成によって得られた情報を使用します。 アーキテクチャが選択されたら、そのアーキテクチャのダイアグラムを参照ソリューションとしてチェックインし、選択の理由が取り込まれた根拠文書を作成します。

レビューの準備

アーキテクトとリード開発者が、提案されたアーキテクチャをレビューするのにふさわしいレビュー担当者を特定して、各参加者にアーキテクチャのドキュメントを配布します。

システム アーキテクチャと配置アーキテクチャのレビュー

レビュー会議では、システム ダイアグラム、配置レポート、および論理データセンター ダイアグラムのレビューを行います。 そこでの目標は、次のイテレーションで実装するアーキテクチャを選択することです。

アセスメント表での順位を踏まえて各アーキテクチャの適合性を評価します。 各アーキテクチャの実装に伴うコストや複雑さなど、概念実証から得られた情報も考慮します。 論理データセンター ダイアグラムについては、変更できない既存のデータセンターを表している場合はレビューから除外します。 データセンターを作成する場合は、論理データセンター ダイアグラムをレビューして配置の問題を確認します。 使用するアーキテクチャを選択し、 アーキテクチャ上の概念をシナリオに照らし合わせてレビューして、そのソリューションが顧客のニーズを満たしていること、完全なソリューションであることを確認します。

参照ソリューションの作成

会議の決定が取り込まれた根拠文書を作成して、 プロジェクト ポータルにアップロードします。 選択されたアーキテクチャのアプリケーション ダイアグラム、システム ダイアグラム、または論理データセンター ダイアグラムを、次のイテレーションで機能を実装するために使用する参照ソリューションとしてチェックインします。 チーム全体および依存している他のチームに、次のイテレーションで使用するアーキテクチャが決定されたことを伝えます。

パフォーマンス モデルの開発

パフォーマンス モデルは、アプリケーションの潜在的なパフォーマンスの問題を見つけて対処するためのもので、 サービス品質要求から開発されます。サービス品質要求は複数の開発タスクに分割されて、 各開発タスクに、実装に対するパフォーマンス割り当てが割り当てられます。

パフォーマンスに対するサービス品質要求にリンクされているシナリオを特定し、 それらのシナリオに開発タスクを対応付けます。 サービス品質要求の一覧からアプリケーションの作業負荷を確認し、 その作業負荷の見積もりとサービス品質要求の一覧を使用して、主要なシナリオのパフォーマンス目標を特定します。 これには、応答時間、スループット、リソース使用量などの目標が含まれます。 それらのパフォーマンス目標を満たすために割り当てられているパフォーマンス関連のリソースを特定し (実行時間、ネットワーク帯域幅など)、 各リソースの割り当ての上限を確認します。

割り当てられているリソースを各シナリオの処理ステップに配分します。 どのように配分すればよいかわからない場合は、適切に推量して配分するか、各ステップに均等に配分します。 割り当ての配分は検証の際に調整されます。 その配分を適切な開発タスクにアタッチまたは記述します。

パフォーマンス目標の達成に対するリスクとなる割り当ての配分を見つけて、 パフォーマンス目標を達成するためのトレードオフについて検討します (設計や配置の他の選択肢など)。 必要に応じてサービス品質要求を再評価します。

割り当ての配分を満たしていないシナリオを特定し、 そのシナリオのパフォーマンスを測定します。 初期のイテレーションでコードを使用できない場合はプロトタイピングを使用します。 必要に応じて、割り当て、評価、検証のステップを、検証で得られたデータを使用して繰り返します。

脅威モデルの開発

詳細については、Microsoft Web サイトの「セキュリティ デベロッパー センター」を参照してください。