乐于分享
好东西不私藏

软考|系分|第十二章|软件架构设计知识点

软考|系分|第十二章|软件架构设计知识点
12.1 软件架构概述
- 定义:软件架构为软件系统提供结构、行为和属性的高级抽象,由构件、连接件、集成模式及约束组成。是需求与设计之间的桥梁。
- 意义(9点核心):
   1. 项目干系人交流的手段(高层抽象)。
   2. 早期设计决策的体现(影响最大、最难改变)。
   3. 明确对系统实现的约束条件。
   4. 决定开发和维护组织的组织结构。
   5. 制约系统的质量属性(大型系统质量主要靠架构)。3
   6. 使推理和控制更改更简单(局部/非局部/架构级变更)。
   7. 有助于循序渐进的原型设计。
   8. 可作为培训基础。
   9. 可传递和可复用的模型(比代码复用粒度更大)。
- 发展史四个阶段:
   1. 无架构(汇编、小规模)。
   2. 萌芽(控制流/数据流图)。
   3. 初级(UML多视图)。
   4. 高级(Kruchten的“4+1”模型为标志,高层抽象)。
12.2 软件架构建模
- 5种模型:结构模型(最常用,研究ADL)、框架模型(侧重整体)、动态模型(补充行为/演化)、过程模型(构建步骤)、功能模型(层次化功能构件)。
- “4+1”视图模型(高频考点):
   - 逻辑视图:功能需求,面向对象类图,面向用户/客户。
   - 开发视图(实现视图):模块组织、复用、开发管理,包/构件图,面向程序员。
   - 进程视图:运行特性(性能、并发、容错),线程/进程,面向集成人员。
   - 物理视图(部署视图):硬件映射、拓扑、通信,部署图,面向系统工程人员。
   - 场景(+1):用例视图,串联验证其他4视图,驱动架构设计。
注:逻辑/开发为静态;进程/物理为动态。
12.3 软件架构风格(重中之重)
架构风格定义:特定领域系统组织方式的惯用模式(词汇表+约束),目的是架构级复用。
1. 数据流风格
- 批处理:每一步独立程序,前一步整体完成后下一步才开始,数据整体传递(无交互)。
- 管道-过滤器:过滤器(构件)通过管道(连接件)连接,数据流增量传递,输入输出明确,可并行,无状态(如编译器、Unix Shell)。
2. 调用/返回风格
- 主程序/子程序:单线程,层次调用。
- 面向对象:对象封装数据与操作,消息传递。
- 层次型:每层服务上层、调用下层,仅相邻层可见,修改影响至多两层。
- C/S风格:
   - 二层C/S:胖客户机、瘦服务器,客户端负担重、难维护、安全性差。
   - 三层C/S:表示层、功能层(应用服务器)、数据层,中间件是关键,逻辑独立、易维护、安全(隔离数据层)。
   - B/S:三层C/S变种(浏览器+Web服务器+DB),零客户端、易部署,但动态交互弱、响应慢、安全难控。
3. 以数据为中心
- 仓库风格:中央数据结构 + 独立操作构件(如数据库、IDE)。
- 黑板风格:仓库 + 知识源 + 控制模块,解决非结构化复杂问题(如语音识别、信号处理),求解过程不确定。
4. 虚拟机风格
- 解释器:模拟执行自定义语言,灵活但效率低(如JVM、专家系统)。
- 规则系统:规则集 + 规则解释器 + 工作内存(如业务规则引擎)。
5. 独立构件风格
- 进程通信:独立进程,消息传递(RPC/同步异步)。
- 事件系统(隐式调用):触发/广播事件,构件注册监听,发布者不知谁响应(松耦合),如GUI、调试器断点。
6. 面向服务的架构(SOA)
- 特征:粗粒度、松耦合、标准接口(明确定义、自包含、互操作)。
- 关键技术:
   - UDDI:服务注册发现。
   - WSDL:服务描述(接口/实现)。
   - SOAP:XML消息传输(信封/头/体)。
   - REST:无状态、资源标识(GET/POST/PUT/DELETE)。
