建築技術

反復型および増分型アプローチ

これは、候補ソリューションの生成に役立つ5つの主要なステップで構成される反復型の増分アプローチです。この候補解は、これらの手順を繰り返すことでさらに洗練され、最終的にアプリケーションに最適なアーキテクチャ設計を作成できます。プロセスの最後に、アーキテクチャを確認して、すべての関係者に伝達できます。

これは、考えられるアプローチの1つにすぎません。アーキテクチャを定義、レビュー、伝達する、より正式なアプローチは他にもたくさんあります。

アーキテクチャの目標を特定する

アーキテクチャと設計プロセスを形成するアーキテクチャの目標を特定します。完璧で定義された目標は、アーキテクチャに重点を置き、設計の適切な問題を解決し、現在のフェーズがいつ完了し、次のフェーズに進む準備ができているかを判断するのに役立ちます。

このステップには、次のアクティビティが含まれます-

最初にアーキテクチャの目標を特定します。
私たちのアーキテクチャの消費者を特定します。
制約を特定します。

アーキテクチャアクティビティの例には、Webアプリケーションの注文処理UIに関するフィードバックを取得するためのプロトタイプの作成、顧客の注文追跡アプリケーションの作成、セキュリティレビューを実行するためのアプリケーションの認証および承認アーキテクチャの設計が含まれます。

主なシナリオ

このステップでは、最も重要な設計に重点を置きます。シナリオは、システムとのユーザーの相互作用の広範囲にわたる包括的な説明です。

重要なシナリオは、アプリケーションを成功させるための最も重要なシナリオと見なされるシナリオです。アーキテクチャに関する決定を下すのに役立ちます。目標は、ユーザー、ビジネス、およびシステムの目標の間でバランスをとることです。たとえば、ユーザー認証は、品質属性（セキュリティ）と重要な機能（ユーザーがシステムにログインする方法）の共通部分であるため、重要なシナリオです。

アプリケーションの概要

アプリケーションの概要を構築します。これにより、アーキテクチャがより使いやすくなり、実際の制約や決定に結び付けられます。以下の活動で構成されています-

アプリケーションタイプを特定する

アプリケーションの種類を、モバイルアプリケーション、リッチクライアント、リッチインターネットアプリケーション、サービス、Webアプリケーション、またはこれらの種類の組み合わせのいずれであるかを特定します。

展開の制約を特定する

適切なデプロイメントトポロジを選択し、アプリケーションとターゲットインフラストラクチャ間の競合を解決します。

重要なアーキテクチャ設計スタイルを特定する

クライアント/サーバー、階層化、メッセージバス、ドメイン駆動設計などの重要なアーキテクチャ設計スタイルを特定して、頻繁に発生する問題の解決策を提供することにより、パーティション分割を改善し、設計の再利用を促進します。多くの場合、アプリケーションはスタイルの組み合わせを使用します。

重要な問題または重要なホットスポット

アプリケーションを設計する際、ホットスポットは間違いが最も頻繁に発生するゾーンです。品質属性と横断的関心事に基づいて重要な問題を特定します。潜在的な問題には、新しいテクノロジーの出現や重要なビジネス要件が含まれます。

品質属性は、実行時の動作、システム設計、およびユーザーエクスペリエンスに影響を与えるアーキテクチャの全体的な機能です。横断的関心事は、すべてのレイヤー、コンポーネント、および層に適用される可能性のある設計の機能です。

これらは、影響の大きい設計ミスが最も頻繁に発生する領域でもあります。横断的関心事の例としては、認証と承認、通信、構成管理、例外管理と検証などがあります。

候補ソリューション

主要なホットスポットを定義した後、最初のベースラインアーキテクチャまたは最初の高レベルの設計を構築し、詳細の入力を開始して候補アーキテクチャを生成します。

候補アーキテクチャには、アプリケーションタイプ、展開アーキテクチャ、アーキテクチャスタイル、テクノロジの選択、品質属性、および横断的関心事が含まれます。候補アーキテクチャが改善である場合、それは新しい候補アーキテクチャを作成およびテストできるベースラインになる可能性があります。

サイクルを繰り返し実行して設計を改善する前に、すでに定義されている主要なシナリオと要件に対して候補ソリューションの設計を検証します。

アーキテクチャスパイクを使用して、設計の特定の領域を発見したり、新しい概念を検証したりする場合があります。アーキテクチャスパイクは、特定の設計パスの実現可能性を判断し、リスクを軽減し、さまざまなアプローチの実行可能性を迅速に判断する設計プロトタイプです。主要なシナリオとホットスポットに対してアーキテクチャのスパイクをテストします。

