今天是10月13号，距2024下半年的软考还有27天，记错时间了，一直以为是11月底考，结果今天发现是11月9号，我……😂😂，挑战一下27天够不够吧，上次其实也只复习了7天，论文差了4分。这次打算在这个过程中，把知识点总结整理一下。

需要临时抱佛脚的同学，赶紧收藏起来，至少综合题你照着我这个背，25~30分基本能覆盖的。

这个系列我是这样规划：
先整理综合题，就是结合历年所有考题，把涉及的知识点分类整理，这部分没什么技术含量，就是背下来、背下来、背下来……尤其是架构设计和软件工程相关的地方，性价比非常高。
案例分析应该会结合真题来整理共同的知识点，论文就准备一些素材和写作框架吧。

软件架构这一大块都非常重要，主要包括以下几个部分，接下来会逐一整理。

• 软件架构定义
• 基于架构的软件开发方法
• 软件架构风格
• 软件架构复用
• 特定领域软件体系结构
• 软件质量属性
• 软件架构评估

1. 基础定义

• 软件系统架构是关于软件系统的结构、行为和属性的高级抽象。（关键词：结构、行为、属性）
• 架构设计主要关注软件组件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。（跟上面一个意思，不同讲法，但是会按原文出挖空选择题）
• 架构描述语言（Architecture Description Language, ADL）基本构成要素包括组件、组件接口、连接件和架构配置。组件是计算或数据存储单元，在架构中可能大小不一。连接件建立组件间的交互和规则。架构配置描述了组件和连接件的连接图。

1.1 视图

• 多视图指从不同角度和视角描述系统体系结构，以获得多个视图，并将其组合在一起以描述整体模型。
• 多视图反映了关注点分离的思想，每个视图只关注系统的一个侧面。（关键点是要区分两种视图，总之还是背下来）

1.1.1 架构的“4+1”视图

“4+1”视图模型来描述软件系统的体系结构。

• 涵盖逻辑视图、进程视图、物理视图、开发视图和场景，每个视图只反映某个侧面。在此模型中，“1” 指的是统一场景。
  • 场景可以看作是其他四个视图的综合体现和验证，它通过一些用例或场景来说明系统的架构。
  • 逻辑视图：从最终用户的角度出发，关注系统提供的功能，即系统应该为用户提供怎样的服务。
  • 开发视图：站在程序员、软件项目经理的角度，描述软件在开发环境下的静态组织。
  • 进程视图（处理视图）：关注系统动态运行时的情况，主要涉及进程以及相关的并发、同步、通信等问题。处理视图考虑一些非功能性需求，如系统的性能、并发性、分布性、系统完整性、容错性等
  • 物理视图：系统工程师的角度解读系统，关注软件的物理拓扑结构，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。

1.1.2 UML的“4+1”视图

• 用例视图：描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计。
• 逻辑视图：主要关注系统的功能性需求，描述系统的业务功能以及这些功能是如何在系统中实现的。逻辑视图和实现视图类似于“4+1”模型中的逻辑视图和开发视图，都是描述软件系统的功能和逻辑结构。
• 进程视图：主要关注系统的运行时行为，特别是组件之间的交互和并发。
• 实现视图：主要关注系统的静态组织，包括软件的物理层面上的组件和层。
• 部署视图：主要关注系统如何在物理层面上分布，包括硬件和软件的映射。

用例视图（需求分析模型）→ 最终用户
逻辑视图（类与对象）→ 系统分析、设计人员
实现视图（物理代码文件和组件）→ 程序员
进程视图（线程、进程、并发）→ 系统集成人员
部署视图（软件到硬件的映射）→ 系统和网络工程师

2. 软件架构风格

• 软件体系结构风格是描述某一特定应用领城中系统组织方式的惯用模式。架构风格定义了一类架构所共有的特征，主要包括架构定义、架构词汇表和架构约束。（背：词汇表、约束）
• 架构风格强调对架构设计的重用。
• 基于描述判断风格，以前在案例题里考，最近逐渐在选择题里考：

2.2 架构风格类型

1、批处理风格

批处理风格中，每个处理步骤都是独立的、顺序执行的，组件间只通过数据传递交互，数据传送作为一个整体在步与步之间进行。典型应用包括经典数据处理、程序开发和 Windows 下的 BAT 程序等。

