ABSD（Architecture-Based Software Design，基于架构的软件设计）是架构驱动的方法，即由构成架构的商业需求、质量需求和功能需求的组合驱动。三个关键描述手段：
ABSD 的三个基础：① 功能的分解（使用基于模块的内聚和耦合技术）；② 通过选择架构风格来实现质量和商业需求；③ 软件模板的使用。ABSD 是自顶向下、递归细化的，迭代的每一步都有清晰定义，有助于降低架构设计的随意性。设计元素逐层分解：系统 → 概念子系统 + 软件模板 → 概念构件 + 附加软件模板。
| 子过程 | 核心内容 |
|---|---|
| ① 架构需求 | 三步：需求获取（三个来源：质量目标、系统的商业目标、系统开发人员的商业目标）→ 标识构件（三步：生成类图 → 对类分组〔隔离的类/概括关联的类/聚合或合成关联的类〕→ 把类打包成构件）→ 需求评审（审查需求是否真实反映用户要求、类的分组/构件合并是否合理） |
| ② 架构设计 | 迭代过程：提出架构模型（首要工作是选择合适的架构风格）→ 映射构件（产生只含明确适合构件的中间结构）→ 分析构件相互作用 → 产生架构 → 设计评审（必须邀请独立于系统开发的外部人员） |
| ③ 架构文档化 | 产出两个结果：体系结构规格说明 + 测试架构需求的质量设计说明书。文档是用户与开发者之间的协约、沟通媒介 |
| ④ 架构复审 | 主版本架构分析后，安排外部人员（用户代表和领域专家）参加复审；目的：标识潜在风险，及早发现设计缺陷和错误；必要时搭建可运行的最小化系统评估测试。设计、文档化、复审是迭代过程 |
| ⑤ 架构实现 | 以复审后的文档化架构说明书为基础：分析与设计 → 构件实现 → 构件组装 → 系统测试（单个构件的功能测试 + 组装后整体功能与性能测试） |
| ⑥ 架构演化 | 满足新需求的七步：需求变化归类 → 制定演化计划 → 构件变动 → 更新构件相互作用 → 构件组装与测试 → 技术评审 → 演化后的架构；不符合则第 2~6 步迭代 |