现在的一切都是为将来的梦想编织翅膀，让梦想在现实中展翅高飞。
Now everything is for the future of dream weaving wings, let the dream fly in reality.
システムアーキテクチャ設計・基礎編(1) 【システムアーキテクチャ設計者】
- 1. ソフトウェアアーキテクチャの概念 ★★★
- 2. ソフトウェアアーキテクチャスタイル ★★★★★
- 3. アーキテクチャベースのソフトウェア開発手法 (ABSD) ★★★★
- 4. ドメイン固有ソフトウェア アーキテクチャ (DSSA) ★★★
- 5. ソフトウェアアーキテクチャの再利用 ★★★
1. ソフトウェアアーキテクチャの概念 ★★★
1.1 ソフトウェアアーキテクチャの定義
ソフトウェア アーキテクチャの概念
ソフトウェアアーキテクチャ=ソフトウェア アーキテクチャ
は、システムの 1 つ以上の構造を指します。構造には次のものが含まれます:
(1) 構造 - ソフトウェアのコンポーネント (プログラム モジュール、クラス、ミドルウェアなど)
(2) 属性 - コンポーネント 外部から見えるプロパティ
(3) インタラクション - コンポーネント間の関係
ソフトウェアアーキテクチャの性質
ソフトウェア アーキテクチャは、ソフトウェア システムの構造、動作、およびプロパティの高レベルの抽象化を提供します。
ソフトウェア アーキテクチャ スタイルは、特定のアプリケーション ドメインの慣用的なパターンであり、語彙と一連の制約を定義します。
ソフトウェアアーキテクチャの役割
ソフトウェア アーキテクチャは、プロジェクトの関係者がコミュニケーションするための手段です。
ソフトウェア アーキテクチャは転送可能で再利用可能なモデルであり、ソフトウェア アーキテクチャを研究することでソフトウェアの品質を予測することができます。
ソフトウェア アーキテクチャにより、推論と変更の制御が簡素化され、段階的なプロトタイピングが容易になり、トレーニングの基礎として機能します。
要件分析→アーキテクチャ（要件から設計までのギャップを埋める）→ソフトウェア設計
アーキテクチャ設計は要件の割り当てであり、要件を満たす責任をコンポーネントに割り当てます。
ソフトウェア アーキテクチャの設計は、4 + 1の複数のビューを通じて包括的に説明されます。
1.2 ソフトウェア アーキテクチャ設計 4 + 1 ビュー
視点と視点:
さまざまな視点から検討すると、さまざまな視点が生まれます。
Kruchten は 1995 年に「4+1」ビュー モデルを提案しました。「4+1」ビュー モデルは、論理ビュー、プロセス ビュー、物理ビュー、開発ビュー、シーン ビューを含む 5 つの異なる観点からソフトウェア アーキテクチャを記述します。各ビューはシステムの 1 つの側面のみを考慮しており、5 つのビューを組み合わせてのみシステムのソフトウェア アーキテクチャの内容全体を反映できます。
論理ビュー: 主にシステムの機能要件、つまりシステムがエンドユーザーに提供するサービスをサポートします。論理ビューの設計で注意すべき主な問題は、システム全体にわたって単一の一貫したオブジェクト モデルを維持し、オブジェクト モデルとオブジェクトの間の関係を記述することです。
開発ビュー: モジュール ビューとも呼ばれ、主にソフトウェア モジュールの編成と管理に焦点を当てています。開発ビューは、システムの入出力関係のモデル図とサブシステム図を通じて説明されます。ソフトウェアに含まれるすべての要素を特定した後で完全な開発の観点を説明することも、各要素を特定する前に開発の観点の原則をリストすることもできます。
プロセス ビュー: プロセス ビューとも呼ばれます。システムの動作特性に焦点を当て、主にシステムのパフォーマンスや可用性などの非機能要件に焦点を当てます。プロセス ビューは、論理ビューの主な抽象化としてのプロセス構造に加えて、同時実行性、分散、システム統合、フォールト トレランスを強調します。プロセス ビューは、各レベルが異なる側面に焦点を当てた複数レベルの抽象化として説明できます。
物理ビュー: 主にソフトウェアをハードウェアにマッピングする方法を検討し、通常はシステム トポロジ、システムの設置、通信などの問題の解決を考慮します。
シナリオ: 4 つのビューを有機的に結び付ける、重要なシステムのアクティビティを抽象化したものとして見ることができ、ある意味、シナリオは要件の最も重要な抽象化です。アーキテクチャを開発する際、設計者がアーキテクチャのコンポーネントとコンポーネント間の関係を見つけるのに役立ちます。シナリオを使用して、特定のビューを分析したり、さまざまなビュー コンポーネントがどのように相互作用するかを説明したりすることもできます。シーンはテキストまたはグラフィックで表現できます。
論理ビューと開発ビューはシステムの静的構造を記述し、プロセス ビューと物理ビューはシステムの動的構造を記述します。ソフトウェア システムが異なれば、焦点角度も異なります。たとえば、管理情報システムの場合は、論理的な観点と開発の観点からシステムを記述することに重点が置かれますが、リアルタイム制御システムの場合は、プロセスの観点と物理的な観点からシステムを記述することに重点が置かれます。
1.3 ソフトウェア アーキテクチャの設計とライフサイクル
ソフトウェア アーキテクチャはライフ サイクル全体を通じて実行され、さまざまな段階で異なる機能と意味を持ちます。各段階のアーキテクチャ作業実績表は次のとおりです。
| ステージ | 機能と意義 |
|---|---|
| 要件分析段階 | 各段階での参加者間のコミュニケーションが容易になり、各段階のトレーサビリティーも維持しやすくなります。 ソフトウェア要件モデルからソフトウェア アーキテクチャ モデルへの変換では、次の 2 つの問題に焦点を当てます。 1) 要件モデルに基づいてソフトウェア アーキテクチャ モデルを構築する方法 2) モデル変換のトレーサビリティを確保する方法 |
| 設計段階 | 最も初期の最も多くの段階に焦点を当てます。 この段階での研究内容は主に以下のとおりです。 1) ソフトウェア アーキテクチャ モデルの説明 2) ソフトウェア アーキテクチャ モデルの設計と分析方法 3) ソフトウェア アーキテクチャの設計経験の概要と再利用 アーキテクチャ モデルの説明 研究内容: ① SA (ソフトウェア アーキテクチャ) の構成モデル - コンポーネントと接続のモデリング ② アーキテクチャ記述言語 (ADL) ③ マルチビュー - 4 + 1 ビュー ADL の 3 つの基本要素: 1) コンポーネント: コンポーネントおよび対応するコンポーネント インターフェイスを含むコンピューティングまたはデータ ストレージ ユニット 2) コネクタ: アーキテクチャコンポーネント間の相互作用をモデル化するためのビルディング ブロックと、これらの相互作用を管理するルール 3) アーキテクチャ構成: アーキテクチャのコンポーネントとコネクタを説明する接続図 ADL はモデリングに使用され、一部の疑似コードです |
| 実装段階 | ソフトウェア アーキテクチャの設計から実装までの変革を効果的に実現します。 この段階でのアーキテクチャ研究には、 1) アーキテクチャ開発プロセスに基づくサポート 2) アーキテクチャから実装への移行方法の模索 3) アーキテクチャベースのテスト技術の研究が含まれます。 |
| 部品組立ステージ | 再利用可能なコンポーネントアセンブリの設計により、システム実装の効率が向上します。 この段階での研究内容は、 1) 再利用可能なコンポーネントの相互接続をどのようにサポートするか、つまり、アーキテクチャ設計モデルで指定されたコネクタの実装をサポートする方法、2)アーキテクチャの不一致問題や適応問題を どのように検出および除去するか、などです。組立工程の 主な内容は、 ① 部品自体の適合 ② コネクタ（相互接続機構）の不一致 ③ 部品と全体の不一致 |
| 導入フェーズ | 導入フェーズでソフトウェアとハードウェアのアーキテクチャを整理して提示し、導入計画を評価および分析します。 ソフトウェア導入における導入段階におけるソフトウェア アーキテクチャの役割: 1) 導入段階でのソフトウェアおよびハードウェア モデルを説明するための高レベルのアーキテクチャ ビューを提供します。 2 ) ソフトウェア アーキテクチャ モデルに基づいて、導入計画の品質属性を決定することができます。合理的な展開計画を選択するために分析される |
| 開発後の段階 | 主に保守、進化、再利用が中心です。 導入およびインストール後のシステム アーキテクチャの研究方向 (開発後段階) には、次のものが含まれます。 1) 動的ソフトウェア アーキテクチャ 2) アーキテクチャの回復と再構築 |
1.4 ソフトウェアアーキテクチャの重要性
ソフトウェア アーキテクチャの設計は、コストを削減し、品質を向上させ、オンデマンドかつオンタイムで製品を提供するための重要な要素です。
2. ソフトウェアアーキテクチャスタイル ★★★★★
- アーキテクチャ スタイルは、システムを説明するために使用される用語集と、システムの構築をガイドする一連のルールを定義します。
- アーキテクチャ スタイルは、現場の多くのシステムに共有される構造的および意味論的な特性を反映しており、さまざまなコンポーネントを効果的に編成して完全なシステムにする方法を示します。
- ソフトウェア アーキテクチャ スタイルは、特定のアプリケーション ドメインの慣用的なパターンであり、語彙と一連の制約を定義します。
2.1 ソフトウェア アーキテクチャの 5 つの古典的なスタイル
| 5つの建築様式 | サブスタイル |
|---|---|
| データフロースタイル | バッチ、パイプラインフィルター |
| コール/リターンスタイル | プログラム/サブルーチン、オブジェクト指向、階層 |
| データ中心のスタイル | データベースシステム、黒板システム、ハイパーテキストシステム |
| 仮想マシンのスタイル | インタプリタ、ルールシステム |
| 独立したコンポーネントのスタイル | プロセス通信、イベント駆動型（暗黙的呼び出し） |
2.1.1 データ フローのアーキテクチャ スタイル
| アドバンテージ | 欠点がある | 代表的な例 |
|---|---|---|
| 1、松耦合【高内聚-低耦合】 2、良好的重用性/可维护性 3、可扩展性【标准接口适配】 4、良好的隐蔽性 5、支持并行 |
1、交互性较差 2、复杂性高 3、性能较差（每个过滤器都需要解析与合成数据） |
传统编译器 网络报文处理 |
2.1.1.1 批处理风格
批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。数据必须是完整的，以整体的方式传递。
2.1.1.2 管道/过滤器风格
在管道/过滤器风格的软件架构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。
2.1.2 调用/返回系结构风格
2.1.2.1 主程序/子程序风格
主程序/子程序风格是结构化开发时期的经典架构风格。这种风格一般采用单线程控制，把问题划分为若干处理步骤，构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制，即充当连接件。
2.1.2.2 面向对象风格
这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。
2.1.2.3 层次结构风格
层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见
2.1.3 以数据为中心系结构风格
2.1.3.1 仓库结构风格
数据库系统是仓库风格最常见的形式。在数据库系统中，构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。
2.1.3.2 黑板结构风格
黑板系统包括知识源、黑板和控制三个部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中，例如，信号处理、问题规划和编译器优化等。语音识别、知识推理。
2.1.3.3 超文本系统风格
超文本系统中出现的构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。
2.1.4 虚拟机体系结构风格
2.1.4.1 解释器风格
解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。
2.1.4.2 规则系统风格
基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。
2.1.5 独立构件体系结构风格
2.1.5.1 进程间通信风格
构件是独立的过程，连接件是消息传递，构件通常是命名过程，消息传递的方式可以是点对点，异步或者同步的方式，以及远程过程方法调用等。
2.1.5.2 事件驱动系统风格（隐式调用）
构件不直接调用一个过程，而是触发或广播一个或多个事件。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用（implicit invocation）来实现的。基于事件的隐式调用风格的主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。
2.2 C2风格
C2风格通过连接件连接构件或某个构件组，构件与构件之间无连接。
软件体系结构设计的一个核心问题就是能否使用重复的体系结构模式，即能否达到体系结构级的软件重用。
C2 = EBI（基于事件的集成）+ LCS（分层客户端服务器）
C2是一种基于构件和消息的架构风格，可用于创建灵活的，可伸缩的软件系统。可以将架构看作是按照一定规则由连接件如消息路由设备连接的许多构件组成的层次网络系统中的构件和连接件都有一个“顶部”和“底部”;一个构件的“顶部”或“底部”可以连接到一个连接件的“底部”或“顶部”;对于一个连接件，和其相连的构件或连接件的数量没有限制，但是构件和构件之间不能直接相连。
C2架构的基本规则：
- 构件和连接件都有一个顶部和一个底部。
- 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。
- 一个连接件可以和任意数目的其他构件和连接件连接。
- 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
2.3 闭环风格
- 适用于嵌入式系统，用于解决简单闭环控制问题。
- 经典应用：空调温控，定速巡航。
三、基于架构的软件开发方法（ABSD）★★★★
3.1 体系机构设计的方法概述
基于架构的软件设计（ABSD，Architecture-Based Software Design）是一种架构驱动方法，架构驱动也就是说架构先行，需求获取和分析还没有完成就开始架构设计，需求获取和分析与架构设计并行，例如产品线系统和长期运行的系统，我们不可能开始就能决定所有的需求。
ABSD强调由业务、质量和功能需求的组合驱动架构设计 ，强调采用 视角和视图 来 描述软件架构 ，采用 用例（功能需求）和质量场景（质量需求） 来 描述需求 。
ABSD方法有三个基础：
- 第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。
- 第二个基础是通过选择架构风格来实现质量和业务需求。
- 第三个基础是软件模板的使用。
3.2 基于架构的开发模型（ABSD）
传统的软件开发过程是问题定义，需求分析，软件设计，实现，测试。ABSD把整个软件过程分成六个部分，架构需求，设计，文档化，复审，实现，演化六个步骤。
四、特定领域的软件架构（DSSA）★★★
DSSA（Domain Specific Software Architecture）特定领域软件架构，可以看做开发产品线的一个方法或理论，目标就是支持一个特定领域中多应用的生成。
4.1 特定领域的软件架构 - 基本活动
（1）建立领域模型，一个严格定义的问题域或解决域。其中，垂直域是在相同领域中深入；水平域是在不同领域中平移。
（2）具有普遍性，使其可以用于领域中某个特定应用的开发。
（3）对整个领域的合适程序的抽象。
（4）具备该领域固定的、典型的在开发过程中的。可复用元素。
4.2 特定领域的软件架构 - 领域分析机制
4.3 特定领域的软件架构 - 建立过程
五、软件架构的复用★★★
-
ソフトウェア アーキテクチャの再利用の定義と分類
ソフトウェア アーキテクチャの再利用は、体系的なソフトウェア開発プロセスです。基本的なソフトウェア コンポーネント モジュールのセットを開発して、さまざまな要件/アーキテクチャ間の類似点をカバーし、システム開発とパフォーマンスの効率と品質を向上させます。 -
ソフトウェア アーキテクチャを再利用する理由は、
開発作業の削減、開発時間の短縮、開発コストの削減、生産性の向上、製品品質の向上、およびより優れた相互運用性の実現です。 -
ソフトウェア アーキテクチャの再利用のオブジェクトと形式 再利用可能な
資産には、要件、アーキテクチャ設計、要素、モデリング分析、テスト、プロジェクト計画、プロセス + メソッド + ツール、人員、サンプル システム、および欠陥の除去が含まれます。
再利用の一般的な形式には、関数の再利用、ライブラリの再利用、オブジェクト指向開発におけるクラス、インターフェイス、およびパッケージの再利用が含まれます。 -
ソフトウェア アーキテクチャの再利用の基本的なプロセスは、
(1)再利用可能なソフトウェア資産を構築/取得する (再利用の前提)、
(2)再利用可能な資産を管理する、
(3)再利用可能な資産を利用する。