每个处理步骤是一个单独的程序，每一步必须在前一步结束后才能开始，并且数据必须是完整的，以整体的方式传递。

2、虚拟机风格

虚拟机风格的基本思想是构建一个运行环境，解析并运行自定义的语言，以增加架构的灵活性，

虚拟机风格允许用户自定义计算方式和规则，增加了架构的灵活性和可维护性。

适用场景：业务需求变化大且要求能够及时响应变化，选择虚拟机风格比较合适，因为它允许用户自定义计算方式和规则，增加了架构的灵活性和可维护性。

包括**（1）解释器、（2）规则为中心/规则系统** 两种架构风格。解释器系统和规则系统的不同点在于它们的思想原理和应用场景。

解释器系统

解释器系统是一种基于知识的推理系统，通过运用专家知识和规则库的知识来解决问题。在解释器系统中，问题求解是基于推理机制和专业领域知识来完成的。通过不断的推理、解释和归纳，解释器系统能够通过一个初始的问题，得到一个最终的答案。

系统能应对“自定义”内容的解析，这需要用到解释器架构风格。

规则系统

规则系统是一种基于规则的推理系统，通过对每个规则的匹配和应用来推导出问题的结论。在规则系统中，规则库中的规则通常是由具体的业务规则归纳总结而来，其执行过程是基于前提条件和结论之间的条件判断和逻辑运算。

规则系统是虚拟机风格下的一种架构形式，最显著的特点是将变化的内容定义为规则，因此可以随时根据业务需求进行修改和更新。

基于规则的系统包括（1）规则集、（2）规则解释器、（3）规则/数据选择器、（4）工作内存等组成部分

6、C2 体系风格

C2 体系结构风格可以概括为通过连接件绑定在一起按照一组规则运作的并行构件网络。

C2风格中的系统组织规则如下：

①系统中的构件和连接件都有一个顶部和一个底部。

②构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部。而构件与构件之间的直接连接是不允许的。

③一个连接件可以和任意数目的其他构件和连接件连接。

④当两个连接件进行直接连接时，必须由其中一个的底部连接到另一个的顶部。

3、分层架构

三层C/S体系结构包括表示层、功能层和数据层三个部分。

表示层作为用户接口，用于输入和输出数据。

功能层是应用的核心，负责具体业务处理逻辑。

数据层是数据库管理系统，负责管理数据读写。

这种架构解决了应用程序复杂性和开发效率之间的矛盾，使得不同层的构建相互独立，接口简洁，适合于复杂事务处理。

层次化架构具有低耦合、依赖关系简单等特点，上层只能依赖于下层，底层错误将导致整个系统无法运行，而上层错误只会影响错误的这一部分。

4、仓库风格

仓库是存储和维护数据的中心场所。

在仓库风格中，有两种不同的构件：

【中央数据结构】说明当前数据的状态

【独立构件】对中央数据进行操作的，在中央数据存储上执

仓库与独立构件间的相互作用在系统中会有大的变化。

这种风格的连接件即为仓库与独立构件之间的交互。

2.2 架构风格的具体案例（来源于历年真题）

