系统架构设计

软考系统架构设计

【新版】软考 - 系统架构设计师（总结笔记）
https://blog.csdn.net/weixin_30197685/article/details/132797803

架构 = 体系结构 = Architecture

---

2 计算机系统基础

操作系统的特征：

• 并发性
• 共享性
• 虚拟性
• 不确定性

文件存储空间管理
1、空闲表法

2.8 系统工程

系统工程方法：
1、霍尔三维结构：

• 时间维：开始到结束的过程
• 逻辑维：每个时间阶段的工作内容
• 知识维：专业知识

2、切克兰德方法：社会经济问题，核心不是最优化而是比较与探寻
3、并行工程方法：从设计阶段就考虑产品全生命周期
4、综合集成法：钱学森，开放复杂巨系统，从定性到定量的综合集成法
5、WSR系统方法：物理、事理、人理。懂物理，明事理，通人理

---

3 信息系统基础

---

4 信息安全基础

对称加密

加密秘钥和解密秘钥是相同的，又叫共享密钥算法

• DES：56位秘钥
• 3DES：三重DES，秘钥112位
• IDEA：128位秘钥
• AES：支持128位、192位和256位3种秘钥长度，用于代替DES
• RC-5
• SM1：国密1，强度与AES相当，128位密钥，算法不公开，仅以IP核的形式存在于芯片中。智能IC卡、智能密码钥匙、加密卡、加密机。。
• SM4：国密4，128位密钥，强度与AES相当

非对称加密

加密秘钥和解密秘钥不同，公钥加密，私钥解密。速度慢

• RSA：基于大素数分解困难性
• SM2：国密2，基于ECC椭圆加密算法，相比RSA速度快安全性高，用于替换RSA

信息摘要与签名

摘要算法：

• MD5
• SHA-1
• SHA-256
• SM3：国密3，256位消息摘要算法，相当于SHA-256

数字签名：使用发送者A的私钥对摘要进行加密，接受者用A的公钥解密后得到摘要。（自己签名肯定要用自己的私钥，不然谁都能签了）
非对称加密：公钥加密，私钥解密。

安全保护等级

《计算机系统安全保护等级划分准则》GB 17859-1999 计算机系统安全保护能力的5个等级：

• 第1级：用户自主保护级。隔离用户和数据，访问控制
• 第2级：系统审计保护级。粒度更细的访问控制。登录规程、安全审计
• 第3级：安全标记保护级。安全策略模型。
• 第4级：结构化保护级。访问控制扩展到所有主题和客体。考虑隐蔽通道。
• 第5级：访问验证保护级。满足访问监控需求。

---

5 软件工程基础

---

5.1 软件工程

5.1.2 软件过程模型

软件工程过程(PDCA)
软件工程过程是指为获得软件产品包括以下4个方面活动（PDCA）：

• Plan 软件规格说明
• Do 软件开发
• Check 软件确认
• Action 软件演进

瀑布模型(Waterfall)-需求明确

瀑布模型包含一系列活动，这些活动从一个阶段到另一个阶段逐次进行，前一阶段的输出结果作为后一阶段工作的输入，每个阶段都建立在前一阶段正确实施的基础之上。不回头。

瀑布模型的缺点：
1、软件需求难确定。瀑布模型试图对每个软件阶段都做详细计划和完整实施，无法拥抱需求变化。
2、严格的串行化过程，变更成本大
3、每个阶段一次性完整的解决该阶段的问题很难实现。

---

原型模型(Prototype)-需求不明确

原型模型又叫快速原型，包含2个阶段：

• 原型开发阶段。快速开发一个原型，展示系统部分功能、性能。
• 目标软件开发阶段。原型确认后，对实际系统的开发。

根据原型作用不同分为：

• 抛弃型原型：原型只作为需求确认手段，需求确认后抛弃不用。
• 演化性原型：需求确认后对原型不断补充和完善，直至形成一个完整的产品。

---

螺旋模型(Spiral)-风险

将整个软件开发流程分为多个阶段，每个阶段由4部分组成：

• 目标设定
• 风险分析，螺旋模型的核心关键词
• 开发和有效性验证
• 评审。评审是否进入下一螺旋回路。

4部分不断迭代，每迭代一次，螺旋线增加一圈，软件产生一个新版本，对目标也更加逼近。

---

V模型-测试

V模型，以测试为中心的开发模型。
V模型是最具有代表意义的测试模型，它是瀑布模型的变种，它在瀑布模型的基础上加强了测试，反映了测试活动与分析和设计的关系。

• 单元测试 - 编码过程
• 集成测试 - 详细设计
• 系统测试 - 概要设计
• 验收测试 - 需求分析

清楚的描述了测试阶段和开发过程期间各阶段的对应关系
局限性：仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试

V模型

---

W模型-测试

对 V 模的改进，将 V 模型演变为 W 模型，也叫双 V 模型，一个 V 是开发的生命同期，另一个 V 是测试的生命周期
W 模型强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试
W 模型有利于尽早全面地发现问题。从需求分析开始测试工程师就参与到项目的测试中

W模型

---

喷泉模型-面向对象

喷泉模型(Fountain model)，是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程

喷泉模型认为软件开发过程的各个阶段是相互重叠和多次反复的，功能模块不是一次完成，而是像喷泉，水喷上去又可以落下来，既可以落在中间，又可以落到底部。各个开发阶段没有特定的次序要求，完全可以并行进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏的需求。

---

增量模型

