前回の記事からの続き: IBM アーキテクチャ設計手法を読み解く - ソリューション設計 I
2. ソリューションを設計する
2.1 開発アーキテクチャの概要
アーキテクチャの概要は、ソリューションによって構築されるシステムの高レベルの抽象化です。アーキテクチャの概要を作成する主な目的は、システムの主な構造と重要な機能をプロジェクトの関係者に伝えることです。関係者が異なれば懸念事項も異なるため、システム アーキテクチャの概要 さまざまな表現形式もありますが、説明の焦点はターゲット システムです。
最初の例は、プロジェクト スポンサーのビジネス チームとの通信によく使用されるエンタープライズ パースペクティブを示しています。システムに含まれる主要な機能モジュール、どのユーザーがどのチャネルを通じてシステムを使用するか、システムがサポートする必要があるリソースが示されています。 。
2 番目の例は、SOA アーキテクチャ ソリューションの設計で一般的に使用される階層化アーキテクチャの観点を示しています。
3 番目の例は、IT の観点から描かれたアーキテクチャの概要図を示しています。
2.2 研究候補資産
このステップでは、アーキテクトは、パッケージ化されたソフトウェア、オープンソース ソフトウェア、以前のプロジェクトで開発された再利用可能なコンポーネントなどを含む利用可能な資産を調査し、これらの資産とプロジェクト要件との間の適合性とギャップを分析する必要があります。調査終了後、調査結果は候補資産リスト（候補資産リスト）にまとめられます。候補アセットのリストの例は次のとおりです。
2.3 主要なサービスの定義
SOA アーキテクチャ ソリューションを設計する場合、プロジェクト関連のサービスを定義するための重要なリンクです。これらのサービスは既存のものである場合もあれば、新しく作成する必要がある場合もあります。主要なサービスを定義するときは、そのサービスが重要な機能要件および非機能要件をどのように満たしているかを評価します。
2.4 高レベルのコンポーネントモデルの開発
コンポーネントはコンポーネントとも呼ばれます。コンポーネント モデルは、システム構造を巨視的に記述し、コンポーネントの責任、関係境界、および相互作用を記述するために使用されます。次の図に示すように、共通コンポーネント モデルには、コンポーネント関係図とコンポーネント相互作用図が含まれます。以下の図に示すように、コンポーネント関係図は、コンポーネントまたはサブシステム間の静的な依存関係を示します。
コンポーネント相互作用図は、コンポーネントがシーンを実現するためにどのように連携するかを示し、コンポーネント間の呼び出しプロセスも示します。
2.5 高度な運用保守モデルの開発
運用モデルは、コンポーネントが地理的にどこに展開されるか、ハードウェアの種類と構成、およびそのハードウェアがどのように接続されるかを記述します。コンポーネントモデルと比較して、コンポーネントモデルはシステムが機能要件をどのように実現するかに重点を置きますが、運用保守モデルはシステムが非機能要件を実現するために非常に重要です。次の図は、一般的な運用および保守モデルです。
2.6 実現可能性評価の改善
実現可能性評価は、ソリューション開発プロセスの中で何度も行われる作業であり、スキーム設計が完了に近づいたら、再度実現可能性評価を改善する必要があります。このとき、予定されている人員、コスト、時間、予見可能なリスク、現在の技術レベルの下で計画の実現可能性を慎重に評価し、非現実的または重大な課題の要件を再交渉し、計画がビジネスや組織に与える影響を評価する必要があります。手頃な価格です。
2.7 ソリューション全体を評価する
顧客にソリューションを説明する前に、技術ソリューション全体を正式にレビューし、ソリューションが顧客の成功条件を満たしているかどうか、および顧客がそのソリューションを受け入れるかどうかを評価する必要があります。
3. 解決策を説く
参考文献
1. CCRA 4.0 概要_20140918_non_conf
2. [インド] Tilak Mitra、実践的なソフトウェア アーキテクチャ: システム環境からソフトウェア展開まで、Mechanical Industry Press、2017
3. https://wenku.baidu.com/view/4c21d7b1ee06eff9aff80768.html
4. https://files.ifi.uzh.ch/rerg/amadeus/teaching/courses/it_architekturen_hs10/
5. https://wenku.baidu.com/view/d77dcd32cf84b9d528ea7adb.html