- 实现方法:
   - Web Service:服务提供者、请求者、注册中心(可选)。
   - 服务注册表:注册、定位、绑定。
   - 企业服务总线(ESB):解耦服务提供者与使用者的基础设施,支持协议转换、消息路由、安全。
12.4 软件架构标准
- IEEE 1471-2000:软件密集型系统架构描述的第一个正式标准,定义架构要素5层次关系:
   1. 任务(Mission):系统需满足的利益相关者目标。
   2. 环境、系统、架构:系统存在于环境中,由架构组织组件完成功能。
   3. 利益相关者、架构说明、原理:描述架构以满足不同利益,记录设计取舍理由。
   4. 关注、关注点(Viewpoint)、视图(View):关注点决定视点规范,视点生成视图(一一对应),反映不同干系人视角。
   5. 关注点库、模型:前人总结的关注点参考库;模型是视图的图形化表示方法。
- 演进:ISO/IEC/IEEE 42010:2022 是当前公认标准。
12.5 软件架构实现(ABSDM模型)
基于架构的软件开发模型(ABSDM)划分为6个迭代子过程:
1. 体系结构需求
- 来源:质量目标、商业目标、开发方目标。
- 步骤:需求获取 → 标识构件(生成类图 → 类分组 → 打包成构件) → 需求评审。
2. 体系结构设计
- 步骤:提出模型(选风格)→ 映射构件 → 分析构件相互作用 → 产生架构 → 设计评审(外部人员参与)。
3. 体系结构文档化
- 核心输出:体系结构规格说明、测试体系结构需求的质量设计说明书。
- 要求:从使用者角度编写,分发全员,保持最新。
4. 体系结构复审
- 目的:标识潜在风险、发现缺陷。通常由外部人员(用户代表、专家)参加,可搭建最小化系统评估。
5. 体系结构实现
- 基础:复审后的文档。
- 步骤:查找/开发构件 → 按接口约束组装 → 功能性测试与整体测试。
6. 体系结构演化
- 触发:需求变更。
- 步骤:需求变化归类 → 制订演化计划 → 增删改构件 → 更新相互作用 → 组装测试 → 技术评审。
12.6 软件架构质量属性
架构重点关注质量属性(功能属性之外),常用质量属性场景(6部分:刺激源、刺激、环境、制品、响应、响应度量)描述。
分类维度
- 开发期质量属性(6个):易理解性、可扩展性(灵活性)、可重用性、可测试性、可维护性、可移植性。
- 运行期质量属性(7个):性能、安全性、可伸缩性、互操作性、可靠性、可用性、健壮性(容错性/鲁棒性)。
架构评估重点关注(8类)
1. 性能:响应时间、吞吐量(MTTF/MTBF为可靠性指标,非性能)。
2. 可靠性:容错(内部修复继续运行)、健壮性(防错误输入,按定义终止)。
3. 可用性:正常运行时间比例(两次故障间时长、恢复速度)。
4. 安全性:机密性、完整性、不可否认性、可控性。
5. 可修改性:含可维护性(修复)、可扩展性(新增)、结构重组、可移植性(跨环境)。
6. 功能性:完成预期工作的能力。
7. 可变性:架构变更为新产品的能力(产品线基础)。
8. 互操作性:与其他系统交换数据/调用的能力。
质量属性场景高频考点(6类要素记忆)
- 刺激源(谁触发)、刺激(什么条件)、环境(何时发生)、制品(作用于谁)、响应(系统做什么)、响应度量(如何量化)。常考可用性(故障检测与恢复)、可修改性(修改成本/影响范围)、性能(延迟/吞吐量)、安全性(攻击规避难度)。
应试提示:
- ABSDM六过程顺序与产出物(文档化输出哪两个文档)是选择题高频点。
- IEEE 1471 的 View(视图)与 Viewpoint(关注点/视点)关系是辨析重点。
- 质量属性分类易混:可靠性 vs 可用性 vs 健壮性;开发期 vs 运行期属性要能准确归类。
- 质量属性场景六要素常在案例题中要求补全或分析。