增量模型(Incremental Model)把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。
增量模型融合了瀑布模型的基本成分和原型实现的迭代特征

增量模型

---

快速应用开发(RAD)-构件

RAD（Rapid Application Development，快速应用开发），是由瀑布模型演变而来的，是一个增量型的软件开发过程模型，强调极短的开发周期。RAD模型是瀑布模型的一个“高速”变种，通过大量使用可复用构件，采用基于构件的建造方法赢得快速开发。

---

5.1.3 敏捷模型(Agile)

核心思想：

• 敏捷方法是适应性的，而非预设性的。
• 敏捷方法是面向人的，而非面向过程的。
• 迭代增量式的开发过程，发行版本小型化。

主要敏捷方法：

• 极限编程，近螺旋式，测试先行。
• 水晶系列方法，以人为中心。
• Scrum，按优先级排列需求列表（backlog），每个迭代周期（Sprint）交付部分高优需求，不断增量迭代。
• 特征驱动开发方法(Feature Driven Development, FDD)，确定 feature 并迭代。

---

5.1.4 统一过程模型(RUP)

统一过程模型（Rational Unified Process, RUP），由 Rational 公司（现被IBM公司收购）开发的一种软件工程过程框架。
重量级过程（敏捷是轻量级的）

RUP 中的软件生命周期在时间上被分解为四个顺序的阶段（Phase）：

• 初始阶段（Inception），确定系统范围
• 细化阶段（Elaboration），确定系统体系结构
• 构造阶段（Construction），开发测试
• 交付阶段（Transition）

每个阶段结束于一个主要的里程碑(Major Milestones)，并在阶段结尾执行一次评估以确定这个阶段的目标是否已经满足

特点：

• 用例驱动
• 以体系结构为中心

UML 4+1 视图模型

4+1 视图模型来描述体系结构：

• 逻辑视图（Logical View），关注功能，最终用户
• 实现视图（Implementation View），程序员
• 进程视图（Process View），系统集成人员
• 部署视图（Deployment View），系统工程师
• 用例视图（Use Case View），系统的行为和功能，用来描述需求

---

5.1.5 软件能力成熟度模型(CMM/CMMI)

软件能力成熟度模型（Capability Maturity Model for Software, CMM），衡量公司或组织的软件过程成熟度级别。

• 初始级(Initial)，软件过程杂乱无章，完全依赖个人努力和英雄式核心人物。不可复制、混乱。
• 可重复级(Repeatable)，基本的项目管理过程和实践，有必要的过程准则可重复成功。
• 已定义级(Defined)，软件过程已文档化、标准化，标准软件过程。不仅有标准，还能定量度量。
• 已管理级(Managed)，软件过程和质量的定量的详细度量标准
• 优化级(Optimized)，不断持续的改进

能力成熟度模型集成(CMMI)，若干过程模型的综合与改进，多个工程学科和领域的过程改进框架。
5个成熟度等级：

• Level 1 初始级，软件过程杂乱无章，完全依赖个人努力和英雄式核心人物。不可复制、混乱。
• Level 2 已管理级，过程为项目服务
• Level 3 已定义级，标准流程，过程为组织服务
• Level 4 量化管理级，定量指标
• Level 5 优化级，专注于过程改进和优化

---

5.2 需求工程

软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。

需求的3个层次（分类）：

• 业务需求：业务需求是指反映企业或客户对系统高层次的目标要求。抽象层次最高
• 用户需求：用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。用户能使用系统来做什么
• 系统需求：系统需求是从系统的角度来说明软件的需求，包括：（1）功能需求（开发人员必须实现的软件功能）（2）非功能需求（软件质量属性等）（3）设计约束（外部限制条件、补充规约，例如必须使用国产数据库）。

需求工程（Requirement Engineering，RE） 是指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。

需求工程的活动包括5个阶段：

• 需求获取
• 需求分析
• 形成需求规格（需求文档化），输出 软件需求规格说明书（Software Requirement Specification，SRS）
• 需求确认与验证，形成 需求基线Baseline（经过评审的SRS）
• 需求管理：需求文档追踪管理、变更控制、版本控制

其中，需求获取、需求分析、形成需求规格、需求确认与验证4个步骤又叫做需求开发

5.2.1 需求获取

需求获取方法：

• 用户面谈：1对1-3，有代表性的用户。形式包括结构化（提前准备好问题）和非结构化两种
• 需求专题讨论会：联合需求计划(JRP)，高度组织的群体会议，各方参与，了解想法，消除分歧，交互好，成本高。
• 问卷调查：针对用户多，无法一一访谈。成本低，但不精准。
• 现场观察：观察用户实际执行业务的过程，针对较为复杂的流程和操作。
• 原型化方法：开发系统原型
• 头脑风暴法：新业务，高度不确定性，发散思维

其他需求获取方法：

• 抽样调查/采样：基于数理统计，降低成本，快速获取。样本大小=0.25*(可信度系数/可接受的错误率):
• 情节串联板(原型法)：一系列图片，通过这些图片来讲故事。
• 收集资料：把与系统有关的、对系统开发有益的信息收集起来。
• 阅读历史文档：对收集数据性的信息较为有用。
• 参加业务实践：有效地发现问题的本质和寻找解决问题的办法。

---

5.2.2 需求变更

需求变更管理过程：

• 问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
• 变更分析和成本计算。对需求变更提议进行影响分析和评估。
• 变更实现

5.2.3 需求追踪

