《系统架构设计师教程（第2版）》第7章-系统架构设计基础知识-02-基于架构的软件设计（ABSD）(原教材题目：基于架构的软件开发方法)

1. 基于架构的软件设计（ABSD）

ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，体系结构总是清晰的，这有助于降低体系结构设计的随意性。

1.1 概述

• 概念：
  • Architecture-Based Software Design
  • 自顶向下，递归细化，直到产生软件构件和类
  • 驱动：由构成体系结构的商业、质量和功能需求的组合驱动
• 设计活动的开始
  • 从项目总体功能框架明确开始
  • 因此与需求抽取和分析活动并行

1.2 ABSD方法的3个基础

• 功能的分解

在功能分解中， ABSD方法使用已有的基于模块的内聚和耦合技术

• 选择体系结构风格
• 软件模板的使用

2. 概念与术语

2.1 设计元素

• 最顶层：
  • 系统被分解为：
    • 概念子系统（若干）
    • 软件模板（一个或若干个）
• 第2层：
  • 概念子系统被分解：
    • 概念构件
    • 附加软件模板

2.2 视角与视图

• 要从不同的视角(Perspective) 来观察对架构的描述，如：
  • 展示功能组织的静态视角：判断质量特性
  • 展示并发行为的动态视角：判断系统行为特性
• 作用：全方位考虑体系结构设计

2.3 用例和质量场景

• 用例：
  • 系统为用户提供的一个能够产生结果的功能点
  • 作用：用来捕获功能需求
• 质量场景：
  • 概念：为捕获质量需求所定义的场景
    • 变更场景：捕获变更
    • 性能场景：捕获性能
    • 可靠性场景：捕获可靠性
    • 交互性场景：捕获交互性
  • 预期的和非预期的场景
    • 质量场景必须包含预期场景和非预期场景
    • 预期场景：是指系统在正常操作条件下应该能够正确处理和执行的场景
    • 非预期场景：是指系统在异常或意外情况下的场景

      非预期场景可能不会真正实现，但它们在决定设计的边界条件时很有用

3. ABSD模型

• 传统软件开发模型
  • 缺点：
    • 开发效率不高
    • 不能很好地支持软件重用
  • 软件体系结构的建立：位于需求分析之后，概要设计之前
• ABSD模型，把整个基于体系结构的软件过程划分为6个子过程
  • 体系结构需求、设计、文档化、复审、实现和演化

4. 体系结构需求

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

• 需求过程如下：

4.1 需求获取

• 体系结构需求获取的3个来源：
  • 系统的质量目标
  • 系统的商业目标
  • 系统开发人员的商业目标
• 体系结构需求获取过程：定义开发人员必须实现的软件功能
  • 满足业务上的功能需求
  • 满足质量属性的非功能需求

4.2 标识构件

• 目的：为系统生成初始逻辑结构，包含大致的构件
• 三个实现步骤 ：
  1. 生成类图
  2. 对类进行分组
     • 作用：简化类图结构
     • 分组原则：
       • 与其他类隔离的类
       • 由概括关联的类：即，通过继承关系相关联的类
       • 由聚合或合成关联的类
  3. 把类打包成构件

4.3 架构需求评审

• 评审小组
  • 组成：分析人员、客户、设计人员、测试人员
• 审查的内容
  • 所获取的需求是否真实地反映了用户的要求
  • 类的分组是否合理
  • 构件合并是否合理等

5. 体系结构设计

5.1 体系结构设计

• 是一个迭代过程
• 可以使用已有系统的设计过程

5.2 软件体系结构设计过程

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

   • 选择一个合适的体系结构风格
   • 产生：理想化的体系结构模型

2. 把已标识的构件映射到软件体系结构中

   • 产生：一个中间结构
     • 它只包含明确适合结构体模型的构件

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

   为把所有已标识的构件集成到体系结构中做准备

4. 产生软件体系结构

   • 对第2阶段中间结构精化

5. 设计评审

   • 人员：系统开发的外部人员对体系结构进行评审。

6. 体系结构文档化

• 文档化的意义：
  • 是系统设计与开发人员的通信媒介
  • 是执行预先分析的基础，旨在验证、提炼和修改体系结构设计

教材另一处对“为什么要文档化”的说明：
体系结构是抽象，由一些概念上的构件组成，要让系统分析员和程序员去实现体系结构，必须将体系结构进行文档化。

• 必须输出的文档：
  • 体系结构规格说明
  • 质量设计说明书
    • 作用：测试体系结构需求

7. 体系结构复审

• 复审人员：外部人员，如用户、领域专家
• 行为：搭建一个可运行的最小化系统
• 目的：标识潜在的风险，及早发现体系结构设计中的缺陷和错误

  如：

  • 体系结构能否满足需求
  • 质量需求是否在设计中得到体现
  • 层次是否清晰
  • 构件的划分是否合理
  • 文档表达是否明确
  • 构件的设计是否满足功能与性能的要求等。

8. 体系结构实现

• 概念：用实体来显示出一个软件体系结构
  • 符合体系结构所描述的结构性设计决策
  • 分割成规定的构件
  • 按规定方式互相交互
• 体系结构实现过程：如下图
  

9. 体系结构的演化

9.1 概述

• 需求的变动
  • 构件开发过程中，用户的需求可能还有变动
  • 软件运行后，由一个单位移植到另一个单位，需求也会发生变化
• 需求变动引起体系结构的修改

9.2 演化步骤

1. 需求变化归类
   • 使变化的需求与已有构件对应
   • 找不到对应构件的变动做好标记（等待创建新构建）
2. 制订体系结构演化计划
   • 作用：为后续演化开发工作的指南
3. 构建的变动：修改、增加或删除构件
4. 更新构件的相互作用
5. 构件组装与测试

测试：对组装后的系统整体功能和性能进行测试。

6. 技术评审
   • 评审内容：评审组装后的体系结构是否反映需求变动、符合用户需求
   • 如果不符合：在第2到第6步之间进行迭代

• 演化后的体系结构
  所有修改必须集成到原来的体系结构中，完成一次演化过程

---