系统架构设计基础知识
一. 系统架构概述
**
**
系统架构的定义**
**
系统架构（System Architecture）是系统的一种整体的高层次的结构表示，是系统的骨架和根基，支撑和链接各个部分，包括构件、连接件、约束规范以及指导这些内容设计与演化的原理，是刻画系统整体抽象结构的一种手段。
**
**
软件架构的定义
软件体系结构为软件系统提供了结构、行为和属性的高级抽象，由构成系统的元素描述、元素的外部可见属性、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。软件体系结构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策和演化的基本原理，是构建于软件系统之上的系统级复用。
信息系统架构的定义
信息系统架构 ISA 是关于软件系统的结构、行为和属性的高级抽象，结构中包括软件的构件、构件的外部可见属性、这些构件之间的相互关系。
在描述阶段，其对象是直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致的描述组件之间的通信。
在实现阶段，这些抽象组件被细化为实际的组件，比如具体的类、对象。
二. 软件架构的生命周期
1. 需求分析阶段
从软件需求模型向SA模型的转换，主要关注两个问题：
(1) 根据需求模型构建架构模型：用例图经过词法分析转换为SA模型（类图）。
(2) 保证模型转换的可追踪性：表格或用例映射。
2. 设计阶段
这个阶段的研究主要包括3个方面：
(1) SA模型的描述
(2) SA模型的设计与分析方法
(3) 对SA设计经验的总结与复用
SA模型描述的三个层次
(1) SA的基本概念：SA描述方法是构件和连接子的建模。
(2) 体系结构描述语言ADL：支持构件、连接子及其配置的描述语言。
(3) SA模型的多视图表示：体现了关注点分离的思想。“4+1”视图模型。
-
逻辑视图：最终用户关注系统的功能，描述系统的静态结构。表示了设计模型中在架构方面具有重要意义的部分。记录设计元素的功能和概念接口。（类图、对象图）
-
开发视图：程序员关注系统的实现, 描述系统构件组织和模块之间的依赖。对组成系统的构件进行建模，描述了在开发环境中软件的静态组织结构，代码构件组织、模块、模块之间的依赖关系。（模块结构图、构件图）
-
过程视图：系统集成人员关注并发和同步特征，描述线程间的并发和同步。可执行线程和进程作为活动类的建模，是逻辑视图的一次执行实例，描述了并发与同步结构。（活动图、状态图）
-
物理视图：系统工程师关注系统的部署、安装, 定义软硬件的物理体系结构。描述了软件到硬件的映射，主要描述硬件配置，系统中软硬件的物理体系结构及连接。（配置图）
-
统一场景：分析人员和测试人员关注系统的行为。
用例：描述功能需求。
质量场景：描述质量需求。
3. 实现阶段****
这个阶段的研究主要包括3个方面：
(1) 研究基于SA的开发过程支持：项目组织结构、配置管理。
(2) 寻求从SA模型向实现过渡的途径：模型映射、构件组装、复用中间件平台。
(3) 研究基于SA的测试技术。
填补高层SA模型和底层实现的鸿沟的典型方法
(1) 在SA模型中引入实现阶段的概念，如引入程序设计语言元素。
(2) 通过模型转换技术，将高层的SA模型逐步精化成能够支持实现的模型。
(3) 封装底层的实现细节，使之成为较大粒度构件，在SA指导下通过构件组装的方式实现系统，通常需要底层中间件平台的支持。
4. 构件组装阶段****
这个阶段的研究主要包括2个方面：
(1) 支持可复用构件的互联，即对SA设计模型中规约的连接子的实现提供支持。
(2) 在组装过程中，检测并消除体系结构失配问题。
对设计阶段连接子的支持：
将连接子转换为具体的程序代码，在工具的支持下，生成连接子的代码。
中间件的基本功能：
提供了构件之间跨平台交互的能力。
提供强大的公共服务能力。
体系结构失配：待复用构件对最终系统的体系结构和环境的假设，与实际状况不同而导致的冲突。
5. 部署阶段
SA对软件部署的作用：
(1) 描述部署阶段的软硬件模型：基于SA提供的高层的体系结构视图。
(2) 分析部署方案的质量属性：基于SA模型分析，选择合理的部署方案。
6. 后开发阶段****
这个阶段的研究主要围绕维护、演化、复用来进行，有2个典型的研究方向：
(1) 动态软件体系结构
- 体系结构设计阶段的支持
变化的描述、修改策略、描述修改过程、修改的可行性、修改所带来的影响。
- 运行时刻基础设施的支持
体系结构的维护、保证修改在约束范围内、运行时刻信息、分析修改后的体系结构符合指定的属性、正确映射构造元素的变化到实现模块。
(2) 体系结构恢复与重建
从已实现的系统中获取体系结构的过程，输出一组体系结构视图。
重建的方法分为4类：手工重建、工具支持的手工重建、通过查询语言来自动建立聚集、使用其它技术(数据挖掘)。
三. 基于架构的软件设计ABSD
基于体系结构的软件设计 Architecture-Based Software Design
ABSD方法是体系结构驱动的，指由构成体系结构的商业、质量、功能需求的组合驱动的架构设计。
ABSD方法是一个自顶向下、递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。
ABSD设计活动从项目总体框架明确就开始，此时需求抽取和分析还没完成。
ABSD方法的3个基础
-
功能的分解。
-
通过选择体系结构风格来实现质量和商业需求。
-
软件模板的使用。
视角与视图 — 描述软件架构
用例 — 描述功能需求
质量场景 — 描述质量需求
静态视角：展示功能组织，判断质量特性。
动态视角：展示并发行为，判断行为特性。
-
描述软件架构：视角 + 视图
-
描述需求：用例(功能需求) + 质量属性场景(质量需求)
要点1：使用ABSD方法的3个基础
(1) 功能的分解：使用已有的基于模块的内聚和耦合技术。(2) 选择架构风格：实现质量和业务需求。(3) 软件模块的使用：复用软件系统的结构。
要点2：基于架构的开发模型
需求获取 -> 生成类图 -> 对类进行分组 -> 把类打包成构件 -> 需求评审
提出架构模型 -> 映射构件 -> 分析构件相互作用 ->产生架构 -> 设计评审
体系结构规格说明 + 测试体系结构需求的质量设计说明书
阶段1：架构需求1. 需求获取
2. 标识构件：生成类图 —> 对类进行分组 —> 把类打包成构件3. 需求评审
阶段2：架构设计
-
提出架构模型
-
把已标识的构件映射到架构中
-
分析构件之间的相互作用
-
产生软件体系结构
-
设计评审
阶段3：架构文档化体系结构规格说明
测试体系结构需求的质量设计说明书
阶段4：架构复审安排一次由外部人员（用户代表和领域专家）参加的复审，标识潜在的风险，及早发现架构设计中的缺陷和错误。
阶段5：架构实现1. 复审后的文档化的架构2. 分析与设计3. 构件实现
- 构件组装5. 系统测试6. 架构演化
阶段6：架构演化1. 需求变化归类 - 制订架构演化计划3. 修改、增加、删除构件4. 更新构件的相互作用5. 构件组装与测试6. 技术评审
四. 架构风格
架构风格：描述某一特定应用领域中系统组织方式的惯用模式，反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
一个架构定义了一个词汇表和一组约束。
词汇表：包含一些构件和连接件类型。
约束：指出系统是如何将这些构件和连接件组合起来的。
对架构风格的研究和实践促进对设计的重用。
5类架构风格
| **架构风格 ** | 定义 | **代表 ** |
|---|---|---|
| 1. 数据流 | 面向数据流，按照一定的顺序从前向后执行 | 批处理序列管道-过滤器 |
| 2. 调用/返回 | 构件之间存在显式的互相调用关系 | 主程序/子程序面向对象层次结构客户端/服务器 |
| 3. 独立构件 | 每个构件都相对独立，构件之间不直接通信，不存在显式的调用关系，而是通过某个事件触发、异步的方式来执行（隐式调用） | 进程通信事件系统 |
| 4. 虚拟机 | 自定义一套规则，使用者基于这个规则来开发构件，能够跨平台适配，规则随时改变，业务灵活定义、组合 | 解释器基于规则的系统 |
| 5. 仓库 | 以数据为中心，所有的操作都是围绕建立的数据中心进行的 | 数据库系统超文本系统黑板系统 |
1. 数据流风格****批处理序列：每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，数据必须是完整的，以整体的方式传递。构件：一系列固定顺序的独立应用程序，构件之间只通过数据传递交互。连接件：某种类型的媒介。
管道-过滤器：对数据的处理分解为几个序贯的步骤，处理步骤由过滤器实现，数据传输由管道负责。每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，产生输出数据流。每个阶段产生的结果作为下一个阶段的输入，即前一个构件的输出作为后一个构件的输入，前后数据流关联，前面执行到部分可以开始下一个的执行。构件：过滤器。连接件：管道。
2. 调用/返回风格****主程序/子程序：单线程控制，显式调用，主程序直接调用子程序，过程调用作为交互机制，调用关系具有层次性。构件：主程序、子程序。连接件：过程调用。
面向对象：对象封装了属性和操作，通过对象调用封装的方法和属性。构件：对象。连接件：过程调用。
层次结构：每层为上一层提供服务，使用下一层的服务，只能见到与自己相邻的层接口。修改某一层，最多只影响其相邻的两层，通常只能影响上层。优点：(1) 支持基于可增加抽象层的设计，将一个复杂问题分解成一个增量步骤序列的实现。(2) 不同的层次处于不同的抽象级别，越靠近底层，抽象级别越高，核心层封装通用的方法，与业务无关。(3) 由于每层最多只影响两层，只要给相邻层提供相同的接口，允许每层用不同的方法实现，为软件复用提供支持。缺点：(1) 很难找到一个合适且正确的层次抽象方法，系统划分层次不容易。(2) 层次越多，性能越差。构件：组成一个层次结构。连接件：通过决定层间如何交互的协议来定义。
3. 独立构件风格****进程通信：独立的进程间消息传递的方式可以是点对点、同步、异步、远程过程调用。构件：独立的进程。连接件：消息传递。
事件驱动(隐式调用) ：基于事件的隐式调用，用于实现松耦合的组件通信。构件之间不直接调用彼此的方法，而是通过事件驱动，采用发布-订阅的模式进行通信。构件中的过程在一个或多个事件中注册，这些过程被绑定到特定的事件上，当该事件被触发时，在这个事件中注册的相应过程会被自动调用。构件：一些模块（过程、事件的集合）。连接件：在事件中注册一些过程，当发生这些事件时，过程被调用。
4. 虚拟机风格****解释器：解析与运行自定义的规则/业务/语言，通常被用来建立一种虚拟机，以弥合程序语义与硬件语义之间的差异，但执行效率低。解释引擎-解释自定义的规则，存储区-存放被解释的程序，存放解释引擎当前工作状态的数据结构，存放程序被解释执行进度的数据结构。
基于规则的系统：将业务逻辑中频繁变化的部分定义为规则，通过灵活的自定义规则，实现规则的重组。规则定义：根据具体需求，设计和定义一系列规则，形成规则集。数据输入：数据输入至工作内存，并进行预处理。规则匹配：通过规则选择器，将输入数据与规则集中的规则进行匹配。操作执行：当规则匹配成功，由规则解释器根据规则定义的操作执行相应的动作。输出生成：根据执行结果生成输出数据。
5. 仓库(共享数据)风格****数据库系统：中央共享数据源+多个独立处理的构件。
黑板系统：适用于解决复杂的非结构化问题，解空间很大，求解过程不确定，对于解决问题没有确定性算法，求解过程中综合运用多种不同的知识源。(1) 知识源：独立计算的不同单元；(2)黑板：全局数据库；(3)控制：通过黑板状态的变化来控制。应用于信号处理、语音识别、问题规划、编译器优化、知识推理、松耦合代理数据共享存取。
超文本系统：互联网领域，网状链接，构件之间任意跳转。
6. 闭环控制风格发出控制命令并接收反馈，循环往复达到平衡，设定参数，不断调整。适合于嵌入式系统，涉及连续的动作与状态。软件与硬件之间可以表示为一个反馈。汽车巡航定速。
7. C2体系结构风格通过连接件绑定在一起，按照一组规则运作的并行构件网络。顶部、底部。
五. 特定领域软件体系结构DSSA
特定领域软件体系结构 DSSA（domain specific software architecture）
定义：专用于一类特定的应用领域，支持一组应用的领域模型、参考需求、参考架构等组成的标准体系结构，目标是支持在一个特定领域中多个应用的生成。
是在整个领域中能有效使用的、标准的组合结构的软件构件的集合。
DSSA的必备特征
-
一个严格定义的问题域和问题域解。
-
具有普遍性，可用于领域中某个特定应用的开发。
-
对整个领域的构件组织模型的恰当抽象。
-
具备该领域固定的、典型的在开发过程中可重用元素。
垂直域：局限在一个特定领域中的通用的完整的软件架构。
水平域：横跨多个不同的领域，涵盖多个领域之间相同的、共有的部分功能。
要点1：DSSA的3个基本活动
- 领域分析
主要目标：获得领域模型。
定义领域的边界，分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。（问题域）
领域模型：描述领域中系统之间的共同需求。
- 领域设计
主要目标：获得DSSA特定领域的软件架构。
DSSA描述在领域模型中表示的需求的解决方案，适应领域中多个系统的需求的一个高层次的设计。（解空间）
- 领域实现
主要目标：依据领域模型和DSSA，开发和组织可重用信息。
可重用信息：从现有系统中提取得到、通过新的开发得到。
**
**
**
**
要点2：建立DSSA的5个过程
- 定义领域范围：领域中的应用要满足用户一系列的需求。2. 定义领域特定的元素：建立领域字典、归纳领域术语的同义词、识别出领域中相同和不同的元素。3. 定义领域特定的设计和实现需求的约束：描述解空间中有差别的特性。4. 定义领域模型和架构：产生一般的体系结构，说明构成它们的模块或构件的语法和语义。5. 产生、搜集可复用的产品单元：为DSSA增加可复用的构件。
总结：DSSA 的建立过程是并发的、递归的、反复进行的。该过程的目的是将用户的需求映射为基于实现限制集合的软件需求，这些需求定义了DSSA。
要点3：DSSA的三层次系统模型
-
领域 开发环境：核心通用架构、领域模型、参考需求、参考结构。
-
领域特定的 应用开发环境：根据具体环境把核心架构实例化。
-
应用 执行环境：实现实例化的架构。
要点4：参与DSSA的4种角色
-
领域专家：提供需求规约、实现知识、领域字典、领域模型、DSSA、样本系统。
-
领域分析人员：控制领域分析过程，将获取的知识组织到领域模型中，验证领域模型的准确性和一致性，维护领域模型。
-
领域设计人员：根据领域模型开发出DSSA，建立领域模型和DSSA之间的联系。
-
领域实现人员：开发可重用构件、从现有系统中提取可重用构件，对可重用构件进行验证，建立DSSA与可重用构件之间的联系。 六. 系统架构评估
架构分析是在架构满足功能需求的前提下，为满足质量属性需求寻找适当的架构策略，重点关注软件系统的质量属性，通常采用质量属性场景的方式来精确、定量的描述。
质量属性的定义
质量属性是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者需求的程度。
面向架构评估的质量属性
- 性能
系统的响应能力，用系统完成某个事务处理所需的时间、单位时间内所处理事务的数量来对性能进行定量表示，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。
- 可用性
系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。MTBF = MTTF + MTTR
- 可靠性
系统能够持续无故障运行的能力，在意外或错误使用的情况下，维持软件系统的功能特性的基本能力。可靠性是最重要的软件特性，分为两个方面：
容错：在错误发生时，确保系统正确的行为，并进行内部修复。
健壮性：应用程序不受错误使用和错误输入的影响，在发生意外错误时，确保应用系统处于预先定义好的状态，保证软件按照某种已经定义好的方式终止执行。
- 安全性
系统在向合法用户提供服务的同时，能阻止非授权用户使用的企图或拒绝服务的能力。
机密性：保证信息不泄露给未授权的用户、实体或过程。
完整性：保证信息的完整和准确，防止信息被非法修改。
不可否认性：信息交换的双方不能否认其在交换过程中发送或接收信息的行为。
可控性：保证对信息的传播及内容具有控制的能力，防止为非法者所用。
- 可修改性
能够快速的以较高的性价比对系统进行变更的能力。
可维护性：问题的修复对其它构件的负面影响最小化。
可扩展性：使用新特性来扩展软件系统。
结构重组：重新组织软件系统的构件、构件间的关系，在不影响实现的主体部分的情况下，灵活的配置构件。
可移植性：系统能够在不同计算环境下运行的能力，适用于多种硬件平台、操作系统、用户界面、编程语言或编译器。
- 功能性
系统能完成所期望的工作的能力。
- 可变性
架构经扩充/变更，而成为新架构的能力。
- 互操作性
系统通常与其它系统或自身环境相互作用，必须为外部可视的功能特性和数据结构提供精心设计的软件入口。
质量属性场景描述
质量属性场景（Quality Attribute Scenario）是一个具体的质量属性需求，是利益相关者与系统的交互的简短陈述。
| 场景要素 | 概念 | 情况 |
|---|---|---|
| 1. 刺激源 | 生成刺激的实体 | 最终用户、开发人员、系统管理员 |
| 2. 刺激 | 当刺激到达系统时，需要考虑的条件 | 希望增加、删除、修改、概念功能、质量属性、容量 |
| 3. 环境 | 刺激在某些条件内发生 | 系统设计时、编译时、构建时、运行时 |
| 4. 制品 | 某个制品被激励，被刺激的客体 | 用户界面、平台、与目标系统交互的系统 |
| 5. 响应 | 在激励到达后所采取的行动 | 查找架构中需要修改的位置，进行修改且不影响其他功能，对所做修改进行测试，部署所做的修改 |
| 6. 响应度量 | 当响应发生时，应当能够以某种方式对其进行度量 | 根据所影响元素的数量度量的成本、努力、资金；该修改所造成影响的程度 |
架构评估中的重要概念
敏感点：为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。
架构风险：指架构设计中潜在的、存在问题的架构决策所带来的隐患。
风险点：可能引起风险的因素，可能导致一些问题。
非风险点：如果某件事是可行的、可接受的，则为非风险点。
场景：从风险承担者的角度对系统的交互的简短描述，描述了各种系统必须支持的活动和可能存在的状态变化，一般用刺激、环境、响应三方面来对场景进行描述。
3种类型的场景
用例场景：对系统典型的使用、引出信息，面向最终用户。
增长场景：对系统的修改，代表了架构发展的方式。
探索场景：可能会对系统造成过载的极端修改，架构中极端的增长形式。
系统架构评估
是在对架构分析、评估的基础上，对架构策略的选取进行决策。
利用数学或逻辑分析技术，针对系统的一致性、正确性、质量属性、规划结果等不同方面，提供描述性、预测性和指令性的分析结果。
3类系统架构评估的方法
-
基于问卷调查或检查表
-
基于场景的评估方法：SAAM、ATAM
-
基于度量的评估方法
软件架构分析方法 SAAM
基于场景的架构分析方法 Scenarios-based Architecture Analysis Method
SAAM的基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。是最早形成文档并得到广泛使用的软件架构分析方法，最初用于比较不同软件体系的架构，以分析系统架构的可修改性，后来实践证明也可用于其它非功能质量属性，最终发展成了评估一个系统架构的通用方法。
SAAM的优点
-
有利于评估架构固有的风险。
-
指导对架构的检查，主要关注潜在的问题点。
-
评估架构对于特定系统需求的使用能力。
-
SAAM被用来比较不同的架构。
SAAM的主要输入
-
问题描述
-
需求声明
-
架构描述
SAAM分析评估架构的过程包括5个步骤
- 场景开发
通过各类风险承担者协商讨论，开发一些任务场景，体现系统所支持的各种活动。
- 架构描述
体现系统的计算构件、数据构件以及构件之间的关系（数据和控制）。
- 单个场景评估
对场景生成一个关于特定架构的场景描述列表（直接场景和间接场景）。
4. 场景交互评估
通过对场景交互的分析，得出系统中所有场景对系统中的构件所产生的影响的列表。
5. 总体评估
对场景和场景间的交互作一个总体的权衡和评价。
| **SAAM方法 ** | **ATAM方法 ** | |
|---|---|---|
| ** 定义 ** | 基本特点是把任何形式的质量属性都具体化为场景，但可修改性是SAAM分析的主要质量属性。是最早形成文档并得到广泛使用的软件架构分析方法。 | 主要针对性能、可用性、安全性、可修改性，在系统开发之前，对这些质量属性进行评价和折中。 分析多个相互竞争的质量属性，权衡取舍。 |
| **特定目标 ** | 对描述应用程序属性的文档，验证基本的架构假设和原则。 | 在考虑多个相互影响的质量属性的情况下，确定在多个质量属性之间折中的必要性，提供一种架构策略 |
| **质量属性 ** | 可修改性 | 性能、可用性、安全性、可修改性 |
| **评估技术 ** | 场景技术 | 场景技术 |
| **风险承担者 ** | 不同参与者感兴趣的共同方面 | 所有系统相关人员 |
| ** 架构描述 ** | 用于架构的最后版本，但早于详细设计。 描述架构的3个主要方面：功能、结构、分配 | 基于5种基本结构： 1. 功能结构 2. 代码结构 3. 过程结构 4. 数据结构 5. 部署结构 |
| ** 方法活动 ** | 1. 场景开发 2. 架构描述 3. 单个场景评估 4. 场景交互 5. 总体评估 | 1. 场景和需求收集 |
-
架构视图描述和场景实现
-
属性模型构造和分析
-
对质量属性进行评价和折中 | | ** 领域知识库的可重用性 ** | 不考虑 | 领域知识库通过ABAS维护。 ABAS 基于属性的架构风格。 基于特定质量属性的模型 基于属性的架构分析的标准问题集合 | | ** 方法验证 ** | 空中交通管制、嵌入式音频、修正控制WRCS、根据上下文查找关键词KWIC | 质量属性效用树Utility tree |
2
架构权衡分析法 ATAM
架构权衡分析法 Architecture Tradeoff Analysis Method
目标：以质量属性作为架构评估的核心概念，分析多个相互竞争的质量属性，对这些质量属性进行评价和折中。
4个主要的活动领域（阶段）
-
场景和需求收集
-
架构视图描述 + 场景实现
-
属性模型构造和分析
-
对质量属性进行评价和折中
质量属性效用树 Utility tree
对质量属性进识别和优先级排序。
树的结构：效用(树根) — 质量属性 — 属性分类 — 质量属性场景(叶子节点）
效用树沿着2个维度进行优先级排序：
场景对系统成功的重要性；
场景实现的难易程度。
每个场景有一个优先级对：（重要度，难易度）
例如：（H，L）表示该场景重要且易实现
评估的步骤
一. 描述和介绍阶段
-
介绍ATAM方法
-
描述业务目标
-
描述体系结构
二. 调查和分析阶段
-
确定架构方法
-
生成质量属性效用树
-
分析架构方法
三. 测试阶段
-
讨论场景和对场景分级
-
分析架构方法
四. 报告阶段
- 描述评估结果。
评估步骤详解
一. 描述和介绍阶段
- 介绍ATAM方法
评估小组负责人向所有参与者描述ATAM方法、介绍ATAM的信息、说明评估中使用的分析技术、说明评估的预期结果、解答疑问。
- 描述业务目标
项目决策者从业务角度，提供被评估系统的业务目标、系统功能、利益相关方、系统其它限制的更多信息。
- 描述体系结构
首席架构师演示体系结构、描述要评估的架构、为满足质量属性而实施的架构方法。侧重于体系结构的质量要求、技术约束。
二. 调查和分析阶段
- 确定架构方法
架构设计师确定能达成关键目标的架构方法，解释了架构的流程控制。
- 生成质量属性效用树
场景生成、对质量属性进刻画和优先级排序。
- 分析架构方法
-
评估小组调查架构方法，分析能否满足这些质量属性。
-
创建分析问题，高优先级场景中产生的分析问题。
-
分析问题的答案。
-
确定架构方法的风险、非风险、敏感点、权衡点。
风险点：可能引起风险的因素，可能导致一些问题。
非风险点：如果某件事是可行的、可接受的，则为非风险点。
敏感点：为了实现某种特定的质量属性，一个或多个构件所具有的特性。
权衡点：影响多个质量属性的特性，是多个质量属性的敏感点。
架构风险：指架构设计中潜在的、存在问题的架构决策所带来的隐患。
三. 测试阶段
- 讨论场景和对场景分级
-
利益相关者使用头脑风暴收集场景。
-
相同质量属性有关的所有场景都被合并，利益相关者投票选出各自认为的最重要的场景，票数 = 场景总数 x 30%
-
场景按总票数排序。
-
将头脑风暴请求的优先列表与步骤5中质量属性效用树进行比较。
- 分析架构方法
仍然是4个步，区别在于，步骤6中高优先级质量属性来自效用树，这一步要考虑头脑风暴投票中票数最高的质量属性，可能会新产生一些高优先级的质量属性，检查相应的架构设计方案是否能满足这些质量属性。
-
调查架构方法
-
创建分析问题
-
分析问题的答案
-
确定架构方法的风险、非风险、敏感点、权衡点
四. 报告阶段
- 评估小组负责人描述评估结果，产出具体的报告。
3
成本效益分析法 CBAM
Cost Benefit Analysis Method
对架构设计决策的成本和收益进行建模，根据投资收益率ROI来选择合适的架构。作为ATAM的补充，在ATAM确定满足质量属性的基础上，再对效益进行分析。
八. 架构设计的方法
**
**
架构设计的核心问题：能否达到架构级别的软件重用。
架构设计主要关注软件构件的结构、属性和交互作用。
**
**
**
**
1. 领域驱动 domain-driven
通过面向领域的思维方式，将要解决的业务概念和业务规则等内容提炼为领域知识，然后借由不同的建模范式，将这些领域知识抽象为能够反映真实世界的领域模型，从领域模型导出架构抽象。
领域：业务范围，范围即是边界。
子领域：对领域进行拆解，将其细化为多个子领域。
核心域：直接对业务产生价值，是决定产品核心竞争力的子域。
通用域：通用功能子域，具有通用性，例如：鉴权、登录等。
支撑域：支撑其它领域业务，具有企业特性，间接对业务产生价值。
DDD分层架构
调用关系：接口层 -> 应用层 -> 领域层 -> 基础层
1. 接口层
完成具体用户请求。
包括：controller、远程调用服务。
2. 应用层
对领域层做编排，协调下一层中的领域对象，只负责分配工作，不包含业务规则，尽量简单。
包括：AppService，消息处理。
- 领域层
是系统的核心，封装业务逻辑。
包括：模型、值对象、域服务、事件。
4. 基础设施层
对所有上层提供技术能力。
包括：数据库、事件总线、发送消息、消费消息、API网关、缓存等。
DDD六边形架构
系统通过适配器的方式与外部交互，将应用服务和领域服务封装在系统内部。
2. 工件驱动 attifact-driven
从工件描述中提取架构。
3. 用例驱动 usecase-driven
从用例导出架构抽象。
4. 模式驱动 pattern-driven
从模式导出架构抽象。
5. 属性驱动 attribute-driven
从设计过程中获得架构质量属性需求。
九. 架构模型
1
层次式架构
-
表现层：用户界面，负责视觉和用户互动。
-
业务层（中间层): 实现业务逻辑。
-
数据访问层（持久层): 提供数据，SQL语句就放在这一层。
-
数据层：保存数据。
2
微服务架构
3
云原生架构
云架构的组成
- 处理单元
实现业务逻辑
- 虚拟中间件
负责通信、保持会话控制、数据复制、分布式处理、处理单元的部署。
(1) 消息中间件
管理用户请求和会话控制，当一个请求进来以后，它决定分配给哪一个处理单元。
(2) 数据中间件
将数据复制到每一个处理单元，即数据同步。
(3) 处理中间件
如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元。
(4) 部署中间件
负责出库单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元；负载减少，就关闭处理单元。
4
面向服务架构
5
事件驱动架构
通过事件进行通信的软件架构，分成四个部分：
-
事件队列：接收事件的入口。
-
分发器：将不同的事件分发到不同的业务逻辑单元。
-
事件通道：分发器与处理器之间的联系渠道。
-
事件处理器：实现业务逻辑，处理完成后会发出事件，触发下一步操作。
6
微核架构
又称为插件架构，指软件的内核相对较小，主要功能和业务都能通过插件实现。
内核core通常只包含系统运行的最小功能。
插件是相互独立的，插件之间的通信应该减少到最低，避免出现互相依赖的问题。