需求双向跟踪：

• 正向跟踪：检查SRS中的每个需求是否都能在后继工作成果中找到对应点。原始需求是否都实现了？有没有少实现
• 逆向跟踪：是指检查设计文档、代码、测试用例等工作成果是否都能在SRS中找到出处。软件实现是否都是需求里的？有没有多实现

---

5.3 系统分析与设计

需求分析：一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

5.3.1 结构化方法(面向过程)

结构化分析方法

• 结构化分析
• 结构化设计
• 结构化编程

自顶向下、逐步分解、面向数据

分析方法（三大模型）：

• 功能模型（数据流图DFD）
• 行为模型（状态转换图）
• 数据模型（ER图）+ 数据字典

数据流图(DFD)与数据字典

结构化分析的常用手段是数据流图（DFD）和数据字典

数据流图（Data Flow Diagram, DFD），4种基本元素：

• 数据流：箭头，箭头上标出信息说明或数据项
• 处理（加工）：矩形框
• 数据存储：双横线、半连接双横线（形似左方括号⊏）。数据库或文件存储。指向箭头表示存，离开箭头表示取。
• 外部项：数据源（输入）或数据终点（输出）。圆角框、平行四边形

数据字典（Data Dictionary）：对数据流图DFD里出现的每个元素都加以定义，给出详细说明。包括：数据项、数据结构、数据流、数据存储、处理过程

内聚与耦合

耦合：耦合表示模块之间联系的程度

• 非直接耦合：没有直接联系。最低耦合。
• 数据耦合：模块间参数传递简单数据
• 标记耦合：模块间参数传递复杂数据（数据结构）
• 控制耦合：模块间传递控制内部逻辑的信息
• 通信耦合：共享输入输出
• 公共耦合：多模块访问公共数据
• 内容耦合：直接访问另一模块内部数据

内聚：内聚表示模块内部各代码成分之间联系的紧密程度。

• 功能内聚：完成单一功能。最高内聚
• 顺序内聚：顺序执行
• 通信内聚：所有处理元素集中在一个数据结构的区域上
• 过程内聚：按特定次序执行
• 时间内聚：在同一时间间隔内执行
• 逻辑内聚：完成逻辑上相关的一组任务
• 偶然内聚：无关的任务

流程图工具

程序流程图（Program Flow Diagram, PFD）：任何复杂的程序流程都应该由顺序、选择和循环结构组合或嵌套而成。

IPO 图（Input Process Output）：描述每个模块的输入、输出和数据加工，DFD 也是一种 IPO 图。

NS 图（盒图）：结构化特征，表示嵌套和层次，不适合复杂程序设计。

PAD 问题分析图（Problem Analysis Diagram，PAD）：结构化程序设计，取代流程图。

ER图

实体关系图（Entity-Relationship，ER图）：

• 矩形框：实体，框内写实体名称
• 菱形框：关系，框内写关系名，无向边与实体相连，无向边上标明关系类型（1:1, 1:n, m:n）
• 椭圆形框：实体或关系的属性。主属性下画一条线。

5.3.2 面向对象分析方法

面向对象设计（Object Oriented Design，OOD），类分为3种类型：

• 实体类：映射需求中的实体，需要永久存储。
• 控制类：控制用例工作，动宾或主谓转化来的名字（创建用户->创建用户类，身份验证->身份验证器）
• 边界类：封装信息或数据流，窗口、对话框

UML类图

统一建模语言（UML）

类：类、属性、方法
关系：

• 依赖：虚线实心箭头
• 关联：实现无箭头。组合（实线实心菱形）/聚合（实现空心菱形）
• 泛化：一般-特殊，子类-父类。子类->指向父类，实线空心箭头
• 实现：虚线空心箭头

系统设计

系统设计的主要内容包括概要设计和详细设计：

• 概要设计：又称为系统总体结构设计，将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图
• 详细设计：模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计（代码、输入输出格式、用户界面），编写详细设计说明书。

人机界面设计

人机界面设计三大黄金原则：

• 置于用户控制之下
• 减少用户的记忆负担
• 保持界面的一致性

---

5.4 软件测试

按程序执行状态分为：

• 静态测试：不运行被测程序，人工检测、计算机辅助静态分析。包括：桌前检查、代码审查、代码走查。
• 动态测试：运行被测试程序。

按是否考虑实现细节分为：

• 黑盒：功能性测试
• 白盒：结构性测试。检查每条逻辑通路是否正常工作。常用方法：控制流分析、数据流分析、路径分析、程序变异。覆盖程度：语句覆盖、判定覆盖（判断语句的真假分支都覆盖）、分支覆盖、路径覆盖。
• 灰盒：介于白盒黑盒之间。

测试阶段：

• 单元测试：测试单个模块，测试依据是详细设计文档。
• 集成测试：测试模块之间，测试依据是概要设计文档。
• 系统测试：在验收测试之前
• 性能测试：负载测试（测试随负载增加系统性能的变化）、压力测试（测试出系统的最大瓶颈）。
• 验收测试（确认测试）：是否满足用户需求，测试依据是需求规格说明书SRS。Alpha测试：用户在软件开发环境下测试。Beta测试：用户在实际环境中测试。
• 其他测试：AB测试、Web测试、链接测试、表单测试

测试用例设计：

• 等价类划分：按某种特性归类，每类里选取一个。有效等价类（成绩0-100分间）、无效等价类（小于0或大于100）。设计原则：依次覆盖全部有效等价类、每次仅覆盖一个无效等价类（一次覆盖多个无效等价类时不知道具体是哪个条件导致不满足）。
• 边界值划分：成绩：-1,0,100,101

