Appearance
ABSD —
ABSD 方法是由商业、质量和功能需求的组合驱动的，是一个自顶向下、递归细化的方法，直到能产生软件构件和类。
ABSD 方法的三个基础：
- 对系统进行功能分解
- 采用架构策略实现质量属性与商业需求
- 采用软件模板设计软件结构
六个子过程：
- 架构需求 — 获取需求
- 架构设计 — 设计方案
- 架构文档化 — 输出架构规格说明和测试架构需求的质量设计说明书
- 架构复审 — 标识潜在风险，及早发现架构设计中的缺陷和错误
- 架构实现 — 编码实现
- 架构演化 — 应对需求变化，修改应用架构满足新需求
ABSD 是架构设计的核心方法论，六个子过程和三基础是高频选择题考点。
基于架构的软件开发方法
ABSD 概述
ABSD方法是架构驱动，强调由业务、质量和功能需求的组合驱动架构设计。它强调，采用用例和质量属性场景来描述需求。进一步来说，（或侧重于非功能需求）。
使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成，就开始了软件设计。
ABSD方法有三个基础。第一个基础是功能的分解，使用已有的基于模块的内聚和耦合技术；第二个基础是通过选择架构风格来实现质量和业务需求；第三个基础是软件模板的使用，软件模板利用了一些软件系统的结构。
ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，有助于降低架构设计的随意性。
ABSD 方法是由商业、质量和功能需求的组合驱动的，是一个自顶向下、递归细化的方法，直到能产生软件构件和类。
ABSD 方法的三个基础：
- 对系统进行功能分解
- 采用架构风格实现质量属性与商业需求
- 采用软件模板设计软件结构
⚠️ "强调由业务、质量和功能需求的组合驱动" 本身不属于三个基础（而是方法驱动因素）。
ABSD 六个子过程
架构设计是在****，是为了解决需求分析和软件设计之间的鸿沟问题。基于架构的软件开发过程可分为下列六步：
架构需求 → 架构设计 → 架构文档化 → 架构复审 → 架构实现 → 架构演化| 子过程 | 核心内容 |
|---|---|
| 1. 架构需求 | 获取需求（质量目标 + 系统商业目标 + 开发人员商业目标） |
| 2. 架构设计 | 设计方案 |
| 3. 架构文档化 | 输出架构规格说明书 + 测试架构需求的质量设计说明书 |
| 4. 架构复审 | 标识潜在风险，及早发现缺陷和错误 |
| 5. 架构实现 | 编码实现（基于文档化后的架构说明书） |
| 6. 架构演化 | 应对需求变化，需先进行需求变化归类 |
⚠️ 标识构件的正确顺序：生成类图 → 对类进行分组 → 把类打包成构件
架构需求：重在掌握标识构件的三步，如下左图。
架构设计：将需求阶段的标识构件映射成构件，进行分析，如下右图。
架构（体系结构）文档化：主要产出两种文档，
- 即架构（体系结构）规格说明，
- 测试架构（体系结构)需求的质量设计说明书。
文档是至关重要的，是所有人员通信的手段，关系开发的成败。
架构复审：由外部人员（独立于开发组织之外的人，如用户代表和领域专家等）参加的复审，复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化，再复审。
架构实现：用实体来显示出架构。实现构件，构件组装成系统，如下左图：
架构演化：对架构进行改变，按需求增删构件，使架构可复用，如下右图：
架构（体系结构）文档化
ABSD 中文档化核心输出：
- 体系结构规格说明
- 测试架构需求的质量设计说明书
文档化原则：
- 从使用者角度书写
- 随时保证文档最新
- 分发给相关人员
- 针对不同背景的人员书写方式不同
架构文档化
架构文档化过程的主要输出结果是架构规格说明书和测试架构需求的质量设计说明书。
文档化原则：
- 从使用者的角度书写文档
- 随时保证文档是最新的
- 将文档分发给相关人员
- 针对不同背景的人员书写文档的方式不同
架构复审
- 目的：标识潜在风险，及早发现架构设计中的缺陷和错误
- 必须邀请：独立于系统开发的外部人员（领域专家）
- 复审过程由用户代表与领域专家决定架构是否满足需求
架构描述与需求对应
| 描述对象 | 使用工具 |
|---|---|
| 架构 | 视角与视图 |
| 功能需求 | 用例 |
| 质量需求 | 质量场景 |
软件系统四大基本功能 + 三硬件构件
四大基本功能（自上而下）：
| 功能 | 说明 |
|---|---|
| 数据存储 | 存储和检索数据 |
| 数据访问逻辑 | 处理访问数据的过程 |
| 应用逻辑 | DFD/用例/功能需求中记录的业务逻辑 |
| 表示逻辑 | 向用户显示信息并接收用户命令 |
三硬件构件： 客户端（Clients）、服务器（Servers）、网络（Network）
DSSA — 特定领域软件架构
DSSA 是特定应用领域中为一组应用提供组织结构参考的标准软件架构。
| 阶段 | 目标 | 产出 |
|---|---|---|
| 领域分析 | 获得领域模型，描述领域中系统间的共同需求 | 领域模型 |
| 领域设计 | 获得特定领域软件架构（DSSA） | 领域架构 |
| 领域实现 | 开发和组织可重用信息，实现基础软件架构 | 可重用构件/资产 |
四类参与角色：
- 领域专家 — 提供领域知识
- 领域分析者 — 控制领域分析过程，进行知识获取，组织领域模型
- 领域设计者 — 根据领域模型开发领域设计，验证设计的准确性和一致性
- 领域实现者 — 实现可重用资产
DSSA 三级层次：
- 领域开发环境 → 应用工程师主要在领域特定应用开发环境中工作
- 领域特定应用开发环境
- 应用执行环境
垂直域 vs 水平域：
- 垂直域：定义了一个特定的系统族，包含整个系统族内的多个系统
- 水平域：定义了多个系统和多个系统族中功能区域的共有部分，在子系统级上涵盖多个系统族
DSSA 是特定领域中一组应用的标准软件架构，三步法和四角色是高频考点。
DSSA就是专用于一类特定类型的任务（领域）的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。 DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成。
- 垂直域：在一个特定领域中的通用的软件架构，是一个完整的架构。
- 水平域：在多个不同的特定领域之间的相同的部分的小工具（如购物和教育都有收费系统，收费系统即是水平域)。
DSSA 三步法
DSSA 的三个基本活动：
| 阶段 | 目标 | 产出 | 主要活动 |
|---|---|---|---|
| 领域分析 | 获得领域模型 | 领域模型 | 分析共性需求 |
| 领域设计 | 获得DSSA | 领域架构 | 高层次设计解决方案 |
| 领域实现 | 开发和组织可重用信息 | 可重用构件/资产 | 实现可重用资产 |
⚠️ 领域设计的主要目标是获得 DSSA（不是领域模型）。建立过程是螺旋模型。
四类参与角色
参与 DSSA 的四种角色人员
| 角色 | 职责 |
|---|---|
| 领域专家 | 提供领域知识、需求规约和实现知识 |
| 领域分析者 | 控制领域分析过程，组织领域模型 |
| 领域设计者 | 开发领域设计，验证准确性和一致性 |
| 领域实现者 | 实现可重用资产 |
⚠️ 最适合担任领域分析师的是：具有知识工程背景的有经验的系统分析员
垂直域 vs 水平域
| 类型 | 定义 | 范围 |
|---|---|---|
| 垂直域 | 特定的系统族，包含整个系统族内的多个系统 | 整个系统族 |
| 水平域 | 多个系统族中功能区域的共有部分 | 子系统级 |
DSSA 特征
- 严格定义的问题域和解决域
- 具有普遍性
- 对领域有合适程度的抽象
- 具备固定典型开发过程中的可重用元素
⚠️ "随机性" 不属于 DSSA 特征。
建立DSSA的过程
- (1)定义领域范围：领域中的应用要满足用户一系列的需求。
- (2)定义领域特定的元素：建立领域的字典，归纳领域中的术语，识别出领域中相同和不相同的元素。
- (3)定义领域特定的设计和实现需求的约束：识别领域中的所有约束，这些约束对领域的设计和实现会造成什么后果。
- (4)定义领域模型和架构：产生一般的架构，并描述其构件说明。
- (5)产生、搜集可复用的产品单元：为DSSA增加复用构件，使可用于新的系统：
以上过程是并发的、递归的、反复的、螺旋型的。该过程的目的是将用户的需求映射为基于实现限制集合的软件需求，这些需求定义了DSSA。
DSSA的三层次系统模型
领域开发环境：领域架构师决定核心架构，产出参考结构、参考需求、架构、领域模型、开发工具。
领域特定的应用开发环境：应用工程师根据具体环境来将核心架构实例化。
应用执行环境：操作员实现实例化后的架构。
4+1 视图模型
4+1 视图模型从多个视图描述软件体系结构，核心思想是关注点分离。
| 视图 | 作用 | 关注点 |
|---|---|---|
| 逻辑视图 | 描述对象模型，说明系统应提供哪些服务 | 功能需求（用户视角） |
| 过程视图 | 捕捉设计的并发和同步特性 | 系统行为特性（动态视角） |
| 开发视图 | 描述开发环境中软件的静态组织结构 | 模块组织 |
| 物理视图 | 描述软件到硬件的映射 | 部署拓扑 |
| 场景（+1） | 用例视图，验证其他视图一致性 | 统一场景 |
视图与视角关系：
- 静态视角（展示功能组织）→ 判断质量特性
- 动态视角（展示并发行为）→ 判断系统行为特性
- 四个视图：逻辑视图、进程视图、实现视图、配置视图
- 使用逻辑视图记录设计元素的功能和概念接口
多视图体现了关注点分离的思想。"4+1"模型中的"1"指的是统一场景（Use Case），将 4 个视图（逻辑视图、进程视图、开发视图、物理视图）串联起来。
软件系统四项基本功能（划分视角）
| 视角 | 关注点 | 能否判断质量特性 |
|---|---|---|
| 静态视角（逻辑视图） | 功能组织 | ✅ |
| 动态视角（进程视图） | 并发行为 → 系统行为特性 | ✅ |
| 配置视角（部署视图） | 软件到硬件的映射 | ❌ |
软件复用
机会复用 vs 系统复用：
- 机会复用（发现复用）：开发过程中，只要发现有可复用的资产，就进行复用
- 系统复用（计划复用）：开发之前就进行规划，决定哪些需要复用
水平式重用 vs 垂直式重用：
| 类型 | 特点 | 典型代表 |
|---|---|---|
| 水平式重用 | 跨领域通用（应用领域无关），提供基础功能 | 标准函数库、通用类库 |
| 垂直式重用 | 面向特定领域（领域相关），包含领域知识 | 医学词汇表、电子商务标准、网银支付接口 |
复用过程的三个主要阶段：
- 构造/获取可复用的软件资产
- 管理可复用资产
- 使用可复用资产
架构复审与演化
架构复审目的： 标识潜在风险，及早发现架构设计中的缺陷和错误。复审过程中主要由用户代表与领域专家决定架构是否满足需求、质量需求是否在设计中得到体现。
架构演化： 针对用户需求变化，修改应用架构满足新的需求。
架构描述与需求对应：
- 架构 → 用视角与视图描述
- 功能需求 → 用用例描述
- 质量需求 → 用质量场景描述
构件组装与架构失配
🎯 架构失配主要包括三类：构件失配（基础设施/控制模型/数据模型冲突）、连接子失配（交互协议/数据格式冲突）、系统成分对全局体系结构的假设冲突。
失配分类与原因：
| 失配类型 | 产生原因 | 关键词 |
|---|---|---|
| 构件失配 | 系统对构件基础设施、控制模型和数据模型的假设存在冲突 | 基础设施、控制模型、数据模型 |
| 连接子失配 | 系统对构件交互协议、构件连接时数据格式的假设存在冲突 | 交互协议、数据格式 |
| 全局体系结构失配 | 系统成分对全局体系结构的假设存在冲突 | 整体架构假设 |
⚠️ 常见坑：由构件操作不当引起的失配不属于构件组装阶段的失配问题。
软件系统四大基本功能 + 三硬件构件（架构设计核心模型）
🎯 软件系统可分为四项基本功能，硬件有三类主要构件。架构设计的首要步骤是将非功能需求细化为更详细的需求。
软件系统四大基本功能（自上而下）：
| 功能 | 英文 | 说明 |
|---|---|---|
| 数据存储 | Data Storage | 存储和检索数据，无论是小文件还是大数据库 |
| 数据访问逻辑 | Data Access Logic | 处理访问数据的过程，通常指 SQL 查询 |
| 应用逻辑 | Application Logic | DFD、用例和功能需求中记录的业务逻辑 |
| 表示逻辑 | Presentation Logic | 向用户显示信息并接收用户命令 |
系统三类主要硬件构件：
🎯 客户端（Clients）、服务器（Servers）、网络（Network）。
设计模式三分类
🎯 设计模式按目的分为：创建型（对象实例化）、结构型（类/对象组合）、行为型（类/对象交互）。
| 分类 | 核心关注 | 典型例子 |
|---|---|---|
| 创建型 | 对象实例化过程的抽象 | 单例（Singleton）、工厂方法 |
| 结构型 | 类或对象的组合方式 | 适配器（Adapter）、桥接（Bridge） |
| 行为型 | 类或对象之间的交互和职责分配 | 策略（Strategy）、观察者（Observer） |
🎯 Bridge 模式 = 将抽象与实现分离；Strategy 模式 = 算法族可互换使用。飞机模拟系统中飞行行为与起飞行为的解耦是 Strategy 模式。