アーキテクチャレビュー

アーキテクチャのレビューは、ミスのコストを削減し、アーキテクチャの問題をできるだけ早く見つけて修正するための最も重要なタスクです。これは、プロジェクトのコストとプロジェクトの失敗の可能性を削減するための確立された費用効果の高い方法です。

プロジェクトの主要なマイルストーンで、およびその他の重要なアーキテクチャの変更に対応して、アーキテクチャを頻繁に確認します。
アーキテクチャレビューの主な目的は、アーキテクチャを正しく検証するベースラインアーキテクチャと候補アーキテクチャの実現可能性を判断することです。
機能要件と品質属性を提案された技術ソリューションにリンクします。また、問題を特定し、改善すべき領域を認識するのにも役立ちます

シナリオベースの評価は、ビジネスの観点から最も重要で、アーキテクチャに最大の影響を与えるシナリオに焦点を当てたアーキテクチャ設計をレビューするための主要な方法です。以下は、一般的なレビュー方法です。

ソフトウェアアーキテクチャ分析方法（SAAM）

もともとは変更可能性を評価するために設計されましたが、後で品質属性に関してアーキテクチャをレビューするために拡張されました。

アーキテクチャトレードオフ分析方法（ATAM）

これはSAAMの洗練された改良版であり、品質属性要件に関するアーキテクチャ上の決定と、それらが特定の品質目標をどの程度満たしているかを確認します。

アクティブデザインレビュー（ADR）

これは、一般的なレビューを実行するのではなく、一度に一連の問題またはアーキテクチャの個々のセクションに焦点を当てる、不完全または進行中のアーキテクチャに最適です。

中間デザインのアクティブレビュー（ARID）

これは、進行中のアーキテクチャをレビューするADRの側面と、一連の問題に焦点を当てたものと、品質属性に焦点を当てたシナリオベースのレビューのATAMおよびSAAMアプローチを組み合わせたものです。

費用便益分析法（CBAM）

これは、アーキテクチャ上の決定のコスト、利点、およびスケジュールへの影響の分析に焦点を当てています。

アーキテクチャレベルの変更可能性分析（ALMA）

これは、ビジネス情報システム（BIS）のアーキテクチャの変更可能性を推定します。

家族建築評価法（FAAM）

相互運用性と拡張性について、情報システムファミリのアーキテクチャを推定します。

アーキテクチャ設計の伝達

アーキテクチャの設計が完了したら、開発チーム、システム管理者、オペレーター、事業主、その他の関係者など、他の利害関係者に設計を伝達する必要があります。

他の人にアーキテクチャを説明するためのいくつかのよく知られた方法があります：−

4 +1モデル

このアプローチでは、アーキテクチャ全体の5つのビューを使用します。その中で、4つのビュー（logical view, インクルード process view, インクルード physical view, そしてその development view）さまざまなアプローチからアーキテクチャを説明します。5番目のビューは、ソフトウェアのシナリオと使用例を示しています。これにより、利害関係者は、特に関心のあるアーキテクチャの機能を確認できます。

アーキテクチャ記述言語（ADL）

このアプローチは、システム実装前のソフトウェアアーキテクチャを説明するために使用されます。動作、プロトコル、コネクタなどの懸念事項に対処します。

ADLの主な利点は、設計の使用を正式に開始する前に、アーキテクチャの完全性、一貫性、あいまいさ、およびパフォーマンスを分析できることです。

アジャイルモデリング

このアプローチは、「コンテンツは表現よりも重要である」という概念に従います。これにより、作成されたモデルがシンプルで理解しやすく、十分に正確で、詳細で、一貫性があることが保証されます。

アジャイルモデルドキュメントは特定の顧客を対象とし、その顧客の作業を遂行します。ドキュメントがシンプルなため、アーティファクトのモデリングに関係者が積極的に参加できます。

IEEE 1471

IEEE 1471は、正式にはANSI / IEEE1471-2000「ソフトウェア集約型システムのアーキテクチャ記述の推奨プラクティス」として知られている規格の略称です。IEEE 1471は、アーキテクチャ記述の内容を強化し、特に、コンテキスト、ビュー、および視点に特定の意味を与えます。

統一モデリング言語（UML）

このアプローチは、システムモデルの3つのビューを表しています。ザ・functional requirements view （ユースケースを含む、ユーザーの観点から見たシステムの機能要件）; the static structural view（オブジェクト、属性、関係、およびクラス図を含む操作）; そしてそのdynamic behavior view （オブジェクト間のコラボレーション、およびシーケンス、アクティビティ、状態図などのオブジェクトの内部状態の変更）。