测试是发现错误，调试是找出错误的代码和原因。

McCabe 度量法：又称为环路复杂度，假设有向图中有向边数为m，节点数为n，则此有向图的环路复杂度为m-n+2。

---

5.5 净室软件工程

净室（Cleaning Room）软件工程是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。

理论基础是函数理论和抽样理论。

技术手段：

• 统计过程控制下的增量式开发
• 基于函数的规范与设计
• 正确性验证
• 统计测试和软件认证

---

5.6 基于构件的软件工程

基于构件的软件工程（Component-Based Software Engineering，CBSE），基于分布对象技术、可复用构件，基于已有的构件组装/集成。

面向过程（结构化开发） -> 面向对象 -> 面向构件 -> 面向服务，粒度逐渐增大，耦合逐渐松散，接口更加标准

构件应该具备的特征：

• 可组装性：所有外部交互必须通过公开定义的接口进行。
• 可部署性：可独立部署运行
• 文档化：用户根据文档来判断构件是否满足需求。
• 独立性：可以在无其他特殊构件的情况下进行组装和部署。
• 标准化：符合某种标准化的构件模型。

构件的组装顺序：

• 顺序组装
• 层次组装：一个构件直接调用另一构件的服务
• 叠加组装：两个以上构件

---

6 数据库设计基础

三层抽象层级（三级模式）：

• 视图层：面向用户
• 逻辑层：数据及关系
• 物理层：底层存储

从数据库管理系统的角度，数据库也分为为外模式、概念模式和内模式。

完整性约束条件包括：

• 实体完整性：必须有主键
• 参照完整性：外键
• 用户定义完整性

连接：

• 等值连接：笛卡尔积中属性值相等的元组
• 自然连接：一种特殊的等值连接，它要求比较属性列必须相同的属性组，并且把结果中重复属性去掉

函数依赖：X -> Y, X函数决定Y 或 Y函数依赖于X

范式：

• 1NF：属性值都是不可再分的原子值
• 2NF：满足1NF，表中的字段必须完全依赖于全部主键而非部分主键
• 3NF：满足2NF，非主键外的所有字段必须互不依赖
• BCNF：巴克斯范式，

不规范化带来的问题：

• 数据冗余存储：重复存储列值
• 修改异常：一些修改了，另一些未修改
• 插入异常：空值列影响其他列无法插入
• 删除异常：删了不该删的数据

数据库设计步骤：

• 用户需求分析
• 概念结构设计：ER图
• 逻辑结构设计：ER图转关系模式，约束，反规范化（冗余列、派生列（其他列计算结果）、表重组（多表合并为1个表）、表分割）
• 物理结构设计：存储引擎选择（哈希/B+树），索引设计
• 数据库实施阶段：转换为DDL
• 数据库运行维护：性能检测，优化，备份，故障恢复

---

7 系统架构设计

7.2 基于架构的软件开发(ABSD)

基于架构的软件开发（Architecture-Based Software Develop，ABSD），由架构驱动，强调由业务、质量和功能需求的组合驱动架构设计
强调采用 视角和视图（4+1视图） 来 描述软件架构，采用 用例（功能需求）和 质量属性场景（质量需求）来描述需求

ABSD 方法的三个基础：

• 功能的分解
• 通过选择架构风格来实现质量和业务需求
• 软件模板的使用

ABSD 的六个步骤：

• 架构需求：标识构件：生成类图、对类进行分组、把类打包成构件
• 架构设计：选择架构风格，映射构件、分析构件之间的相互作用
• 体系结构文档化：产出体系结构规格说明、测试体系结构需求的质量设计说明书
• 架构复审：外部人员参加的复审，复审的目的是标识潜在的风险、提前发现缺陷和错误
• 架构实现：用实体来显示架构，实现构件，构件组装成系统
• 架构演化：构件/构件相互作用的增删改

---

7.3 软件架构风格⭐️

软件架构风格是描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。
架构风格定义了一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。

数据流风格

面向数据流，按一定顺序从前往后执行

• 批处理风格，第1步执行完后第2步才能开始。构件：计算单元。连接件：数据传递。
• 管道-过滤器风格，前一构件的输出作为后一构件的输入。构件：过滤器。连接件：管道。（例如传统编译器，一步一步处理）不适合交互性强的应用。

区别：
1、批处理必须第1步执行完后第2步才能开始，必须整体传递。管道过滤器可以第1步执行过程中第2步就开始（例如边下边播）。
2、批处理前后构件不一定有关联，管道过滤器前一输出作为后一输入

调用/返回风格

构件之间存在互相调用关系，一般是显式的调用

• 主程序/子程序，把问题划分为多个子步骤，主程序中调用子步骤完成。构件：子程序。连接件：过程调用。
• 面向对象，构件：对象。连接件：对象间交互方式。
• 层次结构，上层调用下层提供的服务。构件：层次。连接件：层间调用（例如OSI 7层网络模型）
• 客户端/服务器，CS架构，构件：服务器、客户端、网络。

独立构件风格

构件之间互相独立，不存在显式的调用关系，通过事件触发、异步的方式执行

• 进程通信，构件：进程。连接件：消息传递。
• 事件驱动（隐式调用），触发或广播一个或多个事件，其他模块注册对事件的监听，事件发生时自动调用这些模块。构件：过程。连接件：事件（例如中断程序（终端源触发事件）、语法高亮、语法错误提示、debug断点事件）

