软考 系统架构设计师之回归及知识点回顾（1）

时光荏苒，再续前文。
系统架构设计师系列文章已经有近半年没有更新了。自从去年（2023年）11月4号考完系统架构设计师之后，大概又更新了一段时间，到12月底的时候就转而集中精力攻系统分析师了。由于去年的考试最终遗憾地折在了论文上（差了8分），而系统架构设计师又是一年一次，因此原本计划今年下半年再次开始备战，11月份的时候再次参加系统架构设计师考试。而上半年先备战并参加系统分析师的考试，这才有了近期我的“软考 系统分析师系列”文章。

但是，前天惊悉今年的政策变了，以往一年一次的系统架构设计师和系统分析师考试变为了一年两次，于是决定当前暂停备战系统分析师，转而备战系统架构设计师，之所以这样做是出于以下三点：

（1）系统架构设计师与本人工作最为契合，个人也最为看重系统架构设计师；

（2）去年下半年已经备战了半年、并参加了系统架构设计师的实战考试，惯性还在。这口气也一直憋着；

（3）系统分析师的准备时间还不够充分，更适合下半年参加考试，能够多将近半年的复习时间。

基于以上三点原因，回归到“软考 系统架构设计师系列”文章中来。把去年尚没有完全理解和掌握的知识点进行学习及掌握，把之前已经学习的知识点进行复习和巩固。尤其是对于论文，这次也吸取教训，给予其足够的重视，将其加入到本系列中来。

简单回顾一下之前已经介绍和讲解过的系统架构设计师中的知识点：

1. 软件架构风格

（1）数据流体系结构风格

• 批处理风格
• 管道—过滤器风格

（2）调用/返回体系结构风格

• 主程序/子程序体系结构风格
• 面向对象体系结构风格
• 层次型体系结构风格
• 客户端/服务器体系结构风格

（3）以数据为中心的系结构风格

• 仓库体系结构风格
• 黑板体系结构风格

（4）虚拟机体系结构风格

• 解释器体系结构风格
• 规则系统体系结构风格

（5）独立构件体系结构风格

• 进程通信体系结构风格
• 事件系统体系结构风格

2. 质量属性

软件系统质量属性是一个系统的可测量或者可测试的属性，用来描述系统满足利益相关者需求的程度。基于软件系统的生命周期，可以将软件系统的质量属性分为开发期质量属性和运行期质量属性两个部分。

（1）开发期质量属性

• 易理解性
• 可扩展性
• 可重用性
• 可测试性
• 可维护性
• 可移植性

（2）运行期质量属性

• 性能
• 安全性
• 可伸缩性
• 互操作性
• 可靠性
• 可用性
• 鲁棒性

面向架构评估的质量属性即系统的质量属性包括：

• 性能
• 可靠性（包括容错和健壮性）
• 可用性
• 安全性（包括机密性、完整性、不可否认性、可控性）
• 可修改性（包括可维护性、可扩展性、结构重组、可移植性）
• 功能性
• 可变性
• 互操作性

3. DSSA

DSSA是Domain Specific Software Architecture的简称，中文译为特定领域软件体系结构或特定领域软件架构。

DSSA的必备特征如下：

（1）一个严格定义的问题域和问题解域；

（2）具有普遍性，使其可以用于领域中某个特定应用的开发；

（3）对整个领域的构件组织模型的恰当抽象；

（4）具备该领域固定的、典型的在开发过程中可重用元素。

从功能覆盖范围的角度，有两种理解DSSA中领域的含义的方式。

（1）垂直域

定义了一个特定的系统家族，包含整个系统家族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构。

（2）水平域

定义了在多个系统和多个系统家族中功能区域的共有部分。在子系统级上涵盖多个系统族的特定部分功能。

实施DSSA的过程中的基本活动阶段分为：

（1）领域分析

领域分析阶段的主要目标是获得领域模型。

（2）领域设计

领域设计阶段的主要目标是获得DSSA即特定领域软件体系结构。

（3）领域实现

领域实现阶段的主要目标是依据领域模型和特定领域软件架构（DSSA）开发和组织可重用信息。

参与DSSA的人员可以划分为4种角色：

• 领域专家
• 领域分析人员
• 领域设计人员
• 领域实现人员

DSSA的建立过程分为5个阶段：

• 定义领域范围
• 定义领域特定的元素
• 定义领域特定的设计和实现需求约束
• 定义领域模型和体系结构
• 产生、搜集可重用的产品单元

4. ABSD

ABSD，全称是Architecture-Based Software Design，中文译为基于体系结构的软件设计。ABSD方法是由体系结构驱动的，即指由构成体系结构的商业、质量和功能需求的组合驱动的。

ABSD方法的3个基础：

（1）基础是功能的分解。

（2）通过选择体系结构风格来实现质量和商业需求。

（3）软件模板的使用。

ABSD相关的概念与术语包括：

• 设计元素

ABSD是一个自顶向下、递归细化的方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。

• 视角与视图

考虑体系结构时，要从不同的视角（Perspective）来观察对架构的描述。选择的特定视角或视图（如逻辑视图、进程视图、实现视图和配置视图）可以全方法地考虑体系结构设计。

• 用例和质量场景

用例已经成为推测系统在一个具体设置中的行为的重要技术。用例被用在很多不同的场合，用例是系统的一个给予用户一个结果值的功能点，用例用来捕获功能需求。

在使用用例捕获功能需求的同时，人们通过定义特定场景来捕获质量需求，并称这些场景为质量场景。

ABSD模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化6个子过程。

（1）体系结构需求

1）需求获取

2）标识构件

a. 生成类图；

b. 对类进行分组；

c. 将类打包成构件。

3）架构需求评审

（2）体系结构设计

1）提出软件体系结构模型

2）将已标识的构件映射到软件体系结构中

3）分析构件之间的相互作用

4）产生软件体系结构

5）设计评审

（3）体系结构文档化

体系结构文档化过程的主要输出结果是两个文档：体系结构规格说明和测试体系结构需求的质量设计说明书。

（4）体系结构复审

体系结构设计、文档化、复审是一个迭代过程。复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误。

（5）体系结构实现

体系结构的整个实现过程是以复审后的文档化的体系结构说明书为基础的，每个构件必须满足软件体系结构说明书的对其它构件的责任。

（6）体系结构演化

体系结构演化是使用系统演化步骤去修改应用，以满足新的需求。主要包括以下6个步骤：

1）需求变化归类；

2）制订体系结构演化计划；

3）修改、增加或删除构件；

4）更新构件的相互作用；

5）构件组装与测试；

6）技术评审。

余下的知识点回顾请看下回：

5. 软件构件

6. 设计模式

7. 净室软件工程

8. 架构评估

9. 数字孪生体

10. 边缘计算

11. 云计算

12. 大数据