（1）某公司拟开发一个新闻系统，该系统可根据用户的注册兴趣，向用户推送其感兴趣的新闻内容 —— 事件驱动系统
（2）某公司拟开发一个VIP管理系统，系统需要根据不同商场活动，不定期更新VIP会员的审核标准和VIP折扣系统 —— 虚拟机风格（规则系统）
（3）对于语音识别、知识推理等问题复杂、解空间很大、求解过程不确定的这一类软件系统 —— 黑板架构风格（语音识别是黑板风格的经典应用–对于语音识别、知识推理等问题复杂、解空间很大、求解过程不确定的这一类软件系统，通常会采用黑板架构风格）
（4）对于因数据输入某个构件，经过内部处理，产生数据输出的系统 —— 管道-过滤器架构风格。
（5）某公司拟为某种新型可编程机器人开发相应的编译器。该编译过程包括词法分析、语法分析、语义分析和代码生成四个阶段，每个阶段产生的结果作为下一个阶段的输入，且需独立存储 —— 数据流架构风格（管道-过滤器）
（6）某公司拟开发一个扫地机器人。机器人的控制者首先定义清洁流程和流程中任务之间的关系，机器人接受任务后，需要响应外界环境中触发的一些突发事件，根据自身状态进行动态调整，最终自动完成任务 —— 虚拟机风格（规则系统）（强调了自定义流程，然后按自定义流程来执行）
（7）某企业内部现有的主要业务功能已封装成为 Web 服务。为了拓展业务范围，需要将现有的业务功能进行多种组合，形成新的业务功能 —— 虚拟机风格（解释器系统）
（8）某公司拟开发一个地面清洁机器人。机器人的控制者首先定义清洁任务和任务之间的关系，机器人接受任务后，需要响应外界环境中触发的一些突发事件，根据自身状态进行动态调整，最终自动完成任务 —— 虚拟机风格（规则系统）
（9）某公司拟开发一个轿车巡航定速系统，系统需要持续测量车辆当前的实时速度，并根据设定的期望速度自动控制轿车的油门和刹车 —— 过程控制（过程控制又称闭环风格，该风格的最大特点是设定参数，并不断测量现有的实际数据，将实际值与设定值进行比较，以确定接下来的操作）
（10）某公司拟开发一套在线游戏系统，该系统的设计目标之一是支持用户自行定义游戏对象的属性、行为和对象之间的交互关系 —— 虚拟机风格（解释器系统）（要求拟开发的在线游戏需要自定义对象之间的交互，这样必须有机制能支持系统对新定义的规则进行解析，这需要用到虚拟机风格，构造一个虚拟机对规则进行解析）
（11）某公司为其研发的硬件产品设计实现了一种特定的编程语言，为了方便开发者进行软件开发，公司拟开发一套针对该编程语言的集成开发环境，包括代码编辑、语法高亮、代码编译、运行调试等功能 —— 数据仓库风格（以数据为中心的架构风格）（现代编译器的集成开发环境一般采用数据仓储架构风格进行开发，其中心数据就是程序的语法树。）

3. 基于架构的软件开发（ABSD）

• 基于架构的软件设计（Architecture-Based Software Design. ABSD），采用视角与视图来描述软件架构，采用用例来描述功能需求，采用质量场景来描述质量需求。（整句背背背）
• ABSD 是一个自顶向下，递归细化的软件开发方法，软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。 （背：自顶向下，递归细化、构件和类）
• ABSD 方法强调由商业、质量和功能需求的组合驱动软件架构设计。

3.1 基于体系结构的开发模型（ABSDM）

• 基于体系结构的开发模型（ABSDM）把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现和演化等 6 个过程。
• 体系结构设计过程是一个迭代过程，可以使用已有的系统适用于大部分开发需求。
• 体系结构文档化过程，并提到其主要输出物包括体系结构规格说明和质量设计说明书。文档要从使用者的角度进行编写，必须分发给所有与系统有关的开发人员，且必须保证开发者手上的文档是最新的。这里要注意的是，架构文档要保持较新，但不要随时保证文档最新，要保持文档的稳定性。
• 体系结构复审，其目的是早期发现设计中的缺陷和错误。在一个主版本的软件架构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。
• 体系结构实现过程，其过程是以文档化的体系结构说明书为基础的，并且每个构件必须满足其责任。
• 体系结构演化，使用系统演化步骤对应用程序进行修改，以适应新的需求情况。

4. 软件架构评估

4.1 敏感点和权衡点

• 敏感点和权衡点是关键的架构决策。
• 敏感点是一个或多个构件的特性。
• 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。所谓权衡就是会让一个质量属性变好，一个质量属性变差。只有在这种情况下才需要权衡。
  举例子：改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。所以该设计决策是一个权衡点。
• 风险点与非风险点不是以标准专业术语形式出现的，只是一个常规概念。即可能引起风险的因素，可称为风险点。某个做法如果有隐患，有可能导致一些问题，则为风险点；而如果某件事是可行的、可接受的，则为非风险点。

4.2 体系结构权衡分析方法（ATAM）

体系结构权衡分析方法（Architecture Tradeoff Analysis Method，ATAM）主要针对系统开发之前对质量属性进行评价和折中，其中包括性能、可用性、安全性和可修改性等方面。（背：性能、可用性、安全性和可修改性）

ATAM主要关注系统的需求说明。