虚拟机风格

• 解释器，构件：解释引擎、代码存储区、状态记录数据、执行进度记录数据。自定义规则，解释引擎按规则执行。例如jvm，效率低。（灵活自定义规则）
• 规则系统，人工智能、机器人、专家系统、dss决策系统

以数据为中心的风格/仓库风格

仓库风格，也叫数据共享风格

• 数据库系统，构件：中央共享数据源、独立处理单元。
• 黑板系统。构件：知识源、黑板、控制。黑板是一个全局数据库。（语音识别、知识推理）
• 超文本系统，构件以网状链接方式相互连接。（互联网领域）

集成开发环境IDE -> 数据存储风格，以数据为中心

---

闭环控制风格

闭环反馈

例如：

• 例如空调系统，设定温度后，高了放冷风，低了放热风。
• 汽车定速巡航。设定速度，速度低了、反馈、加速；速度高了、反馈、减速。

C2风格

C2 风格通过连接件连接构件或某个构件组，构件与构件之间无连接。

构件和连接件都有一个顶部和一个底部。
构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。

---

7.4 软件架构复用

软件产品线概念，产品家族，以一种规范的、策略性的方法复用资产。

软件架构复用类型：

• 机会复用：随机复用
• 系统复用：提前规划好

软件架构复用的基本过程

• 复用的前提：构建/获取可复用的软件资产
• 管理可复用资产：加入构件库
• 使用可复用资产

---

7.5 特定领域软件架构(DSSA)

DSSA（Domain Specific Software Architecture）特定领域软件架构

DSSA 的基本活动：

• 领域分析：获得领域模型（领域需求）
• 领域设计：获得 DSSA
• 领域实现

参与 DSSA 的人员：

• 领域专家：该领域有经验的用户、有经验的软件工程师。
• 领域分析人员
• 领域设计人员
• 领域实现人员

---

8 系统质量属性与架构评估

8.1 软件质量属性

软件质量属性分为：
1、开发期质量属性：

• 易理解性 指设计开发人员理解的难易程度。
• 可扩展性 软件因适应新需求变化而增加新功能的能力，也称为灵活性。
• 可重用性 指重用软件系统或某一部分的难易程度。
• 可测试性 当软件测试以证明其满足需求规范的难易程度。
• 可维护性 当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
• 可移植性 将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

2、运行期质量属性：

• 性能 软件系统及时提供相应的服务能力，如速度、吞吐量和容量等。
• 安全性 软件系统同时兼顾向合法用户提供服务，以及组织非授权使用的能力 。
• 可伸缩性 当用户数和数据量增加时，软件系统维持高服务质量的能力。
• 互操作性 软件系统与其他系统交换数据和相互调用服务的难易程度。
• 可靠性 软件系统在一定时间内持续无故障运行的能力。
• 可用性 系统在一定时间内正常工作的时间所占比例。
• 鲁棒性 软件系统在非正常情况（用户进行非法操作、相关软硬件系统发生故障）下仍正常运行的能力，也称健壮性或容错性。

---

8.1.2 面向架构评估的质量属性⭐️

软件架构评估的质量属性包括

性能(Performance)

性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

• 响应时间，比如用户要求页面打开时间小于1秒
• 吞吐量，比如要求1秒内完成10个事件处理

设计策略：

• 优先级调度
• 增加计算资源
• 减少计算开销
• 引入并发机制
• 采用资源调度

可靠性(Reliablity)

在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。
包括：

• 容错，错误发生时保持系统正确的行为
• 健壮性，保护系统不受错误使用和错误输入的影响

可用性(Availability)

可用性（availability）是系统能够正常运行的时间比例。

可靠性 和 可用性几乎相同，指标和设计策略也都一样，架构评估时主要使用可用性描述

衡量指标

• 平均失效等待时间(Mean Time To Failure, MTTF)，平均无故障时间，指系统无故障运行的平均时间
• 平均失效间隔时间(Mean Time Between Failure, MTBF)，平均故障间隔时间
• 平均修复时间(Mean Time To Repair, MTTR)，平均故障修复时间

设计策略：

• 心跳
• Ping/Echo
• 冗余，备份
• 选举

安全性(Security)

安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。
安全性又可划分为机密性、完整性、不可否认性及可控性等特性。

设计策略：

• 加密
• 数字签名
• 入侵检测
• 防火墙
• 用户认证授权
• 追踪审计

可修改性(Modifiability)

可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。

可修改性分为四个子属性：

• 可维护性(Maintainability)：可做局部修改，对其他构件的负面影响最小化。
• 可扩展性(Extendibility)：松散耦合，更易实现新特性/功能，不影响架构。
• 结构重组(Reassemble)：不影响主体进行的灵活配置。
• 可移植性(Portability)：适用于多样的环境（硬件平台、语言、操作系统等）。

指标：

• 以小于20人月的工作量添加 xx 中间件
• 以小于4人周的工作量更改web界面
• 以小于5人天的工作量新增一个算法支持

设计策略：

• 接口-实现分离
• 高内聚、低耦合
• 抽象
• 信息隐藏

功能性(Functionality)

系统能完成所期望的工作的能力。

可变性(Changeability)

架构经扩充或变更而成为新架构的能力

互操作性

为外部提供可视化操作或接口，方便其他系统操作

用户界面方便用户操作。

其他

1、易用性：易用性关注的是对用户来说完成某个期望任务的容易程度
方便用户使用
界面友好
新用户学习使用系统时间不超过2小时

2、可测试性：软件可测试性是指通过测试揭示软件缺陷的容易程度
提供远程调试接口，支持远程调试

---

8.1.3 质量属性场景描述

质量属性场景是一种面向特定质量属性的需求，包括6部分：

• 刺激源(Source)：生成刺激的实体（人、计算机系统或者任何其他刺激器）
• 刺激(Stimulus)：要进行的操作，即输入
• 环境(Environment)：设计时、编译时、构建时、运行时
• 制品(Artifact)：被刺激的客体，用户界面、平台或系统的一部分
• 响应(Response)：刺激到达后所采取的行动，即输出
• 响应度量(Measurement)：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试

---

8.2 系统架构评估

三类系统架构评估方法：

• 基于调查问卷（检查表）的方式：挨个列出8种质量属性，符合打对钩
• 基于度量的方式：定量指标，比如衡量代码行数，客观
• 基于场景的方式：设计评估质量属性的场景，ATAM、SAAM

8.2.1 系统架构评估中的重要概念⭐️

架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患

系统架构评估中的重要概念：

• 敏感点(Sensitivity Point) ：为了实现某种特定的质量属性，一个或多个构件的特性
• 权衡点(Tradeoff Point) ：是影响多个质量属性的特性，是多个质量属性的敏感点
• 风险点(Risk Point) ：架构设计中潜在的、可能引起风险的因素。某个做法有隐患，有可能导致一些问题，则为风险点
• 非风险点(Non-Risk Point) ：某件事是可行的、可接受的、可实现的，则为非风险点。
• 风险承担者或者相关利益人：影响架构或被架构影响的群体。
• 场景(Scenarios)：一般采用刺激(Stimulus)、环境(Environment)和响应(Response)三方面来对场景进行描述。

---

8.2.2 基于场景的系统架构评估方法

软件架构分析法(SAAM)

软件架构分析法（SAAM，Software Architecture Analysis Method），最初用于分析架构可修改性，后扩展到其它质量属性

SAAM 的输入：问题描述、需求说明、架构描述
SAAM 的评估过程：场景开发、架构描述、单个场景评估、场景交互评估、总体评估

架构权衡分析法(ATAM)

架构权衡分析法（ATAM，Architecture Tradeoff Analysis Method），是在 SAAM 上发展而来，ATAM 强调以质量属性作为架构评估的核心概念，主要针对性能、可用性、安全性和可修改性，在系统开发之前，对这些质量属性进行评价和折中。

4个主要的活动领域（阶段）：

• 场景和需求收集
• 架构视图和场景实现
• 属性模型构造和分析
• 架构决策与折中

质量属性效用树⭐️

ATAM 方法采用效用树(Utility tree)这一工具来对质量属性进行分类和优先级排序。效用树的结构包括：树根一质量属性一属性分类一质量属性场景（叶子节点）。需要注意的是，ATAM 主要关注4类质量属性：性能、安全性、可修改性和可用性，这是因为这4个质量属性是利益相关者最为关心的。

成本效益分析法(CBAM)

成本效益分析法（CBAM，the Cost Benefit Analysis Method），从成本的角度评估，根据投资收益率来选择合适的架构，是对 ATAM 的补充，在 ATAM 评估结束后开始。

ROI(Return On Investment) 投资回报率

---

8.3 ATAM 方法架构评估实践(论文)

8.3.1 阶段1-描述和介绍阶段

1、描述 ATAM 评估方法，就是评估规则（评估小组负责人，向全部项目干系人描述评估规则）
2、描述业务动机，也就是需求（项目决策者，从业务角度）
3、描述架构（架构师）
画出架构图

8.3.2 阶段2-调查和分析阶段

1、确定架构方法（架构师）
用一大段文字描述系统流程

2、生成质量属性效用树（评估小组、设计小组、管理人员、客户代表）
列出场景，利益相关者：从用户角度，从架构师角度，开发者角度，每个对应的质量属性
画出效用树：性能、可用性、安全性和可修改性

3、分析架构方法（评估小组）
（1）针对 性能、可用性、安全性和可修改性 4个属性，挨个详细介绍，也可以加其他属性
（2）提出几个问题，也是针对质量属性的问题
（3）回答问题
（4）列出风险点、敏感点、权衡点

8.3.3 阶段3-测试阶段

1、讨论场景和对场景分级（项目干系人，投票设计场景）
列出场景，对应的质量属性，投票数，优先级

2、分析架构方法（架构师，基于场景分析）

8.3.4 阶段4-报告阶段

描述评估结果，产生报告（评估小组负责人）

---

9 软件可靠性基础

软件可靠性（Software Reliability）是软件产品在规定的条件下和规定的时间区间完成规定功能的能力。

---

12 信息系统架构设计理论与实践

单机应用模式

单机应用（Standalone），一台物理机上的独立应用程序

CS/BS模式

• 两层C/S架构：（胖客户端）前台客户端+后台数据库服务。前台界面和业务逻辑处理合并在一起。已经不常用。
• 三层C/S架构：（瘦客户端）表示层（客户机）、功能层（服务器）、数据层（数据库）
• 三层B/S架构：（三层C/S架构模式的一种）浏览器（表示层）、web服务器（功能层）、数据库

---

13 层次架构设计理论与实践