ATAM 方法采用效用树 (Utility tree）这一工具来对质量属性进行分类和优先级排序。效用树的结构包括质量效用树的结构是树根—质量属性—属性分类—质量属性场景（叶子节点）

4.2.1 评估方面

1、性能

“并发用户数量10000人时用户请求要在1秒内得到响应”

“网站在并发用户数量10万的负载情况下，用户请求的平均响应时间应小于3秒”

“数据传递时延不大于1s ”

“系统正常运行时，人员信息查询请求应该在2秒内返回结果”

“机器人在正常运动过程中如果发现前方2米内有人或者障碍物，应在1秒内停止并在2秒内选择一条新的运行路径”

“在并发用户数不超过1000人时，用户的交易请求应该在0.5s内完成”

策略：增加计算资源、减少计算开销、引入并发机制、采用资源调度、策略优先级队列等

2、可修改性

“对游戏系统进行二次开发的时间不超过3个月”

“系统完成上线后，少量的外围业务功能和界面的调整与修改不超过10人/月”

“对系统的消息中间件进行替换时，替换工作需要在5人/月内完成”

策略：接口-实现分离、抽象、信息隐藏等架构策略实现该属性

3、可用性

“主站宕机后，系统能够在10秒内自动切换至备用站点并恢复正常运行”

“系统采用双机热备，主备机必须实时监测对方状态，以便完成系统的实时切换”

“管理系统遭遇断电后，能够在15秒内自动切换至备用系统并恢复正常运行”

“机器人系统主电源断电后，能够在10秒内自动启动备用电源并进行切换，恢复正常运行”

“系统主站断电后，能够在2分钟内自动切换到备用站点，并恢复正常运行”

“当系统面临断电故障后，需要在1小时内切换至备份站点并恢复正常运行”

策略：心跳、Ping/Echo、主动冗余、被动冗余、选举等架构策略

4、安全性

“系统应能够防止99%的黑客攻击”

“系统需要对用户的操作情况进行记录，并对所有针对系统的恶意操作行为进行报警和记录”

“对机器人的远程控制命令应该进行加密，从而能够抵挡恶意的入侵破坏行为，并对攻击进行报警和记录”

“系统应该能够抵挡恶意用户的入侵行为，并进行报警和记录”

策略：追踪审计、抵抗攻击、检测攻击和从攻击中恢复

4.2.2 效用树

效用树以“效用”作为根结点，质量属性构成效用树的辅助级别。

在每个质量属性中都会包含特定的质量属性说明，以提供对方案更精确的描述。后者形成了实用程序树中的叶节点。效用树沿着两个维度进行优先顺序。每个场景对系统成功的 重要性以及对此场景实现(架构师的角度来看）所带来的难易程度的估计。

4.2.3 质量属性

• 质量属性场景描述六大组成本部分：刺激源、刺激、环境、制品、响应、响应度量。（背背吧，去年考了个大题）
• 【刺激源】是生成该刺激的实体，例如在网购系统中，用户进行操作（如购买商品、修改信息等）会对系统产生刺激，用户就是刺激源。
• 【刺激】是刺激到达系统时可能产生的影响，根据不同的质量属性，质量属性场景的刺激也有所不同，比如对于一个在线视频播放平台，大量用户同时请求高清视频播放就是一种刺激；对于银行系统，短时间内大量的转账交易请求也是一种刺激。
  • 可用性：错误，
  • 修改性：增加/删除/修改/改变，
  • 性能：定期事件、随机时间、偶然事件，
  • 安全性：试图显示数据、改变/删除数据、访问系统服务、降低系统服务的可用性，
  • 易用性：学习系统特性、有效使用系统、使错误影响最低、适配系统、对系统满意；
• 【环境】是该刺激在某条件内发生，环境因素包括系统运行的时间、系统当前的负载情况、网络状况、硬件条件等。例如，在网络高峰期，系统的响应速度可能会受到影响，这就是一种特定的环境。
• 【制品】是系统中受刺激的部分。制品是被刺激的对象，即系统中受到影响的部分。比如在一个电商系统中，购物车模块、支付模块、商品展示模块等都可能是制品。
• 【响应】是刺激到达后所采取的行动，
• 【响应度量】是对响应的度量，用于测试需求是否满足。

4.3 基于场景的架构评估方法

基于场景的架构评估方法（SAAM）的评估过程包括场景开发、架构描述、单场景评估、场景交互评估和总体评估。

使用SAAM进行评估时，需要使用场景对于质量目标进行判断，以判定体系结构的优劣。场景是从风险承担者的角度对系统交互的简短描述。在体系结构评估中，通常采用刺激、环境和响应三个方面对场景进行描述。

SAAM 的主要输入是问题描述、需求声明和架构描述。

4.4 其他评估方法（了解）

• SAEM 方法将软件架构视为最终产品和设计过程中的中间产品。它从外部和内部质量属性两个角度进行评估，创建了一个基础框架，用于规约建模、创建度量准则和评估质量属性。
• SAABNet 方法使用贝叶斯信念网络（Bayesian Belief Networks, BBN）来表达和使用定性知识，辅助架构的定性评估。
• 软件架构修改度量方法（Software Architecture Change Measurement Method, SACMM）专注于软件架构在修改过程中的变化。它基于图内核定义差异度量准则，计算两个软件架构之间的距离，从而描述架构在修改过程中的转换模型。
• 软件架构静态分析方法（Static Analysis of Software Architecture Model, SASAM）通过映射和比较预期架构和实际架构来静态地评估软件架构。
• 软件架构可靠性风险评估方法（Architecture-based Reliability Risk Assessment, ALRRA）使用动态复杂度和耦合度准则来定义组件和连接件的复杂性因素，结合失效模式和影响分析（FMEA）来定义故障引起的后果的严重性因素，从而评估软件架构的可靠性风险。
• 层次分析法（Analytical Hierarchy Process, AHP）是一种多准则决策方法，它通过划分问题层次、构造比较判断矩阵、计算合成权重等步骤，帮助解决软件架构评估中的冲突问题，并对设计方案进行整体排名。
• COSMIC+UML 方法是一种基于面向对象系统源代码的可维护性度量准则的方法，它通过将面向对象的度量准则与COSMIC方法相关联，并提出UML组件图的度量准则，来评估软件架构的可维护性。

5. 特定领域软件架构（DSSA）

• DSSA 以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，旨在支持一个特定领域中多个应用的生成。
• DSSA 基本活动包括领域分析、领域设计和领域实现。（三个阶段获得的东西要背下来）
  • 领域分析的主要目的是获得领域模型，描述领域中系统之间共同的需求，即领域需求。
  • 领域设计的主要目标是获得 DSSA，描述领域模型中表示需求的解决方案。
  • 领域实现的主要目标是依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。
• 根据领域的不同，特定领域架构 DSSA 可以分为垂直域和水平域。在特定领域架构中，垂直域关注的是与行业相关的，聚焦于行业特性的内容，而水平域关注的是各行业共性部分的内容。
  • 垂直域定义了一个特定的系统族，包含整个系统族内的多个系统，结果是在该领域中可作为系统的可行解决方案的一个通用软件体系结构。
  • 水平域则定义了在多个系统和多个系统族中功能区城的共有部分，其范围在子系统级上涵盖多个系统族的特定部分功能。
• 参与 DSSA 的人员包括领域专家、领域分析人员、领域设计人员和领域实现人员，他们各自扮演不同的角色，负责领域工程中的不同方面。
  • 领域专家的主要任务是提供有关领域中系统需求规格和实现知识，维护领域字典和复审领域模型和 DSSA 等。
  • 领域分析人员则负责整个领域分析过程控制以及将从领域专家处获得的知识组织到领域模型中等。
  • 领域设计人员则需要根据领域模型和现有系统开发出 DSSA 以及建立领域模型和 DSSA 之间的联系。
  • 领域实现人员的任务是根据领域模型和DSSA进行软件实现以及对可重用构件进行验证。

6. 软件复用和遗留系统

6.1 遗留系统演化策略

【低水平低价值】淘汰是最好理解的。

【低水平高价值】意味着代码很难维护（屎山）。但因为它承载着核心业务，一直跑的很好，所以你也不敢轻易动它的代码，只能做点修修补补的操作，这叫继承。

【高水平低价值】意味着业务价值低，使用场景比较单一，这个时候就要把这些系统集成起来，以免形成孤岛。

【高水平高价值】是既可以维护又承载核心业务的代码，企业可以根据需求大胆改动的，在此基础上增强新的功能，这就是改造。

6.2 软件架构复用

• 软件复用过程的主要阶段可以分为构造/获取可复用的软件资产、管理可复用资产和使用可复用资产
• 软件架构复用的类型包括机会复用和系统复用。
  • 机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。
  • 系统复用是指在开发之前，就要进行规划，以决定哪些需要复用。