软件架构是软件系统 结构、行为和属性 的高级抽象，由构成系统的元素描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。

分层式体系结构是一种最常见的架构设计方法，能有效地使设计简化，结构清晰，便于提高复用能力和产品维护能力。层次式体系结构设计是将系统组成一个层次结构，每一层为上层服务，并作为下层的客户。层间接口只对相邻层可见，允许每层用不同的方式实现。

分层架构本身没有规定要分为多少层，大部分应用会划分为 表现层（展示层）、中间层（业务层）、数据访问层（持久层）、数据层
分层架构的一个特性就是关注 分离

注意：

• 污水池反模式：层很薄，无业务逻辑，只是简单调用下层接口。此类请求占超20%，可以考虑开放、合并。
• 规模膨胀：分层带来应用规模膨胀。

13.2 表现层(MVC/MVP/MVVM)

表现层
1、MVC 模式
主要用在 Java EE Web 应用中

• 模型（Model）：业务数据和业务逻辑。一个模型可为多个视图提供数据，提高可重用性。
• 视图（View）：用户交互界面。接收用户的输入，向用户展示数据。但无业务处理逻辑。
• 控制器（Controller）：连接视图和模型，接收用户输入转换为模型调用，处理模型事件转为视图展示

优势：

• 允许多种用户界面扩展，模型层不需要改动。
• 易于维护。
• 功能强大的用户界面

2、MVP模式
MVP(Model-View-Presenter) 模式，主要用在 Android 应用中，和 MVC 的区别：

• MVP：View 和 Model 不允许直接交互，必须通过 Presenter 进行。避免 View 和 Model 层的耦合。
• MVC：View 直接从 Model 中读取数据而不经过 Controller 层。

3、MVVM模式
MVVM(Model-View-ViewModel)，为了 View 和 Mode 的分离，View 和 Mode 的交互通过 ViewModel 实现，ViewModel 是 MVVM 的核心，通过 DataBinding 实现 View 与 Model 之间的双向绑定

13.3 中间层

业务逻辑框架位于系统架构的中间层，是实现系统功能的核心组件。逻辑层实体提供对业务数据及相关功能（在某些设计中）的状态编程访问。

13.4 数据访问层

5种数据访问模式：

• 在线访问
• Data Access Object(DAO模式)：J2EE 标准设计模式，包括：（1）DAO工厂类（2）DAO接口（3）DAO实现类（4）数据传输对象
• Data Transfer Object：EJB经典设计模式
• 离线数据模式
• 对象/关系映射（Object Relation Mapping，ORM）：Hibernate

---

14 云原生架构设计理论与实践

云原生(Cloud Native)，Cloud 指应用软件是在云端而非传统的数据中心，Native 指应用软件从一开始就是基于云环境、专门为云端特性而设计。
DevOps，开发、技术运营和质量保障三者的交集，促进之间的沟通、协作与整合，云原生的容器、微服务等技术为 DevOps 提供了绝佳的前提条件。

云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化地剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

云原生架构原则

• 服务化原则：拆分为微服务、小服务架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代。
• 弹性原则：弹性是指系统的部署规模可以随着业务量的变化而自动伸缩，无需事先根据容量规划准备固定的软硬件资源
• 可观测原则：通过日志、链路跟踪和度量等手段，使得多次服务调用的耗时、返回值和参数都清晰可见。
• 韧性原则：软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，提高MTBF。重试/限流/降级/熔断/反压、主从模式、集群模式、AZ内高可用、单元化、跨region容灾、异地多活容灾。
• 所有过程自动化原则：让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。
• 零信任原则：默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础。
• 架构持续演进原则：架构具备持续演进的能力。

云原生主要架构模式

• 服务化架构模式：要求以应用模块为颗粒度划分一个应用软件，以接口契约（例如IDL）定义彼此业务关系，以标准协议（HTTP、gRPC等）确保彼此的互联互通，结合领域模型驱动（Domain Driven Design，DDD）、测试驱动开发（Test Driven Design，TDD）、容器化部署提升每个接口的代码质量和迭代速度。服务化架构的典型模式是微服务和小服务。
• Mesh化架构模式：Mesh 化架构是把中间件框架（如RPC、缓存、异步消息等）从业务进程中分离，让中间件 SDK 与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。实施 Mesh 化架构后，大量分布式架构模式（限流、降级、熔断、重试、反压、隔仓）都由 Mesh 进程完成，即使在业务代码的制品中并没有使用这些三方软件包。
• Serverless模式：Serverless 模式适合事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。
• 存储计算分离模式：分布式环境中的 CAP 困难主要是针对有状态应用，一致性（Consistency，C），可用性（Available，A），分区容错性（Partition Tolerance，P）三者无法同时满足，最多满足其中两个。无状态应用不存在一致性 C 这个维度，可以获得很好的可用性和分区容错性，因而获得更好的弹性。把各类暂态数据、结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。
• 分布式事务模式：微服务提倡每个服务使用私有数据源，大颗粒业务需要访问多个微服务，必然带来分布式事务问题，否则会出现数据不一致。XA模式、BASE基于消息的最终一致性、TCC模式、SAGA模式、SEATA模式。
• 可观测架构：可观测架构包括Logging、Tracing、Metrics，其中 Logging 提供多个级别（verbose/debug/warning/error/fatal）的详细信息跟踪，由应用开发者主动提供；Tracing 提供一个请求从前端到后端的完整调用链路跟踪，对分布式场景尤其有用；Metrics 则提供对系统量化的多维度度量。建立可观测性是为了对服务 SLO(service level objective) 进行度量，从而优化 SLA(service level agreement)，架构设计时需为各个组件定义清晰的 SLO。
• 事件驱动架构：事件驱动架构（Event Driven Architecture，EDA）是一种应用/组件间的集成架构模式。适用于：增强服务韧性、命令查询责任分离（Command Query Responsibility Segregation，CQRS）、数据变化通知、构建开放接口、事件流处理。

云原生架构相关技术

容器技术

容器作为标准化软件基础单元，他将应用及其所依赖项打包发布，由于依赖项齐备，应用不再受环境限制，在不同计算环境间快读、可靠地运行。

云原生微服务

微服务设计约束：
1、微服务个体约束
微服务也应具备正交分解特性，在职责划分上专注于特定业务并将之做好，即SOLID原则中单一职责原则 (Single Responsibility Principle,SRP)。
2、微服务与微服务之间的横向关系
主要从微服务的可发现性和可交互性处理服务间的横向关系。
（1）可发现性：引入三方注册中心，自动感知新服务和服务变化。
（2）可交互性：服务之间的调用需要采用与语言无关的远程调用协议（REST、IDL）
3、微服务与数据层之间的纵向约束
（1）在微服务领域，提侣数据存储隔离 (Data Storage Segregation,DSS) 原则，即数据是微服务的私有资产，对于该数据的访问都必须通过当前微服务提供的 API 来访问。如若不然，则造成数据层产生耦合，违背了高内聚低耦合的原则。
（2）同时，出于性能考虑，通常采取读写分离(CQRS) 手段。
（3）微服务的设计应当尽量遵循无状态设计原则
4、全局视角下的微服务分布式约束
（1）准备全自动化的CI/CD流水线满足对开发效率的诉求，并在这个基础上支持蓝绿、金丝雀等不同发布策略
（2）全链路、实时和多维度的可观测能力

主要技术：Dubbo、SpringCloud、Eclipse MicroProfile、腾讯Tars、蚂蚁金服SOFAStack、微软DAPR

无服务技术

客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作。
函数计算（Function as a Service，FaaS）是 Serverless 中最具代表性的产品形态。
主要服务形态：FaaS函数计算、阿里Serverless应用引擎SAE、谷歌CloudRun、谷歌Knative

服务网格

服务网格 (ServiceMesh) 是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦 。这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。
主要技术：Istio、Linkerd、Consul、Conduit

---

15 面向服务的架构设计理论与实践

SOA 将应用程序的不同功能模块（称为服务）通过服务间定义好的接口和契约连接起来，使得服务可以以统一和通用的方式进行交互。服务接口是标准的，服务实现与语言无关。
SOA 是粗粒度、松耦合的服务架构。

业务流程执行语言（Business Process Execution Language，BPEL），业务流程是指为了实现某种业务目的行为所进行的流程或一系列动作。
BPEL目前用于整合现有的Web Services，将现有的Web Service按照要求的业务流程整理成为一个新的Web Service。

面向过程（结构化开发） -> 面向对象 -> 面向构件 -> 面向服务，粒度逐渐增大，耦合逐渐松散，接口更加标准

UDDI 协议：发现服务
WSDL 协议：描述服务
SOAP 协议：服务交换，传递信息
REST 规范：数据交换

SOA的微服务化发展：随着互联网的发展，单体架构 到 SOA架构 到 微服务架构
SOA与微服务的区别

• 微服务相比于SOA更加精细，微服务更多地以独立的进程的方式存在，相互之间并无影响。
• 微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制。
• 微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合。

微服务架构是SOA架构的进一步优化，去除了ESB服务总线，去中心化的分布式架构。

SOA的设计标准要求：

• 文档标准化
• 通信协议标准：XML
• 应用程序统一登记与集成
• 服务质量QoS：（1）可靠性（一次且仅一次、最多一次、重复过滤、保证送达）（2）安全性：认证（3）策略（4）控制（5）管理

SOA设计原则：

• 无状态
• 单一实例
• 明确定义接口
• 自包含和模块化
• 粗粒度
• 松耦合
• 可重用
• 互操作性

SOA设计模式

• 服务注册模式：服务注册、注册中心、服务消费者
• ESB企业服务总线模式：一根总线连接不同服务，ESB做消息格式适配转发
• 微服务模式

企业服务总线（Enterprise Service Bus，ESB）：企业服务总线模式提供一种标准的软件底层架构，各种程序组件能够以服务单元的方式“插入”到该平台上运行，并且组件之间能够以标准的消息通信方式来进行交互。

微服务架构：

• 解耦：单体应用拆分为多个微服务，保持总体功能不变。
• 独立：每个服务可以独立进行开发、管理和迭代
• 技术选型灵活：每个服务单独选型与架构
• 容错：故障被隔离在单个微服务中。重试、熔断降级
• 易水平扩展

微服务架构模式方案

• 聚合器微服务：有个微服务负责聚合多个调用结果
• 链式微服务：A调B，B调C
• 数据共享微服务：单体服务拆分过渡阶段，多个微服务共享数据库
• 异步消息传递微服务：消息队列，非同步

SOA架构注意问题：

• 全面考虑原有系统架构中的集成需求
• 服务粒度的控制：对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。
• 无状态服务的设计：SOA架构中的服务应该是无状态的服务

SOA实施过程

• 选择SOA解决方案
• 业务流程分析

---